Sobrevivendo ao Caos: Injetando Falhas com o ChaosEngineeringMasterDeck

"Se o seu sistema só funciona quando nada dá errado, ele não está pronto para produção. Está só com sorte."

Às 2h17 da manhã, o alerta de latência alta dispara. O serviço de pagamentos de um parceiro começou a responder em 8 segundos. Em poucos minutos, as threads do nosso backend estão todas presas esperando uma resposta que não vem, o checkout para de funcionar e o time de plantão acorda.

Eu já vivi essa história, e o pior não foi a falha em si. O pior foi descobrir durante o incidente que nossa arquitetura não estava preparada para ela.

Foi por isso que passamos a quebrar coisas de propósito, de forma controlada, e a organizar essa prática em um baralho de experimentos: o ChaosEngineeringMasterDeck. Neste artigo eu explico como ele funciona e mostro um experimento completo, da hipótese ao resultado.

Nota: o cenário e os números deste artigo são didáticos, construídos para ilustrar o método. Os conceitos, as ferramentas e os trechos de código, porém, são reais e aplicáveis.

Sumário

1. O que é Chaos Engineering (e por que quebrar coisas de propósito)
2. Dissecando o ChaosEngineeringMasterDeck
3. Estudo de caso: a carta "Parceiro Lento"
4. Observabilidade e resultados
5. Conclusão: o que o caos nos ensinou

1. O que é Chaos Engineering (e por que quebrar coisas de propósito)

Chaos Engineering é a disciplina de realizar experimentos controlados em um sistema para ganhar confiança de que ele resiste a condições turbulentas em produção. A prática foi popularizada pela Netflix com o Chaos Monkey, que desligava instâncias aleatoriamente para forçar os engenheiros a construir serviços tolerantes a falhas.

Em sistemas distribuídos, a pergunta mudou. Já não é "será que algo vai falhar?", e sim "quando algo vai falhar, e o que acontece com o usuário?". Com dezenas de microsserviços, redes, filas, bancos e dependências de terceiros, falhas parciais são o estado normal da operação.

A mudança de mentalidade

Por que não bastam os testes tradicionais?

Testes unitários e de integração verificam se o código faz o que esperamos. O caos descobre o que não esperávamos: timeouts mal configurados, retries que amplificam o problema, filas que enchem, fallbacks que nunca foram exercitados.

Os conceitos-chave

Antes de seguir, vale fixar o vocabulário que vai aparecer no restante do artigo:

• Estado estável (steady state): o comportamento normal e mensurável do sistema, definido por métricas de negócio e técnicas. Exemplo: "99,5% dos checkouts são concluídos com sucesso, com p95 abaixo de 800 ms".
• Hipótese: a aposta de que o estado estável se mantém mesmo durante a falha injetada.
• Variável (falha injetada): o evento que alteramos no ambiente (latência, queda de instância, perda de pacotes, erro de DNS).
• Blast radius (raio de explosão): o limite do impacto possível do experimento. Começamos pequenos de propósito.
• Observabilidade: a capacidade de entender o que acontece dentro do sistema a partir de métricas, logs e traces. Sem ela, o experimento é só uma queda.
• Abort conditions (condições de aborto): o "botão vermelho". Se uma métrica ultrapassar o limite, o experimento é interrompido automaticamente.

Produção ou staging?

O ideal é a produção, porque só lá existem o tráfego, os dados e as interações reais. Mas ninguém começa por lá. O caminho seguro é:

Local/Dev  →  Staging  →  Produção (canário, baixo tráfego)  →  Produção (ampliado)

Cada degrau só é subido quando o experimento anterior já passou sem surpresas.

2. Dissecando o ChaosEngineeringMasterDeck

O que é o Master Deck?

O ChaosEngineeringMasterDeck é o nosso catálogo gamificado de experimentos de caos. Em vez de uma planilha confusa de "testes de resiliência", cada experimento vira uma carta padronizada. O baralho inteiro vive em um repositório Git, com uma carta por arquivo, e é usado em dois momentos:

