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á.
Começando com a engenharia do caos
Antes de realizar um experimento, recomendamos que você implemente alguns itens essenciais para aproveitar ao máximo suas práticas de engenharia do caos. Esses itens essenciais incluem:
-
Observabilidade (métricas, registro, rastreamento de solicitações)
-
Uma lista de eventos ou falhas do mundo real que você gostaria de explorar
-
Patrocínio de resiliência organizacional por meio da adesão da liderança
-
Priorização de descobertas críticas, com base no impacto potencial nos negócios, em relação aos novos recursos que são descobertos ao realizar experimentos de caos
Observabilidade para experimentos de caos
A observabilidade, que inclui métricas, registros e rastreamento de solicitações, desempenha um papel fundamental na engenharia do caos. Você vai querer entender as métricas de negócios, métricas do lado do servidor, métricas de experiência do cliente e métricas de operações ao realizar um experimento. Sem a observabilidade, você não conseguirá definir um comportamento estável ou criar um experimento significativo para verificar se sua hipótese sobre seu aplicativo é verdadeira.
Metrics
O diagrama a seguir mostra os tipos de métricas que você pode monitorar para experimentos de caos em diferentes tipos de aplicativos.
-
Métricas de negócios — O estado estável indica a operação normal do seu sistema e é definido pelas métricas do seu negócio. Ela pode ser representada por transações por segundo (TPS), fluxos de cliques por segundo, pedidos por segundo ou uma medida similar. Seu aplicativo exibe um estado estável quando está operando conforme o esperado. Portanto, verifique se o aplicativo está íntegro antes de executar experimentos. O estado estável não significa necessariamente que não haverá impacto no aplicativo quando ocorrer uma falha, pois uma porcentagem de falhas pode estar dentro de limites aceitáveis. O estado estacionário é sua linha de base. Por exemplo, o estado estável de um sistema de pagamentos pode ser definido como o processamento de 300 TPS com uma taxa de sucesso de 99% e tempo de ida e volta de 500 ms. Visualmente, pense no estado estacionário como um eletrocardiograma (EKG). Se o estado estável do seu sistema flutuar repentinamente, você sabe que há um problema com seu serviço.
-
Métricas do lado do servidor — Para entender o desempenho de seus recursos durante o experimento, você precisa de insights sobre o desempenho deles antes, durante e depois do experimento. Para medir o impacto de seus recursos AWS, você pode usar a Amazon CloudWatch. CloudWatch é um serviço que monitora aplicativos, responde às mudanças de desempenho, otimiza o uso de recursos e fornece informações sobre a integridade operacional. Durante seus experimentos, você desejará capturar métricas do lado do servidor, como saturação, volumes de solicitações, taxas de erro e latência.
-
Métricas de experiência do cliente — Ativado AWS, você pode capturar métricas reais do usuário usando o CloudWatchRUM para simular solicitações do usuário por meio de ferramentas como Locust, Grafana k6, Selenium ou Puppeteer. Métricas reais de usuários são cruciais para organizações que realizam experimentos de engenharia do caos. Ao monitorar como os usuários reais são afetados durante um experimento, as equipes podem ter uma visão precisa de como as falhas e interrupções afetarão os clientes na produção. As principais métricas de experiência do cliente são Time to First Byte (TTFB), Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Total Blocking Time (TBT).
-
Métricas de operações — As intervenções medem o sucesso na mitigação de falhas de forma automatizada ― por exemplo, a latência bem-sucedida da solicitação do cliente durante a reinicialização de pods, tarefas ou instâncias do EC2 com mecanismos como controlador de replicação ou escalabilidade automática. Ser capaz de intervir automaticamente durante uma falha se correlaciona diretamente com uma boa experiência do usuário. Entender se há alguma mudança nesses mecanismos de mitigação ao longo do tempo é crucial. Ao definir métricas para mitigações automatizadas bem-sucedidas e fracassadas, você cria diretrizes que ajudam a identificar possíveis regressões em todo o sistema.
Registro em log
O registro centralizado é fundamental para entender os estados dos componentes do seu aplicativo antes, durante e depois de um experimento de caos. Recomendamos que você colete registros de todos os componentes do seu aplicativo para criar uma visão consolidada do que cada componente estava fazendo no momento em que o experimento foi injetado. Isso fornece uma imagem clara do fluxo do end-to-end experimento.
Rastreamento de solicitação
O rastreamento de solicitações permite que você observe o fluxo de qualquer solicitação única nos componentes do seu aplicativo para obter uma compreensão abrangente do impacto que a falha injetada tem no sistema e em suas dependências. Ao rastrear as solicitações, você pode ver como a falha se propaga por meio de diferentes serviços e componentes, para que você possa avaliar melhor o escopo da interrupção. Para rastrear suas solicitações AWS, você pode usar AWS X-Ray.
Cenários de falha para injetar em experimentos de caos
O objetivo de injetar falhas comuns em seu aplicativo é entender como o aplicativo reage a esses eventos inesperados, para que você possa criar mecanismos de mitigação e tornar seu sistema resiliente a essas falhas. Além disso, você deve usar a engenharia do caos para reproduzir cenários históricos de falhas para verificar se seus mecanismos de mitigação ainda estão funcionando conforme o esperado e não se alteraram com o tempo.
Considere os eventos a seguir ao planejar seus experimentos de engenharia do caos.
| Modo de falha | Description |
|---|---|
Deficiência do servidor |
Reinicie instâncias do EC2, exclua pods do Kubernetes ou tarefas do Amazon Elastic Container Service (Amazon ECS) para entender como seu aplicativo reage a essas falhas. |
Erros de API |
Injete falhas em AWS seu próprio serviço APIs para entender o comportamento do aplicativo. |
Problemas de rede |
Introduza latência ou congestionamento ou bloqueie conexões para imitar problemas de rede do mundo real. |
AWS Diminuição da zona de disponibilidade |
Repita a deficiência de uma zona de disponibilidade inteira para verificar a recuperação em todas as zonas. |
Região da AWS comprometimento da conectividade |
Repita uma falha na rede Regiões da AWS para verificar como os recursos na região secundária reagem a esse evento. |
Falhas no banco de |
Faça o failover de réplicas do banco de dados ou corrompa os dados, ou torne as instâncias do banco de dados inacessíveis, para entender o impacto em suas estratégias de aplicativo e recuperação. |
Pausa no banco de dados e na replicação do Amazon S3 |
Pause a replicação do banco de dados ou do Amazon Simple Storage Service (Amazon S3) entre zonas de disponibilidade ou Regiões da AWS para entender o impacto do aplicativo downstream. |
Degradação do armazenamento |
Pause a E/S, remova os volumes do Amazon Elastic Block Store (Amazon EBS) ou exclua arquivos para verificar a durabilidade e a recuperação dos dados. |
Diminuição da dependência |
Reduza ou diminua o desempenho dos serviços downstream ou upstream dos quais você depende, incluindo serviços de terceiros, para entender o end-to-end fluxo e o impacto para seus clientes. |
Surtos de tráfego |
Gere picos no tráfego de usuários para testar os recursos de escalabilidade automática e veja como o tempo de inicialização a frio pode afetar o estado geral do aplicativo. |
Esgotamento de recursos |
Maximize a CPU, a memória e o espaço em disco para verificar a degradação normal do seu aplicativo. |
Falhas em cascata |
Inicie falhas primárias que se espalham em cascata para aplicativos e componentes posteriores. |
Implantações incorretas |
Implemente alterações ou configurações problemáticas para verificar os mecanismos de reversão. |
Patrocínio de resiliência organizacional
A engenharia do caos fornece mais valor quando aplicada em toda a organização. Recomendamos que você trabalhe com um patrocinador executivo que possa ajudar a definir metas de resiliência em toda a organização, eliminar o medo, a incerteza e a dúvida sobre o domínio e iniciar o processo de transformação para tornar a resiliência responsabilidade de todos.
Para apoiar o caso comercial da criação de uma prática de engenharia do caos, associe esforços de engenharia do caos aos seus projetos comerciais críticos. Fazer da resiliência um ativo e impulsionador da aceleração ajudará você a monitorar o sucesso ao longo do tempo. Comece com uma contagem de incidentes críticos por mês ou por trimestre, o tempo médio de recuperação e o impacto que esses incidentes causaram em seus clientes e organização. Estabeleça uma meta com suas equipes para reduzir o número de incidentes em um período de 6 a 12 meses, à medida que melhorias são feitas em suas pilhas de aplicativos em resposta aos experimentos de engenharia do caos.
Avalie se os incidentes são altamente repetitivos. Por exemplo, digamos que um certificado TLS expirado leve ao tempo de inatividade porque os clientes não conseguem estabelecer uma conexão confiável. Se vários incidentes ocorrerem em um ano devido à expiração de vários certificados TLS, você pode realizar um experimento de expiração de um certificado TLS e verificar se suas equipes recebem alertas ou são capazes de mitigar automaticamente esses problemas. Isso ajudará a garantir que você se torne resiliente a essas falhas.
Para acompanhar o progresso na engenharia do caos ao longo do tempo, capture as seguintes métricas para ajudar a destacar o valor da engenharia do caos em todo o ciclo de vida de um aplicativo:
-
Taxa de incidentes reduzida — Acompanhe o número de incidentes de produção ao longo do tempo e correlacione esse número com a adoção da engenharia do caos. A expectativa é que a taxa de incidentes graves diminua.
-
Tempo médio de resolução aprimorado (MTTR) — Calcule o tempo médio necessário para resolver incidentes e acompanhe esses dados para ver se eles melhoram com a engenharia do caos ao longo do tempo.
-
Maior disponibilidade de aplicativos — use métricas de nível de serviço para mostrar melhorias na disponibilidade à medida que a resiliência dos aplicativos aumenta por meio de experimentos caóticos.
-
Menor tempo de lançamento no mercado — A engenharia do caos pode fornecer a confiança necessária para lançar ofertas inovadoras com mais rapidez, porque você sabe que seus aplicativos são resilientes. Acompanhe os aumentos na velocidade de liberação do produto.
-
Redução de custos operacionais — Quantifique se indicadores como ruído de alerta, carga operacional e esforço manual para gerenciar aplicativos diminuem com a implementação de práticas caóticas.
-
Aumentar a confiança — Faça uma pesquisa com desenvolvedores, engenheiros de confiabilidade de sites (SREs) e outras equipes técnicas para avaliar se a engenharia do caos aumentou sua confiança na resiliência de aplicativos. As percepções importam.
-
Experiências aprimoradas do cliente ‒ Conecte a engenharia do caos a resultados positivos para os clientes, como menos interrupções no serviço, reversões e interrupções.
Priorizando a remediação
Ao realizar experimentos de caos, é provável que você identifique áreas de melhoria nas quais o aplicativo não funciona conforme o esperado. A correção desses itens se tornará um trabalho em sua lista de pendências que deverá ser priorizado junto com outros trabalhos, como o desenvolvimento de recursos. Recomendamos que você reserve um tempo para esses aprimoramentos para evitar futuras falhas. Considere priorizar essas tarefas de aprendizado e remediação com base no nível de impacto que elas podem causar. As descobertas que afetam diretamente a resiliência ou a segurança do seu aplicativo devem ter prioridade sobre os novos recursos, para evitar o impacto no cliente. Se a equipe tiver dificuldade em priorizar o trabalho de remediação em vez do desenvolvimento de recursos, considere entrar em contato com seu patrocinador executivo para garantir que as prioridades sejam definidas com base na tolerância ao risco comercial.
