Chaos Engineering: sustentabilidade de sistemas

Chaos Engineering: sustentabilidade de sistemas

1) Porquê engenharia de caos

• verificar as hipóteses sobre o comportamento do sistema e validar o SLO;
• detectar SPOF escondidos, timeouts errados/retraias, efeitos em cascata;
• treinar os comandos: game-days, trabalho runbook's, comunicações;
• criar uma cultura de «sustentabilidade padrão», em vez de «esperamos melhor».

Importante: Chaos Engineering ≠ «quebrar tudo». É um método científico: steady-state → hipótese → experimento → conclusões → melhorias.

2) Ciclo básico da experiência

1. Steady-state (linha básica): Quais SLI são estáveis? (por exemplo, sucesso ≤500 ms em 99. 95%).
2. A hipótese é que a perda de um AZ p95 aumente <10% e a disponibilidade ≥99. 9%.
3. Experiência: folt planeado com critérios limitados blast radius e stop.
4. Observação: métricas/trailers/logs, burn-rate SLO, business SLI (por exemplo, depósitos bem sucedidos).
5. Melhorias: Detectamos as descobertas, alteramos os horários/limites/rotação, atualizamos o runbook.
6. Automação/regressão: Repita no horário, adicione no CI/CD e calendários de game-days.

3) Corrimão de segurança (safety first)

Blast radius: Comecemos com um pequeno pod/instância/rota/namespace.
Guardrails: alertas em SLO burn-rate (rápido/lento), limites de retrações, limite QPS, orçamento incidente.
Critérios de stop: «Se error-rate> X% ou p99> Y mN minutos - instantaneamente stop e rollback».
Janelas: horas de trabalho on-call, steakholders notificados, lançamentos congelados.
Comunicação: IC/Tech lead/Comms, canal claro (War-room), modelo de mensagens.

4) Classes de rejeição e ideias de hipótese

Rede: atraso/jitter/perda, drop parcial de portas, comunicação «flaper» entre serviços/PSP.
Compêndio/nódulos: matar processos, superaquecer CPU, esgotar descriptores de arquivos, poulas estreitas de conexões.
Armazéns e BD: crescimento latency discos, lag réplicas, pare um shard/líder, split-brain.
Dependências: degradação de APIs externas, limites de provedores, 5xx/429 picos.
Gerenciamento de alterações: lançamento falhado, bandeira de fich ruim, partial rollout.
Perímetro: CDN degradado, DNS/Anycast Drift, falha WAF/bot-proteção.
Região/AZ: perda total ou incidente «parcial» (um pouco pior e imprevisível).

5) Ferramentas e técnicas

Kubernetes: Chaos Mesh, Litmus, PowerfulSeal, kube-monkey.
Nuvens: AWS Fault Inhation Simulator (FIS), Fault Domins junto às nuvens.
Rede/proxy: Toxiproxy (TCP-veneno), tc/netem, iptáveis, Envoy fault (delay/abort), Istio fault inhation.
Processos/nós: 'stress-ng', cgroups/CPU-throttle, disk fill.
Tráfego-Rotação: GSLB/DNS weights, canary/blue-green para verificações de feedback.

6) Exemplos de cenário (Kubernetes)

6. 1 Delay/abort na rota (Istio VirtualService)

yaml apiVersion: networking. istio. io/v1alpha3 kind: VirtualService metadata: { name: api-chaos }
spec:
hosts: ["api. internal"]
http:
- route: [{ destination: { host: api-svc } }]
fault:
delay: { percentage: { value: 5 }, fixedDelay: 500ms }
abort: { percentage: { value: 1 }, httpStatus: 503 }

Hipótese: os temporizadores do cliente/retrai e CB manterão p95 <300 ms e error-rate <0. 5%.

6. 2 Pod Kill (Chaos Mesh)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: PodChaos metadata: { name: kill-one-api }
spec:
action: pod-kill mode: one selector:
namespaces: ["prod"]
labelSelectors: { "app": "api" }
duration: "2m"

Hipótese: balanceador e HPA compensam loss de uma única instância sem crescimento p99> 20%.

6. 3 Caos da rede (atraso para o banco de dados)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: NetworkChaos metadata: { name: db-latency }
spec:
action: delay mode: all selector: { namespaces: ["prod"], labelSelectors: {"app":"payments"} }
delay: { latency: "120ms", jitter: "30ms", correlation: "25" }
direction: to target:
selector: { namespaces: ["prod"], labelSelectors: {"role":"db"} }
mode: all duration: "5m"

Hipótese: pool/timeouts/dinheiro reduzirão o impacto; p95 pagamentos ficarão ≤ SLO.

6. 4 Preencher disco

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: IOChaos metadata: { name: disk-fill-logs }
spec:
action: fill mode: one selector: { labelSelectors: {"app":"ingest"} }
volumePath: /var/log size: "2Gi"
duration: "10m"

A hipótese de rotação de logs/quotas/alertas funcionarão antes da degradação das rotas.

7) Experiências fora de K8s

7. 1 Toxiproxy (local/integração)