1. Game Days: sessões em que o time "compra" uma carta, executa o experimento e discute o resultado.
2. Regressão de resiliência: as cartas mais maduras são automatizadas e rodam periodicamente em staging.

A gamificação tem um objetivo prático: tirar o medo. Quando quebrar o sistema vira uma dinâmica de equipe com regras claras, e não um ato isolado e arriscado, mais gente participa e mais fragilidades aparecem.

Anatomia de uma carta

Toda carta segue a mesma estrutura, que reflete o método científico do Chaos Engineering:

Os naipes do baralho

Organizamos as cartas por tipo de falha:

• ♠️ Infraestrutura: queda de instância, de zona de disponibilidade (AZ), esgotamento de CPU/memória.
• ♥️ Rede: latência, perda de pacotes, partição de rede, falha de DNS.
• ♦️ Dependências: banco indisponível, API de terceiros lenta, fila cheia, cache fora do ar.
• ♣️ Aplicação: memory leak, deploy defeituoso, feature flag quebrada, dados corrompidos.

Exemplo de carta em YAML

Guardar a carta como código permite versionar, revisar em pull request e até automatizar a execução:

# cards/dependencias/parceiro-lento.yaml
id: DEP-007
nome: "Parceiro Lento"
naipe: dependencias
risco: medio

estado_estavel:
  descricao: "Checkout saudável sob carga normal"
  metricas:
    - "taxa de sucesso do checkout >= 99,5%"
    - "latência p95 do POST /checkout <= 800ms"
    - "taxa de erros 5xx <= 0,5%"

hipotese: >
  Se o serviço de pagamentos do parceiro passar a responder com 3s de
  latência adicional, o Circuit Breaker abrirá em até 30s e o checkout
  continuará aceitando pedidos em modo degradado (pagamento pendente),
  mantendo a taxa de sucesso acima de 95%.

variavel:
  tipo: latencia
  alvo: "payment-gateway (via proxy Toxiproxy)"
  valor: "+3000ms, jitter 500ms"
  duracao: "10 minutos"

blast_radius:
  ambiente: staging
  escopo: "somente chamadas do order-service ao payment-gateway"
  trafego_afetado: "100% do tráfego sintético; 0% de usuários reais"

condicao_de_aborto:
  - "taxa de erros 5xx > 10% por 2 minutos"
  - "pool de threads do order-service > 90% por 1 minuto"

padroes_esperados:
  - Timeout agressivo
  - Circuit Breaker
  - Fallback (pedido com pagamento pendente)
  - Bulkhead (isolamento de threads)

3. Estudo de caso: a carta "Parceiro Lento"

A arquitetura sob teste

Nosso sistema de e-commerce roda na AWS. Resumindo o que importa para este experimento:

                    ┌──────────────────────┐
   Usuário ───────► │  Application Load    │
                    │  Balancer (ALB)      │
                    └──────────┬───────────┘
                               │
              ┌────────────────┴────────────────┐
              │   Auto Scaling Group (2 AZs)    │
              │  ┌───────────┐   ┌───────────┐  │
              │  │ order-svc │   │ order-svc │  │   Spring Boot
              │  │   (AZ-a)  │   │   (AZ-b)  │  │
              │  └─────┬─────┘   └─────┬─────┘  │
              └────────┼───────────────┼────────┘
                       │               │
           ┌───────────┴──┐     ┌──────┴──────────┐
           │ RDS Postgres │     │ payment-gateway │
           │  (Multi-AZ)  │     │  (API externa)  │
           └──────────────┘     └─────────────────┘

• order-service: backend em Spring Boot que recebe o checkout, grava o pedido e cobra o pagamento.
• payment-gateway: API de um parceiro. É a dependência que não controlamos.
• RDS PostgreSQL Multi-AZ e Auto Scaling Group distribuído em duas zonas de disponibilidade.

A carta sorteada

No Game Day, o time comprou DEP-007 — Parceiro Lento (🟡 risco médio).

Estado estável: 99,5% de sucesso no checkout e p95 abaixo de 800 ms.

