# Definições Definições Este whitepaper aborda a confiabilidade na nuvem, descrevendo as práticas recomendadas para estas quatro áreas: + Fundamentos + Arquitetura da workload + Gerenciamento de alterações + Gerenciamento de falhas Para obter confiabilidade, você deve começar com os fundamentos: um ambiente em que cotas de serviço e topologia de rede acomodam a workload. A arquitetura da workload do sistema distribuído deve ser projetada para evitar e mitigar falhas. A workload deve processar as alterações na demanda ou nos requisitos e ser projetada para detectar falhas e se reparar automaticamente. **Topics** + [ # Resiliência e os componentes da confiabilidade ](resiliency-and-the-components-of-reliability.md) + [ # Disponibilidade ](availability.md) + [ # Objetivos de recuperação de desastres (DR) ](disaster-recovery-dr-objectives.md) # Resiliência e os componentes da confiabilidade Resiliência e os componentes da confiabilidade A confiabilidade de uma workload na nuvem depende de vários fatores, o principal deles é a *Resiliência*: + **Resiliência** é a capacidade de uma workload se recuperar de interrupções na infraestrutura ou nos serviços, adquirir dinamicamente recursos de computação para atender à demanda e mitigar interrupções, como configurações incorretas ou problemas transitórios de rede. Os outros fatores que afetam a confiabilidade da workload são: + Excelência operacional, que inclui automação de alterações, uso de playbooks para responder a falhas e revisões de prontidão operacional (ORRs) para confirmar que as aplicações estão prontas para operações de produção. + Segurança, que inclui a prevenção de danos a dados ou infraestrutura de agentes mal-intencionados, o que pode afetar a disponibilidade. Por exemplo, criptografe backups para garantir que os dados estejam seguros. + Eficiência de performance, que inclui projetar para taxas máximas de solicitação e a minimização de latências para sua workload. + Otimização de custos, que inclui compensações, como se você deseja gastar mais em instâncias do EC2 para alcançar ajuste de escala automático ou confiar no ajuste de escala automático quando mais capacidade for necessária. A resiliência é o foco principal deste whitepaper. Os outros quatro fatores também são importantes e são cobertos por seus respectivos pilares do [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/). Muitas das práticas recomendadas aqui também resolvem esses aspectos da confiabilidade, mas o foco está na resiliência. # Disponibilidade Disponibilidade A *Disponibilidade* (também conhecida como *disponibilidade de serviços*) é uma métrica comumente usada para medir quantitativamente a resiliência, bem como um objetivo de resiliência alvo. + A **disponibilidade** é a porcentagem de tempo durante a qual uma workload está disponível para uso. *Disponível para uso* significa que ela executa a função combinada quando necessário. Esse percentual é calculado em períodos como um mês, um ano ou os últimos três anos. Aplicando a interpretação mais estrita possível, a disponibilidade diminui sempre que a aplicação não está operando normalmente, incluindo interrupções agendadas e não agendadas. Definimos *disponibilidade* da seguinte forma: ![\[\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/reliability-pillar/images/availability-formula.png) + A disponibilidade é um percentual do tempo de atividade (como 99,9%) em um período (geralmente de um mês ou de um ano). + Uma forma comum de abreviar essas informações é mencionar apenas o “número de noves”. Por exemplo, “cinco noves” significa 99,999% disponível. + Alguns clientes preferem excluir o tempo de inatividade agendado do serviço (por exemplo, manutenção planejada) do *tempo total* na fórmula. No entanto, isso não é recomendado, uma vez que os usuários podem preferir usar o serviço durante essas horas. Veja a seguir uma tabela das metas de design de disponibilidade de aplicação comuns e a máxima duração das interrupções que podem ocorrer em um ano sem que a meta deixe de ser atingida. A tabela contém exemplos dos tipos de aplicações comuns em cada nível de disponibilidade. Neste documento, vamos nos referir a esses valores. | Disponibilidade | Indisponibilidade máxima (por ano) | Categorias de aplicações | | --- | --- | --- | | 99% | 3 dias e 15 horas | Tarefas de processamento em lote e de extração, transferência e carregamento de dados | | 99,9% | 8 horas e 45 minutos | Ferramentas internas como gerenciamento de conhecimento e rastreamento de projetos | | 99,95% | 4 horas e 22 minutos | Comércio online, ponto de vendas | | 99,99% | 52 minutos | Workloads de entrega e broadcast de vídeo | | 99,999% | 5 minutos | Workloads de transações em caixas eletrônicos, telecomunicações | **Medição da disponibilidade com base nas solicitações.** Para seu serviço, talvez seja mais fácil contar as solicitações bem-sucedidas e com falha, em vez do "tempo disponível para uso". Nesse caso, o seguinte cálculo pode ser usado: ![\[Mathematical formula for calculating availability using successful responses divided by valid requests.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/reliability-pillar/images/availability-formula-requests.png) Isso é medido com frequência para períodos de um minuto ou de cinco minutos. Então, um percentual de tempo ativo mensal (medição da disponibilidade baseada em tempo) pode ser calculado da média desses períodos. Se nenhuma solicitação for recebida em determinado período, ela será contada como 100% disponível nesse período. **Cálculo de disponibilidade com dependências rígidas.** Muitos sistemas têm dependências rígidas de outros sistemas, onde uma interrupção de um sistema dependente leva diretamente a uma interrupção do sistema que o invocou. Isso é o oposto de uma dependência flexível, em que uma falha do sistema dependente é compensada na aplicação. Quando ocorrem essas dependências rígidas, a disponibilidade do sistema invocador é o produto das disponibilidades dos sistemas dependentes. Por exemplo, se você tiver um sistema projetado para uma disponibilidade de 99,99% que tenha uma dependência rígida de outros dois sistemas independentes, cada um projetado para uma disponibilidade de 99,99%, a workload teoricamente poderá atingir uma disponibilidade de 99,97%: Availinvok × Avail*dep1* × Avail*dep2* = Availworkload 99,99% × 99,99% × 99,99% = 99,97% Portanto, é importante entender suas dependências e as respectivas metas de design de disponibilidade ao calcular as suas próprias. **Cálculo de disponibilidade com componentes redundantes.** Quando um sistema envolve o uso de componentes independentes e redundantes (por exemplo, recursos redundantes em diferentes zonas de disponibilidade), a disponibilidade teórica é calculada como 100% menos o produto das taxas de falha dos componentes. Por exemplo, se um sistema usar dois componentes independentes, cada um com uma disponibilidade de 99,9%, a disponibilidade efetiva dessa dependência será 99,9999%: ![\[Diagram showing calculation of availability with redundant components in a system.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/reliability-pillar/images/image2.png) Availeffective = *Avail*MAX − ((100%−Availdependency)×(100%−Availdependency)) 99,9999% = 100% − (0,1%×0,1%) *Cálculo com atalho*: se as disponibilidades de todos os componentes em seu cálculo consistirem apenas no dígito nove, você poderá somar a contagem do número de nove dígitos para obter a resposta. No exemplo acima, dois componentes independentes e redundantes com disponibilidade de três noves resultam em seis noves. **Cálculo da disponibilidade da dependência.** Algumas dependências fornecem orientações sobre a disponibilidade delas, incluindo metas de design da disponibilidade para muitos serviços da AWS. Porém, em casos em que isso não está disponível (por exemplo, um componente em que o fabricante não publica informações de disponibilidade), uma maneira de estimar é determinar o **tempo médio entre falhas (MTBF)** e o **tempo médio para recuperação (MTTR)**. É possível estabelecer a estimativa de disponibilidade da seguinte maneira: ![\[\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/reliability-pillar/images/avail-est-formula.png) Por exemplo, se o MTBF for 150 dias e o MTTR for 1 hora, a estimativa de disponibilidade será 99,97%. Para obter detalhes adicionais, consulte [Disponibilidade e além: como entender e melhorar a resiliência de sistemas distribuídos na AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-and-beyond-improving-resilience.html) para obter ajuda para calcular sua disponibilidade. **Custos para a disponibilidade.** Desenvolver aplicações para níveis mais altos de disponibilidade costuma resultar em mais custos. Assim, é importante identificar as verdadeiras necessidades de disponibilidade antes de iniciar o design da aplicação. Altos níveis de disponibilidade impõem exigências maiores para teste e validação sob cenários de falha exaustivos. Eles exigem automação para recuperação de todos os tipos de falhas e exigem que todos os aspectos das operações do sistema sejam criados e testados de modo similar conforme os mesmos padrões. Por exemplo, as ações de adicionar ou remover capacidade, implantar ou reverter software atualizado ou alterações de configuração ou migrar dados do sistema devem ser feitas conforme a meta de disponibilidade desejada. Contribuindo com os custos de desenvolvimento de software, em níveis muito altos de disponibilidade, a inovação é prejudicada devido à necessidade de avançar mais lentamente na implantação dos sistemas. Assim, a orientação é ter cautela ao aplicar os padrões e considerar o objetivo de disponibilidade adequado para todo o ciclo de vida de operação do sistema. A seleção de dependências também contribui para o aumento dos custos em sistemas que operam com metas de design de disponibilidade maiores. Com esses objetivos maiores, o conjunto de software ou serviços que podem ser escolhidos como dependências diminui com base em quais receberam os investimentos elevados descritos anteriormente. Conforme a meta de design de disponibilidade aumenta, é comum encontrar menos serviços multiuso (como um banco de dados relacional) e mais serviços direcionados a uma finalidade específica. Isso acontece porque estes são mais fáceis de avaliar, testar e automatizar e têm menos potencial de interações inesperadas com funcionalidade incluída, mas não utilizada. # Objetivos de recuperação de desastres (DR) Além dos objetivos de disponibilidade, a estratégia de resiliência também deve incluir objetivos de recuperação de desastres (DR) baseados em estratégias para recuperar a workload em caso de um desastre. A recuperação de desastres se concentra em objetivos de recuperação de uma única vez em resposta a desastres naturais, a falhas técnicas em grande escala ou a ameaças humanas, como ataques ou erros. Isso difere da disponibilidade que mede a resiliência por um período em resposta a falhas de componentes, a picos de carga ou a erros de software. **Objetivo de tempo de recuperação (RTO)** definido pela organização. O RTO é o atraso máximo aceitável entre a interrupção e a restauração do serviço. Ele determina o que é considerado uma janela de tempo aceitável quando o serviço não está disponível. **Objetivo de ponto de recuperação (RPO)** definido pela organização. O RPO é o período máximo de tempo aceitável desde o último ponto de recuperação de dados. Isso determina o que é considerado uma perda aceitável de dados entre o último ponto de recuperação e a interrupção do serviço. ![\[Business continuity timeline showing RPO, disaster event, and RTO with data loss and downtime periods.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/reliability-pillar/images/business-continuity.png) *A relação do objetivo de ponto de recuperação (RPO), objetivo do tempo de recuperação (RTO) e o evento de desastre.* O RTO é semelhante ao MTTR, pois ambos medem o tempo entre o início de uma interrupção e a recuperação da workload. No entanto, o MTTR é um valor médio assumido em vários eventos que afetam a disponibilidade ao longo de um período, enquanto RTO é um destino, ou valor máximo permitido, para um *único* evento que afeta a disponibilidade.