# Confiabilidade O pilar Confiabilidade abrange a capacidade de uma workload de executar a função pretendida correta e consistentemente quando esperado. Isso inclui a capacidade de operar e testar a workload durante todo o ciclo de vida dela. Este documento fornece orientações detalhadas sobre as práticas recomendadas para a implementação de workloads confiáveis na AWS. O pilar Confiabilidade apresenta uma visão geral de princípios de design, práticas recomendadas e perguntas. Recomendações sobre implementação estão disponíveis no [whitepaper Pilar Confiabilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html?ref=wellarchitected-wp). **Topics** + [Princípios de design](rel-dp.md) + [Definição](rel-def.md) + [Práticas recomendadas](rel-bp.md) + [Recursos](rel-resources.md) # Princípios de design Existem cinco princípios de design para confiabilidade na nuvem: + **Recuperar de falhas automaticamente:** ao monitorar os indicadores-chave de performance (KPIs) de uma workload, você pode acionar a automação quando um limite é violado. Esses KPIs devem ser uma medida do valor comercial, e não dos aspectos técnicos da operação do serviço. Isso possibilita a notificação automática e o rastreamento de falhas, além de processos de recuperação automatizados que solucionam ou reparam a falha. Com uma automação mais sofisticada, é possível antecipar e corrigir falhas antes que elas ocorram. + **Teste os procedimentos de recuperação:** em um ambiente on-premises, muitas vezes os testes são realizados para provar que a workload funciona em um cenário específico. Normalmente, o teste não é usado para validar estratégias de recuperação. Na nuvem, você pode testar o comportamento de falha da workload e validar os procedimentos de recuperação. É possível usar a automação para simular falhas diferentes ou para recriar cenários que levaram a falhas no passado. Essa abordagem expõe caminhos de falha que você pode testar e corrigir antes que um cenário de falha real ocorra, reduzindo assim o risco. + **Escale horizontalmente para aumentar a disponibilidade agregada da workload:** substitua um recurso grande por vários recursos pequenos para reduzir o impacto de uma única falha na workload geral. Distribua as solicitações por vários recursos menores para garantir que elas não compartilhem um ponto de falha comum. + **Pare de tentar adivinhar a capacidade:** uma causa comum de falha nas workloads on-premises é a saturação de recursos, quando as demandas impostas a uma workload excedem a respectiva capacidade (esse muitas vezes é o objetivo dos ataques de negação de serviço). Na nuvem, você pode monitorar a demanda e a utilização da workload e automatizar a adição ou a remoção de recursos para manter o nível mais eficiente e atender à demanda, sem provisionamento excessivo ou subprovisionamento. Ainda há limites, mas algumas cotas podem ser controladas e outras podem ser gerenciadas. Consulte Gerenciar cotas de serviço e restrições. + **Gerencie alterações na automação:** as alterações em sua infraestrutura devem ser feitas por meio de automação. Entre aquelas que devem ser gerenciadas estão as alterações na automação, que podem ser acompanhadas e analisadas. # Definição Existem quatro áreas de práticas recomendadas para confiabilidade na nuvem: + Fundamentos + Arquitetura da workload + Gerenciamento de alterações + Gerenciamento de falhas Para atingir a confiabilidade, você deve começar com as bases: um ambiente em que as cotas de serviço e a 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. # Práticas recomendadas **Topics** + [Fundamentos](rel-found.md) + [Arquitetura da workload](rel-workload-arch.md) + [Gerenciamento de alterações](rel-chg-mgmt.md) + [Gerenciamento de falhas](rel-failmgmt.md) # Fundamentos Os requisitos fundamentais são aqueles que têm um escopo que vai além de uma única workload ou projeto. Antes de criar a arquitetura de um sistema, é necessário instaurar os requisitos fundamentais que influenciam a confiabilidade. Por exemplo, você deve ter largura de banda de rede suficiente no data center. Com a AWS, a maioria desses requisitos fundamentais já está incorporada ou pode ser tratada conforme necessário. A nuvem foi projetada para ser praticamente ilimitada, portanto, é responsabilidade da AWS atender ao requisito de capacidade suficiente de rede e de computação, permitindo que você altere o tamanho e as alocações de recursos sob demanda. As perguntas a seguir referem-se a essas considerações sobre confiabilidade. (Para obter uma lista de perguntas e práticas recomendadas de confiabilidade, consulte o [Apêndice](a-reliability.md).) | REL 1: Como gerenciar as cotas e restrições de serviço? | | --- | | Para arquiteturas de workload baseadas na nuvem, existem cotas de serviço (que também são chamadas de limites de serviço). Essas cotas existem para evitar o provisionamento acidental de mais recursos do que você precisa e para limitar as taxas de solicitação nas operações de API, a fim de proteger os serviços contra uso abusivo. Também há restrições de recursos, por exemplo, a taxa em que você pode propagar bits por um cabo de fibra óptica ou a quantidade de armazenamento em um disco físico. | | REL 2: Como planejar a topologia de rede? | | --- | | Geralmente, existem workloads em vários ambientes. Isso inclui vários ambientes de nuvem (acessíveis ao público e privados) e, possivelmente, a infraestrutura de datacenter existente. Os planos devem incluir considerações de rede, como conectividade intra e entre sistemas, gerenciamento de endereços IP públicos, gerenciamento de endereços IP privados e resolução de nomes de domínio. | # Arquitetura da workload Uma workload confiável começa com as decisões iniciais de projeto que envolvem tanto o software quanto a infraestrutura. Suas decisões de arquitetura afetarão o comportamento da workload em todos os pilares do Well-Architected. Para atingir a confiabilidade, há padrões específicos que devem ser seguidos. Com a AWS, os desenvolvedores de workload podem usar suas linguagens e tecnologias preferidas. AWS Os SDKs eliminam a complexidade da codificação por meio de APIs específicas à linguagem para os serviços da AWS. Esses SDKs e a possibilidade de escolher a linguagem permitem que os desenvolvedores implementem as práticas recomendadas de confiabilidade apresentadas neste documento. Os desenvolvedores também podem ler e descobrir como a Amazon cria e opera softwares na [Amazon Builders' Library](https://aws.amazon.com/builders-library/?ref=wellarchitected-wp). As perguntas a seguir referem-se a essas considerações sobre confiabilidade. | REL 3: Como projetar sua arquitetura de serviços de workload? | | --- | | Use uma arquitetura orientada a serviços (SOA) ou uma arquitetura de microsserviços para criar workloads altamente escaláveis e confiáveis. A arquitetura orientada a serviços (SOA) é a prática de tornar componentes de software reutilizáveis por meio de interfaces de serviço. A arquitetura de microsserviços vai além para tornar os componentes menores e mais simples. | | REL 4: Como projetar interações em um sistema distribuído para evitar falhas? | | --- | | Os sistemas distribuídos dependem de redes de comunicação para interconectar componentes, como servidores ou serviços. A workload deve operar de forma confiável, apesar da perda de dados ou da latência nessas redes. Os componentes do sistema distribuído devem operar de uma maneira que não afete negativamente outros componentes ou a workload. Essas práticas recomendadas evitam falhas e melhoram o tempo médio entre falhas (MTBF). | | REL 5: Como projetar interações em um sistema distribuído para mitigar ou resistir a falhas? | | --- | | Os sistemas distribuídos dependem de redes de comunicação para interconectar componentes (como servidores ou serviços). Sua workload deve operar de forma confiável, apesar da perda de dados ou da latência nessas redes. Os componentes do sistema distribuído devem operar de uma maneira que não afete negativamente outros componentes ou a workload. Essas práticas recomendadas permitem que as workloads resistam a tensões ou falhas, recuperem-se mais rapidamente delas e reduzam o impacto de tais prejuízos. Como resultado, o tempo médio para recuperação (MTTR) é melhorado. | # Gerenciamento de alterações As alterações na workload ou no respectivo ambiente devem ser previstas e acomodadas para alcançar uma operação confiável da workload. As alterações incluem aquelas impostas à sua workload, como picos na demanda, bem como as internas, como implantações de recursos e patches de segurança. Ao usar a AWS, você pode monitorar o comportamento de uma workload e automatizar a resposta aos KPIs. Por exemplo, a workload pode adicionar outros servidores à medida que recebe mais usuários. É possível controlar quem tem permissão para fazer alterações na workload e realizar auditorias no histórico dessas alterações. As perguntas a seguir referem-se a essas considerações sobre confiabilidade. | REL 6:  Como monitorar recursos de workload? | | --- | | Logs e métricas são ferramentas avançadas para obter informações sobre a integridade da workload. Você pode configurar a workload para monitorar logs e métricas e enviar notificações quando os limites forem ultrapassados ou ocorrerem eventos significativos. O monitoramento permite que sua workload reconheça quando os limites de baixa performance são ultrapassados ou quando há falhas para que ela possa se recuperar automaticamente em resposta. | | REL 7:  Como projetar sua workload para se adaptar às mudanças na demanda? | | --- | | Uma workload escalável fornece elasticidade para adicionar ou remover recursos automaticamente, de modo que eles correspondam perfeitamente à demanda atual em determinado momento. | | REL 8:  Como implementar uma alteração? | | --- | | As alterações controladas são necessárias para implantar novas funcionalidades e garantir que as workloads e o ambiente operacional executem softwares conhecidos e possam ser corrigidos ou substituídos de maneira previsível. Se essas alterações não forem controladas, será difícil prever o efeito dessas alterações ou resolver os problemas que surgem por causa delas. | Quando você cria a arquitetura de uma workload para adicionar e remover recursos automaticamente em resposta às alterações na demanda, isso não apenas aumenta a confiabilidade, mas também garante que o sucesso nos negócios não se torne um fardo. Com o monitoramento implantado, sua equipe será automaticamente alertada quando os KPIs se desviarem das normas esperadas. O log automático de alterações em seu ambiente permite realizar auditorias e identificar rapidamente as ações que podem ter afetado a confiabilidade. Os controles de gerenciamento de alterações garantem que você possa impor as regras que oferecem a confiabilidade necessária. # Gerenciamento de falhas Em qualquer sistema de complexidade razoável, espera-se que ocorram falhas. A confiabilidade exige que sua workload reconheça as falhas no momento em que elas ocorrem e tome medidas para evitar que elas prejudiquem a disponibilidade. As workloads devem ser capazes de resistir a falhas e reparar problemas automaticamente. Com a AWS, você pode aproveitar a automação para reagir aos dados de monitoramento. Por exemplo, quando uma métrica específica ultrapassa um limite, você pode iniciar uma ação automatizada para solucionar o problema. Além disso, em vez de tentar diagnosticar e corrigir um recurso com falha que faz parte do seu ambiente de produção, você pode substituí-lo por um novo e executar a análise do recurso com falha fora de banda. Como a nuvem permite que você suporte versões temporárias de um sistema inteiro a baixo custo, é possível usar testes automatizados para verificar os processos de recuperação completos. As perguntas a seguir referem-se a essas considerações sobre confiabilidade. | REL 9: Como fazer backup dos dados? | | --- | | Faça backup de dados, aplicações e configurações para atender às suas necessidades de objetivos de tempo de recuperação (RTO) e objetivos de ponto de recuperação (RPO). | | REL 10: Como usar o isolamento de falhas para proteger sua workload? | | --- | | O isolamento de falhas limita o impacto de uma falha de componente ou do sistema a um limite definido. Com o isolamento adequado, os componentes fora do limite não são afetados pela falha. Executar a workload em vários limites de isolamento de falhas pode torná-la mais resistente a falhas. | | REL 11: Como projetar a workload para resistir a falhas de componentes? | | --- | | As workloads que exigem alta disponibilidade e baixo tempo médio até a recuperação (MTTR) devem ser projetadas visando a resiliência. | | REL 12: Como testar a confiabilidade? | | --- | | Depois de projetar a workload para resiliência à pressão da produção, o teste é a única maneira de garantir que ela opere conforme projetado e com a resiliência esperada. | | REL 13: Como planejar a recuperação de desastres (DR)? | | --- | | Implementar backups e componentes redundantes de workload é o ponto de partida da sua estratégia de DR. O [RTO e o RPO são os objetivos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) para restaurar a workload. Defina-os de acordo com suas necessidades de negócios. Implemente uma estratégia para atender a esses objetivos, considerando os locais e a função dos recursos e dos dados da workload. A probabilidade de interrupção e o custo de recuperação também são fatores principais que ajudam a determinar o valor empresarial de fornecer a recuperação de desastres para uma workload. | Regularmente, faça backup dos dados e teste os arquivos de backup para garantir a capacidade de recuperação de erros tanto físicos quanto lógicos. Para gerenciar falhas, é essencial testar as workloads com frequência e de maneira automatizada por meio da indução de falhas e da observação do processo de recuperação. Faça isso periodicamente e também após alterações significativas na workload. Acompanhe ativamente os KPIs, como objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO), para avaliar a resiliência de uma workload, principalmente em cenários de teste de falhas. O rastreamento dos KPIs ajudará você a identificar e mitigar os pontos únicos de falha. O objetivo é testar integralmente os processos de recuperação da workload para ter certeza de que é possível recuperar todos os seus dados e continuar a atender os clientes, mesmo diante de problemas contínuos. Seus processos de recuperação devem ser tão bem trabalhados quanto os processos de produção normais. # Recursos Consulte os recursos a seguir para saber mais sobre nossas práticas recomendadas para Confiabilidade. ## Documentação + [Documentação do AWS](https://docs.aws.amazon.com/index.html?ref=wellarchitected-wp) + [Infraestrutura global da AWS](https://aws.amazon.com/about-aws/global-infrastructure?ref=wellarchitected-wp) + [AWS Auto Scaling: como os planos de ajuste de escala funcionam](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html?ref=wellarchitected-wp) + [O que é o AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html?ref=wellarchitected-wp) ## Whitepaper + [Pilar Confiabilidade: AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html?ref=wellarchitected-wp) + [Implementar microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html?ref=wellarchitected-wp)