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á.
Implementando engenharia de caos em AWS
A engenharia do caos faz parte do estágio de avaliação e teste do ciclo de vida da AWS resiliência, conforme ilustrado no diagrama a seguir. Os aplicativos distribuídos não operam isoladamente de outros aplicativos ou clientes, portanto, recomendamos que você revise todo o ciclo de vida da resiliência. A mudança é constante em aplicativos distribuídos à medida que a rede evolui, os aplicativos upstream e downstream passam por mudanças e o uso do cliente muda com o tempo.
Para entender como essas mudanças em seu aplicativo podem afetar sua resiliência, faça da engenharia do caos uma parte de suas day-to-day operações. Você pode implementar experimentos de caos de diferentes maneiras:
-
Ad hoc — Você pode realizar experimentos de caos como experimentos únicos para abordar um problema ou questão específica.
-
Dias de jogo do caos — Esses são eventos estruturados e recorrentes projetados para verificar a confiabilidade e a resiliência de um aplicativo. O objetivo de um dia de jogo do caos é identificar possíveis problemas ou deficiências de resiliência entre pessoas, processos e tecnologias e praticar os processos e procedimentos para identificar, mitigar e responder a incidentes.
-
Chaos Pipeline — Integração e entrega contínuas (CI/CD) is about building new features and deploying them safely throughout the environments. To implement chaos engineering experiments, create a chaos pipeline that's separate from your CI/CD pipeline. To understand why, let's assume that you want to add a single chaos engineering experiment to your CI/CDtubulação que injeta uma perda crescente de pacotes para componentes posteriores). Esse experimento é executado 3 vezes e leva 5 minutos para ser concluído a cada vez. A perda de pacotes aumenta de 10 por cento para 20 por cento a 30 por cento a cada execução, e o experimento leva 15 minutos no geral para ser concluído. Se você tiver 100 implantações paralelas, precisará esperar 1500 minutos para que um único experimento seja concluído. Se você tiver 10 experimentos para realizar, o impacto para seus desenvolvedores seria insuportável. Em grande escala, a engenharia do caos precisa de seu próprio pipeline que permita que você execute experimentos paralelamente ao seu processo de ciclo de vida de desenvolvimento de software (SDLC).
-
Implantações do Canary — Os Canários fornecem um ambiente de teste para experimentos de caos. Ao direcionar uma pequena porcentagem do tráfego para um serviço canário ou usar métodos como espelhamento de tráfego ou repetição, você pode verificar novas alterações na infraestrutura ou no código sem impacto em seu sistema de produção estável. Você pode realizar experimentos contra o canário e injetar falhas conforme necessário, pois pode limitar o escopo do impacto para o usuário final.
-
Experimentos programados — Você pode programar experimentos para verificar mecanismos de recuperação previsíveis para seu aplicativo. Use experimentos programados para reproduzir eventos comumente conhecidos e capturar como seus sistemas podem se recuperar de eventos como encerrar uma EC2 instância por trás de um grupo de escalabilidade automática, remover um pod do Kubernetes ou excluir uma tarefa do Amazon ECS.
