Engenharia do caos

Engenharia do caos não é quebrar produção por esporte. É um método científico aplicado à confiabilidade: você escreve a hipótese de como o sistema deveria se comportar diante de uma falha, provoca essa falha em escala controlada e compara. A falha vai acontecer de qualquer jeito — a escolha é entre descobrir o comportamento às três da manhã ou numa terça-feira à tarde, com o time inteiro observando.

A hipótese vem antes do experimento

Sem hipótese escrita, o exercício vira anedota. O formato:

Hipótese. Se uma das três réplicas do serviço de pedidos for terminada, o tráfego é redistribuído em menos de 10 segundos, a taxa de erro fica abaixo de 0,1% e nenhum alerta de página dispara.

Como medimos. sum(rate(http_requests_total{status=~"5..", route="/pedidos"}[1m])) e p95 de latência, no painel do serviço.

Abortamos se. A taxa de erro passar de 1% por mais de 30 segundos.

O experimento é interessante justamente quando você não tem certeza da resposta. Se todo mundo sabe o que vai acontecer, não há nada a aprender ali.

Raio de alcance controlado

Comece pequeno e cresça só depois de confirmar a hipótese: um Pod, depois uma zona, depois uma dependência. E defina antes:

• Botão de parada. Um comando que encerra o experimento em segundos, testado antes de começar.
• Janela. Horário de baixo tráfego, dia útil, com o time disponível — nunca sexta à tarde nem véspera de campanha.
• Aviso. Suporte e plantão sabem que está acontecendo, e o canal está aberto.
• Limite de impacto. Um percentual do tráfego, um namespace, uma zona.

Homologação é onde se aprende a operar a ferramenta. Mas o aprendizado real vem de produção, porque é lá que existem os dados, o tráfego e as dependências que ninguém mapeou — só vá para lá quando os experimentos em homologação já forem chatos de tão previsíveis.

Experimentos que valem a pena

Em ordem crescente de risco e de aprendizado:

• Terminar um Pod (o mais barato: valida probes, PDB e redistribuição).
• Adicionar 300 ms de latência a uma dependência (valida timeout e retry).
• Fazer uma dependência retornar erro (valida circuit breaker e modo degradado).
• Esgotar CPU ou memória de um nó (valida limites e despejo).
• Tirar uma zona de disponibilidade (valida a arquitetura que você desenhou no slide).
• Expirar um certificado ou credencial em homologação (valida rotação e alerta).

# Chaos Mesh: 300 ms de latência no serviço de pagamento, por 5 minutos, em 1 Pod
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata: { name: latencia-pagamento, namespace: loja }
spec:
  action: delay
  mode: one                       # um Pod só — raio de alcance mínimo
  selector:
    namespaces: [loja]
    labelSelectors: { app: pagamento }
  delay: { latency: "300ms", jitter: "50ms" }
  duration: "5m"                  # encerra sozinho mesmo se ninguém estiver olhando

O duration obrigatório é um guarda-corpo: experimento que depende de alguém lembrar de desligar já causou incidente.

Game days

O experimento testa o sistema; o game day testa o sistema e as pessoas. Reserve duas horas, escolha um cenário realista, e observe o que acontece de verdade: o alerta dispara? Quanto tempo até alguém ver? O runbook está correto? Quem assume o comando? A comunicação sai?

Boa parte dos achados não é técnica — é o runbook desatualizado, o acesso que ninguém do plantão tem, o painel que só uma pessoa sabe abrir. Registre os resultados como um postmortem normal, com ações, dono e prazo.

Não faça isso sem observabilidade

Pré-requisitos honestos, e cada um tem um motivo:

1. Você enxerga o sintoma em tempo real. Sem painel confiável, você injeta falha e não sabe o que aconteceu.
2. Os alertas de página funcionam. Se o experimento passa despercebido, o achado já apareceu — e é grave.
3. Existe reversão rápida. Rollback e botão de parada testados.
4. O time concordou. Caos surpresa quebra confiança, e confiança é o que sustenta a prática.

Se você ainda não tem esses quatro, o próximo passo não é instalar uma ferramenta de caos: é fechar a lacuna de observabilidade. O experimento só tem valor quando você consegue medir a resposta.

Próximo passo: você fechou a trilha de SRE. Leve as práticas para a organização em Métricas DORA e revise seus objetivos em SLO na prática.