Post-mortem de Incidentes: um jeito simples de aprender com falhas sem procurar culpados

Incidentes acontecem.

Um sistema pode ficar lento, uma aplicação pode parar de responder, uma rotina crítica pode falhar ou uma alteração aparentemente pequena pode gerar impacto para usuários.

Na hora do problema, a prioridade é clara: restaurar o serviço.

Não é o melhor momento para discutir todos os detalhes, procurar a causa profunda ou revisar o processo inteiro. Durante o incidente, a equipe precisa reduzir o impacto, comunicar quem precisa ser comunicado e colocar o ambiente de volta em operação.

Mas depois que a situação estabiliza, vem uma parte que muitas equipes deixam passar: entender o que aconteceu e transformar o problema em aprendizado.

É aí que entra o post-mortem.

O que é um post-mortem?

Post-mortem, ou análise pós-incidente, é um registro feito depois de um incidente para responder perguntas simples:

• O que aconteceu?
• Quem ou o que foi afetado?
• Como percebemos o problema?
• O que fizemos para resolver?
• O que funcionou bem?
• O que dificultou a resposta?
• O que precisamos mudar para reduzir a chance de acontecer de novo?

A ideia não é criar um documento bonito para arquivar. A ideia é tirar o conhecimento da cabeça das pessoas e transformar em algo que possa ser consultado depois.

Sem isso, a história costuma se repetir: alguém resolve o problema no improviso, o time segue a vida e, algumas semanas depois, o mesmo tipo de falha volta. Quando isso acontece, todos dependem de memória, prints soltos, mensagens antigas ou da pessoa que estava no atendimento naquele dia.

Um post-mortem simples evita isso.

Ele cria memória operacional.

O objetivo não é achar culpados

Um ponto importante: post-mortem não é caça às bruxas.

Se o documento termina apontando uma pessoa como causa do incidente, provavelmente a análise ficou rasa.

Por exemplo, escrever isto ajuda pouco:

O técnico executou o comando errado.

Uma forma melhor de analisar seria:

O procedimento permitia executar o comando em produção sem confirmação do ambiente, revisão ou validação automática.

A diferença é grande.

Na primeira frase, a conversa morre na culpa. Na segunda, a equipe consegue discutir melhoria de processo, automação, permissão, documentação e proteção contra erro.

Em sistemas reais, incidentes quase nunca acontecem por uma única causa. Normalmente existe uma combinação de fatores:

• documentação incompleta;
• alerta que não disparou;
• monitoramento insuficiente;
• rotina manual sensível a erro;
• mudança sem validação;
• permissão ampla demais;
• pressão de tempo;
• falta de revisão;
• comunicação confusa;
• dependência de conhecimento individual.

Por isso, “erro humano” raramente deveria ser a conclusão final. O mais útil é perguntar: o que no processo, no sistema ou na operação permitiu que esse erro gerasse impacto?

Na prática, como isso ajuda?

O post-mortem é funcional porque cria um ciclo simples de melhoria.

Primeiro, a equipe estabiliza o serviço. Depois, registra o que aconteceu. Em seguida, entende os fatores que contribuíram para o problema. Por fim, transforma o aprendizado em ações concretas.

Esse ciclo evita que o incidente seja tratado como um caso isolado.

Um bom post-mortem pode ajudar a:

• reduzir a repetição de falhas parecidas;
• melhorar alertas e monitoramento;
• deixar procedimentos mais claros;
• acelerar diagnósticos futuros;
• justificar melhorias técnicas;
• reduzir dependência de pessoas específicas;
• melhorar a comunicação durante incidentes;
• criar histórico para novos membros da equipe.

E não precisa ser um documento enorme.

Em muitos casos, uma página bem escrita já resolve. O importante é que ela seja objetiva, fácil de consultar e termine com ações reais.

Um post-mortem bom não é aquele cheio de termos técnicos. É aquele que, meses depois, qualquer pessoa da equipe consegue ler e entender rapidamente o que aconteceu, como foi resolvido e o que foi aprendido.

