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á.

Ciclo de vida contínuo do experimento de engenharia do caos

Conforme discutido na seção anterior, você pode implementar experimentos de engenharia do caos de maneiras diferentes. Em todos os casos, a chave para criar um experimento de caos significativo é entender a aplicação, os incidentes históricos e as remediações implementadas, além de entender claramente as áreas a serem investigadas, como resiliência ou segurança. Seu conhecimento sobre o aplicativo ajuda você a formular uma hipótese sobre as possíveis fraquezas do aplicativo e a entender como ele detectará, remediará e se recuperará quando a falha for injetada.

O ciclo de vida do experimento de caos inclui estas etapas:

Essas etapas são ilustradas no diagrama e discutidas nas seções a seguir.

Defina objetivos e estabeleça expectativas

Antes de cada experimento, certifique-se de que seus objetivos e expectativas sejam específicos, mensuráveis, alcançáveis, relevantes e com limite de tempo. Defina claramente o seguinte:

Selecione o aplicativo de destino

A engenharia do caos é uma técnica poderosa, mas requer uma priorização cuidadosa para maximizar o valor. Ao decidir onde concentrar os esforços de engenharia do caos, comece considerando os serviços essenciais de sua empresa. Peça às suas equipes que percorram os estágios do ciclo de vida de desenvolvimento de software e comecem a injetar falhas nos ambientes de teste primeiro. Os aplicativos essenciais para os negócios estão diretamente vinculados à receita, à experiência do cliente e às principais operações. Experimentos de caos nesses serviços podem revelar vulnerabilidades que podem afetar gravemente a organização, e potencialmente mercados inteiros, se não forem resolvidas. Por exemplo, concentre-se primeiro nos serviços voltados para o cliente, como sistemas de negociação ou sistemas de pedidos. Priorizar esses serviços centrais fornece a maior proteção por investimento de tempo.

Depois dos serviços essenciais, analise os componentes fundamentais, como bancos de dados, filas de mensagens, redes e serviços compartilhados. APIs Eles podem ser usados como componentes ou serviços compartilhados em toda a organização, portanto, sua falha causará problemas generalizados. Confirmar a resiliência dos serviços de infraestrutura fornece a confiança de que eles não prejudicarão os aplicativos dependentes acima deles. Por exemplo, um experimento de engenharia do caos que derruba um cluster Kafka revela muito sobre a tolerância a falhas de aplicativos posteriores. Embora a infraestrutura do sistema não esteja diretamente voltada para o cliente, ela é o principal alvo da engenharia do caos.

Não se esqueça de mapear as lacunas mentais de pessoas, processos, informações sobre instalações e dependências de terceiros, pois elas podem causar grandes interrupções se não estiverem alinhadas com os objetivos de tolerância ao impacto da sua organização. Para obter mais informações sobre como medir o ROI da engenharia do caos, leia Quantificando o ROI da engenharia do caos no documento estratégico Investir na engenharia do caos como uma necessidade estratégica.

O diagrama a seguir mostra o retorno do investimento para realizar experimentos de caos em diferentes níveis de serviços.

Alinhe mapas mentais (descoberta de aplicativos)

Ao realizar experimentos ad-hoc ou dias de jogos, você iniciará o processo de descoberta do aplicativo realizando uma sessão de quadro branco que se concentra em mapear os detalhes do seu aplicativo. (Se você executar os experimentos no pipeline do caos, você já terá alinhado esse mapa mental, definindo o aplicativo de destino.) Uma boa abordagem para entender as lacunas mentais é fazer com que o membro mais jovem da equipe desenhe primeiro um diagrama do aplicativo e, em seguida, peça a mais funcionários seniores que o adicionem progressivamente. Isso revelará quaisquer lacunas na compreensão em todos os níveis de experiência.

O diagrama deve descrever as dependências diretas a montante e a jusante do aplicativo, bem como quaisquer integrações críticas de terceiros. Certifique-se de que haja alinhamento no fluxo esperado de uma solicitação por meio do aplicativo. Mapeie os principais fluxos de trabalho e jornadas do usuário para obter clareza sobre como os clientes usam o aplicativo. Considere usar um diagrama de sequência para capturar essas informações.

Após essa sessão colaborativa, a equipe deve ter um modelo mental compartilhado do aplicativo, suas dependências críticas e seus recursos de monitoramento, além de uma compreensão dos riscos de tomar uma decisão informada de prosseguir ou cancelar um possível experimento de caos.

Resolva os problemas conhecidos com seu aplicativo

Os experimentos de engenharia de caos são projetados para revelar defeitos de forma proativa em uma aplicação. Ao injetar falhas, como aumentos de latência, reinicializações de servidores ou deficiências de energia na zona de disponibilidade, você pode verificar a capacidade do seu aplicativo de tolerar interrupções realistas. No entanto, esse processo pressupõe um nível subjacente de estabilidade e integridade no aplicativo de destino. Executar experimentos de caos em um aplicativo já problemático corre o risco de mascarar problemas mais profundos.

Antes de empreender a engenharia do caos, as equipes devem resolver quaisquer defeitos, bugs e problemas de desempenho conhecidos em seus aplicativos.

Defina a hipótese e o experimento

Incidentes anteriores que causaram interrupções em seu aplicativo ou em outros aplicativos em sua organização podem servir como excelentes fontes para ideias de experimentos caóticos. Por exemplo, as interrupções anteriores foram provocadas por erros de configuração ou falta de padrões de resiliência? Analisar histórias de incidentes e repetir as causas dessas falhas no mundo real por meio de experimentos de caos é uma forma eficaz de desenvolver resiliência contra problemas semelhantes no futuro.

