Simulações de incidentes

1) Por que fazer simulações

• reduz o MTTD/MTTA/MTTR, aumenta a confiança em retrocessos e feeds;
• identificam brechas em processos (escalada, comunicação) e fraquezas arquitetônicas;
• servem de entrada de RCA→CAPA e melhoram a documentação (runbook/SOP);
• confirmam a preparação para os requisitos da SLA/Reguladores/Auditoria.

2) Formatos de simulação

Tabletop (desktop) é um cenário de conversa no quadro/bate-papo: barato, rápido, excelente para o trabalho de papel e comunicação.
Game Day (exercício de stage/venda restrito) - passos práticos sobre playbooks; Em venda, apenas ações seguras e reversíveis com gates claros.
Chaos Engineering - Falhas controladas (desativação de dependências/redes/nós) para verificação de estabilidade e gates SLO.
Ensinamentos DR. (Disaster Recovery) - falha AZ/região, recuperação de bacapes, mudança de provedores.
Comms-drill - pura comunicação, página de status, modelos de mensagens, PR/Legal.

3) Papéis e responsabilidades

Invident Commer (IC) - toma decisões, conduz planos, desoneração.
Tech Lead (TL) - diagnósticos, «injectos» técnicos e hipóteses.
Comms Lead (CL) - update interno/externo, página status.
Scribe - protocolo (timeline, ações, soluções, artefatos).
Observers/Assessors - deteta métricas e conformidade com os procedimentos.
Red Team (opcional) - Introduz «injectos» imprevistos.

4) Métricas de sucesso de simulações

MTTD/MTTA/MTTR sobre um incidente sintético.
Comm SLA: oportunidade e qualidade dos updates.
Guarda SLO: resposta correta ao burn-rate, quórum de amostras externas.
Runbook fidelidade:% dos passos foram concluídos através do documento, sem improvisação.
Escalation latency: velocidade de conexão do rol/provedor desejado.
Checklists pass-rate: cumprimento de «pronto/aceitado/fechado».
Noise & Fatiga: alertas extras, sobrecarga on-call.
CAPA correspondência: proporção de ações executadas após a simulação.

5) Preparação: o que é necessário antes da partida

O objetivo e as hipóteses, o que testamos (processos, arquitetura, humanos).
Guião e «injectos», uma sequência de sintomas/eventos com temporizadores.
Restrições de segurança: proibição de mudanças irreversíveis; pontos de cancelamento.
Dados e estandes, tráfego sintético, bandeiras de degradação, chaves seguras.
Documentos: links de runbook/SOP, escalação, contatos de provedores.
Observabilidade: dashboards/alertas pré-marcados, testes canarinhos.
Logística: tempo/duração, participantes, war-room canal, gravação.

6) Simulação: etapas

1. Brief (5-10 min): IC lembra metas, papéis, regras de segurança, critérios de conclusão.
2. T0 - Injecção de sintomas: alert (s), queda do SLI, status externo do provedor.
3. Triagem e escalação: atribuição de SEV, lançamentos freeze, conexão dos papéis desejados.
4. Diagnóstico: hipóteses, verificação DNS/TLS/CDN/BD/kesh/pneus, anotações de lançamento.
5. Ações mitigantes: otkat/kanareyka↓, bandeiras de degradação, provedor de failover, limites/retais.
6. Comunicações: updates regulares (formato: Impakt→Diagnostika→Deystviya→Sled. update).
7. Restauração e verificação: Sintético externo + SLI na área verde N intervalos.
8. Debrief (AAR): 15-30 min - factos, conclusões, CAPA.

7) Exemplos de cenário (diretório)

Queda do sucesso dos pagamentos: provedor A se degrada em um país; ações pendentes - redistribuição de tráfego, inclusão de UX simplificado, comunicação.
Falha DNS: erro de grafia/TTL, alguns usuários não cortam o domínio; os passos previstos são fixação/folback, limpeza de CDN, status-update.
Certificado TLS vencido: o aperto de mão é quebrado para clientes antigos; espera-se uma extensão de emergência e verificação da cadeia.
Kafka lag: aumento do atraso nos eventos KYC/AML; espera - escalar os consoantes, limitar os produtores.
BD p99 ↑ e crescimento de 5xx: índices estreitos, limite de conexões; espera - porta-bandeiras, limites, hotfix/reversão.
Falha regional: desativação do AZ/PoP; espera - GSLB/Anycast alternar, verificar dados e SLO.
Comunicação Drill: Tudo verde, mas verificamos modelos, intervalos e alinhamento com o Legal/PR.

8) Modelo de «injecto» (cartão)

