Skip to content
Publicado em

Chaos Engineering: Quebrando sua aplicação... de Propósito

--
Autores
  • avatar
    Nome
    Lucas Andrade

Imagina a seguinte cena: sexta-feira, 17h, todo mundo já tá quase saindo e de repente o sistema inteiro cai. Ninguém sabe por quê. O banco tá fora? O serviço de autenticação morreu? Um deploy recente quebrou alguma coisa? Caos total.

Agora imagina um cenário diferente: sua equipe provoca falhas controladas durante o horário comercial, com todo mundo de olho, pronto pra agir. Descobre que o sistema não lida bem com a queda de um nó do banco e corrige antes de virar problema de verdade.

Eu sei que parece contraintuitivo. A gente fica o tempo todo pensando em como não quebrar nada, e de repente, eu te falo pra quebrar algo de propósito? Sair puxando os cabos? Meio que isso. Mas com método.

Isso se chama chaos engineering. E é mais divertido do que parece.

Por que Quebrar Coisas de Propósito?

A lógica é simples: falhas vão acontecer. Servidores vão cair, redes vão falhar, discos vão encher. A pergunta não é "se", é "quando".

Então por que esperar a falha te pegar de surpresa? Pode ser melhor provocar ela num ambiente controlado, entender o comportamento do sistema e corrigir as fraquezas.

O Paradoxo da Resiliência

Existe um paradoxo interessante: quanto mais você quebra seu sistema, mais forte ele fica. Cada falha injetada revela uma fraqueza. Cada fraqueza corrigida torna o sistema mais robusto. Com o tempo, seu sistema se torna tão resiliente que as falhas injetadas não causam mais impacto. Até que restem poucos, quase nenhum ponto de falha.

É o conceito do Nassim Taleb de sistemas antifrágeis: sistemas que ficam mais fortes com o estresse, ao invés de simplesmente resistirem a ele.

A Netflix e o Chaos Monkey

Não podemos falar de chaos engineering sem falar da Netflix.

Eles migraram para a AWS em 2010 e rapidamente perceberam que cloud não é tão confiável quanto parece. Servidores podem morrer a qualquer momento. E ao invés de lutarem contra isso, eles abraçaram isso.

Em 2011, eles criaram o Chaos Monkey, uma ferramenta que aleatoriamente desliga instâncias de produção durante o horário comercial.

Sim, em produção. Durante o horário de trabalho.

A ideia era genial: se seus engenheiros sabem que instâncias podem cair a qualquer momento, eles vão construir sistemas que lidam com isso naturalmente. Você não projeta pra falha se nunca experimenta falha.

A Netflix depois expandiu pra uma suíte inteira chamada Simian Army (isso é assustador):

  • Chaos Monkey: Desliga instâncias aleatórias
  • Latency Monkey: Injeta atraso nas chamadas de rede
  • Chaos Gorilla: Derruba uma zona de disponibilidade inteira
  • Chaos Kong: Simula falha de uma região inteira da AWS

Outros casos do mundo real

The S3 Outage (2017)

Em 2017, um typo num comando do S3 derrubou uma boa parte da internet que o usava. Inclusive sites que são conhecidos por serem resilientes.

A lição? Se você nunca testou o que acontece quando o S3 está indisponível, você não sabe se seu sistema ficaria de pé nesse cenário. Empresas que praticaram esse cenário tiveram uma recuperação rápida, enquanto outras sofreram por horas.

The Stripe Chaos Engineering Culture

Na Stripe, eles rodam algo chamado "failure Fridays", que consiste numa simulação de falhas em produção toda semana, com os SWEs de olho. Isso cria uma memória muscular de resposta a incidente, porque a prática é recorrente, mesmo sem incidentes,

Google's DiRT (Disaster Recovery Testing)

A Google roda todo ano um exercício de Disaster Recovery, cortando capacidade dos data centers, simulando danos por terremotos, e testando todo tipo de falha. O resultado? Google é uma das empresas mais estáveis do planeta no que tange seus produtos.

