Post Mortem de Incidentes de TI: Guia Completo + Template Gratuito

Todo sistema de produção vai falhar em algum momento. A questão não é se vai acontecer, mas o que a organização faz depois que acontece. Times que tratam incidentes como eventos isolados a serem resolvidos e esquecidos tendem a ver os mesmos tipos de falha se repetirem. Times que constroem aprendizado sistemático a partir de incidentes evoluem continuamente.

O post mortem é o mecanismo que torna esse aprendizado sistemático possível. É um processo estruturado de análise conduzido após um incidente significativo, com o objetivo de entender o que aconteceu, por que aconteceu e o que o time pode fazer para evitar que aconteça de novo — ou para detectar e responder mais rápido quando acontecer.

Este guia explica o que é post mortem, como conduzir um de forma eficaz, o que inclui um template completo, e qual é a relação com as práticas de SRE e as métricas DORA.

O que é post mortem?

Post mortem (também chamado de “incident review” ou “learning review”) é uma análise estruturada realizada após um incidente de TI com o objetivo de identificar causas raiz, documentar o impacto e definir ações de melhoria para evitar recorrência.

O termo vem da medicina — literalmente “após a morte” — e foi adaptado pela engenharia de software para descrever o processo de examinar o “corpo” de um incidente: o que falhou, como se propagou e o que o time fez para resolver.

A característica mais importante de um post mortem eficaz não é técnica: é cultural. O Google, que popularizou a prática através do livro SRE Book, estabeleceu o princípio do post mortem sem culpa (blameless post mortem). O objetivo é entender os fatores sistêmicos que permitiram que o incidente ocorresse, não identificar quem cometeu o erro. Times que conduzem post mortems punitivos observam que as pessoas param de reportar problemas e de documentar erros honestos — destruindo exatamente o aprendizado que o processo deveria gerar.

Quando conduzir um post mortem?

Nem todo incidente justifica um post mortem completo. O critério de ativação deve ser definido com antecedência pelo time para evitar tanto a sobrecarga de documentar eventos triviais quanto o risco de deixar incidentes significativos sem análise.

Os gatilhos mais comuns para ativar um post mortem são: violação de SLO (o incidente consumiu uma parcela significativa do error budget), impacto em usuários acima de um threshold definido (por exemplo, mais de 5% dos usuários afetados por mais de 5 minutos), necessidade de escalonamento fora do time de plantão, qualquer incidente que envolva perda de dados ou degradação de segurança, e incidentes que o time considerou “quase críticos” mesmo sem impacto real — os chamados near-misses.

Como conduzir um post mortem eficaz

Um post mortem bem conduzido segue uma sequência de etapas que transforma a narrativa do incidente em aprendizado acionável.

1. Construir a linha do tempo do incidente

A primeira etapa é reconstruir cronologicamente o que aconteceu, com timestamps precisos. A linha do tempo deve cobrir: quando o problema começou (mesmo que antes de ser detectado), quando foi detectado, quando foi escalado, quais ações de mitigação foram tomadas e quando cada uma surtiu efeito, e quando o serviço foi restaurado.

A linha do tempo deve ser construída coletivamente pelo time, usando logs, dados de métricas e traces. Memória individual é pouco confiável em situações de pressão — os dados de telemetria são a fonte de verdade.

2. Identificar a causa raiz — e as causas contribuintes

A análise de causa raiz em um post mortem vai além de identificar “o que quebrou”. Sistemas distribuídos raramente falham por uma única razão — há uma cadeia de fatores que tornaram possível o impacto.

A técnica dos “5 Porquês” é um ponto de partida útil: a cada resposta sobre o que causou o problema, pergunte “por quê” novamente. O objetivo é chegar nas falhas sistêmicas — processos ausentes, cobertura de testes insuficiente, falta de observabilidade — em vez de parar em “o engenheiro X fez Y”.

3. Avaliar o impacto com precisão

O impacto deve ser documentado de forma objetiva: quantos usuários foram afetados, por quanto tempo, qual foi o impacto em métricas de negócio (transações perdidas, receita afetada, tickets de suporte gerados) e quanto do error budget foi consumido pelo incidente.

Dados precisos de impacto são necessários para priorizar as ações de melhoria e para comunicar o ocorrido ao negócio de forma objetiva.

4. Definir ações de melhoria com dono e prazo

A parte mais importante — e mais frequentemente negligenciada — do post mortem são as action items. Cada ação de melhoria identificada deve ter: descrição clara do que precisa ser feito, dono (uma pessoa específica, não um time), prazo realista e critério de conclusão verificável.

Ações sem dono e sem prazo não se tornam realidade. Times maduros rastreiam os action items dos post mortems no backlog de engenharia com a mesma prioridade que features de produto.

Template de post mortem

Um post mortem completo deve conter as seguintes seções:

Título e metadata: nome do incidente, data, duração, severidade, times envolvidos e autor do documento.

Resumo executivo: 3 a 5 linhas descrevendo o que aconteceu, o impacto e a causa raiz principal. Deve ser compreensível por alguém sem contexto técnico.

Linha do tempo: tabela cronológica com timestamps, eventos e ações tomadas.

Causa raiz e causas contribuintes: análise dos fatores que tornaram possível o incidente, usando os 5 Porquês ou diagrama de Ishikawa.

Impacto: usuários afetados, duração, impacto em SLO/error budget e impacto em negócio.

O que funcionou bem: seção explícita para registrar o que o time fez corretamente — detecção rápida, comunicação eficaz, rollback bem executado. Reforça comportamentos positivos.

O que pode melhorar: gaps identificados no processo, na observabilidade, na cobertura de alertas ou nos runbooks.

Action items: tabela com ação, dono, prazo e status.

Post mortem e as métricas DORA

O post mortem conecta diretamente com duas das métricas DORA mais impactantes.

O Failed Deployment Recovery Time (MTTR) mede quanto tempo o time leva para restaurar o serviço após uma falha. Post mortems bem conduzidos identificam os gargalos na resposta a incidentes — ausência de runbooks, alertas que chegam tarde, falta de acesso a ferramentas de diagnóstico — e geram action items que reduzem o MTTR nos incidentes seguintes.

A Change Failure Rate mede a proporção de deploys que causam degradação. Post mortems de incidentes causados por deploys identificam padrões recorrentes no pipeline de entrega — testes insuficientes, ausência de feature flags, falta de rollback automatizado — que, quando corrigidos, reduzem diretamente a Change Failure Rate.

Times que conduzem post mortems consistentemente e implementam seus action items observam melhora mensurável nas métricas DORA ao longo de 2 a 4 trimestres.

Conclusão

O post mortem é uma das práticas mais valiosas de engenharia de confiabilidade — e uma das mais subestimadas. Quando conduzido de forma consistente e sem culpa, ele transforma cada incidente em aprendizado que fortalece o sistema e o time.

Os elementos críticos para um post mortem eficaz são: linha do tempo baseada em dados de telemetria, análise de causa raiz que vai além do erro imediato, impacto quantificado e — mais importante — action items com dono e prazo rastreados no backlog. A referência canônica do tema é o capítulo sobre cultura de post mortem do Google SRE Book, disponível gratuitamente online.

Para estruturar sua prática de post mortem e resposta a incidentes, fale com nossos especialistas.