Engenharia do Caos

O BoxOffice agora tem timeouts, um retry com jitter, um circuit breaker, um bulkhead, um fallback, uma região em warm standby e uma política de backups. Eles funcionam? Os testes unitários passam. Mas ninguém nunca viu o breaker do pagamento abrir com tráfego real, ninguém nunca promoveu o banco standby, e ninguém sabe quanto tempo o failover regional realmente leva. A primeira vez em que algo disso vai importar será durante uma abertura de vendas real no estádio, com dois milhões de fãs assistindo. O único jeito de saber é causar as falhas você mesmo, de propósito, enquanto observa e está pronto.

A engenharia do caos é 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 as falhas acontecerem, você as injeta deliberadamente, de forma controlada, e usa o que aprende para corrigir fraquezas antes que incidentes reais as encontrem.

"The best way to avoid failure is to fail constantly." — John Ciancutti, Netflix, 2010⁴

De onde veio

A ideia é mais antiga que o nome. Na Amazon, no começo dos anos 2000, Jesse Robbins conduzia exercícios de GameDay que causavam deliberadamente falhas grandes em produção para expor fraquezas escondidas — no software e nos times que o operavam³.

A Netflix deu nome e ferramentas à prática. Depois de sair do próprio data center para a AWS, por volta de 2010 — onde qualquer instância pode sumir a qualquer momento —, ela criou o Chaos Monkey, um serviço que encerra instâncias de produção aleatórias em horário comercial, para que todo time precisasse construir serviços que sobrevivem à perda de instâncias, e os engenheiros estivessem em suas mesas para ver o que quebrava⁴. Veio então todo um Simian Army: o Latency Monkey injetava atrasos nas chamadas, o Chaos Gorilla simulava a perda de uma zona de disponibilidade inteira. Em 2016, engenheiros da Netflix formalizaram a disciplina em um artigo da IEEE Software², de onde vêm os princípios abaixo.

A percepção central: falha não é um caso especial a evitar; é o ambiente em que os sistemas de produção vivem, e o único jeito de saber se um sistema sobrevive a ela é testá-lo ali.

Princípios

Os Principles of Chaos Engineering¹ definem a disciplina com cinco ideias:

1. Construa uma hipótese sobre o comportamento em estado estável : Descreva o "normal" com saídas mensuráveis que importam para os usuários — os SLIs (SLOs): taxa de sucesso das compras, p99 das reservas, atualidade dos e-mails. A hipótese: "o estado estável continua mesmo quando X acontece."

2. Varie eventos do mundo real : Injete falhas que de fato acontecem: perda de instâncias e de zonas, latência, perda de pacotes, uma dependência devolvendo erros, disco cheio, relógio desajustado, um pico de tráfego, um certificado expirado.

3. Rode experimentos em produção : A homologação raramente tem o formato do tráfego, o volume de dados ou o comportamento das dependências da produção. Produção é o objetivo — alcançado aos poucos, não o primeiro passo.

4. Automatize os experimentos para rodarem continuamente : Sistemas mudam todo dia; uma fraqueza corrigida hoje pode voltar com o deploy da semana que vem. Repita os experimentos automaticamente.

5. Minimize o raio de impacto : Afete o menor número possível de usuários, tenha um botão de abortar e amplie o escopo só depois que experimentos menores passarem.

O ciclo de vida de um experimento

Cada experimento segue o método científico: prever, mudar uma variável, medir, comparar⁵.

flowchart LR
    H["1. Hipótese<br/>estado estável + comportamento esperado"] --> D["2. Projeto<br/>falha, escopo, condições de aborto"]
    D --> I["3. Injeção<br/>da falha controlada"]
    I --> O["4. Observação<br/>SLIs, traces, estado do breaker"]
    O --> A["5. Análise<br/>esperado vs real"]
    A --> F["6. Melhoria<br/>corrigir, atualizar runbooks"]
    F -->|"repetir com escopo maior"| H

Um experimento que confirma a hipótese é evidência de que uma defesa funciona. Um que a refuta é uma descoberta: uma fraqueza encontrada no seu cronograma, com o time pronto, em vez de às 10:00 de um dia de vendas.

