O que é
Engenharia do Caos é a prática de quebrar de propósito o seu sistema em produção (ou em ambientes parecidos), de forma controlada, pra descobrir fraquezas antes que elas descubram você num feriado.
A história começa na Netflix por volta de 2010, com o lendário Chaos Monkey: uma ferramenta que mata aleatoriamente instâncias EC2 da Netflix em produção, durante o horário comercial. Soa loucura, mas a lógica é genial: se uma instância caindo derruba o sistema, o problema já existe — só não foi acionado ainda. Melhor descobrir às 14h de quarta-feira (com a equipe toda online) do que às 3h de domingo.
Por que usar?
Algumas verdades inconvenientes:
- Sistemas distribuídos têm muitos modos de falha, e a maioria você não vai prever lendo documentação.
- Testes unitários, de integração e de carga não capturam falhas como "rede entre dois pods fica com 30% de packet loss" ou "o disco do banco fica 100% cheio às 3h da manhã".
- Equipes que nunca viveram uma falha não sabem operar uma falha. Quando ela vem, é caos puro.
Engenharia do caos resolve os três pontos. Os benefícios concretos:
- Descobre dependências escondidas ("não sabíamos que o serviço A dependia do B").
- Valida runbooks e alertas (alerta dispara mesmo? Runbook funciona?).
- Treina o time pra incidentes reais.
- Mede mean time to recovery (MTTR) — quanto tempo leva pra recuperar.
Os princípios
A comunidade documentou os Princípios da Engenharia do Caos (resumo):
- Defina o "estado estável" (steady state): qual métrica de negócio prova que tá tudo bem? RPS, taxa de conversão, etc.
- Hipotetize que o estado estável continuará apesar do experimento.
- Introduza variáveis do mundo real: queda de servidor, latência, erros, falhas de DNS.
- Refute a hipótese: se o estado estável quebra, você achou um problema.
- Minimize o raio de explosão (blast radius): comece pequeno (1 pod, 1% do tráfego, ambiente staging).
Ferramentas
- Chaos Monkey (Netflix): mata instâncias aleatórias.
- Litmus / Chaos Mesh: chaos engineering nativo de Kubernetes (mata pods, injeta latência, corrompe pacotes, lota disco).
- Gremlin: plataforma comercial completa.
- Toxiproxy (Shopify): proxy TCP que injeta latência, timeouts, drops em ambiente de dev.
- AWS Fault Injection Simulator: se você vive na AWS.
Tipos de experimento clássicos
- Matar instância/pod.
- Adicionar latência (50ms, 500ms, 5s).
- Injetar erros HTTP (5xx).
- Encher o disco / a CPU / a memória.
- Bloquear chamadas DNS.
- Particionar a rede entre dois serviços.