Engenharia do Caos

Você adicionou timeouts, um circuit breaker e um fallback à chamada do serviço de pedidos para o serviço de produtos. Eles funcionam? Os testes unitários passam, mas ninguém nunca viu o breaker abrir em produção — e a primeira vez que isso importar será durante uma indisponibilidade real, de madrugada, com clientes reais. A única forma de saber é causar a falha você mesmo, de propósito, enquanto está observando.

Engenharia do Caos (Chaos Engineering) é a disciplina de fazer experimentos em um sistema para ganhar confiança na sua capacidade de suportar condições turbulentas em produção¹. Em vez de esperar que as falhas aconteçam naturalmente, os praticantes injetam falhas controladas deliberadamente — e usam os resultados para encontrar e corrigir fraquezas antes que incidentes reais o façam.

"The best way to avoid failure is to fail constantly." ("A melhor forma de evitar a falha é falhar constantemente.") — John Ciancutti, Netflix, 2010⁵

A ideia é mais antiga que o nome. Na Amazon, no início dos anos 2000, Jesse Robbins (mais tarde cofundador da Opscode, a empresa por trás do Chef) conduzia exercícios de GameDay que causavam deliberadamente grandes falhas em sistemas de produção para expor fraquezas ocultas no software e nas equipes que o operavam⁴.

Origem: a Netflix e o Simian Army

Em 2008, uma corrupção de banco de dados impediu a Netflix de enviar DVDs por três dias. A empresa decidiu sair do próprio data center e migrar para a AWS, aceitando que, na nuvem, instâncias individuais podem desaparecer a qualquer momento. Durante essa migração (por volta de 2010), os engenheiros construíram o Chaos Monkey: um serviço que encerra instâncias aleatoriamente em produção durante o horário comercial, obrigando todas as equipes a construir serviços que sobrevivam à perda arbitrária de instâncias⁵. Executá-lo no horário de trabalho é proposital — os engenheiros estão em suas mesas para ver e corrigir o que quebrar.

A prática foi posta à prova de verdade em abril de 2011, quando uma grande falha da AWS na região us-east-1 derrubou muitos sites conhecidos por horas; a Netflix continuou fazendo streaming, com alguma degradação, em grande parte porque seus serviços já eram construídos para perder instâncias. Naquele ano a Netflix descreveu todo um Simian Army⁶ — uma coleção de ferramentas que introduziam diferentes cenários de falha:

A percepção foi transformadora: a falha não é um caso especial a ser evitado; é o ambiente em que os sistemas de produção vivem, e a única forma de saber se o seu sistema sobrevive a ela é testá-lo ali. Em 2016, engenheiros da Netflix formalizaram a prática e lhe deram nome em um artigo da IEEE Software²; os princípios abaixo vêm desse trabalho.

Princípios da Engenharia do Caos

Os Principles of Chaos Engineering¹ definem a disciplina em torno de cinco ideias centrais:

1. Construa uma hipótese em torno do comportamento em estado estável : Defina como é o "normal" antes de injetar falhas — em termos de saídas mensuráveis (taxa de requisições, taxa de erros, latência). A hipótese é: "Este sistema continuará exibindo o estado estável mesmo quando a condição X for introduzida."

2. Varie eventos do mundo real : Simule eventos que realmente acontecem: queda de servidor, partição de rede, disco cheio, desvio de relógio, timeout de dependência, pico de tráfego. Falhas sintéticas ou artificiais que nunca ocorrem na prática produzem uma confiança enganosa.

3. Execute os experimentos em produção : Ambientes de staging não reproduzem fielmente a carga, a distribuição dos dados nem o comportamento das dependências de produção. Fraquezas que só aparecem em condições de produção são invisíveis em staging. Comece com um raio de impacto pequeno e amplie à medida que a confiança cresce.

4. Automatize os experimentos para rodarem continuamente : Um experimento pontual produz um resultado pontual. Os sistemas mudam o tempo todo; novos deploys podem reintroduzir fraquezas. Experimentos de caos contínuos rodam automaticamente (muitas vezes de forma agendada), de modo que regressões sejam detectadas imediatamente.

5. Minimize o raio de impacto : Controle com cuidado o escopo de cada experimento. Afete o número mínimo de usuários necessário para validar a hipótese. Amplie o escopo só depois que experimentos menores não produzirem impacto observável.

O ciclo de vida do experimento

Cada experimento segue o método científico³: diga o que você espera, mude uma variável, meça e compare.