ID: INJ-2025-11-01-01
Purpose: Verification of failover payments and comms SLA
Trigger T0: 30% reduction in transaction success in the TR region (alert SLI + burn rate)
Signals: 5xx growth in payment API, external status PSP-A = partial outage
Expected actions: reduction of the share on PSP-A to 30%, inclusion of degrade-payments-UX, status update 15 min
Success criteria: success of payments ≥ 98% in 30 minutes, two green SLI intervals
NOTAM (security): prohibition of direct database edits; flags/routing only

9) Segurança e Complacência

As simulações de prod são apenas reversíveis: bandeiras de fich, alteração de tráfego em pequenas partes, réplicas de leitura, «shadow traffic».
Controle de Acesso/Auditoria: todas as ações através do ChatOps/Pipeline; registros no armazém imutável.
PII/segredos - não são usados em artefatos didáticos; os dados foram despersonalizados.
Regulação: Se a simulação envolver comunicações de clientes, marca «ensinamento» em canais privados; posts públicos não são simulados.

10) Avaliação e AAR → RCA → CAPA

AAR (After Action Review) - logo após o exercício: o que esperavam/viram o que funcionou/não.
RCA - para falhas significativas (por exemplo, a escalação não funcionou) no modelo RCA.
CAPA - lista ações com proprietários/prazos/métricas de efeito (alterações em playbooks, alertas, arquitetura).
Os pontos de controle são D + 14/D + 30: verificação de execução, reaproveitamento de mini-drill para locais vulneráveis.

11) Documentação e artefatos

Plano de simulação: metas, cenário, injeções, participantes, janelas, critérios de sucesso.
Timeline (UTC): T0... Tn, soluções IC, passos técnicos, updates.
Imagens de dashboards/logs, excertos de alertas e estatais.
Relatório final: métricas, divergências com playbooks, CAPA.
Atualizações de documentação: edição de runbook/SOP/contatos, links para novos dashboards.

12) Frequência e abrangência

Tabletop: 2 a 4 vezes por mês (em fluxos e papéis-chave).
Game Days em um stage: 1 a 2 vezes por mês.
Taos-mala (prod-light): trimestral, estritamente gays.
Ensinamentos Dr. 1 a 2 vezes por ano com mudança real.
Comms-drill: mensalmente para treinar modelos e updates SLA.

13) Folhas de cheque

Antes da simulação

• Guião, «injeções», critérios de sucesso, janelas de segurança.
• Papéis, canais, status de padrões concordantes.
• A disponibilidade de estandes/bandeiras/dashboards foi verificada.
• O plano de cancelamento e reversibilidade foi documentado.
• Riscos e impacto sobre SLO/clientes avaliados.

Durante

• O SEC é atribuído, freeze lançamentos (se necessário).
• Comunicações programadas, formato suportado.
• Todas as ações com ferramentas de auditoria.
• Scribe cadastra, recolhe artefatos.
• Segurança: restrições/restrições são cumpridas.

Depois

• AAR realizado, relatório salvo.
• RCA (falhando) iniciado.
• CAPA são feitos com proprietários/prazos.
• Runbook/SOP/contatos foram atualizados.
• Está previsto um retuíte de locais vulneráveis.

14) Anti-pattern

«Improvisação em vez de um plano» - não há cenário ou critérios de sucesso.
Riscos sem gates ou plano de cancelamento - os exercícios transformam-se num incidente.
A única forma de trabalhar é sem comunicação ou escalação.
Falta de AAR/RCA - equipe não está aprendendo.
Caos prod sem observabilidade ou guarda-vidas SLO.
Permissões opacas: redações manuais secretas vendidas.

15) Mini-modelos

Agenda do Game Day (60-90 min)

1. Brief (5 min) → Objetivos, papéis, segurança.
2. Cenário T0 (5 min) → Fornecimento de sintomas.
3. Triagem/escalação (10 min).
4. Diagnóstico + ação (30-45 min) - 1-2 «injecção».
5. Restauração e verificação (10 min).
6. AAR (15 min) - conclusões, CAPA.

Modelo AAR (breve)

What was expected:
What happened:
What worked:
What didn't work:
Solutions and why:
Actions (CAPA) with deadlines:
Responsible persons:
Retest Date:

16) Resultado

Simulações de incidentes são um «equipamento» para pessoas, processos e arquitetura. Ensinamentos regulares, seguros e mensuráveis transformam as crises em uma rotina: a equipe reage mais rapidamente, os playbooks funcionam efetivamente, a arquitetura é mais sustentável e o regulador e os clientes veem a maturidade da função operacional. O importante são objetivos claros, gates seguros, boas métricas e AAR→RCA→CAPA obrigatória.