Análises pós-incidentes

1) Por que precisa de testes pós-incidentes

O exame pós-incidente (pós-mortem/AAR) é um processo estruturado de treinamento da organização após a falha. O objetivo não é encontrar culpados, mas identificar causas de raiz e contribuintes e consolidar ações mensuráveis (CAPA) que reduzam o risco de repetição e o custo de incidentes, melhorando o SLO, o MTTR e a confiança dos clientes/reguladores.

2) Princípios (Just Cultura)

Sem acusações, analisamos sistemas, decisões e contextos, não indivíduos.
Os factos são mais importantes do que as opiniões: timelines, logs, métricas, trailers, artefatos de mudanças.
Visão E2E: desde sintomas no cliente até dependências internas e provedores externos.
Verificável: cada hipótese é confirmada por um experimento/dados.
Circuito de circuito: análise de → CAPA → pontos de controle → retesta.

3) Quando iniciar a análise e quais são os formatos

Obrigatório: V-0/1; violação do SLA/regulação; fuga de dados; Risco PR significativo.
Acelerado (light): V-2 com influência notável ou sintomas repetitivos.
AAR de comunicação: Se a falha afetou o status da página/suporte, verifique os updates de SLAs e a qualidade das mensagens.

Prazo: rascunho de 48 a 72 horas, versão final de até 5 dias úteis (se não for o caso).

4) Papéis e responsabilidades

Dono do exame (RCA Lead): organiza o processo, mantém a reunião, é responsável pela qualidade do relatório e CAPA.
Invident Commer (IC): fornece a factualização do incidente e da solução.
Tech Lids (por sistemas): análise de razões que confirmam artefatos.
Comms/Apoio/Legal: avaliação de comunicações e requisitos de complacência.
Scribe: protocolo, coleta de provas, cumprimento de estrutura.
Steakholders de produto/negócio: impacto sobre clientes/circulação, priorização de CAPA.

5) Preparar: o que reunir antes da reunião

Timeline (UTC): T0 detecção → Tn recuperação; lançamentos/bandeiras de fich/configs, status de provedores.
Dados de observabilidade: gráficos SLI/SLO, error-rate, perfilados, logs, traçados, capturas de tela.
Contexto de mudanças: referências a PR/deplay, migrações de banco de dados, bandeiras de fique, planos de trabalho.
Impacto: cômodos/regiões/provedores afetados, minutos de interrupção, créditos SLA.
Comunicações: rascunhos/posts de status, respostas de safort, anúncios internos.
Políticos/playbooks: O que deveria acontecer no processo onde houve desvios.

6) Técnicas de análise (escolha uma combinação)

5 Why: rápida autópsia da cadeia causal (risco - simplificação excessiva).
Diagrama de Ishikawa (Fishbone): People/Processo/Platford/Policy/Partner/Product.
Fault Tree Analysis (FTA): dedução do evento para várias causas (AND/OR).
Mudança Analisis: O que mudou durante o incidente vs estável.
Causal Graph: Gráfico de causalidade para microsserviços complexos e dependências externas.
Human Factors Review: fadiga, barulho de informação, runbook 'i irrelevante.

7) Estrutura de relatório (modelo)

1. Resumo (Executive Summary): O que, quando, quem foi afetado, o status final.
2. Impacto: SLI/SLO, usuários, regiões/provedores, minutos de inatividade, efeitos financeiros/regulatórios.
3. Timeline (UTC): eventos-chave, lançamentos, soluções IC, comunicações.
4. Observações e dados: gráficos, logs, trailers, difs de configs/circuitos.
5. Suposições e verificações: as referências aceitas/rejeitadas para experimentos/simulações.
6. Razões de raiz: sistema/processo/técnica (definição clara).
7. Os fatores favoráveis são porque não repararam ou não pararam antes.
8. O que funcionou não funcionou, processos, ferramentas, pessoas.
9. CAPA: Medidas de correção e prevenção com proprietários/prazos/métricas de sucesso.
10. O plano de verificação é D + 14/D + 30, critérios de encerramento.
11. Versões externas: cliente/regulador (sem dados sensíveis).
12. Aplicativos: artefatos, referências a tíquetes/PR, screenshots de dashboards.

8) CAPA: como tornar as ações operacionais