flowchart LR
    H["1. Formular hipótese\nDefinir estado estável\ne comportamento esperado"]
    D["2. Projetar\nEscolher tipo de falha\ne raio de impacto"]
    I["3. Injetar\nIntroduzir a\nfalha controlada"]
    O["4. Observar\nMedir SLIs e o\ncomportamento do sistema"]
    A["5. Analisar\nComparar o real com\no comportamento esperado"]
    R["6. Melhorar\nCorrigir fraquezas;\natualizar runbooks"]

    H --> D --> I --> O --> A --> R
    R -->|"rodar de novo\ncom escopo maior"| H

Um experimento de caos que confirma a hipótese (o sistema se comporta como esperado) gera confiança naquele modo de falha. Um experimento que refuta a hipótese é uma descoberta: o sistema não trata aquela falha corretamente, e a equipe agora sabe disso antes que um incidente real a ensine.

Tipos de injeção de falhas

Controle do raio de impacto

O raio de impacto de um experimento de caos é o conjunto de usuários e sistemas afetados pela falha injetada. Controlá-lo é o que separa a prática de engenharia da imprudência.

flowchart TD
    S1["Estágio 1\nTestes unitários / de integração\n(nenhum usuário afetado)"]
    S2["Estágio 2\nAmbiente de staging / canário\n(só usuários internos)"]
    S3["Estágio 3\n1% do tráfego de produção\n(pequeno grupo de usuários)"]
    S4["Estágio 4\nProdução completa\n(todo o tráfego, todas as regiões)"]

    S1 -->|confiança aumenta| S2
    S2 -->|sem descobertas| S3
    S3 -->|SLIs se mantêm| S4

Controles práticos:

• Feature flags: habilitar a injeção de caos só para uma porcentagem das requisições.
• Janelas de tempo: rodar experimentos só no horário comercial, quando a equipe está disponível para abortar.
• Condições automáticas de aborto: se um SLI cair abaixo de um limite, interromper o experimento automaticamente.
• Leituras no escuro / tráfego espelhado (dark reads / shadow traffic): rodar experimentos sobre uma cópia dos dados de produção, não sobre o caminho principal.

GameDay

Um GameDay é um exercício de caos planejado, envolvendo toda a equipe, em que os engenheiros introduzem falhas deliberadamente e observam se o sistema e a equipe respondem corretamente. Diferentemente dos experimentos de caos contínuos e automatizados, GameDays são eventos colaborativos focados tanto no processo quanto na tecnologia.

Um GameDay típico:

1. Briefing: o cenário é descrito para a equipe (por exemplo, "O banco de dados principal falha às 10h"). Alternativamente, o cenário é mantido em segredo (um GameDay surpresa) para testar uma resposta a incidentes realista.
2. Execução: a falha é injetada. Os engenheiros acompanham os dashboards, executam os procedimentos de resposta a incidentes e se comunicam como fariam em um incidente real.
3. Observação: a equipe registra quanto tempo leva a detecção, quanto tempo leva a recuperação e quais runbooks foram eficazes.
4. Debriefing: um post-mortem sem culpados identifica o que funcionou bem, o que falhou e quais melhorias fazer no sistema e nos runbooks.

Ferramentas

Pré-requisito: observabilidade primeiro

Engenharia do caos sem observabilidade é perigosa e improdutiva. Antes de rodar qualquer experimento, a equipe precisa ser capaz de:

1. Medir o estado estável: dashboards de SLI precisam existir e mostrar os valores de referência.
2. Detectar desvios: alertas precisam disparar segundos depois de um SLI cair.
3. Atribuir causalidade: o rastreamento distribuído precisa permitir que a equipe identifique qual componente introduziu a latência ou os erros.
4. Abortar com segurança: um kill switch automatizado precisa conseguir interromper o experimento imediatamente se ele ultrapassar o raio de impacto definido.

Comece pela observabilidade. Depois adicione os padrões de resiliência. Depois rode experimentos de caos para validar que os padrões realmente funcionam.

Conexões

• SLI / SLO / SLA — o estado estável é expresso como SLIs, e os experimentos gastam error budget.
• Padrões de Resiliência — o que os experimentos de caos verificam.
• Observabilidade e Hands-on 10 — você precisa de métricas e traces para observar um experimento.
• Hands-on 5 — apagar um pod manualmente (kubectl delete pod) é o experimento de caos mais simples que você pode rodar no Kubernetes.

Pontos-chave

• Engenharia do caos é experimentação: uma hipótese de estado estável, uma injeção controlada, medição e análise.
• Ela nasceu do Chaos Monkey da Netflix (2010) e do Simian Army, e dos GameDays da Amazon.
• Injete falhas do mundo real (perda de instância, latência, erros de dependência) e mantenha o raio de impacto pequeno, ampliando-o passo a passo.
• Uma hipótese refutada é uma descoberta, não um fracasso.
• Pré-requisitos: observabilidade, padrões de resiliência, um aborto automatizado — e uma cultura sem culpados.