O deploy foi revertido, a fila voltou a andar e o canal de incidentes finalmente ficou quieto. É justamente aí que muitos times encerram o assunto cedo demais. Restaurar o serviço é uma parte do trabalho; entender por que a equipe descobriu tarde, teve pouca informação ou precisou improvisar é a parte que reduz a chance de viver a mesma noite de novo.
Um postmortem útil não é o documento que procura “quem fez”. É o registro que permite responder, com calma, o que aconteceu no sistema, qual foi o impacto, quais decisões foram tomadas com as informações disponíveis e o que precisa mudar de verdade.
Não comece pelo culpado
“Fulano subiu sem testar” parece uma explicação rápida, mas quase nunca é uma explicação completa. Por que aquele caminho passou pelos controles? O alerta avisou algo antes do cliente? Havia rollback fácil? A mudança era compreensível para quem estava de plantão? Essas perguntas atacam o sistema de trabalho, não a pessoa que ficou visível no final da cadeia.
Isso não significa transformar o texto em diplomacia vazia. O relato precisa registrar decisões e erros concretos. A diferença é escrever sobre condições e efeitos: o alerta não separava falha de dependência de queda de tráfego, por exemplo, é mais acionável do que apontar que alguém “demorou para perceber”.
Escreva a linha do tempo antes da memória virar versão oficial
Logo após o incidente, cada participante carrega uma sequência diferente na cabeça. Junte fatos verificáveis: primeiro sinal, início estimado do impacto, alerta, reconhecimento, comunicação, tentativas de mitigação, rollback ou correção e normalização. Use horário exato quando houver log, ticket ou métrica. “Perto das 14h” só serve quando não existe dado melhor.
Uma linha do tempo boa frequentemente revela o problema que o resumo esconde: houve oito minutos entre o impacto e o alerta; o rollback levou mais tempo por depender de uma permissão; a página de status foi atualizada quando a maior parte dos usuários já tinha sido afetada. Não é burocracia. É material para decidir onde investir.
Separe impacto, causa e fatores que contribuíram
Misturar tudo num parágrafo produz um texto que ninguém consegue usar depois. O impacto responde quem foi afetado e como: indisponibilidade, lentidão, transações perdidas, retrabalho de suporte ou degradação parcial. A causa descreve o mecanismo que disparou o problema. Os fatores contribuintes explicam por que aquilo teve alcance maior, demorou a aparecer ou foi difícil de mitigar.
Exemplo: uma configuração inválida pode ser a causa imediata. A ausência de validação no pipeline, uma mudança grande demais e um dashboard que escondia o erro podem ser fatores contribuintes. Corrigir só a configuração resolve o hoje; lidar com os outros pontos melhora o próximo incidente.
Ação sem dono e prazo é só desejo
“Melhorar monitoramento” e “revisar deploy” parecem bons itens até a próxima sprint apertar. Toda ação precisa de uma mudança observável, uma pessoa responsável e uma data de revisão. Em vez de “criar alerta melhor”, prefira “criar alerta para taxa de erros acima de X por Y minutos e testar a rota de escalonamento até 15 de novembro”.
Também vale distinguir correção, prevenção e redução de impacto. Uma correção elimina o defeito conhecido. Prevenção dificulta que a mesma classe de falha entre em produção. Redução de impacto diminui o estrago quando algo inevitavelmente escapar. Backups testados, feature flags e um rollback documentado muitas vezes entram na terceira categoria — e isso já é um ganho enorme.
Feche o ciclo em poucos dias
Descansar depois de uma ocorrência pesada é necessário. Mas deixar o documento para “quando der” costuma custar detalhes importantes. Faça um rascunho enquanto logs, decisões e dúvidas ainda estão frescos; depois revise com quem participou e publique internamente para quem possa aprender com ele.
O teste final é simples: alguém novo no plantão conseguiria entender o que aconteceu, saber o que mudou e localizar as pendências abertas? Se a resposta for não, o serviço voltou, mas o aprendizado ainda não.
Checklist enxuto para o próximo postmortem
- Impacto descrito em linguagem de usuário e de operação.
- Linha do tempo com horários e fontes de evidência.
- Causa imediata separada dos fatores contribuintes.
- Texto objetivo, sem culpar pessoas.
- Ações com dono, prazo e resultado verificável.
- Revisão marcada e pendências acompanhadas no fluxo normal do time.
O objetivo não é produzir um PDF bonito para provar que houve processo. É deixar o sistema, o plantão e a comunicação um pouco menos frágeis antes do próximo alerta tocar.