Cada ação possui um proprietário, um efeito deadline e um efeito KPI (por exemplo, redução de mudança-failure-rate de X%, repetição zero de 90 dias, redução do burn-rate em picos).
Divida o Corrente (corrigir) e o Preventive (não permitir) medidas.
Vincule-se a policy-as-código: alerts, gates SLO, scale automático/limite, GitOps.
CAPA entra em um backlog público com revisões em reuniões operacionais semanais.

9) Verificar o efeito e fechar

Pontos de referência: D + 7 (intermediário), D + 14/D + 30 (essenciais), D + 90 (total).
Verificação: testes/simulações (game day), tráfego shadow, observabilidade (SLI estável na área verde), sem reincidência.
O fechamento só pode ser feito com as métricas de CAPA e confirmadas.

10) Comunicação e complacência

Interna: O status compreensível para alimentos/suporte/gestão, SLA update respeitado.
Externo: página de status, e e-mails para clientes/parceiros; linguagem sem acusações, plano claro de prevenção.
Regulação: prazos de notificação, despersonalização de exemplos, armazenamento constante de relatórios e artefatos.

11) Métricas de maturidade de processo

Tempo de publicação do relatório: fato vs SLA (por exemplo, ≤5 dias úteis).
CAPA complition rate:% das ações encerradas dentro do prazo.
Reopen rate: proporção de incidentes em 90 dias.
Porção de causa de sistema vs «erro humano».
Alert-higiene: redução de falsos pagies, crescimento de alertas cobertas de runbook 'ami.
Alteração das métricas DORA: MTTR, mudança-failure-rate antes/depois.

12) Folhas de cheque

Antes de analisar

• O dono do RCA e a composição dos participantes foram definidos.
• Coletado timeline e artefatos (logs/gráficos/lançamentos/bandeiras).
• Foi avaliado o impacto por grupo/região/provedor.
• Foram produzidos rascunhos das seções «Impacto» e «Timeline».
• Políticas/playbooks relevantes são mapeadas com ações reais.

Durante

• As hipóteses e bases aceitas/rejeitadas foram registradas.
• São definidas as causas de raiz e contribuintes.
• Plano CAPA formado com KPI e prazos.
• Versões do relatório para os lados externos concordadas (se necessário).

Depois

• Relatório publicado dentro do prazo, acesso por papel.
• CAPA incluídos no backlog, proprietários confirmados.
• Os pontos de controle e a simulação mini-simulada foram atribuídos.
• Atualizados runbook/SOP/alert/documentação.

13) Anti-pattern

«Culpa do Homem X». Sem razões sistêmicas.
Relatório sem CAPA ou sem proprietários/prazos - papel por papel.
Não há factos ou artefactos - as conclusões são sensoriais.
Uma linguagem demasiado comum («sobrecarga do banco de dados»), sem alterações específicas.
Ignorar comunicações e complacências são riscos de reputação.
Fechar sem verificar os efeitos - recaídas semanas depois.

14) Mini-modelos

Chapéu de relatório

Incident: INC-2025-10-31 (SEV-1)
Window: 2025-10-31 18: 05-18: 47 UTC
Owner of the analysis: @ rca-lead
Affected: EU region, payments (success -28% peak)
Status: corrected; 48 hours monitoring

Formulação da causa raiz (exemplo)

CAPA (fatia)

Incluir canary-roteamento para PSP-A (1%→5%→25%), proprietário de @ payments-tl, até 2025-11-07, KPI: zero P1 incidentes nos lançamentos de provedores 30 dias.
Reconfigurar os temporizadores/retrações com tempo total de SLA 800 ms, proprietário de @ plataforma-sre, para: 2025-11-05, KPI: p99 <600 ms sob carga de N.

Adicione um SLI de negócios por cômodos BIN, dono de @ data-lead, até: 2025-11-10, KPI: detecção de degradação <5 min

15) Incorporação à prática diária

RCA semanal: status CAPA, novas lições, atualizações de processos.
Catálogo de pós-mortems em wiki com marcas (serviço, SEV, razões) e busca.
Simulações motivadas pelo incidente dentro de 2-4 semanas para verificar as medidas.
A inclusão de aulas no sistema on-call e atualização de cenários de treinamento.

16) Resultado

As análises pós-incidentes são um mecanismo de melhoria do sistema. Quando os fatos são coletados, a causalidade é comprovada, as ações são mensuráveis e testadas, a organização acumula capital operacional de confiabilidade, com queda de MTTR e incidentes repetitivos, maior previsibilidade de lançamentos e confiança dos clientes.