bash toxiproxy-cli create psp --listen 127. 0. 0. 1:9999 --upstream psp. prod:443 toxiproxy-cli toxic add psp -t latency -a latency=200 -a jitter=50 toxiproxy-cli toxic add psp -t timeout -a timeout=1000

7. 2 Envoy HTTP fault (perímetro/mesh)

yaml fault:
delay: { fixed_delay: 0. 3s, percentage: { numerator: 10, denominator: HUNDRED } }
abort: { http_status: 503, percentage: { numerator: 1, denominator: HUNDRED } }

7. 3 AWS FIS (a exemplo da ideia)

Experimento «matar» N% EC2 no Auto Escaling Group, elevar artificialmente EBS-latency, desativar NAT-GW em um AZ.
Critérios de stop embutidos em CloudWatch métricas SLO.

8) Métricas de observabilidade durante o caos

SLO/SLI: fraction of good requests, p95/p99, burn-rate.
Modelo RED em rotas críticas (Rate, Errors, Duration).
Pulas: espera por conexão p95, utilization.
BD: lag réplicas, locks, à deriva p95 solicitações.
Rede: retransmits, RPT, dscp/ecn comportamento.
Negócios SLI: transações de sucesso (depósitos/chekout),% de reembolsos/erros.
Traçado: Trailers seletivos (exemplars), correlação de anotações de lançamento.

9) Integração com SLO/Erro-Budget

Planeie experiências dentro do orçamento de erros, o caos não deve destruir os objetivos trimestrais.
Burn-rate alerts como automático kill-switch.
Relatórios: «Quantos orçamentos queimaram», «Quais desonerações steady-state».

10) Game-days (exercícios)

Cenário: uma breve lenda (por exemplo, «região-East perdida»), passos de injeção, objetivos SLO, papéis, tempo.
Avaliação: RTO/RPO real, qualidade das comunicações, correção do runbook.
Retrô: lista de melhorias com proprietários e prazos, atualização de documentação/dashboards.

11) Automação e CI/CD

Smoke-chaos: testes de staging curtos a cada lançamento (por exemplo, 1 pod-kill + 200 ms delay por trajeto).
Noturno/semanal: cenários mais pesados (5-15 min) com relatório.
Promoção-gates: Se p95/erros> limiar canary - reversão automática.
Repositórios com catálogo de experiências (YAML + runbook + SLO-thresholds).

12) Anti-pattern

Não há critérios de stop, não há on-call → risco de ocorrência.
Ação descartável em vez de processo.
Caos sem steady-state: Não se sabe o que é um sucesso/fracasso.
Retraias em excesso → por si-DDoS para injeção de atrasos.
Ignorar SLI de negócios: sucesso «técnico» em pagamentos/pedidos falhados.
Falta de pós-análise e de proprietários de melhorias.

13) Folha de cheque de implementação (0-45 dias)

0-10 dias

Definir steady-state SLI (personalizado + negócio).
Selecione a ferramenta (Chaos Mesh/Litmus/Toxiproxy/FIS).
Descrever corrimão: blast radius, critérios de stop, janelas, papéis.

11 a 25 dias

Iniciar as primeiras experiências: pod-kill, 100-200 ms delay para upstream crítico, drop 1% pacotes.
Personalizar burn-rate alerts, associar kill-switch a critérios stop.
Realizar o primeiro game-day, reunir retrô e fixação.

26-45 dias

Adicionar cenários de nível AZ/dependência (PSP externo, BD-lag).
Automatizar o caos nightly no estaging; preparar cenários «sazonais» (picos).
Catálogo de experiências e relatórios regulares para o manual/SRE.

14) Métricas de maturidade

≥80% das rotas críticas têm as experiências descritas e as métricas steady-state.
Auto kill-switch funciona quando os limites p99/erro-rate são ultrapassados.
Trimestralmente - game-day nível AZ/região; ≥1 vezes/m é o cenário alvo das dependências.
A MTTR é reduzida após um ciclo de melhorias, e a correlação «lançamento ↔ incidente» diminui.
A proporção de baixas «inesperadas» com falhas reais busca zero.
Dashboards mostram «resiliência» como KPI (burn-rate, tempo de recuperação, proporção de ações de DR. bem-sucedidas).

15) Exemplos de guindastes e trigers stop

Stop em 'http _ req _ failed> 1%' 3 minutos, 'p99> 1000 ms' 3 janelas, 'deposit _ sucess <99. 5%`.
Redução de blast radius: reversão automática do manifesto, retorno da balança GSLB, desativação de injeções fault.
O comando Stop é um único botão/script com a justificativa da causa.

16) Cultura e processos

O caos faz parte do ritmo SRE, não é «extrim».
Relatórios transparentes, reconhecimento de vulnerabilidades, ações corretivas.
Treinamento on-call, simulações de comunicação com clientes/parceiros.
Conexão com SLA/SLO e orçamentos: o caos deve aumentar e não comprometer a confiabilidade.

17) Conclusão

Chaos Engineering transforma a «esperança dos nove» em sustentabilidade comprovada. Formule o steady-state, coloque corrimões, rompa o pequeno e o controlado, observe o SLO e o SLI de negócios, e verifique e automatize melhorias. O RTO previsível, o error seguro e a disposição da equipe para agir sem pânico.