Quando vale fazer um post-mortem?

Nem todo incidente precisa de uma análise completa.

Se a equipe tentar criar um relatório detalhado para qualquer pequeno ruído, o processo vira burocracia. Por outro lado, se nunca documentar nada, os aprendizados se perdem.

Uma forma prática é separar por impacto:

Alguns gatilhos ajudam a decidir:

• afetou cliente, usuário ou área crítica;
• causou indisponibilidade ou lentidão relevante;
• exigiu intervenção emergencial;
• envolveu risco de perda ou inconsistência de dados;
• demorou mais do que o esperado para diagnosticar;
• revelou falha de monitoramento;
• aconteceu mais de uma vez;
• gerou dúvida sobre processo, comunicação ou responsabilidade.

A regra não precisa ser perfeita. O mais importante é não deixar incidentes relevantes passarem sem aprendizado.

Comece simples: cinco perguntas

Um erro comum é tentar começar com um modelo muito complexo.

Isso assusta a equipe e transforma o post-mortem em uma tarefa pesada.

Para começar, responda bem estas cinco perguntas:

1. O que aconteceu?
2. Qual foi o impacto?
3. Como percebemos o problema?
4. O que fizemos para resolver?
5. O que vamos mudar para reduzir a chance de acontecer de novo?

Se essas cinco perguntas forem respondidas com clareza, a equipe já tem um bom ponto de partida.

Com o tempo, dá para evoluir o processo com linha do tempo mais detalhada, métricas, análise de causa raiz, revisão de backlog, recorrência e indicadores operacionais.

Mas no começo, o mais importante é criar o hábito.

Registre enquanto o contexto ainda está fresco

O melhor momento para iniciar o post-mortem é logo depois que o incidente foi estabilizado.

Não precisa estar tudo perfeito no mesmo dia, mas o rascunho inicial deve ser feito enquanto as informações ainda estão frescas.

Isso ajuda porque:

• as pessoas ainda lembram das decisões tomadas;
• os logs e métricas ainda estão disponíveis;
• os horários são mais fáceis de reconstruir;
• os detalhes da comunicação não se perdem;
• as ações corretivas ainda parecem urgentes.

Se a equipe espera uma ou duas semanas, muita coisa vira suposição.

Uma boa prática é criar a página do post-mortem logo após a resolução e completar a análise nos dias seguintes.

Linha do tempo: a parte que mais ajuda no futuro

A linha do tempo é uma das partes mais úteis do post-mortem.

Ela mostra a sequência dos acontecimentos: quando o problema começou, quando foi detectado, quem foi acionado, quais hipóteses foram testadas, quais ações foram feitas e quando o serviço estabilizou.

Um exemplo simples:

O objetivo não é escrever uma novela. O objetivo é deixar claro como o incidente evoluiu.

Quando possível, cada evento importante deve ter alguma evidência: log, alerta, métrica, chamado, commit, mensagem ou registro de mudança.

Se algum horário for aproximado, deixe isso claro.

Causa raiz ou fatores contribuintes?

Muita gente fala em “causa raiz” como se todo incidente tivesse uma única explicação.

Na prática, isso pode simplificar demais o problema.

É comum existir uma causa imediata e vários fatores contribuintes.

A causa imediata é o evento técnico mais próximo do impacto.

Exemplo:

A aplicação excedeu o limite de conexões disponíveis no banco de dados.

Mas isso ainda não explica por que o incidente foi possível.

Os fatores contribuintes poderiam ser:

• não havia alerta para uso elevado de conexões;
• a alteração foi aplicada sem teste suficiente;
• o rollback não estava documentado;
• o limite de conexões era desconhecido pela equipe;
• o dashboard não mostrava esse indicador.

Esse tipo de análise é mais útil do que parar na primeira resposta.

O objetivo é entender o sistema como um todo: tecnologia, processo, comunicação, monitoramento e tomada de decisão.

