Como este tema funciona na sua empresa
Sem post-mortem formal. "Aconteceu problema, resolvemos, próximo". Aprendizado é zero. Solução: começar processo simples. Reunião informal após incidente crítico, questões guia, documento rápido. Resultado: próxima vez é melhor.
Post-mortem existe, mas pode ser superficial ou defensivo ("culpa do operador"). Solução: estruturar, treinar facilitador, implementar metodologia blameless. Template claro, facilitador neutro, ações rastreadas e executadas.
Post-mortem maduro, pode ser formalizado em ITSM. Desafio: manter qualidade, garantir ações executadas, analisar padrões. Plataforma de post-mortem (Blameless, FireHydrant), análise de trends, integração com learning management.
Post-mortem de incidente é reunião estruturada após incidente crítico para analisar o que aconteceu, por que aconteceu (sem culpa), e quais ações evitarão recidiva, promovendo aprendizado organizacional e melhoria contínua[1].
Blameless: o princípio central
Blameless não significa "sem accountability". Significa: foco em sistema/processo, não em indivíduo. Pergunta certa: "por que o sistema permitiu esse erro?" Pergunta errada: "por que você errou?"
Exemplo: operador deletou banco de dados por erro. Blameless pergunta: "por que sistema não tinha proteção contra deletion acidental?" (solução: permissões, backup, alertas). Não blameless culpa operador (solução: desligar operador, problema volta).
Psicologia: pessoas só admitem erro em ambiente seguro. Culpa gera defensão, mentira, silos. Segurança psicológica gera honestidade, aprendizado.
Estrutura de reunião de post-mortem
- Timeline: cronologia exata de eventos. "10:30 alert de CPU. 10:31 operador loginava. 10:32 descobriu problema. 10:45 resolveu." Exatidão importa.
- O que aconteceu: descrição neutra do incidente. "BD ficou fora por 15 minutos, causando timeout em 200 usuários".
- Por quê (5 Whys): análise de causa raiz. "Por que BD ficou fora? Porque disco encheu. Por que encheu? Porque logs não eram rotacionados. Por que não? Porque script de rotação falhava silenciosamente sem alerta."
- Impacto: quantificar: usuários afetados, receita perdida, reputação. Isso justifica investimento em prevenção.
- Ações: quais mudanças evitam recidiva? Exemplo: "adicionar alerta de disco > 80%", "automaticar rotação de logs", "testar logs diariamente".
- Responsáveis e prazos: quem faz cada ação? Quando? Sem isso, ações nunca saem do papel.
Papel do facilitador
Facilitador é neutro, não é chefe nem do time afetado. Deve:
- Manter tom curiosidade, não blame ("como isso aconteceu?" não "por que você deixou?").
- Garantir que pessoas falam abertamente (se chefe está presente, medo de represália).
- Aprofundar em causa raiz (muitas vezes raiz é sistêmica, não óbvia).
- Garantir ações concretas (não vago: "melhorar comunicação"; sim específico: "implementar canal de Slack #on-call").
Rastreamento de ações e medição de impacto
Problema comum: post-mortem gera ações, ações ficam em documento, nunca são executadas. Resultado: próximo incidente, mesma causa.
Solução:
- Cada ação tem responsável, deadline, e status (em aberto, em progresso, completo).
- Revisão semanal: "o que foi feito dessa semana?"
- Post-mortem follow-up: "as ações evitaram o problema?"
- Se mesmo incidente acontece 2x, significa ação falhou ou não foi adequada.
Sinais de que seu processo de post-mortem precisa melhorar
- Incidentes similares acontecem múltiplas vezes (mesma causa raiz)
- Post-mortem é reunião chata que ninguém quer assistir
- Blame e defensão dominam a conversa, não curiosidade
- Ações são genéricas ("melhorar monitoramento") não específicas ("adicionar alerta de disco > 85%")
- Ações são listadas mas nunca são executadas
- Operador que cometeu erro é punido ou saído, problema volta
- Você não conseguir prever ou evitar incidentes similares
Caminhos para implementar processo de post-mortem
Viável se tem facilitador experiente (gestor de TI, SRE).
- Perfil necessário: gestor de operações ou SRE com experiência em incident management
- Tempo estimado: 1–2 meses para estruturar processo, treinar time
- Faz sentido quando: incidentes são recorrentes mas organização não tem processo formal
- Risco principal: facilitador não consegue manter tom blameless; blame volta
Indicado para mudar cultura de blame para blameless.
- Tipo de fornecedor: Consultoria de SRE, Consultoria de Organizational Psychology
- Vantagem: experiência em mudança de cultura, treinamento de facilitadores, auditoria de processos
- Faz sentido quando: cultura de culpa é forte na empresa, ou incidentes críticos recorrentes
- Resultado típico: em 3–6 meses, processo blameless implementado, facilitadores treinados, ações executadas
Precisa de apoio para estruturar processo de post-mortem ou melhorar incident learning?
Se aprender com incidentes é prioridade, o oHub conecta você gratuitamente a consultores de SRE e especialistas em incident management. Em menos de 3 minutos, descreva sua situação e receba propostas, sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
O que é post-mortem de incidente?
Reunião estruturada após incidente crítico para: (1) entender timeline exata; (2) análise de causa raiz; (3) quantificar impacto; (4) definir ações para evitar recidiva. Não é "reunião de blame", é "reunião de aprendizado".
Por que conduzir post-mortem?
Sem post-mortem: próximo incidente, mesma causa, perda de tempo. Com post-mortem: aprender, evitar recidiva, melhorar sistema, reduzir downtime. ROI: uma ação bem feita salva 10 incidentes futuros.
Como evitar que post-mortem vire "caça às bruxas"?
Implementar blameless: foco em sistema, não pessoa. Facilitador neutro que não é chefe. Promessa de confidencialidade (o que é dito em post-mortem não é usado para punição). Ações que melhoram sistema, não que culpam operador.
Qual é a metodologia blameless?
Blameless é abordagem onde cada pessoa agiu racionalmente com informação que tinha no momento. Erro acontece porque sistema permitiu. Solução: melhorar sistema (alertas, permissões, automação), não culpar pessoa.
Como documentar e acompanhar ações de post-mortem?
Cada ação tem: (1) descrição; (2) responsável; (3) deadline; (4) status (aberto/em progresso/completo). Revisar semanalmente. Validar que ação evitou problema similar. Se mesmo incidente acontece 2x, ação falhou e precisa ser revisada.
Com que frequência fazer post-mortem?
Incidentes críticos (afeta negócio): sempre. Incidentes moderados: se houver aprendizado. Incidentes leves: documentar mas talvez não reunião formal. Cadência: poucos incidentes = post-mortem ad-hoc. Muitos incidentes = weekly session de post-mortem.