Chaos Engineering — Fundamentos

Em 2010, a Netflix migrou sua infraestrutura para a AWS. Em 2011, Cory Bennett e Ariel Tseitlin publicaram um post no blog de tecnologia da Netflix descrevendo o Chaos Monkey — uma ferramenta que, em horários de trabalho normal, aleatoriamente terminava instâncias de servidores de produção da Netflix. A motivação era direta: se a Netflix ia operar na nuvem onde instâncias poderiam falhar a qualquer momento, o time precisava ter certeza de que a falha de uma instância não derrubava o serviço. A única forma de ter essa certeza era verificar continuamente — não em staging, não em simulação, mas em produção com tráfego real de usuários.

A reação inicial da indústria oscilou entre admiração e incredulidade. "Você está terminando propositalmente seus próprios servidores em produção?" Era, à época, uma abordagem radical. Mas a lógica era impecável: se o sistema não sobrevive ao Chaos Monkey controlado, ele não vai sobreviver à falha real não controlada que inevitavelmente acontecerá. O custo de descobrir isso em produção de forma inesperada — em uma sexta-feira de noite, durante um pico de uso — é ordens de magnitude maior que o custo de descobrir durante um experimento planejado de terça de manhã.

Kolton Andress, que liderou o desenvolvimento da plataforma Simian Army no Netflix e depois fundou a Gremlin, formalizou os princípios em "Principles of Chaos Engineering" (principlesofchaos.org, 2014, atualizado 2016) — um documento que se tornou a referência canônica da disciplina. O livro Chaos Engineering de Casey Rosenthal et al. (O'Reilly, 2020) expandiu esses princípios em profundidade teórica e prática.

Este conceito cobre os fundamentos: o que chaos engineering é (e o que não é), a steady state hypothesis como núcleo metodológico, o papel dos game days, e por que chaos em staging raramente basta.

O que chaos engineering não é

Antes de definir o que é, vale definir o que não é — porque as confusões são comuns.

Chaos engineering não é destruição aleatória. Chaos Monkey tem "aleatório" no nome, mas o processo de chaos engineering é scientific: hipótese definida, steady state estabelecido, blast radius controlado, rollback planejado. Um engenheiro que roda kill -9 em processos aleatórios sem hipótese não está fazendo chaos engineering — está fazendo vandalismo.

Chaos engineering não é teste de stress. Teste de stress (covered no módulo 06) aplica carga crescente para encontrar limites de throughput. Chaos engineering injeta falhas nos componentes para verificar comportamento sob condições adversas — não volume alto, mas componente ausente, dependência lenta, disco cheio, rede particionada.

Chaos engineering não é exercício de uma vez ao ano. Se o chaos é praticado uma vez no lançamento de um serviço e nunca mais, o conhecimento acumulado decai rapidamente: o sistema muda, dependências mudam, configurações mudam. Chaos que não é contínuo ou ao menos periódico perde sua validade como garantia de resiliência.

A steady state hypothesis

O núcleo metodológico do chaos engineering é a steady state hypothesis — a hipótese de estado estável. Antes de qualquer experimento, o time deve definir: como é o comportamento normal do sistema, quantificado? Isso é o steady state. A hipótese é que o sistema continuará nesse estado estável mesmo quando a condição adversa for introduzida.

O steady state não é "nenhum erro" — sistemas em produção têm sempre algum ruído. É a baseline mensurável do comportamento normal: taxa de erro em X%, P99 de latência em Yms, throughput de Z req/s. O steady state deve ser capturável em métricas observáveis — não em "o sistema parece OK".

Exemplo de steady state hypothesis:

Sistema: API de checkout
Steady state:
  - taxa de erro < 0.1%
  - P99 de latência < 400ms
  - throughput = 500 req/s

Hipótese: O sistema manterá esse steady state
  mesmo quando a latência do serviço de inventário
  aumentar em 500ms.

Método: Injetar latência de 500ms nas chamadas
  ao serviço de inventário por 5 minutos.

Rollback automático: Se taxa de erro > 1% OU
  P99 > 800ms durante o experimento.

Resultado esperado: O checkout continua processando
  porque o timeout configurado para inventário é
  300ms e o fallback para cache de inventário
  é ativado.

A diferença entre o resultado esperado e o resultado observado é onde o aprendizado acontece. Se o sistema se comportar como esperado — ótimo, o teste confirmou a hipótese. Se o sistema se comportar diferente — melhor ainda, o experimento revelou uma fragilidade antes que um incidente real a revelasse.

Definindo bom steady state

Um steady state bem definido tem três características:

Mensurável: existe uma métrica concreta para verificar. "O sistema parece saudável" não é steady state. "Taxa de erro < 0.1% medida pelo load balancer nos últimos 5 minutos" é.

Automaticamente verificável: deve ser possível verificar o steady state programaticamente, não com um humano olhando para um dashboard. Isso permite abort automático quando o steady state é violado.

Relevante para o usuário: idealmente, o steady state é um SLI — algo que reflete a experiência do usuário, não a saúde interna da infra.

Os cinco princípios do chaos engineering

O documento principlesofchaos.org define cinco princípios fundamentais. Cada um tem uma razão específica de existir:

1. Build a Hypothesis around Steady State Behavior: o experimento começa pelo estado normal, não pela perturbação. Sem definir o normal, não dá para saber quando o anormal aconteceu.

2. Vary Real-world Events: as hipóteses devem ser baseadas em eventos que realmente acontecem: servidores morrem, discos ficam cheios, redes partem, dependências ficam lentas. Não inventar falhas improváveis — reproduzir falhas que o sistema já enfrentou ou que certamente vai enfrentar.

3. Run Experiments in Production: staging nunca replica produção com fidelidade suficiente — tráfego diferente, dados diferentes, configurações diferentes, dependências diferentes. Para validar resiliência real, é necessário testar no ambiente real. (Com blast radius controlado.)

4. Automate Experiments to Run Continuously: um experimento manual executado uma vez em um sprint de segurança anual não é chaos engineering — é teatro de resiliência. A automação contínua garante que resiliência é uma propriedade mantida ao longo do tempo, não apenas em um ponto no tempo.

5. Minimize Blast Radius: o experimento deve ser projetado para afetar o menor número possível de usuários. Um experimento que começa com 1% do tráfego, com abort automático ao primeiro sinal de degradação além do esperado, é radicalmente menos arriscado que um que afeta 100% dos usuários sem proteção.

Blast radius — o conceito mais crítico

Blast radius é a medida do impacto máximo de um experimento: quantos usuários podem ser afetados, por quanto tempo, em que magnitude. Minimizar o blast radius é o que separa chaos engineering responsável de irresponsabilidade operacional.

As dimensões do blast radius:

Escopo: quantas instâncias, quantos usuários, qual percentual do tráfego. Um experimento que afeta 1 de 100 instâncias tem blast radius menor que um que afeta todas as instâncias.

Duração: por quanto tempo o experimento roda antes do rollback. Um experimento de 5 minutos com rollback automático tem blast radius menor que um de 30 minutos com rollback manual.

Magnitude: a intensidade da perturbação. Latência adicional de 100ms tem blast radius menor que latência de 10 segundos ou que kill de processo.

Chaos em staging vs produção

A questão mais frequente ao adotar chaos engineering é: "por que não fazer só em staging?" A resposta é que staging raramente replica as características que mais importam para chaos:

Staging geralmente tem tráfego sintético ou muito menor que produção. Muitas falhas só se manifestam sob carga real — thread starvation, connection pool exhaustion, race conditions. Com 10% do tráfego de produção, esses problemas podem não aparecer.

Staging geralmente tem dados diferentes. Muitas falhas dependem de distribuição específica de dados: queries lentas em tabelas com bilhões de registros, bugs que só aparecem com combinações específicas de campos. Com dados de teste, esses cenários podem não ser cobertos.

Staging geralmente tem dependências simuladas. Se o serviço de pagamento em staging é um mock que sempre retorna 200, chaos em staging nunca vai descobrir o que acontece quando o serviço real de pagamento tem latência de 5 segundos.

A estratégia matura é usar staging para calibrar experimentos — acertar o blast radius, validar abort conditions, confirmar que o rollback funciona — e produção para validar resiliência real, com escopo mínimo inicial.

Game days — chaos como exercício coletivo

Game day é a prática de simular um incidente de forma controlada com todo o time presente — engenheiros, on-call, produto, às vezes observadores da liderança. O objetivo não é só testar a resiliência técnica do sistema, mas testar a resiliência do time: consegue detectar o problema? Responde adequadamente? Comunica corretamente? Resolve sem escalar desnecessariamente?

Um game day tem três fases:

Prepare: definir o cenário (qual falha será injetada), o steady state (como o sistema deve se comportar), quem são os participantes e seus papéis, quando começa e quando termina. Crucialmente: o time de on-call não sabe antecipadamente qual falha será injetada — apenas que haverá um game day.

Execute: injetar a falha. O time de on-call detecta, diagnostica, e responde como faria em um incidente real. Os facilitadores do game day observam e registram: quanto tempo para detectar? Qual foi o primeiro alerta? Qual foi a hipótese inicial de diagnóstico? Qual ação resolveu?

Debrief: imediatamente após a resolução, enquanto o contexto está fresco, revisar: o que funcionou? O que não funcionou? Quais são os action items? O debrief deve ser blameless — o objetivo é aprender, não apontar culpa.

O Google chamava seus game days de DiRT (Disaster Recovery Testing) e os executava anualmente em grande escala — simulações que incluíam falhas de datacenter inteiro, partições de rede cross-região, e perda de serviços críticos. O que o DiRT revelou repetidamente é que os maiores problemas em incidentes não eram técnicos — eram de comunicação, escalação, e processo.

A maturidade do chaos engineering

Não há um caminho único para adotar chaos engineering, mas há um caminho progressivo que faz sentido para a maioria dos times:

Nível 0 — Reativo:
  Sem chaos. Incidentes ensinam resiliência na marra.

Nível 1 — Game days manuais:
  Simulações periódicas (trimestrais ou anuais).
  Aprendizado pontual.

Nível 2 — Experimentos controlados:
  Chaos Toolkit ou Gremlin com hipóteses definidas.
  Executados manualmente, mas com processo.

Nível 3 — Chaos automatizado em staging:
  Bateria de experimentos no CI/CD.
  Garante que deploys não regridem resiliência.

Nível 4 — Chaos contínuo em produção:
  Experimentos rodando continuamente em prod,
  com blast radius mínimo e abort automático.
  Netflix Chaos Monkey é a referência.

A maioria dos times que não é Netflix ou Google fica no nível 2–3, e isso é completamente válido. O nível 4 requer maturidade operacional, observabilidade robusta, e cultura de confiança no time que demora anos para construir.

Como praticar

1. Definir um steady state para um serviço. Escolha um serviço que você opera. Defina o steady state em três métricas: taxa de erro, latência P99, e throughput. Capture os valores atuais. Isso é o pré-requisito para qualquer experimento — sem steady state definido, não há como saber se o experimento foi bem-sucedido.
2. Escrever uma hipótese de chaos. Sem executar nada, escreva uma hipótese de chaos para o serviço acima: qual falha você injetaria, qual seria a steady state hypothesis, quais seriam as abort conditions, e o que você esperaria observar. Discuta com o time. O exercício de escrever a hipótese frequentemente revela pontos de fragilidade antes de qualquer experimento.
3. Conduzir um tabletop game day. Reúna o time e simule um incidente verbalmente — sem injetar falha real. Um facilitador descreve o cenário: "O serviço de pagamento está retornando 503 para 30% das chamadas. O alerta disparou. O que vocês fazem?" O time responde. Identifiquem: quais runbooks existem? Quais são os gaps no processo de resposta? Documentem os action items.