Hipótese: "Mesmo com +3s de latência no gateway, o Circuit Breaker abre em até 30s e o checkout segue funcionando em modo degradado, com taxa de sucesso acima de 95%."

Definindo o blast radius

Esta é a etapa que separa um experimento sério de uma irresponsabilidade. Nosso raio de explosão foi deliberadamente pequeno:

• Ambiente: staging, com tráfego sintético gerado por k6.
• Escopo: apenas a chamada order-service → payment-gateway. O banco, o ALB e as demais rotas não foram tocados.
• Duração: 10 minutos, com a condição de aborto sempre vigiada.
• Rollback: remover a "toxic" do proxy, uma operação de segundos.

Injetando a falha

Usamos o Toxiproxy como proxy entre o order-service e o gateway, o que permite injetar latência sem alterar o código da aplicação:

# Cria o proxy para o gateway (o order-service passa a apontar para ele)
toxiproxy-cli create payment_gateway \
  --listen 0.0.0.0:8474 \
  --upstream payment-gateway.staging.internal:443

# Injeta 3000ms de latência com 500ms de jitter (a "carta" em ação)
toxiproxy-cli toxic add payment_gateway \
  --type latency \
  --attribute latency=3000 \
  --attribute jitter=500

# Rollback imediato (botão vermelho)
toxiproxy-cli toxic remove payment_gateway --toxicName latency_downstream

O que o código precisava ter (e a hipótese testava)

A hipótese dependia de quatro defesas configuradas com Resilience4j no Spring Boot:

# application.yml
resilience4j:
  timelimiter:
    instances:
      paymentGateway:
        timeout-duration: 2s          # não esperamos mais que 2s

  circuitbreaker:
    instances:
      paymentGateway:
        sliding-window-type: COUNT_BASED
        sliding-window-size: 20
        failure-rate-threshold: 50    # abre com 50% de falhas
        slow-call-duration-threshold: 2s
        slow-call-rate-threshold: 50  # chamadas lentas também contam!
        wait-duration-in-open-state: 30s
        permitted-number-of-calls-in-half-open-state: 5

  bulkhead:
    instances:
      paymentGateway:
        max-concurrent-calls: 20      # isola o pool de threads
        max-wait-duration: 100ms

@Service
public class PaymentService {

    private static final Logger log = LoggerFactory.getLogger(PaymentService.class);

    private final PaymentGatewayClient gateway;

    public PaymentService(PaymentGatewayClient gateway) {
        this.gateway = gateway;
    }

    @CircuitBreaker(name = "paymentGateway", fallbackMethod = "pagamentoPendente")
    @Bulkhead(name = "paymentGateway")
    @TimeLimiter(name = "paymentGateway")
    public CompletableFuture<PaymentResult> cobrar(Order order) {
        return CompletableFuture.supplyAsync(() -> gateway.charge(order));
    }

    // Fallback: não derruba o pedido, apenas agenda a cobrança para depois
    private CompletableFuture<PaymentResult> pagamentoPendente(Order order, Throwable ex) {
        log.warn("Gateway indisponível/lento. Pedido {} em modo degradado: {}",
                 order.getId(), ex.getClass().getSimpleName());
        return CompletableFuture.completedFuture(
            PaymentResult.pending(order.getId())   // cobrança reprocessada por fila
        );
    }
}

A ideia do fallback é de negócio, não só técnica: é melhor aceitar o pedido com pagamento pendente e cobrar depois do que perder a venda.

4. Observabilidade e resultados

Como monitoramos

Sem observabilidade, o experimento vira um "derrubei e não sei o que aconteceu". Nosso painel (Prometheus + Grafana, com traces no OpenTelemetry) acompanhava, lado a lado:

• Negócio: taxa de sucesso do checkout e pedidos em modo "pagamento pendente".
• Aplicação: latência p50/p95/p99, taxa de erros 5xx.
• Resiliência: estado do Circuit Breaker (closed, open, half_open) via métricas do Resilience4j no Actuator.
• Recursos: uso do pool de threads, CPU e conexões abertas.

