Pós-Incidente: Análise de Causa Raiz

Oriente uma equipe a escrever um pós-incidente estruturado e sem culpa após um incidente de produção. O resultado é um documento que constrói um entendimento compartilhado, identifica as causas raiz sem apontar dedos e produz itens de ação concretos para prevenir a recorrência.

Princípio de Ausência de Culpa

Sistemas falham, pessoas não. O objetivo é entender COMO o incidente aconteceu — não QUEM o causou. Evite linguagem como "X esqueceu de", "Y deveria ter sabido". Use "o sistema não", "o processo carecia de", "o alerta não disparou".

Quando Usar

• Interrupção de produção ou degradação de serviço foi resolvida
• Um "quase incidente" significativo ocorreu (teria sido um incidente se detectado mais tarde)
• Ocorreram erros voltados para o usuário, perda de dados ou violação de SLA
• A equipe quer registrar aprendizados antes que o contexto se perca

Não usar para: Bugs menores detectados em staging, janelas de manutenção planejadas ou incidentes sem valor de aprendizado.

Requisitos de Entrada

Reúna estes detalhes antes de escrever o pós-incidente. Peça por qualquer coisa que esteja faltando:

Metadados do Incidente

• Título do incidente (curto, descritivo)
• Data e hora da detecção (com fuso horário)
• Data e hora da resolução
• Nível de severidade / impacto (P1–P4 ou equivalente)
• Comandante do incidente / responsável de plantão

Impacto

• Serviços e sistemas afetados
• Impacto voltado para o usuário (erros, lentidão, interrupção total)
• Número estimado de usuários afetados
• Perda ou corrupção de dados (sim/não, escopo)
• Violação de SLA/SLO (sim/não, por quanto)

Eventos da Linha do Tempo

Momentos chave para reconstruir:

• Primeiro sintoma ocorreu
• Alerta disparou (ou foi notado manualmente)
• Plantonista foi acionado / incidente declarado
• Investigação iniciada
• Causa raiz identificada
• Mitigação aplicada
• Resolução completa confirmada
• Comunicação ao cliente enviada (se houver)

Fatores Contribuintes

Pergunte à equipe: "O que tornou isso pior do que precisava ser?" — não "quem falhou". Exemplos:

• Limiar de alerta muito alto / alerta não disparou
• Runbook estava ausente ou desatualizado
• Deploy não tinha um feature flag para rollback
• Monitoramento não cobria este modo de falha
• Passagem de plantão perdeu contexto

Processo

Passo 1 — Coletar Metadados

Se o usuário não forneceu detalhes completos do incidente, peça por eles seção por seção. Não prossiga para a escrita até ter: título, horários, severidade, serviços afetados e pelo menos uma linha do tempo aproximada.

Passo 2 — Reconstruir Linha do Tempo

Trabalhe com o usuário para construir uma linha do tempo cronológica precisa. Para cada evento:

• Horário exato (UTC preferencialmente)
• O que aconteceu (evento do sistema ou ação humana)
• Quem observou ou tomou a ação
• Link para log / alerta / mensagem do Slack, se disponível

Marque lacunas: "Não sabemos o que aconteceu entre 14:32 e 14:47 — vale a pena verificar os logs."

Passo 3 — Análise de Causa Raiz

Use os 5 Porquês iterativamente:

Why did users see 500 errors?
→ The API pods were crash-looping.

Why were they crash-looping?
→ Memory limit was exceeded.

Why was the limit exceeded?
→ A new query was loading full result sets into memory.

Why wasn't this caught before deploy?
→ Load tests only covered the p50 case, not high-cardinality accounts.

Why did load tests only cover p50?
→ We had no test fixtures for large accounts.

Pare quando chegar a uma lacuna no sistema/processo que você possa corrigir. O último "porquê" deve apontar para um item de ação.

Diferencie:

• Causa raiz — a lacuna sistêmica mais profunda (uma ou duas)
• Fatores contribuintes — condições que pioraram a situação, mas não são a causa raiz

Passo 4 — Quantificação do Impacto

Ajude o usuário a ser preciso:

• Duração: detecção até resolução (não início do sintoma até resolução — separe estes)
• Taxa de erro no pico vs. linha de base normal
• Porcentagem de tráfego afetado
• Impacto financeiro / de negócios, se conhecido

Passo 5 — Itens de Ação

Para cada causa raiz e fator contribuinte, gere pelo menos um item de ação:

Itens de ação devem ter um responsável (uma pessoa, não uma equipe) e um prazo. Ações vagas como "melhorar monitoramento" não são aceitáveis — divida-as em entregas específicas.

Passo 6 — Escrever o Documento

Produza o pós-incidente completo usando o template abaixo. Salve em docs/postmortems/YYYY-MM-DD-<slug>.md.

Template de Saída

# Pós-Incidente: [Título do Incidente]


…