export const options = {
  scenarios: {
    pay: {
      executor: 'constant-arrival-rate',
      exec: 'pay',
      rate: Number(__ENV.PAY_RATE || 20),
      timeUnit: '1s',
      duration: DURATION,
      preAllocatedVUs: 50,
      maxVUs: 600,
    },
    browse: {
      executor: 'constant-arrival-rate',
      exec: 'browse',
      rate: 20,
      timeUnit: '1s',
      duration: DURATION,
      preAllocatedVUs: 20,
      maxVUs: 300,
    },
  },
  summaryTrendStats: ['avg', 'med', 'p(95)', 'p(99)', 'max'],
  thresholds: {
    'http_req_duration{name:pay}': ['p(95)<1500'],
    'http_req_duration{name:browse}': ['p(95)<200'], // the collateral damage
    'http_req_failed{name:browse}': ['rate<0.01'],
  },
};

Injeção de falhas

Toxiproxy: caos no seu notebook

O Toxiproxy é um proxy TCP com uma API para adicionar "toxics" — latência, timeouts, limites de banda, resets de conexão — a uma conexão. Coloque-o entre o payment e o stub do provedor no Docker Compose, e aponte o payment para o proxy:

# docker-compose.yaml (excerpt)
services:
  toxiproxy:
    image: ghcr.io/shopify/toxiproxy:2.9.0
    ports:
      - "8474:8474"           # Toxiproxy API
  payment:
    environment:
      PROVIDER_URL: http://toxiproxy:8666   # instead of http://provider-stub:8080

# create the proxy: toxiproxy:8666 -> provider-stub:8080
toxiproxy-cli create -l 0.0.0.0:8666 -u provider-stub:8080 provider

# experiment 1: 3 s of latency (+/- 500 ms) on every response
toxiproxy-cli toxic add -t latency -a latency=3000 -a jitter=500 provider

# experiment 2: connections hang forever (a "black hole")
toxiproxy-cli toxic add -t timeout -a timeout=0 provider

# end of the experiment
toxiproxy-cli toxic remove -n latency_downstream provider
toxiproxy-cli toxic remove -n timeout_downstream provider

[
  { "name": "payment", "listen": "0.0.0.0:18085", "upstream": "payment:8085", "enabled": true },
  { "name": "psp",     "listen": "0.0.0.0:18095", "upstream": "psp:8080",     "enabled": true }
]

toxic() { # proxy, json
  curl -s -X POST "$API/proxies/$1/toxics" -d "$2" > /dev/null
}
echo "$(date +%T) experiment $1"
case "$1" in
  1) toxic payment '{"name":"gd","type":"latency","stream":"downstream","attributes":{"latency":2000,"jitter":300}}' ;;
  2) toxic psp '{"name":"gd","type":"timeout","stream":"downstream","attributes":{"timeout":0}}' ;;
  3) toxic payment '{"name":"gd","type":"reset_peer","toxicity":0.4,"attributes":{"timeout":0}}' ;;
  4) curl -s -X POST "$API/proxies/payment" -d '{"enabled":false}' > /dev/null ;;
  5) docker compose pause db ;;
  6) toxic payment '{"name":"gd","type":"bandwidth","stream":"downstream","attributes":{"rate":1}}' ;;
  reset) curl -s -X POST "$API/reset" > /dev/null; docker compose unpause db 2> /dev/null || true ;;
  *) echo "unknown experiment"; exit 1 ;;
esac

Rode o k6 antes, durante e depois de cada toxic e compare os números — esse é o passo "Meça" do Hands-on 9.

Chaos Mesh: caos no Kubernetes

No Kubernetes, os experimentos são declarados como recursos, versionados no Git e limitados no tempo:

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: payment-latency
  namespace: boxoffice
spec:
  action: delay
  mode: one                  # affect a single pod: small blast radius
  selector:
    namespaces: [boxoffice]
    labelSelectors:
      app: payment
  delay:
    latency: "3s"
    jitter: "500ms"
  duration: "10m"            # the experiment ends by itself

Controlando o raio de impacto

