Template Postmortem

Postmortem sem culpa: da segurança da aviação à engenharia de software

Um postmortem (frequentemente chamado blameless post-mortem) é uma análise escrita de um incidente depois de resolvido: o que aconteceu, qual foi o impacto, por que aconteceu, como o time respondeu e o que vai mudar para não acontecer de novo. O formato foi emprestado da cultura de segurança da aviação — o NTSB (National Transportation Safety Board) publica relatórios detalhados de acidentes há décadas — e adaptado para software pelo Google no capítulo "Postmortem Culture: Learning from Failure" do livro de SRE. O adjetivo definidor é blameless: o objetivo é encontrar a causa sistêmica, não atribuir culpa a um indivíduo.

Um postmortem canônico contém: Resumo (um parágrafo), Impacto (usuários afetados, duração, receita, queima de SLO), Linha do tempo (eventos com timestamp da detecção à recuperação), Causa raiz (frequentemente chegada via 5 Porquês), Fatores contribuintes, Detecção (como descobrimos?), Resposta, Recuperação, Lições aprendidas e Itens de ação (cada um com dono explícito e prazo). A técnica dos 5 Porquês foi criada por Taiichi Ohno na Toyota nos anos 1950: continue perguntando "por quê" até parar de bater em sintomas e começar a bater em estrutura.

Por que "sem culpa" importa

"Sem culpa" não é uma questão de cortesia — é um investimento de engenharia em segurança psicológica. Quando engenheiros sabem que não serão punidos por descrever honestamente o que aconteceu, eles contam a verdade, e o time aprende. O contrário — uma cultura que culpa "erro humano" — produz postmortems em que todos escondem os detalhes interessantes, e o mesmo incidente se repete seis meses depois. O reenquadramento certo é "o que permitiu o erro humano?": falta de guardrails, ferramentas ambíguas, alertas que dispararam tarde demais, runbooks errados. A combinação "sem culpa mais responsabilização" às vezes é chamada de just culture.

Severidades, métricas e postmortems famosos

A maioria dos times classifica incidentes por severidade — SEV1 (crítico, todos na ponte), SEV2 (grave), SEV3 (menor) — e reserva postmortem escrito obrigatório para SEV1 e SEV2. Métricas-chave incluem MTTD (Mean Time To Detect), MTTR (Mean Time To Recovery) e MTTF (Mean Time To Failure). Postmortems publicados publicamente que valem a leitura: AWS S3 (fevereiro de 2017, um typo num comando), Cloudflare (julho de 2019, uma regex ruim deployada globalmente), GitHub (outubro de 2018, o "Octopus" split-brain), Slack (janeiro de 2022), Fastly (junho de 2021, a configuração de um único cliente causou um outage global).

Ferramentas e disciplina de ação

Plataformas modernas de gestão de incidentes — Atlassian Statuspage, FireHydrant, incident.io, Jeli (analytics de incidente, hoje PagerDuty), Rootly — embutem o template de postmortem no ciclo de vida do incidente. Itens de ação devem ser SMART (Specific, Measurable, Achievable, Relevant, Time-bound) e cada um precisa de um dono nomeado e uma data. O segredo sujo dos postmortems é que o documento em si vale muito pouco; o que muda o futuro é se os itens de ação são de fato concluídos. Uma reunião semanal ou mensal que percorre os itens de ação em aberto é a diferença entre cultura de aprendizado e ritual de postmortem.

Perguntas frequentes

Postmortems devem ser públicos ou internos? Geralmente os dois. A versão interna é mais longa e detalhada (timestamps, nomes de cliente, nomes de ferramentas internas); a externa é uma comunicação para o cliente na status page. AWS, Cloudflare e GitHub publicam versões externas para incidentes maiores.

Postmortem é obrigatório? Para SEV1 e a maior parte dos SEV2, sim. Trate a decisão "devemos escrever um?" como default-sim; o custo de escrever é baixo comparado ao custo de repetir o incidente.

Quando o postmortem deve ser escrito? Dentro de uma semana após o incidente, enquanto a memória está fresca. O rascunho frequentemente começa durante o próprio incidente (linha do tempo, decisões-chave) e é finalizado depois de uma retrospectiva estruturada.

"Erro humano" é uma causa raiz válida? Não. Se uma ação humana disparou o incidente, a verdadeira causa raiz é o sistema que permitiu que uma única ação humana tivesse aquele efeito. Reenquadre toda resposta "erro humano" como "o que estava faltando que teria evitado isso?".