Princípios de Chaos Engineering

O pessoal da Netflix formalizou os princípios num documento chamado "Principles of Chaos Engineering". Vou deixar o link aqui, mas resumir um pouco a explicação:

1. Defina o Estado Estável

Antes de quebrar qualquer coisa, você precisa saber como o sistema se comporta normalmente.

# Defina métricas que representam "tudo funcionando"
steady_state = {
    "latency_p99": "< 200ms",
    "error_rate": "< 0.1%",
    "throughput": "> 1000 req/s",
    "cpu_usage": "< 70%",
    "active_users": "crescimento normal"
}

# Se essas métricas se mantêm durante o experimento,
# o sistema é resiliente à falha injetada

2. Formule uma Hipótese

Não saia quebrando coisas aleatoriamente. Tenha uma hipótese clara:

Hipótese: "Se uma instância do serviço de pagamento cair,
o load balancer vai redirecionar o tráfego pras instâncias restantes
e a latência p99 vai se manter abaixo de 500ms."

3. Varie Eventos do Mundo Real

Simule coisas que realmente acontecem, falhas realistas:

  • Instância morre (acontece o tempo todo)
  • Latência de rede aumenta (congestionamento)
  • Disco enche (logs crescem)
  • DNS falha (mais comum do que parece)
  • Certificado expira (clássico)
  • Banco fica lento (query pesada)

4. Execute em Produção

Parece assustador, mas a ideia é que staging nunca replica perfeitamente o ambiente de produção. O tráfego é diferente, os dados são diferentes, o comportamento é diferente.

Claro, com cuidado. Comece pequeno.

5. Minimize o Blast Radius

Esse é o ponto mais importante, o diferencial pro chaos engineering funcionar. Blast radius é o impacto potencial do seu experimento, em níveis:

  • Nível 1: Um pod em um deployment (impacto mínimo)
  • Nível 2: Um nó inteiro do cluster
  • Nível 3: Um serviço inteiro
  • Nível 4: Uma zona de disponibilidade
  • Nível 5: Uma região inteira

Comece pelo nível 1. Só suba quando tiver confiança.

Game Days

Game days são exercícios planejados onde a equipe simula cenários de falha e pratica a resposta. É tipo um simulado de incêndio pro seu sistema.

O roteiro de um Game Day funciona como algo parecido com isso:

  1. PREPARAÇÃO (1 semana antes)

    • Escolhe o cenário de falha
    • Define blast radius máximo
    • Prepara runbook de resposta
    • Garante que todo mundo sabe como reverter

  2. EXECUÇÃO (dia do evento)

    • Time inteiro reunido (presencial ou call)
    • Dashboards abertos e visíveis
    • Injeta a falha
    • Time responde como se fosse incidente real
    • Cronometra tudo

  3. RETROSPECTIVA (mesmo dia ou dia seguinte)

    • O que funcionou?
    • O que demorou demais?
    • O que faltou nos alertas?
    • O que precisa ser automatizado?

Exemplo de Cenário

Cenário: "O serviço de cache (Redis) ficou indisponível"

Hipótese: "A aplicação vai degradar graciosamente,
servindo dados direto do banco com latência maior,
mas sem erros pro usuário."

Execução:
  09:00 - Bloqueia conexões pro Redis via iptables
  09:01 - Monitora métricas
  09:05 - Verifica se fallback pro banco está funcionando
  09:10 - Avalia impacto na latência
  09:15 - Restaura conexão
  09:20 - Verifica se cache se recupera

Resultado: Descobrimos que o pool de conexões do banco
esgotou em 3 minutos porque não tinha limite adequado.

Ferramentas de Chaos Engineering

Chaos Monkey (Netflix)

A original. Foca em desligar instâncias na AWS.

# Configuração do Chaos Monkey (Spinnaker)
chaos_monkey:
  enabled: true
  mean_time_between_kills: 120  # minutos
  min_time_between_kills: 60
  grouping: cluster
  exceptions:
    - account: production
      region: us-east-1
      stack: critical  # Não mexe nos serviços críticos no início

