As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Atividades de pós-implantação
A resiliência é um processo contínuo, e a avaliação da resiliência da sua aplicação deve continuar após sua implantação. Os resultados de suas atividades pós-implantação, como avaliações contínuas de resiliência, podem exigir que você reavalie e atualize algumas das atividades de resiliência realizadas anteriormente no ciclo de vida da resiliência.
## Realização das avaliações de resiliência
A avaliação da resiliência não para depois que você implementa sua aplicação na produção. Mesmo que você tenha pipelines de implantação bem definidos e automatizados, às vezes as mudanças podem ocorrer diretamente em um ambiente de produção. Além disso, pode haver fatores que você ainda não tenha levado em consideração na verificação de resiliência pré-implantação. O [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) fornece um local central onde você pode avaliar se sua arquitetura implantada atende às suas necessidades definidas de RPO e RTO. [Você pode usar esse serviço para executar avaliações sob demanda da resiliência do seu aplicativo, automatizar avaliações e até mesmo integrá-las às suas ferramentas de CI/CD, conforme discutido na postagem do AWS blog Avaliando continuamente a resiliência do aplicativo com e. AWS Resilience HubAWS CodePipeline](https://aws.amazon.com/blogs/architecture/continually-assessing-application-resilience-with-aws-resilience-hub-and-aws-codepipeline/) Automatizar essas avaliações é uma prática recomendada porque ajuda a garantir que você esteja avaliando continuamente sua postura de resiliência na produção.
## teste de DR
Na [Etapa 2: projetar e implementar](stage-2.md), você desenvolveu estratégias de recuperação de desastres (DR) como parte do seu sistema. Durante a Etapa 4, você deve testar seus procedimentos de DR para garantir que sua equipe esteja totalmente preparada para um incidente e que seus procedimentos funcionem conforme o esperado. Você deve testar regularmente todos os seus procedimentos de DR, incluindo failover e failback, e analisar os resultados de cada exercício para determinar se e como os procedimentos do seu sistema devem ser atualizados para obter o melhor resultado possível. Ao desenvolver seu teste de DR inicialmente, programe o teste com bastante antecedência e garanta que toda a equipe entenda o que esperar, como os resultados serão avaliados e qual mecanismo de feedback será usado para atualizar os procedimentos com base no resultado. Depois de se tornar proficiente na execução de testes de DR programados, considere a realização de testes de DR sem aviso prévio. Desastres reais não ocorrem de acordo com uma programação, então tudo precisa estar pronto para colocar em prática seu plano a qualquer momento. No entanto, sem aviso prévio não significa não planejado. As principais partes interessadas ainda precisam planejar o evento para garantir que o monitoramento adequado esteja em vigor e que os clientes e as aplicações essenciais não sejam afetados adversamente.
## Detecção de desvios
Mudanças imprevistas na configuração em aplicações de produção podem ocorrer mesmo quando há automação e procedimentos bem definidos. Para detectar alterações na configuração da sua aplicação, você deve ter mecanismos para detectar *desvios*, que se referem a desvios de uma configuração de linha de base. Para saber como detectar desvios em suas AWS CloudFormation pilhas, consulte [Detecção de alterações de configuração não gerenciadas em pilhas e](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html) recursos na documentação. AWS CloudFormation Para detectar desvios no AWS ambiente do seu aplicativo, consulte [Detectar e resolver desvios AWS Control TowerAWS Control Tower na](https://docs.aws.amazon.com/controltower/latest/userguide/drift.html) documentação.
## Testes sintéticos
O [teste sintético](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) é o processo de criação de software configurável que é executado em produção, de forma programada, para testar seus aplicativos de uma APIs forma que simule a experiência do usuário final. Esses testes às vezes são chamados de *canários*, em referência ao uso original do termo na mineração de carvão. Os testes sintéticos geralmente podem fornecer avisos antecipados quando uma aplicação sofre uma interrupção, mesmo que a deficiência seja parcial ou intermitente, como geralmente acontece com [falhas cinzentas](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html).
## Engenharia do caos
A engenharia do caos é um processo sistemático que envolve submeter deliberadamente uma aplicação a eventos disruptivos de forma a mitigar os riscos, monitorando de perto sua resposta e implementando as melhorias necessárias. Seu objetivo é validar ou desafiar as suposições sobre a capacidade da aplicação de lidar com essas interrupções. Em vez de deixar esses eventos ao acaso, a engenharia do caos capacita os engenheiros a orquestrar experimentos em um ambiente controlado, normalmente durante períodos de pouco tráfego e com o suporte da engenharia prontamente disponível para uma mitigação eficaz.
A engenharia do caos começa com a compreensão das condições operacionais normais, conhecidas como *estado estacionário*, da aplicação em questão. A partir daí, você formula uma hipótese que detalha o comportamento com êxito da aplicação na presença de interrupções. Você executa o experimento, que envolve a injeção deliberada de interrupções, incluindo, entre outras, latência da rede, falhas no servidor, erros no disco rígido e deficiência das dependências externas. Em seguida, você analisa os resultados do experimento e aprimora a resiliência da aplicação com base em seus aprendizados. O experimento serve como uma ferramenta valiosa para melhorar várias facetas da aplicação, incluindo sua performance, e revela problemas latentes que poderiam ter permanecido ocultos de outra forma. Além disso, a engenharia do caos ajuda a revelar deficiências nas ferramentas de observabilidade e alarme e ajuda a refiná-las. Também contribui para reduzir o tempo de recuperação e aprimorar as habilidades operacionais. A engenharia do caos acelera a adoção das práticas recomendadas e cultiva uma mentalidade de melhoria contínua. Em última análise, ela permite que as equipes desenvolvam e aprimorem suas habilidades operacionais por meio da prática regular e da repetição.
AWS recomenda que você inicie seus esforços de engenharia do caos em um ambiente que não seja de produção. Você pode usar o [AWS Fault Injection Service (AWS FIS)](https://aws.amazon.com/fis/) para executar experimentos de engenharia de caos com falhas de uso geral, bem como falhas exclusivas da AWS. Esse serviço totalmente gerenciado inclui alarmes de condições de parada e controles completos de permissão para que você possa adotar facilmente a engenharia do caos com segurança e confiança.