Um post-mortem técnico é um documento usado após um incidente (como falha em servidor, bug crítico, queda de serviço, etc.) para analisar o que aconteceu, por que aconteceu e como evitar no futuro. O foco é aprendizado, não culpa. É uma prática comum em operações de TI, DevOps e engenharia de software para melhorar processos e reduzir recorrência de problemas.
1️⃣ Objetivo do post-mortem
- Entender a causa raiz do incidente.
- Documentar impacto e resposta.
- Criar ações corretivas e preventivas.
- Servir como registro histórico e aprendizado para a equipe.
2️⃣ Estrutura típica de um post-mortem técnico
1. Resumo Executivo
- Breve descrição do incidente.
- Quando e onde ocorreu.
- Impacto resumido (serviços afetados, usuários impactados, downtime).
- Status final (resolvido / mitigado / em monitoramento).
2. Linha do Tempo
- Sequência detalhada dos eventos:
- Hora exata do início do problema.
- Ações tomadas.
- Identificação do impacto.
- Isso ajuda a entender como a equipe reagiu e identificar gargalos na resposta.
3. Impacto
- Serviços afetados.
- Número de usuários impactados ou processos interrompidos.
- Perdas financeiras ou operacionais, se aplicável.
4. Causa Raiz (Root Cause)
- Explicação técnica detalhada do que causou o incidente.
- Evite “culpar pessoas”; foque em sistemas, processos ou falhas de configuração.
- Pode incluir logs, screenshots ou trechos de código.
5. Ações Imediatas / Mitigação
- O que foi feito para restaurar o serviço rapidamente.
- Ferramentas usadas, comandos executados, reinicializações, ajustes de configuração, etc.
6. Lições Aprendidas
- O que a equipe descobriu sobre processos, monitoramento ou infraestrutura.
- Pontos de melhoria em comunicação, alerta ou resposta a incidentes.
7. Ações Corretivas e Preventivas
- Mudanças definitivas para evitar que o problema se repita.
- Pode incluir:
- Automação de alertas.
- Ajuste de thresholds em monitoramento.
- Atualização de documentação ou runbooks.
- Treinamentos ou revisão de processos.
8. Responsáveis e Prazo
- Quem vai implementar cada ação corretiva.
- Prazo estimado de implementação.
- Status de acompanhamento.
9. Anexos
- Logs, prints, gráficos de monitoramento.
- Links para tickets, commits ou deploys relacionados.
3️⃣ Boas práticas
- Seja objetivo e claro: qualquer membro da equipe deve entender.
- Evite culpar pessoas; foque em processos e sistemas.
- Inclua ações concretas, não só relatos.
- Use métricas e evidências sempre que possível.
- Faça distribuição interna: todos que dependem dos serviços devem ter acesso.
Veja Mais:
Diferentes tipos de vulnerabilidades de segurança e como se proteger
Custos Ocultos de Infraestrutura: Como Evitar Surpresas no Orçamento de TI
Cache de servidor vs cache de plugin: diferenças reais