Ações precisam virar tarefas reais

A parte mais importante do post-mortem é o plano de ação.

Se o documento termina sem ações claras, ele vira apenas histórico.

E ações vagas quase nunca funcionam.

Evite escrever:

Melhorar o monitoramento.

Prefira algo como:

Criar alerta para uso de conexões do banco acima de 80% por mais de 5 minutos.

Uma boa ação precisa ter:

• descrição clara;
• responsável;
• prazo;
• prioridade;
• critério de conclusão;
• local de acompanhamento, como chamado, issue ou tarefa.

Exemplo:

O post-mortem só gera valor quando essas ações são acompanhadas.

Sem acompanhamento, a equipe documenta bem, mas continua repetindo os mesmos problemas.

Precisa sempre ter reunião?

Nem sempre.

Se o incidente foi pequeno, o documento pode ser suficiente.

Mas se o impacto foi maior, se várias pessoas participaram da resolução ou se existem dúvidas sobre as causas, uma conversa curta ajuda bastante.

Essa reunião não deve ser uma leitura do documento inteiro.

O objetivo é alinhar o entendimento e decidir o que será feito depois.

Um roteiro simples:

• relembrar rapidamente o que aconteceu;
• confirmar o impacto;
• revisar a linha do tempo;
• discutir fatores contribuintes;
• definir ações de acompanhamento;
• confirmar responsáveis e prazos.

Durante a conversa, prefira perguntas como:

• O que parecia estar acontecendo naquele momento?
• Quais informações estavam disponíveis?
• O que dificultou o diagnóstico?
• O que ajudou na recuperação?
• Que proteção poderia ter reduzido o impacto?
• O que precisamos mudar no processo?

Evite perguntas que já apontam culpa:

• Quem errou?
• Por que você fez isso?
• Quem deixou isso acontecer?

A qualidade da conversa influencia diretamente a qualidade das melhorias.

Uma pessoa precisa puxar o processo

Mesmo que o post-mortem seja colaborativo, é importante ter uma pessoa responsável por conduzir o processo.

Isso não significa que essa pessoa causou o incidente. Também não significa que ela precisa escrever tudo sozinha.

O responsável apenas garante que:

• a página seja criada;
• as informações sejam reunidas;
• as pessoas certas sejam envolvidas;
• as ações sejam registradas;
• os próximos passos não sejam esquecidos.

Quando a responsabilidade fica solta para “o time”, existe um risco grande de todo mundo achar que outra pessoa vai fazer.

No fim, ninguém faz.

Por isso, depois de um incidente relevante, defina uma pessoa para puxar o post-mortem até o encerramento.

Como saber se isso está funcionando?

O post-mortem não deve ser medido pela quantidade de documentos criados.

Ele deve ser medido pela melhoria que gera.

Alguns sinais de que o processo está funcionando:

• incidentes parecidos diminuem;
• o tempo de detecção melhora;
• o tempo de recuperação reduz;
• alertas ficam mais precisos;
• procedimentos ficam mais claros;
• ações corretivas são concluídas;
• novos membros conseguem aprender com incidentes antigos;
• a equipe fala sobre falhas com mais transparência.

Se os documentos são escritos, mas nenhuma ação é concluída, o processo precisa ser revisto.

Post-mortem não é o fim do incidente. É a ponte entre o problema e a melhoria.

Template simples de post-mortem

Copie o modelo abaixo e adapte conforme o tamanho do incidente.

# Post-mortem — [Nome do incidente]

## Informações gerais

| Campo | Informação |
|---|---|
| Data do incidente | [DD/MM/AAAA] |
| Início | [HH:MM] |
| Detecção | [HH:MM] |
| Normalização | [HH:MM] |
| Duração total | [00h00min] |
| Severidade | [Baixa / Média / Alta / Crítica] |
| Serviço afetado | [Nome do serviço] |
| Responsável pelo post-mortem | [Nome] |
| Status | [Rascunho / Em revisão / Concluído] |

