# REL 11 Como você projeta sua carga de trabalho para resistir a falhas de componentes?
As cargas de trabalho que exigem alta disponibilidade e baixo Tempo médio até a recuperação (MTTR) devem ser projetadas visando a resiliência.
**Topics**
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP02 Failover para recursos íntegros](rel_withstand_component_failures_failover2good.md)
+ [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md)
+ [REL11-BP04 Confiar no plano de dados e não no ambiente de gerenciamento durante a recuperação](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP05 Usar a estabilidade estática para evitar o comportamento bimodal](rel_withstand_component_failures_static_stability.md)
+ [REL11-BP06 Enviar notificações quando os eventos afetarem a disponibilidade](rel_withstand_component_failures_notifications_sent_system.md)
# REL11-BP01 Monitorar todos os componentes da workload para detectar falhas
Monitore constantemente a integridade da workload para que você e seus sistemas automatizados detectem degradações ou falhas assim que elas ocorrerem. Monitore os Key Performance Indicators (KPIs – Indicadores-chave de performance) com base no valor empresarial.
Todos os mecanismos de reparo e recuperação devem começar com a capacidade de detectar problemas rapidamente. As falhas técnicas devem ser detectadas primeiro para que possam ser resolvidas. No entanto, a disponibilidade é baseada na capacidade da workload em entregar valor empresarial, portanto, os indicadores-chave de performance (KPIs) que medem isso precisam fazer parte da sua estratégia de detecção e remediação.
**Antipadrões comuns:**
+ Nenhum alarme foi configurado, portanto as interrupções ocorrem sem notificação.
+ Os alarmes existem, mas com limites que não permitem um tempo adequado para reação.
+ As métricas não são coletadas com frequência suficiente para atender ao Recovery Time Objective (RTO – Objetivo do tempo de recuperação).
+ Dentre os níveis da carga de trabalho, somente aquele voltado ao cliente é monitorado ativamente.
+ Coleta apenas das métricas técnicas, não das métricas de função de negócios.
+ Não há métricas que medem a experiência do usuário da carga de trabalho.
**Benefícios do estabelecimento dessa prática recomendada:** O monitoramento adequado de todas as camadas reduz o tempo de detecção e, assim, permite reduzir o tempo de recuperação.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Determine o intervalo de coleta dos componentes com base nas suas metas de recuperação.
+ O intervalo de monitoramento depende da rapidez com que você precisa fazer a recuperação. O tempo de recuperação é determinado pelo tempo necessário para a recuperação. Desse modo, você deve considerar esse tempo e o RTO para determinar a frequência da coleta.
+ Configure o monitoramento detalhado dos componentes.
+ Determine se o monitoramento detalhado das instâncias do EC2 e do Auto Scaling é necessário. O monitoramento detalhado fornece métricas de intervalo de 1 minuto, e o monitoramento padrão fornece métricas de intervalo de 5 minutos.
+ [Habilitar ou desabilitar o monitoramento detalhado de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Monitoramento de grupos do Auto Scaling e instâncias usando o Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ Determine se o monitoramento avançado para RDS é necessário. O monitoramento avançado usa um agente nas instâncias do RDS para obter informações úteis sobre processos ou threads diferentes em uma instância do RDS.
+ [Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ Crie métricas personalizadas para medir os indicadores-chave de performance (KPIs) de negócios. As cargas de trabalho implementam as principais funções de negócios. Essas funções devem ser usadas como KPIs que ajudam a identificar quando ocorre um problema indireto.
+ [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Use os canários de usuário para monitorar falhas na experiência do usuário. O teste de transações sintéticas (também conhecido como teste canário, que não deve ser confundido com as implantações canário) que pode executar e simular o comportamento do cliente está entre os processos de teste mais importantes. Execute esses testes constantemente nos endpoints da carga de trabalho de diversos locais remotos.
+ [O Amazon CloudWatch Synthetics permite criar canários de usuário](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ Crie métricas personalizadas que acompanham a experiência do usuário. Se você puder estabelecer instrumentos de medição da experiência do cliente, conseguirá determinar o momento de degradação da experiência do consumidor.
+ [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Defina alarmes para detectar quando uma parte da carga de trabalho não estiver funcionando corretamente e indicar quando deve ser feita a escalabilidade automática dos recursos. É possível exibir os alarmes em painéis, enviar alertas pelo Amazon SNS ou por e-mail e trabalhar com o Auto Scaling para aumentar ou reduzir a escala verticalmente dos recursos de uma workload.
+ [Uso de alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ Crie painéis para visualizar as métricas. É possível usar os painéis para ver as tendências, os casos atípicos e outros indicadores de possíveis problemas ou para obter uma indicação de problemas a serem investigados.
+ [Uso de painéis do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
## Recursos
**Documentos relacionados:**
+ [O Amazon CloudWatch Synthetics permite criar canários de usuário](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Habilitar ou desabilitar o monitoramento detalhado de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ [Monitoramento de grupos do Auto Scaling e instâncias usando o Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Uso de alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Uso de painéis do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**Exemplos relacionados:**
+ [Laboratório do Well-Architected: nível 300: implementação de verificações de integridade e do gerenciamento de dependências para melhorar a confiabilidade](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP02 Failover para recursos íntegros
Verifique se, caso ocorra uma falha de recurso, os recursos íntegros podem continuar atendendo às solicitações. Para falhas de localização (como zona de disponibilidade ou Região da AWS), garanta que você tenha sistemas implementados para executar failover para recursos íntegros em locais sem problemas.
Os serviços da AWS, como o Elastic Load Balancing e o AWS Auto Scaling, ajudam a distribuir carga entre recursos e zonas de disponibilidade. Portanto, a falha de um recurso individual (como uma instância do EC2) ou o comprometimento de uma zona de disponibilidade podem ser atenuados desviando o tráfego para os recursos íntegros restantes. Para as cargas de trabalho multirregionais, o procedimento é mais complicado. Por exemplo, réplicas de leitura entre as regiões permitem implantar os dados em várias Regiões da AWS, mas você ainda deve promover a réplica de leitura a primária e apontar o tráfego para ela em caso de failover. O Amazon Route 53 e o AWS Global Accelerator ajudam a rotear o tráfego entre Regiões da AWS.
Se a workload estiver usando serviços da AWS, como o Amazon S3 ou o Amazon DynamoDB, ela será implantada automaticamente em várias zonas de disponibilidade. Em caso de falha, o ambiente de gerenciamento da AWS roteia automaticamente o tráfego para locais íntegros. Os dados são armazenados de forma redundante em várias zonas de disponibilidade e permanecem disponíveis. Para o Amazon RDS, você deve escolher multi-AZ como opção de configuração e, em caso de falha, a AWS direcionará automaticamente o tráfego para a instância íntegra. Para instâncias do Amazon EC2, tarefas do Amazon ECS ou pods do Amazon EKS, você escolhe em quais zonas de disponibilidade implantar. Em seguida, o Elastic Load Balancing fornece a solução para detectar instâncias em zonas com problemas de integridade e rotear o tráfego para as zonas íntegras. O Elastic Load Balancing pode até mesmo rotear o tráfego para componentes no seu datacenter on-premises.
Para abordagens multirregionais (que também podem incluir datacenters on-premises), o Amazon Route 53 oferece uma maneira de definir domínios da Internet e de atribuir políticas de roteamento que podem incluir verificações de integridade para garantir que o tráfego seja roteado para regiões íntegras. Como alternativa, o AWS Global Accelerator fornece endereços IP estáticos que atuam como um ponto de entrada fixo para a aplicação e, em seguida, roteia para endpoints nas Regiões da AWS de sua escolha, usando a rede global da AWS em vez da Internet para obter melhor performance e confiabilidade.
A AWS aborda o design dos nossos serviços pensando na recuperação de falha. Projetamos os serviços para minimizar o tempo para recuperação de falhas e o impacto sobre os dados. Nossos serviços usam principalmente repositórios de dados que reconhecem solicitações apenas após serem armazenadas de modo durável entre várias réplicas em uma região. Esses serviços e recursos incluem o Amazon Aurora, instâncias de banco de dados multi-AZ doAmazon Relational Database Service (Amazon RDS), o Amazon S3, o Amazon DynamoDB, o Amazon Simple Queue Service (Amazon SQS) e o Amazon Elastic File System (Amazon EFS). Eles são criados para usar isolamento com base em células e usar o isolamento de falhas fornecido por Zonas de disponibilidade. Usamos automação amplamente em nossos procedimentos operacionais. Também otimizamos nossa funcionalidade de substituir e reiniciar para a recuperação rápida de interrupções.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Faça failover para recursos íntegros. Verifique se, caso ocorra uma falha de recurso, os recursos íntegros podem continuar atendendo às solicitações. Para falhas de localização (como zona de disponibilidade ou Região da AWS), garanta que você tenha sistemas implementados para executar failover para recursos íntegros em locais sem problemas.
+ Se a workload estiver usando serviços da AWS, como o Amazon S3 ou o Amazon DynamoDB, ela será implantada automaticamente em várias zonas de disponibilidade. Em caso de falha, o ambiente de gerenciamento da AWS roteia automaticamente o tráfego para locais íntegros.
+ Para o Amazon RDS, você deve escolher multi-AZ como opção de configuração e, em caso de falha, a AWS direcionará automaticamente o tráfego para a instância íntegra.
+ [Alta disponibilidade (multi-AZ) para o Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ Para instâncias do Amazon EC2 ou tarefas do Amazon ECS, você escolhe em quais Zonas de disponibilidade implantar. Em seguida, o Elastic Load Balancing fornece a solução para detectar instâncias em zonas com problemas de integridade e rotear o tráfego para as zonas íntegras. O Elastic Load Balancing pode até mesmo rotear o tráfego para componentes no seu datacenter on-premises.
+ Para abordagens em várias regiões (que também podem incluir datacenters on-premises), certifique-se de que os dados e os recursos de locais íntegros possam continuar atendendo a solicitações
+ Por exemplo, réplicas de leitura entre as regiões permitem implantar os dados em várias Regiões da AWS, mas você ainda deve promover a réplica de leitura a primária e apontar o tráfego para ela em caso de falha no local primário.
+ [Visão geral das réplicas de leitura do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ O Amazon Route 53 oferece uma maneira de definir domínios da Internet e de atribuir políticas de roteamento que podem incluir verificações de integridade para garantir que o tráfego seja roteado para regiões íntegras. Como alternativa, o AWS Global Accelerator fornece endereços IP estáticos que atuam como um ponto de entrada fixo para a aplicação e, em seguida, roteia para endpoints nas Regiões da AWS de sua escolha, usando a rede global da AWS em vez da Internet pública para obter melhor performance e confiabilidade.
+ [Amazon Route 53: escolher uma política de roteamento](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [O que é o AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
## Recursos
**Documentos relacionados:**
+ [Parceiro da APN: parceiros que podem ajudar na automação da sua tolerância a falhas](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: produtos que podem ser usados para tolerância a falhas](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: como usar a autorreparação para substituir instâncias com falha](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Amazon Route 53: escolher uma política de roteamento](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Alta disponibilidade (multi-AZ) para o Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ [Visão geral das réplicas de leitura do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ [Estratégias de posicionamento de tarefas do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Criação de grupos de Auto Scaling do Kubernetes para várias zonas de disponibilidade](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/)
+ [O que é o AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
**Exemplos relacionados:**
+ [Laboratório do Well-Architected: nível 300: implementação de verificações de integridade e do gerenciamento de dependências para melhorar a confiabilidade](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP03 Automatizar a reparação em todas as camadas
Após a detecção de uma falha, use recursos automatizados para executar ações de correção.
*Capacidade de reiniciar* é uma ferramenta importante para corrigir falhas. Como discutido anteriormente para sistemas distribuídos, uma melhor prática é tornar os serviços sem estado sempre que possível. Isso evita a perda de dados ou a disponibilidade na reinicialização. Na nuvem, você pode (e geralmente deve) substituir todo o recurso (por exemplo, instância do EC2 ou função do Lambda) como parte da reinicialização. A reinicialização em si é uma maneira simples e confiável de se recuperar de falhas. Muitos tipos diferentes de falhas ocorrem em cargas de trabalho. As falhas podem ocorrer em hardware, software, comunicações e operações. Em vez de criar mecanismos novos para capturar, identificar e corrigir cada um dos diferentes tipos de falhas, mapeie várias categorias diferentes de falhas para a mesma estratégia de recuperação. Uma instância pode falhar devido a uma falha de hardware, um bug no sistema operacional, vazamento de memória ou outras causas. Em vez de criar uma correção personalizada para cada situação, trate qualquer uma delas como uma falha de instância. Encerre a instância e permita que o AWS Auto Scaling a substitua. Posteriormente, você pode executar a análise do recurso com falha fora de banda.
Outro exemplo é a capacidade de reiniciar uma solicitação de rede. Aplique a mesma abordagem de recuperação tanto a um tempo limite de rede quanto a uma falha de dependência em que a dependência retorna um erro. Ambos os eventos têm um efeito similar sobre o sistema, assim, em vez de tentar tornar qualquer um dos eventos um “caso especial”, aplique uma estratégia similar de nova tentativa limitada com recuo e variação exponenciais.
*Capacidade de reiniciar* é um mecanismo de recuperação destacado em computação orientada à recuperação (ROC) e arquiteturas de cluster de alta disponibilidade.
É possível usar o Amazon EventBridge para monitorar e filtrar eventos, como alarmes do CloudWatch ou alterações no estado de outros serviços da AWS. Com base nas informações do evento, ele pode acionar o AWS Lambda, o AWS Systems Manager Automation ou outros destinos para executar a lógica de correção personalizada na workload.
O Amazon EC2 Auto Scaling pode ser configurado para verificar a integridade da instâncias do EC2. Se a instância estiver em qualquer estado que não seja em execução, ou se o status do sistema for prejudicado, o Amazon EC2 Auto Scaling considerará que essa instância não é íntegra e executará uma instância de substituição. Se estiver usando o AWS OpsWorks, você poderá configurar a autorreparação das instâncias do EC2 no nível da camada do OpsWorks.
Para substituições em grande escala (como a perda de uma Zona de disponibilidade inteira), a estabilidade estática é preferida para alta disponibilidade, em vez de tentar obter vários novos recursos de uma só vez.
**Antipadrões comuns:**
+ Implantação de aplicações em instâncias ou contêineres individualmente.
+ Implantação de aplicações que não podem ser implantadas em vários locais sem usar a recuperação automática.
+ Reparação manual de aplicações que não são reparadas por meio da escalabilidade e recuperação automáticas.
**Benefícios do estabelecimento desta prática recomendada:** A reparação automatizada, mesmo que a carga de trabalho só possa ser implantada em um local por vez, reduzirá o tempo médio até a recuperação e garantirá a disponibilidade da carga de trabalho.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Use os grupos de Auto Scaling para implantar níveis em uma workload. O Auto Scaling pode executar a autorreparação em aplicativos sem estado e adicionar e remover capacidade.
+ [Como funciona o AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ Implemente a recuperação automática em instâncias do EC2 que tenham aplicativos implantados que não possam ser implantados em vários locais e possam tolerar a reinicialização em caso de falhas. É possível usar a recuperação automática para substituir o hardware com falha e reiniciar a instância quando o aplicativo não puder ser implantado em vários locais. Os metadados e os endereços IP associados da instância são mantidos, assim como os volumes e pontos de montagem do Amazon EBS para o Elastic File Systems ou File Systems for Lustre e Windows.
+ [Recuperação automática do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [O que é o Amazon FSx for Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [O que é o Amazon FSx for Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
+ Ao usar o AWS OpsWorks, é possível configurar a autorreparação das instâncias do EC2 no nível da camada
+ [AWS OpsWorks: como usar a autorreparação para substituir instâncias com falha](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ Implemente a recuperação automatizada usando o AWS Step Functions e o AWS Lambda quando não for possível usar a escalabilidade ou a recuperação automáticas, ou quando a recuperação automática falhar. Quando não for possível usar a escalabilidade ou a recuperação automáticas ou quando a recuperação automática falhar, você poderá automatizar a reparação usando o AWS Step Functions e o AWS Lambda.
+ [O que é o AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [O que é o AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ É possível usar o Amazon EventBridge para monitorar e filtrar eventos, como alarmes do CloudWatch ou alterações no estado de outros serviços da AWS. Com base nas informações do evento, ele pode acionar o AWS Lambda (ou outros destinos) para executar a lógica de correção personalizada na workload.
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Uso de alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Recursos
**Documentos relacionados:**
+ [Parceiro da APN: parceiros que podem ajudar na automação da sua tolerância a falhas](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: produtos que podem ser usados para tolerância a falhas](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: como usar a autorreparação para substituir instâncias com falha](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Recuperação automática do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [Como funciona o AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Uso de alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [O que é o AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [O que é o AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [O que é o Amazon FSx for Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [O que é o Amazon FSx for Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
**Vídeos relacionados:**
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
**Exemplos relacionados:**
+ [Laboratório do Well-Architected: nível 300: implementação de verificações de integridade e do gerenciamento de dependências para melhorar a confiabilidade](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP04 Confiar no plano de dados e não no ambiente de gerenciamento durante a recuperação
O ambiente de gerenciamento é usado para configurar recursos, e o plano de dados fornece serviços. Os planos de dados geralmente têm metas de design de disponibilidade mais altas do que os ambientes de gerenciamento e costumam ser menos complexos. Ao implementar respostas de recuperação ou mitigação para eventos que possam ter um impacto na resiliência, o uso de operações do ambiente de gerenciamento pode diminuir a resiliência geral da sua arquitetura. Por exemplo, você pode confiar no plano de dados do Amazon Route 53 para rotear consultas ao DNS com base nas verificações de integridade. Porém, a atualização das políticas de roteamento do Route 53 usa o ambiente de gerenciamento, portanto, não conte com ele para a recuperação.
Os planos de dados do Route 53 respondem as consultas ao DNS, além de realizarem e avaliarem verificações de integridade. Eles são distribuídos globalmente e projetados para um [Acordo de Serviço (SLA) de 100% de disponibilidade.](https://aws.amazon.com/route53/sla/) As APIs e consoles de gerenciamento do Route 53 usados para criar, atualizar e excluir recursos do Route 53 são executados em ambientes de gerenciamento projetados para priorizar a consistência e a durabilidade necessária para gerenciar o DNS. Para que isso aconteça, os ambientes de gerenciamento estão localizados em uma única região, US East (N. Virginia). Embora ambos os sistemas sejam construídos para serem muito confiáveis, os ambientes de gerenciamento não estão incluídos no SLA. Pode ser que ocorram raros eventos onde o design resiliente do plano de dados permita que ele mantenha a disponibilidade, enquanto os ambientes de gerenciamento não. Para mecanismos de recuperação de desastres e failover, use funções de plano de dados para fornecer a melhor confiabilidade possível.
Para obter mais informações sobre planos de dados, ambientes de gerenciamento e como a AWS cria serviços para atender destinos de alta disponibilidade, consulte o documento [estabilidade estática usando Zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) e a [Amazon Builders’ Library.](https://aws.amazon.com/builders-library/)
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Confie no plano de dados e não no ambiente de gerenciamento ao usar o Amazon Route 53 para recuperação de desastres. O Route 53 Application Recovery Controller ajuda a gerenciar e coordenar o failover usando verificações de prontidão e controles de roteamento. Esses recursos monitoram continuamente a capacidade da aplicação de se recuperar de falhas, permitindo que você controle a recuperação da aplicação em várias Regiões da AWS, zonas de disponibilidade e ambientes on-premises.
+ [O que é o Route 53 Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Criação de mecanismos de recuperação de desastres usando o Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Criação de aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 1: pilha de região única](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Criação de aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 2: pilha multirregional](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ Compreenda quais operações estão no plano de dados e quais estão no ambiente de gerenciamento.
+ [Amazon Builders’ Library: evite a sobrecarga em sistemas distribuídos colocando o menor serviço no controle](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [API do Amazon DynamoDB (ambiente de gerenciamento e plano de dados)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [Execuções do AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (divididas entre o ambiente de gerenciamento e o plano de dados)
+ [Execuções do AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (divididas entre o ambiente de gerenciamento e o plano de dados)
## Recursos
**Documentos relacionados:**
+ [Parceiro da APN: parceiros que podem ajudar na automação da sua tolerância a falhas](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: produtos que podem ser usados para tolerância a falhas](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [Amazon Builders’ Library: evite a sobrecarga em sistemas distribuídos colocando o menor serviço no controle](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [API do Amazon DynamoDB (ambiente de gerenciamento e plano de dados)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [Execuções do AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (divididas entre o ambiente de gerenciamento e o plano de dados)
+ [Plano de dados do AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html)
+ [Criação de aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 1: pilha de região única](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Criação de aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 2: pilha multirregional](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [Criação de mecanismos de recuperação de desastres usando o Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [O que é o Route 53 Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
**Exemplos relacionados:**
+ [Introdução ao Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
# REL11-BP05 Usar a estabilidade estática para evitar o comportamento bimodal
O comportamento bimodal é quando a carga de trabalho apresenta um comportamento diferente nos modos normal e de falha, por exemplo, depender da execução de novas instâncias se uma zona de disponibilidade falhar. Em vez disso, você deve criar cargas de trabalho que sejam estaticamente estáveis e que operem em apenas um modo. Nesse caso, provisione instâncias suficientes em cada zona de disponibilidade para processar a carga de trabalho se uma AZ foi removida e use as verificações de integridade do Elastic Load Balancing ou do Amazon Route 53 para remover a carga das instâncias danificadas.
A estabilidade estática para implantação de computação (como instâncias ou contêineres do EC2) resultará na mais alta confiabilidade. Isso deve ser ponderado em relação a preocupações de custo. É mais barato provisionar menos capacidade computacional e contar com a execução de novas instâncias em caso de falha. No entanto, para falhas em grande escala (como uma falha de zona de disponibilidade), essa abordagem é menos eficaz porque depende de reagir a prejuízos à medida que ocorrem, em vez de estar preparada para essas deficiências antes que elas ocorram. Sua solução deve ponderar a confiabilidade em comparação com as necessidades de custo para sua carga de trabalho. Ao usar mais zonas de disponibilidade, a quantidade de computação adicional necessária para a estabilidade estática diminui.
![\[Diagrama mostrando estabilidade estática de instâncias do EC2 em várias zonas de disponibilidade\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/static-stability.png)
Depois que o tráfego for deslocado, use o AWS Auto Scaling para substituir de forma assíncrona instâncias da zona com falha e executá-las nas zonas íntegras.
Outro exemplo de comportamento bimodal seria um tempo limite de rede que poderia fazer com que um sistema tentasse atualizar o estado de configuração de todo o sistema. Isso adicionaria uma carga inesperada a outro componente e pode fazê-lo falhar, levando a outras consequências inesperadas. Esse ciclo de comentário negativo afeta a disponibilidade de sua carga de trabalho. Em vez disso, você deve criar sistemas estaticamente estáveis e operar em apenas um modo. Um design estático estável seria fazer um trabalho constante e sempre atualizar o estado da configuração em um ritmo fixo. Quando uma chamada falha, a carga de trabalho usa o valor armazenado em cache anteriormente e aciona um alarme.
Outro exemplo de comportamento bimodal é permitir que os clientes ignorem o cache da carga de trabalho em caso de falhas. Isso pode parecer ser uma solução que acomoda as necessidades do cliente, mas não deve ser permitida porque altera significativamente as demandas em sua carga de trabalho e provavelmente resultará em falhas.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Use a estabilidade estática para evitar o comportamento bimodal. O comportamento bimodal é quando a carga de trabalho apresenta um comportamento diferente nos modos normal e de falha, por exemplo, depender da execução de novas instâncias se uma zona de disponibilidade falhar.
+ [Minimizar dependências em um plano de recuperação de desastres](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [A Amazon Builders’ Library: estabilidade estática usando zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
+ Em vez disso, você deve criar sistemas que sejam estaticamente estáveis e que operem em apenas um modo. Nesse caso, provisione instâncias suficientes em cada zona para processar a workload se uma AZ foi removida e use as verificações de integridade do Elastic Load Balancing ou do Amazon Route 53 para remover a carga das instâncias danificadas.
+ Outro exemplo de comportamento bimodal é permitir que os clientes ignorem o cache da carga de trabalho em caso de falhas. Isso pode parecer uma solução para acomodar as necessidades do cliente, mas não deve ser permitido porque altera significativamente as demandas em sua carga de trabalho e pode resultar em falhas.
## Recursos
**Documentos relacionados:**
+ [Minimizar dependências em um plano de recuperação de desastres](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [A Amazon Builders’ Library: estabilidade estática usando zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
**Vídeos relacionados:**
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
# REL11-BP06 Enviar notificações quando os eventos afetarem a disponibilidade
As notificações são enviadas após a detecção de eventos significativos, mesmo que o problema causado pelo evento tenha sido resolvido automaticamente.
A correção automatizada permite que a carga de trabalho seja confiável. No entanto, ele também pode obscurecer problemas subjacentes que precisam ser resolvidos. Implemente eventos e monitoramento apropriados para que você possa detectar padrões de problemas, incluindo aqueles abordados pela correção automática, para que você possa resolver problemas de causa raiz. Alarmes do Amazon CloudWatch podem ser acionados com base em falhas que ocorrem. Eles também podem ser acionados com base em ações de correção automatizadas executadas. Alarmes do CloudWatch podem ser configurados para enviar e-mails ou registrar incidentes em sistemas de rastreamento de incidentes de terceiros usando a integração com o Amazon SNS.
**Antipadrões comuns:**
+ Envio de alarmes sem necessidade de reação.
+ Execução da automação de autorreparação, mas sem notificar que a reparação era necessária.
**Benefícios do estabelecimento dessa prática recomendada:** As notificações de eventos de recuperação garantem que você não ignore problemas que ocorrem com pouca frequência.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Alarmes de indicadores-chave de performance de negócios quando eles excedem um limite baixo. Possuir um alarme de limite baixo nos KPIs de negócios ajuda a saber quando a workload está indisponível ou não funcional.
+ [Criação de um alarme do CloudWatch com base em um limite estático](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ Alarmes de eventos que invocam automação de reparação. Você pode invocar diretamente uma API do SNS para enviar notificações com qualquer automação criada.
+ [O que é o Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
## Recursos
**Documentos relacionados:**
+ [Criação de um alarme do CloudWatch com base em um limite estático](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [O que é o Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)