Blameless Postmortem

Em novembro de 2012, John Allspaw publicou um post no blog de engenharia da Etsy que mudou a conversa sobre cultura de operações na indústria: "Blameless PostMortems and a Just Culture". O argumento central era deceptivamente simples: quando um incidente acontece e a resposta da organização é punir ou envergonhar quem estava envolvido, a organização destrói a capacidade de aprender com esse incidente. As pessoas envolvidas ocultam informação para se proteger, evitam tomar riscos no futuro, e o conhecimento sobre o que realmente aconteceu fica restrito a quem estava "no lugar errado na hora errada". O resultado é que a falha não é aprendida — é apenas sofrida.

Allspaw foi buscar o conceito em Sidney Dekker, pesquisador de segurança de sistemas que estudou acidentes em aviação, medicina e engenharia nuclear em The Field Guide to Understanding Human Error (2006). Dekker demonstrou que atribuir acidentes a "erro humano" como causa final é empiricamente errado: pessoas cometem os erros que o sistema as coloca em posição de cometer. A causa do acidente não é a pessoa — é o contexto, o design do sistema, os incentivos, as ferramentas disponíveis. Punir a pessoa sem mudar o sistema garante que o mesmo acidente vai acontecer de novo, com outra pessoa.

O Google SRE Book (capítulo 15, "Postmortem Culture: Learning from Failure") formalizou essa abordagem no contexto de software: cada incidente significativo merece um postmortem, e o postmortem deve ser conduzido com o pressuposto de que todos os envolvidos agiram da melhor forma possível com as informações que tinham. O objetivo é entender o que aconteceu, não quem tem culpa.

O que é um postmortem

Um postmortem (também chamado de "incident review", "retrospectiva de incidente", ou "post-incident analysis" em variações sem a conotação macabra do nome original) é um documento estruturado produzido após um incidente significativo, com o objetivo de:

1. Estabelecer uma linha do tempo factual do que aconteceu
2. Identificar os fatores contribuintes — não uma causa única
3. Entender o impacto (usuários afetados, duração, custo)
4. Definir action items concretos para prevenir recorrência ou reduzir impacto
5. Compartilhar o aprendizado com o resto da organização

Um postmortem não é uma sessão de confissão. Não é uma investigação criminal. Não é uma avaliação de desempenho disfarçada. É uma análise de sistema — com o objetivo de melhorar o sistema, não de julgar pessoas.

Quando fazer postmortem

Não todo incidente merece postmortem formal. A regra do Google SRE é: qualquer incidente que violou SLO, que envolveu intervenção manual significativa fora do horário comercial, que afetou usuários de forma perceptível, ou que revelou uma falha de sistema que poderia ter impacto maior — merece postmortem. Incidentes menores com causa óbvia e resolução rápida podem ser tratados com um ticket de bug.

O timing importa: o postmortem deve acontecer dentro de 48–72 horas do incidente, enquanto o contexto ainda está fresco nos participantes. Um postmortem de um incidente de 3 semanas atrás raramente produz análise de qualidade — os detalhes desaparecem, as emoções passam, e o impulso de melhorar o sistema esfria.

Estrutura de um postmortem eficaz

A estrutura básica que o Google SRE Book recomenda — e que a maioria dos times adapta:

1. Sumário

Uma ou duas frases descrevendo o incidente para quem não estava lá: o que falhou, qual foi o impacto, quanto durou. O sumário deve ser legível por não-engenheiros.

2. Impacto

Dados concretos: número de usuários afetados, percentual de tráfego, duração da degradação, impacto financeiro estimado (pedidos perdidos, SLA comprometidos), impacto em SLO (quanto do error budget foi consumido).

3. Linha do tempo

Sequência cronológica dos eventos com horários precisos: quando a falha começou, quando foi detectada, quando o primeiro alerta disparou, quando o on-call foi acionado, que hipóteses foram formuladas, que ações foram tomadas, quando o serviço começou a se recuperar, quando foi declarado resolvido. O registro do scribe durante o incidente é a fonte principal.

LINHA DO TEMPO — Incidente Checkout 2026-04-15

14:02 — Deploy v2.14.3 concluído com sucesso
14:07 — Alerta de taxa de erro > 1% disparado
14:09 — On-call Ana reconhece alerta
14:12 — Hipótese inicial: problema no serviço de pagamento
14:18 — Eliminado: serviço de pagamento saudável
14:22 — Nova hipótese: memory leak no novo código de v2.14.3
14:25 — Confirmado: heap dump mostra objeto não liberado
14:27 — Rollback para v2.14.2 iniciado
14:32 — Rollback concluído, serviço estabilizando
14:38 — Taxa de erro voltou a < 0.1%
14:40 — Incidente declarado resolvido

4. Análise de causa raiz — contributing factors

Aqui está a diferença mais importante entre postmortem blameless e postmortem de culpa. Em vez de buscar a causa raiz (que frequentemente resulta em "erro humano" como resposta final e improdutiva), o postmortem blameless busca fatores contribuintes — as condições do sistema que tornaram o incidente possível.

A técnica dos Five Whys (Toyota, anos 1950) é um ponto de partida: perguntar "por quê" repetidamente até chegar à causa sistêmica. Mas Dekker e outros pesquisadores de segurança de sistemas apontam que o Five Whys tende a convergir para uma única causa linear — "o engenheiro fez X" — quando incidentes são tipicamente causados por múltiplos fatores que se alinharam. Uma abordagem mais rica é mapear os fatores contribuintes como uma árvore, não uma cadeia.