Outra fonte valiosa de conceitos experimentais pode vir diretamente dos engenheiros, arquitetos e operadores que estão mais familiarizados com um aplicativo. Permitir que os membros da equipe enviem cenários hipotéticos de falha que eles acreditam que poderiam interromper significativamente o aplicativo permite que você colete ideias com base no conhecimento interno. A equipe de aplicativos pode então avaliar quais desses cenários propostos podem ter o maior impacto potencial ou expor os maiores riscos desconhecidos. Visar experimentos de caos para cenários de alto risco e menos compreendidos pode gerar aprendizados importantes e evitar problemas no futuro.

Uma terceira fonte de ideias vem da modelagem de resiliência para antecipar as condições que levariam às perdas comerciais identificadas. Alguns exercícios de modelagem de resiliência têm uma abordagem baseada em componentes para construir um modelo de resiliência, enquanto outros têm uma abordagem baseada em sistemas. Uma abordagem baseada em componentes faz a pergunta: “O que acontece quando o componente x está sob carga extrema ou falha?” A equipe que desenvolve o modelo de resiliência então especula o efeito desse cenário na aplicação mais ampla e identifica os controles preventivos e de monitoramento atualmente em vigor para detectar e mitigar os efeitos do cenário. Como alternativa, uma abordagem baseada em sistemas segue um processo de cima para baixo para destacar um estado indesejável do aplicativo — como “A loja virtual está mostrando níveis de estoque obsoletos” — e convida a equipe de aplicativos a prever quais condições fariam com que o aplicativo se comportasse dessa maneira.

Garanta a prontidão operacional para o experimento

Você precisa de indicadores quantificáveis para medir o impacto de condições adversas no aplicativo e em seu comportamento, conforme descrito anteriormente na seção sobre observabilidade. A capacidade de medir o comportamento do aplicativo permite determinar se as condições adversas afetaram o aplicativo e em que magnitude.

A melhor maneira de entender se há um impacto em seu aplicativo é medir seu estado estável. O estado estável mede a aparência da operação normal e normalmente se alinha aos indicadores de negócios e de experiência do cliente de um determinado aplicativo. Antes de passar para a próxima etapa, certifique-se de ter a observabilidade pronta para entender o impacto e os mecanismos de reversão, caso o experimento não ocorra conforme o esperado.

Execute experimentos e cenários controlados

Em AWS, não recomendamos realizar um experimento inicial de caos em um aplicativo que está em produção. O objetivo de um experimento de caos é aprender algo novo sobre como o aplicativo se comporta em condições estressantes. O comportamento do aplicativo pode ser imprevisível durante o experimento, portanto, realizar um experimento pela primeira vez na produção pode ter consequências impactantes para o cliente. Portanto, você deve sempre realizar um experimento inicial de caos em um ambiente de nível inferior que tenha um potencial mínimo de afetar usuários do mundo real e, em seguida, percorrer seus ambientes depois de verificar e ter certeza de que seu aplicativo pode absorver, se adaptar e se recuperar das ações injetadas.

Planeje cada experimento minuciosamente usando um documento que capture os principais detalhes, semelhante ao documento de planejamento do experimento fornecido no apêndice. Alguns dos campos críticos a serem incluídos são a definição de estado estacionário, a hipótese e o método de injeção de falhas. O planejamento, a execução e a análise de um experimento de caos podem ser abordados em um único artefato.

Depois de finalizar o plano escrito para o experimento, prepare qualquer código necessário para injetar as interrupções planejadas descritas no documento.

Para capturar o impacto potencial durante o experimento, certifique-se de que os mecanismos de observabilidade estejam em vigor. Se você ainda não tem uma forma automatizada de capturar os resultados do experimento, como relatórios do AWS FIS experimento, identifique os membros da equipe que farão anotações durante a execução, capturarão capturas de tela dos painéis e conduzirão a equipe durante o experimento.

Aprenda e ajuste

Depois de cada experimento, reúna-se como uma equipe para analisar e refletir sobre o experimento do caos. Faça um esforço consciente para manter uma mentalidade irrepreensível. Seu objetivo deve ser ter um diálogo aberto e construtivo que se concentre inteiramente em obter o máximo de aprendizado, sem atribuir culpas.

Comece revisando a definição e a hipótese do estado estacionário para o experimento. O aplicativo se comportou conforme o esperado? Houve alguma surpresa que invalidou as suposições? Discuta as observações de como o aplicativo reagiu durante o experimento, tanto boas quanto ruins. Os dados coletados — métricas, registros, capturas de tela etc. — devem contar exatamente o que aconteceu.

Aborde essa análise de dados com curiosidade em vez de julgamento e identifique áreas em que melhorias podem ser feitas no design, na documentação, no monitoramento ou em outros recursos do aplicativo com base nos aprendizados. Esses itens de ação são capturados como projetos de acompanhamento para tornar o aplicativo mais resiliente.

Por meio dessa abordagem irrepreensível, você pode ter conversas francas sobre o que deu errado e como corrigi-lo. Assuma a intenção positiva de todos os envolvidos e confie que eles estavam trabalhando para obter bons resultados. Seu objetivo comum é o crescimento e a progressão organizacional por meio do aprendizado e da adaptação contínuos. As análises de experimentos do Chaos, conduzidas de forma construtiva e irrepreensível, fornecem um espaço seguro para sua equipe obter informações valiosas que tornam seus aplicativos e sua organização mais confiáveis e resilientes a longo prazo. O foco permanece nos aprendizados, não nas pessoas. Para divulgar o aprendizado entre suas equipes, publique o relatório do resultado do experimento em um local central e divulgue as descobertas para que outras pessoas possam aprender com elas.