Chaos Engineering

1) Princípios básicos

Steady State como hipótese original. Defina claramente a norma (por exemplo, p95 <200 ms, errador rate <0. 3%, sucesso do flow crítico> 99. 5%).
Variáveis isoladas. Mude um fator de cada vez, sempre que possível, para ligar o efeito e a melhora.
Gradativo. Começamos com uma pequena amplitude em um ambiente seguro → ampliando a abrangência e a intensidade.
Guardrails. Condições nítidas de parar por SLO/alertas/orçamento de erros.
Repetência. O experimento deve ser reproduzido determinadamente (script/manifesto/IaC).
Ética e segurança. Sem dados pessoais reais ou transações financeiras em experiências de risco.

2) O que é um «estado sustentável»

• Latência p50/p95/p99 endpoint chave.
• Taxa de transações bem sucedidas e conversão de caminhos críticos.
• Erro rate, temporizações, porção «shed» de solicitações (cortadas durante a saturação).
• Velocidade de auto-definição (MTTR), resistência a retais (sem tempestades).
• Invariantes de domínio: falta de «contras no balanço», pagamento unificado, consistência dos dias relatados, etc.

3) Catálogo de injeções (que «quebramos»)

Rede: atraso, jitter, perda/duplicação, limitação de largura de banda, aberturas TLS, flapping DNS.
Cálculos: sobrecarga de CPU, pressão de memória/GC, esgotamento de descriptores, clock skew.
Armazenamento: alta p95 I/O, ENOSPC, falha líder/réplica, split-brain, fsync prolongado.
Dependências: 5xx/429, «sucesso lento», degradação das APIs externas, rate-limit.
Dados: duplas/omissões de mensagens, out-of-order, gravações «sujas», conflito de versões.
Operações: lançamento falhado/config, bandeira de fich, certificado vencido, rotação da chave.
Pessoas e processos: indisponibilidade dos responsáveis, retardo manual, runbook incorreto.

4) Design de experiência (modelo)

1. Hipótese: «A + 300 ms para o serviço de câmbio p99 API principal <450 ms, o breaker é aberto e a resposta stale é dada há 15 minutos».
2. Injeção: perfil de falha (tipo/amplitude/duração) e traçado de destino.
3. Métricas/logs-tags: marcação 'chaos. experiment_id`, `phase=inject|recover`.
4. Guardrails: abort a 'erro _ rate> 2%' ou p99> SLA x 2 mais de 1 minuto.
5. Resultados/conclusão: Lista de observações, melhorias, planos de trabalho e reaproveitamento.

5) Observabilidade: o que é obrigatório

Tracing: caminho de consulta através de dependências; os segmentos de degradação estão marcados.
As métricas de recursos são CPU, heap/GC, FD, IOPS/lat em disco, bandwidth em rede, profundidade das filas.
Métricas de negócios: conversão/sucesso de transações, proporção de transações compensadas.
Logs de eventos: abertura/encerramento de breakers, retratos e seu orçamento, mudança de líder da base de dados.
O painel da experiência é «live-dashboard», com liminares de guardrails e «botão vermelho» do aborto.

6) Guardrails e segurança

Técnica: limite superior de error rate/latency, queda na proporção de operações bem sucedidas, crescimento do DLQ.
Organização: janela do tempo envolvida on-call, princípio «uma zona é uma experiência».
Dados/complicações: apenas sintéticos ou conjuntos impessoais; a proibição de testes que levem a violações regulatórias.
Reversão: Procedimento de rolback/sinalização/tráfego macio.

7) Patternos de sustentabilidade que devem se manifestar

Orçamentos de tempo e retais jitters (sem tempestades).
Circuito Breaker com semiaberto (half-open) e restauração exponencial.
Bolkheads: isolamento de pool por criticidade (pagamentos vs analista).
Backpressure e rate-limit: corte de baixa prioridade previsível.
Cash coalescing, protecção contra «tempestades aquecidas».
Idempotidade dos efeitos colaterais e sagas de compensação.
Quórum, feelover e anti-entropia para recuperar dados.

8) Exemplos de cenário (sketches)

8. 1 Dependência lenta (YAML)

yaml experiment: slow-downstream target: svc:api inject:
dependency:
name: currency mode: add_latency p95_ms: 300 duration: 10m guardrails:
error_rate: "< 1. 5%"
p99_latency: "< 450ms"
expectations:
breaker_open: true stale_data_served: "<= 15m"

8. 2 Perda do Líder da Base de Dados

Injeção: paragem do líder/reeleição forçada.
Espera: proibição temporária de gravações, leitura de quórum, preservação de WAL/Outbox, recuperação automática de replicação, falta de gravação dupla.

8. 3 ENOSPC no disco de logs

