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 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 da sua aplicação, automatizar avaliações e até mesmo integrá-las às suas ferramentas de CI/CD, conforme analisado na publicação do Blog da AWS Continually assessing application resilience with AWS Resilience Hub and AWS CodePipeline
teste de DR
Na Etapa 2: projetar e implementar, 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 pilhas do AWS CloudFormation, consulte Detectar alterações de configuração não gerenciadas em pilhas e recursos com detecção de desvios na documentação do AWS CloudFormation. Para detectar desvios no ambiente da AWS da sua aplicação, consulte Detect and resolve drift in AWS Control Tower na documentação do AWS Control Tower.
Testes sintéticos
O teste sintético é o processo de criação de software configurável que é executado na produção, de forma programada, para testar as APIs da sua aplicação de uma 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.
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.
A AWS recomenda que você inicie seus esforços de engenharia de caos em um ambiente que não seja de produção. Você pode usar o AWS Fault Injection Service (AWS FIS)