O raio de impacto de um experimento é o conjunto de usuários e sistemas que ele pode afetar. Controlá-lo é o que separa engenharia de imprudência.

flowchart LR
    S1["1. Local / Compose<br/>nenhum usuário"] -->|"a hipótese se mantém"| S2["2. Homologação sob carga k6<br/>usuários internos"]
    S2 -->|"sem descobertas"| S3["3. Um pod canary em produção<br/>alguns % do tráfego"]
    S3 -->|"os SLIs se mantêm"| S4["4. Produção mais ampla<br/>uma zona, depois uma região"]

• Condições de aborto ligadas aos SLOs: pare automaticamente se o burn rate do error budget passar de um limite ou se um SLI-chave cair (o AWS FIS e o Chaos Mesh suportam condições de parada; no mínimo, uma pessoa com um botão).
• Limitado no tempo: todo experimento tem duração e se limpa sozinho.
• Horário comercial, nunca durante uma abertura de vendas: o time precisa estar presente; a política de error budget decide se dá para pagar o custo.
• Avise: o plantão e o time de suporte sabem que um experimento está rodando.

Game days

Um game day é um exercício planejado, com o time todo, em que falhas são injetadas e as pessoas respondem como num incidente real. Experimentos automatizados testam o software; game days testam também os runbooks, os dashboards, os alertas e a comunicação.

Verificação contínua

Depois que um experimento passa, mantenha-o passando:

• No CI: testes de integração com Toxiproxy (o Testcontainers tem um módulo de Toxiproxy) verificam que o cliente desiste depois do timeout e que o breaker abre — barato, em todo build.
• Agendado em homologação: workflows do Chaos Mesh ou do LitmusChaos rodam os experimentos padrão toda noite contra o último deploy.
• Em produção, pequeno: um pod-kill recorrente num canary, uma restauração mensal de backup, um exercício de failover regional duas vezes por ano (Recuperação de desastres).

Observabilidade primeiro

Caos sem observabilidade é só quebrar coisas. Antes de injetar qualquer coisa, você precisa conseguir:

1. Ver o estado estável — dashboards de SLI com valores de referência.
2. Detectar o desvio — alertas que disparam em minutos (alertas de burn rate).
3. Explicá-lo — traces que mostram qual chamada ficou lenta, métricas de breakers e pools.
4. Pará-lo — um botão de abortar que funciona em segundos.

Observabilidade primeiro, depois padrões de resiliência, depois experimentos de caos para provar que os padrões funcionam.

É também a ordem dos labs: o lab 8 instrumenta o BoxOffice antes de o lab 9 quebrá-lo de propósito, e os operadores do game day trabalham com o dashboard e os alertas do lab 8.

Como se conecta

flowchart LR
    SS["estado estável = SLIs<br/>→ SLOs"] --> HYP["hipótese"]
    HYP --> INJ["injetar: Toxiproxy,<br/>Chaos Mesh, AWS FIS"]
    LOAD["carga do k6 durante o teste<br/>→ Performance"] --> INJ
    INJ --> PAT["defesas sob teste:<br/>breaker, bulkhead, fallback"]
    INJ --> DR["failover, restauração<br/>→ Recuperação de desastres"]
    OBS["métricas, traces, alertas de burn rate<br/>→ Observabilidade"] --> OA["observar e abortar"]
    PAT --> OA
    DR --> OA
    OA --> BR["ampliar o raio de impacto:<br/>local → canário → zona"]
    OA --> GD["game day + debrief sem culpados<br/>→ Resposta a incidentes"]
    GD --> HYP

Componentes da paleta: thirdparty (o stub do provedor atrás do Toxiproxy) · app (pods de order derrubados durante o game day) · kafka (um broker parado) · sql (failover para o standby) · cache (Redis esvaziado: proteção contra stampede) · metrics · tracing · alerting (sem eles não há caos possível). Cenários: flash-sale (perfil chaos), cascading-failure. Continua em: Observabilidade — resposta a incidentes, Performance — testes de carga, Cloud-native — Kubernetes, Hands-on 9 — pagamento e Toxiproxy, Projeto — game day.