Injeção: preenchimento do disco até 95% a 100%.
Espera: rotação de emergência de logs, conservação de revistas críticas, desativação de fits não ritíticos, alert e remunção automática.

8. 4 Tráfego burst + shading

Injeção x 3 RPS por 5 minutos em um endpoint quente.
Espera: baixa prioridade, estável p95 «núcleo», sem cascata de retais.

9) Automação em CI/CD

Chaos-smoke em um stage para cada lançamento (injeções curtas em amplitude segura).
Testes noturnos por catálogo de experiências (matriz de serviços x tipos de falhas).
GATES: O lançamento é bloqueado se «resistência abaixo do limite» (por exemplo, a taxa de sucesso fallback <95%).
Artefactos: relatório, trailers, flaymógrafos CPU/heap, metricos e configs.

10) Dias de jogo (Game Days)

• Papel: líder de experiência, observador de métricas, operador de reversão, representante do negócio.
• Cenários: degradação do cachê, falha parcial AZ/região-feedback, «mau lançamento», indisponibilidade do provedor externo.
• Resultados: as lacunas encontradas no runbook, melhorias de alertas, ajustes de SLO e orçamentos de retrações.

11) Caos para dados, eventos e ML

Fluxo de dados: testes de duplicação, omissões, out-of-order, atrasos; verificação de consoantes idepartidos e estratégias DLQ.
Armazéns: degradação de índice, hot-partition, conflito de bloqueio, replicação sob a laje.
ML: atraso do fich-store, recuo para o modelo baseline, deterioração da qualidade dos dados de entrada (draft) - o sistema deve ser «suave», em vez de cair.

12) Anti-pattern

Caos sem observabilidade, você é cego, as conclusões são especulativas.
Injeções na venda, sem stage ou guard rail.
«Uma grande experiência» para tudo, não está claro o que funcionou.
Acções de caos sem suposições e retalhos.
Focar-se apenas na infraestrutura - os invariantes do negócio foram esquecidos.
Ignorar pessoas/processos: alerts, on-call, runbook faz parte do sistema.

13) A maturidade da prática (modelo)

1. Injeções individuais localmente.
2. Um catálogo de cenários, recorrentes, dashboards.
3. Arranque-caos, smoke-caos em cada lançamento, gates, relatórios.
4. O caos de Prod com restrições, tráfego pequeno, guardas rigorosas, regresso pronto.
5. Sustentabilidade contínua: experimentos automáticos, controle SLO, melhorias como fluxo de trabalho.

14) Integração com práticas arquitetônicas

Testes de sustentabilidade: experiências de caos complementam injeções fault e cenários de degradação.
Teste de carga: experiências combinadas «carga + falha» identificam cascatas e tempestade de retrações.
Policy as Code/RBAC/ABAC: Guardas, passos de reversão e limites de política.
Gestão de concordâncias/privacidade: Não admita experiências que violem o modo de processamento de dados.
Geo-arquitetura: teste caos do feedback regional e vinculação de dados a jurisdições.

15) Mini-receitas (pseudocode)

Breaker + degradação

if breaker. open():
return serve_stale(cache. max_age=15m)
try:
res = call(dep, timeout=250ms)
return res except Timeout:
breaker. trip()
return serve_stale()

Limitador + shading

if cpu. load() > 0. 85 or queue. depth() > HIGH:
if req. priority < HIGH: return 503_SHED limiter. acquire()

Efeito secundário idumpotente

key = "payout:"+external_id if kv. exists(key): return kv. get(key)
res = side_effect()
kv. put(key, res, ttl=30d)
return res

16) Folha de cheque do arquiteto

1. O Steady State e o Guardrails?
2. Há um catálogo de cenários (rede/CPU/armazenamento/dependências/dados/operações)?
3. A observabilidade cobre recursos, caudas de latência, invariantes de negócios?
4. Os temporizadores/retrações/breakers/limitadores/bulkheads estão incluídos e configuráveis?
5. O runbook e o botão vermelho estão preparados?
6. Há caos-smoke no stage e experiências nightly?
7. Janelas e papéis «seguros» para os dias de game?
8. As experiências são reproduzidas (IaC/script), os resultados são versionados?
9. As melhorias são fixadas em tarefas e são feitas retalhas?
10. As linhas de montagem de dados e ML, não são apenas HTTP?

Conclusão

Chaos Engineering transforma «incidentes imprevistos» em cenários previsíveis. Hipótese de resistência, injeções controladas, guardrails rígidas, observabilidade e disciplina de retalhos são ferramentas que reduzem o risco de lançamentos e aumentam a confiança na plataforma. Finalmente, a equipe compreende os limites do sistema, sabe degradar-se elegantemente e rapidamente devolver o serviço ao usuário, mesmo em condições de falha.