Linha do tempo do experimento

Resultado: a hipótese se confirmou?

A arquitetura sobreviveu. Mas o experimento não termina aí: o maior valor está no que não saiu como o planejado.

As surpresas (onde o caos paga a conta)

1. O pico inicial de latência foi pior que o esperado. Nos primeiros 12 segundos, antes de o breaker abrir, o p95 chegou a 1,9 s. Reduzir a janela de deslizamento (sliding-window-size de 20 para 10) fez o breaker reagir mais rápido, e anotamos essa melhoria para a próxima rodada.
2. O reprocessamento de pagamentos pendentes não tinha limite de taxa. Quando o gateway voltou, a fila disparou todas as cobranças de uma vez, quase criando uma segunda falha. Adicionamos rate limiting ao consumidor.
3. Um alerta que deveria ter disparado, não disparou. A métrica de "breaker aberto" existia no Grafana, mas ninguém era notificado. Criamos o alerta antes de encerrar o Game Day.

Essas três descobertas custaram 30 minutos de experimento e evitaram, com boa probabilidade, um incidente real.

Padrões de resiliência que entraram em ação

• ⏱️ Timeout: impediu que threads ficassem presas indefinidamente.
• 🔌 Circuit Breaker: parou de bater em um serviço claramente doente e deu a ele espaço para se recuperar.
• 🛟 Fallback: transformou uma falha técnica em degradação controlada do negócio.
• 🧱 Bulkhead: garantiu que a lentidão do gateway não consumisse todas as threads e derrubasse rotas que nada têm a ver com pagamento.

5. Conclusão: o que o caos nos ensinou

Lições aprendidas

1. Resiliência é uma hipótese até ser testada. Ter Circuit Breaker configurado não prova que ele funciona como você imagina.
2. Comece pequeno. Um blast radius reduzido permite errar barato e aprender rápido.
3. Observabilidade vem primeiro. Se você não consegue ver o efeito da falha, não consegue aprender com ela.
4. Falhas de negócio importam tanto quanto as técnicas. O fallback "pagamento pendente" só existe porque o time de produto participou da conversa.
5. O valor está nas surpresas. Um experimento em que tudo funciona como previsto é bom. Um que revela uma fragilidade escondida é ótimo.

O impacto na cultura DevOps

O maior efeito do Master Deck não foi técnico, foi cultural:

• Menos culpa, mais curiosidade. Falhar em um experimento é aprendizado, não erro de alguém.
• Desenvolvimento e operações na mesma mesa. O Game Day junta quem escreve o código e quem o opera, quebrando o clássico "problema do outro time".
• Resiliência como requisito, não como favor. Novas funcionalidades passaram a vir acompanhadas de uma pergunta: "qual carta do baralho testaria isso?"
• Confiança para evoluir. Times que sabem como o sistema se comporta sob falha fazem deploys com menos medo.

Próximos passos

• Automatizar as cartas maduras no pipeline de CI/CD (regressão de resiliência).
• Evoluir para experimentos em produção com tráfego canário.
• Criar cartas de maior risco, como queda de uma AZ inteira, usando o AWS Fault Injection Service.

Quer começar hoje?

Você não precisa de uma plataforma sofisticada. Faça assim:

1. Escolha um serviço crítico e defina seu estado estável.
2. Escreva uma carta com hipótese, blast radius e condição de aborto.
3. Execute em staging com um grupo pequeno, com o painel de métricas aberto.
4. Documente o que aprendeu e corrija o que falhou.
5. Repita, sempre com uma carta nova.

Quebre as coisas com cuidado, para que elas não quebrem sozinhas na hora errada.

Referências e ferramentas

• Principles of Chaos Engineering
• Resilience4j — Circuit Breaker, Bulkhead, TimeLimiter para Java/Spring
• Toxiproxy — simulação de condições de rede
• Chaos Monkey for Spring Boot
• AWS Fault Injection Service
• k6 — geração de carga para os experimentos

Gostou? Deixe nos comentários qual carta você colocaria no seu baralho. 🃏