## Resumo

Descreva em poucas linhas o que aconteceu, qual foi o impacto,
como o serviço foi recuperado e quais ações serão tomadas.

## Impacto

| Item | Descrição |
|---|---|
| Usuários afetados | |
| Serviços afetados | |
| Funções afetadas | |
| Duração | |
| Dados afetados | |
| Impacto operacional | |
| SLA afetado | |

## O que aconteceu

Descreva os acontecimentos de forma objetiva.

## Detecção

- Como o incidente foi detectado?
- Quem ou qual sistema detectou?
- O monitoramento alertou corretamente?
- O problema foi percebido antes dos usuários?

## Linha do tempo

| Data e horário | Evento | Evidência |
|---|---|---|
| [DD/MM/AAAA HH:MM] | [Evento] | [Log, alerta, métrica ou chamado] |
| [DD/MM/AAAA HH:MM] | [Evento] | [Log, alerta, métrica ou chamado] |

## Diagnóstico

### Sintomas observados

- 
- 
- 

### Hipóteses analisadas

| Hipótese | Resultado | Evidência |
|---|---|---|
| | Confirmada / Descartada | |
| | Confirmada / Descartada | |

## Causa imediata

Descreva o evento técnico diretamente relacionado ao incidente.

## Fatores contribuintes

Liste condições técnicas, processuais ou organizacionais que contribuíram
para o incidente.

- 
- 
- 

## Resolução

### Ação emergencial

Descreva o que foi feito para restaurar o serviço.

### Solução temporária

Descreva qualquer contorno ainda em uso.

### Solução definitiva

Descreva a correção permanente planejada ou implementada.

## O que funcionou bem

- 
- 
- 

## O que pode ser melhorado

- 
- 
- 

## Ações de acompanhamento

| ID | Ação | Responsável | Prioridade | Prazo | Critério de conclusão | Status |
|---|---|---|---|---|---|---|
| AC-01 | | | Alta | | | Pendente |
| AC-02 | | | Média | | | Pendente |
| AC-03 | | | Baixa | | | Pendente |

## Riscos aceitos ou ações adiadas

| Item | Motivo | Próxima revisão |
|---|---|---|
| | | |

## Comunicação

### Comunicação interna

Resumo ou link da comunicação interna.

### Comunicação externa

Texto enviado ou planejado para clientes e usuários, se aplicável.

## Evidências

- Logs:
- Dashboard:
- Alertas:
- Chamado:
- Commit ou alteração:
- Capturas de tela:

## Lições aprendidas

Descreva o principal aprendizado técnico, operacional e de processo.

## Conclusão

- Estado atual do serviço:
- Riscos residuais:
- Ações pendentes:
- Próxima revisão:

Checklist rápido

Antes de encerrar um post-mortem, confira:

• o impacto foi descrito com clareza;
• a linha do tempo está baseada em fatos;
• a análise não parou em “erro humano”;
• os fatores contribuintes foram registrados;
• o que funcionou bem também foi documentado;
• as ações são específicas;
• cada ação tem responsável e prazo;
• existe um local para acompanhar as ações;
• os riscos aceitos foram registrados;
• o documento pode ser entendido por alguém que não participou do incidente.

Conclusão

Post-mortem não precisa ser complicado.

Ele precisa ser útil.

Quando bem feito, ajuda a equipe a entender melhor seus sistemas, melhorar processos, reduzir recorrência e responder melhor ao próximo incidente.

Mais importante: ele muda a conversa.

Em vez de perguntar “quem errou?”, a equipe passa a perguntar “o que aprendemos e o que vamos melhorar?”.

Essa mudança parece simples, mas faz muita diferença na maturidade de uma operação de TI.

Leituras recomendadas

• Google SRE Book — Postmortem Culture
• PagerDuty — Postmortems and Post-Incident Reviews
• Atlassian — Incident Postmortem Process
• ITSM na Prática — Post Mortem de Incidentes de TI