Incidente v2.14.3 — Fatores contribuintes:

1. O memory leak não foi detectado em testes
   → Por quê? Testes de memória só rodavam em staging
     com volume 10× menor que produção
   → Ação: Adicionar testes de memória com volume realístico

2. O alerta disparou 5 minutos após o deploy, não imediatamente
   → Por quê? Alerta configurado com janela de 5 minutos
     para reduzir falsos positivos
   → Ação: Revisar janela de alerta para 60s com
     detecção de anomalia estatística

3. O rollback demorou 5 minutos para estabilizar
   → Por quê? Rolling update com 20% de instâncias por vez
   → Ação: Implementar abort automático de rolling update
     se taxa de erro subir durante o processo

4. O diagnóstico demorou 13 minutos
   → Por quê? Hipótese inicial estava errada;
     heap dump não estava no runbook de troubleshooting
   → Ação: Adicionar heap dump ao runbook de memory issues

5. O que funcionou bem

Um ponto frequentemente negligenciado no postmortem: o que o time fez certo? Alertas que dispararam no tempo correto, runbooks que funcionaram, decisões de escalação acertadas, comunicação eficaz com stakeholders. Isso reforça os comportamentos positivos e evita que o postmortem seja percebido como exercício puramente punitivo.

6. Action items

O valor do postmortem está nos action items — as ações concretas que reduzem a probabilidade de recorrência ou reduzem o impacto se o incidente recorrer. Um action item precisa de três atributos para ser real: o que (ação específica e verificável), quem (owner único, não "equipe"), e quando (data de entrega).

Conduzindo o meeting de postmortem

O meeting de postmortem (1–2 horas para incidentes complexos) tem um facilitador — que não precisa ser quem estava de on-call, e idealmente não é. O facilitador garante que:

• A discussão é sobre sistema, não sobre pessoas ("o código tinha uma condição de corrida", não "Carlos escreveu código com condição de corrida")
• Todos têm espaço para falar — não apenas quem estava mais envolvido
• A análise de contributing factors vai fundo o suficiente — não para no "erro humano"
• Action items terminam com owner e data, não com "alguém deveria"
• O meeting termina em tempo — 2 horas é o máximo razoável

Uma técnica útil para facilitar é o "rewrite de linguagem": quando alguém diz "o Carlos esqueceu de liberar o objeto", o facilitador reescreve: "existe um caminho de código onde o objeto não é liberado, e não havia detecção automática para isso". A mudança de "Carlos esqueceu" para "caminho de código + falta de detecção" muda fundamentalmente o foco da conversa.

Postmortem como documento compartilhado

Postmortems guardados em pastas privadas ou restritos ao time que viveu o incidente perdem grande parte do valor. Um dos princípios do Google SRE é que postmortems devem ser compartilhados amplamente na organização — para que outros times possam aprender com incidentes que não viveram.

Isso requer um repositório de postmortems acessível (não necessariamente público, mas acessível internamente), e uma cultura de leitura — alguns times têm uma reunião quinzenal de "leitura de postmortem" onde um postmortem recente (de qualquer time) é discutido em grupo.

Five Whys e suas limitações

Os Five Whys são úteis como primeira abordagem, mas têm limitações bem documentadas. Taiichi Ohno, que popularizou a técnica na Toyota, aplicava em contextos de manufatura onde as causas são frequentemente lineares. Em sistemas de software distribuídos, com múltiplas camadas de abstração e dependências, as causas raramente são lineares.

As críticas mais relevantes: o Five Whys tende a parar quando atinge um "erro humano" — "o operador não seguiu o procedimento" — que é conveniente como resposta final mas não é sistêmica. Além disso, o Five Whys pressupõe que a cadeia de causa e efeito é única e linear, quando incidentes em sistemas complexos geralmente têm múltiplas cadeias que se intersectam.

Para incidentes complexos, técnicas como Event Analysis (Richard Cook) ou Causal Loop Diagrams são mais adequadas que os Five Whys. O princípio é o mesmo — entender fatores sistêmicos — mas o método é mais robusto para complexidade.

Como praticar

1. Fazer postmortem de um incidente passado. Escolha um incidente recente (das últimas semanas) que não teve postmortem formal. Reúna os envolvidos por 90 minutos. Use o template: sumário, impacto, linha do tempo, contributing factors, o que funcionou, action items. Foque especialmente nos contributing factors — a pergunta "por quê o sistema permitiu isso?" em vez de "por quê alguém fez isso?". Documente em um lugar compartilhado.
2. Analisar um postmortem público. Diversas empresas publicam postmortems abertamente (GitHub Status, Cloudflare, Vercel). Encontre um postmortem público de um incidente relevante. Analise: a linha do tempo está completa? Os contributing factors são sistêmicos ou param em "erro humano"? Os action items são específicos com owner e data? O que você faria diferente na análise?
3. Criar um template de postmortem para o time. Com base na estrutura deste conceito, crie um template de postmortem no Google Docs, Notion, ou equivalente. Inclua as seções principais e, em cada uma, perguntas guia que o facilitador pode usar. Teste o template em um tabletop exercise — não em um incidente real — para calibrar se as perguntas guia produzem análise útil.