Gremlin

Plataforma comercial mais completa. Interface amigável e controle fino do blast radius.

# Exemplo usando Gremlin API
import requests

experiment = {
    "command": {
        "type": "cpu",
        "args": ["-c", "1", "-l", "80", "--length", "300"]
    },
    "target": {
        "type": "Random",
        "containers": {
            "multiSelectLabels": {
                "app": ["payment-service"]
            }
        },
        "percent": 50  # Afeta 50% dos containers
    }
}

response = requests.post(
    "https://api.gremlin.com/v1/attacks",
    headers={"Authorization": f"Bearer {token}"},
    json=experiment
)

Litmus (Cloud Native)

Open source, feito pro Kubernetes. Define experimentos como CRDs.

# ChaosEngine pro Kubernetes
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: payment-chaos
spec:
  appinfo:
    appns: 'default'
    applabel: 'app=payment-service'
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: '60'        # 60 segundos de caos
            - name: CHAOS_INTERVAL
              value: '10'        # Deleta um pod a cada 10s
            - name: FORCE
              value: 'false'     # Graceful shutdown

Chaos Toolkit

Framework open source que permite definir experimentos como código.

{
    "title": "Verificar resiliência quando Redis cai",
    "description": "O sistema deve continuar funcionando sem cache",
    "steady-state-hypothesis": {
        "title": "Aplicação está saudável",
        "probes": [
            {
                "type": "probe",
                "name": "app-responde-200",
                "tolerance": 200,
                "provider": {
                    "type": "http",
                    "url": "http://app:8080/health"
                }
            }
        ]
    },
    "method": [
        {
            "type": "action",
            "name": "parar-redis",
            "provider": {
                "type": "process",
                "path": "docker",
                "arguments": ["stop", "redis"]
            }
        }
    ],
    "rollbacks": [
        {
            "type": "action",
            "name": "reiniciar-redis",
            "provider": {
                "type": "process",
                "path": "docker",
                "arguments": ["start", "redis"]
            }
        }
    ]
}

Tipos de Falha pra Injetar

Infraestrutura

Tipo de Falha          │ O que Testa
───────────────────────┼────────────────────────────────
Kill de processo       │ Auto-healing, restart policies
Falha de rede          │ Timeouts, circuit breakers
Latência de rede       │ Tolerância a atraso
Disco cheio            │ Tratamento de erros de I/O
CPU alta               │ Comportamento sob pressão
Memória esgotada       │ OOM killer, graceful degradation
DNS falha              │ Caching de DNS, fallbacks

Erros Comuns

  1. Começar grande demais: Derrubar uma região inteira no primeiro experimento. Comece com um pod.

  2. Não ter observabilidade: Se você não consegue ver o que tá acontecendo, não vai aprender nada. Monitoramento primeiro, chaos depois.

  3. Não ter hipótese: "Vamos ver o que acontece" não é chaos engineering. É só caos.

  4. Sem rollback: Sempre tenha um botão de "desfazer". Se o experimento sair do controle, você precisa poder parar imediatamente.

  5. Não fazer retrospectiva: O valor não tá em quebrar coisas, tá em aprender com o que acontece e melhorar o sistema.

  6. Chaos engineering não é teste de carga: São coisas diferentes. Teste de carga é sobre volume. Chaos é sobre resiliência.

Chaos engineering pode parecer contra-intuitivo no começo. Quem em sã consciência quer quebrar o próprio sistema? Mas a verdade é que sistemas que nunca são testados sob falha são sistemas que você não sabe se funcionam de verdade.

Se você tá começando, dá uma olhada no Chaos Toolkit ou no Litmus pro Kubernetes. São gratuitos, open source e um ótimo ponto de partida.

Dúvidas? Manda nos comentários!

Até a próxima!

Discutir no Twitter • Ver no GitHub

COMPARTILHAR