Engenharia do caos não é quebrar coisas

O nome não ajuda. Engenharia do caos não é matar processos ao acaso para ver o que acontece. É um método com um formato específico, e é o formato que o torna útil em vez de imprudente.

Os quatro passos

Formule uma hipótese sobre o estado estável. Não "o sistema funciona", e sim algo mensurável: "99% das requisições do roadmap devolvem 200 em até 500 milissegundos."

Injete uma falha específica: uma coisa, escolhida de propósito.

Observe se a hipótese continua valendo.

Pare se não continuar, e você terá aprendido algo que não sabia.

flowchart TB
  H["uma hipótese mensurável sobre o estado estável"] --> I["injete uma falha específica"]
  I --> O["observe a mesma medição"]
  O --> Q{"a hipótese continua valendo?"}
  Q -->|sim| L["confiança, só sobre aquela falha"]
  Q -->|não| F["um achado. pare o experimento"]
  H --> N["sem hipótese, isso é só uma queda"]

Por que a hipótese vem primeiro

Sem ela, você não distingue sucesso de fracasso.

Se você derruba o banco e o site quebra, não aprendeu nada, porque todo mundo esperava isso. Se você derruba o banco e o site continua servindo páginas em cache por quatro minutos, isso é uma descoberta. A hipótese é o que torna visível a diferença entre as duas coisas.

Uma hipótese em que você confia é o tipo mais valioso de testar. Uma hipótese confiante que falha mostra onde o seu modelo mental estava errado, e esse é o produto inteiro desta prática.

Para que ela serve

Ela serve para encontrar as falhas que ninguém anotou.

Um sistema tem dependências documentadas e dependências reais, e o conjunto real é sempre maior: uma biblioteca que tenta de novo em silêncio, um tempo limite mais longo do que você pensa, uma verificação de saúde que reporta sucesso pelo motivo errado.

Os testes verificam o que você especificou. A engenharia do caos descobre o que você não especificou.

Por que o nome persiste

Ele veio da Netflix, de uma ferramenta que matava instâncias de produção ao acaso, e pegou.

Matar ao acaso era a parte menos importante e a que se transferiu pior. Funcionava lá porque aquele sistema já era redundante o bastante para que uma perda aleatória não fosse nada. Para um sistema que não é, o mesmo ato não é um experimento.

Pontos-chave

• Engenharia do caos é hipótese, injeção, observação e parada, e não destruição aleatória.
• A hipótese precisa ser mensurável, ou você não distingue sucesso de fracasso.
• Uma hipótese confiante que falha é o resultado mais valioso disponível.
• Os testes verificam o que você especificou, e a engenharia do caos descobre o que você não especificou.
• Matar instâncias ao acaso funcionava na Netflix porque aquele sistema já era redundante.