Conceito e mecanismo
A passagem de turno deve permitir continuar a resposta sem repetir investigação nem perder compromissos. Resume impacto atual, estado do serviço, decisões tomadas, mudanças temporárias, evidências, riscos, responsáveis e próximos prazos. Confirma que a equipa seguinte compreendeu e aceitou as tarefas. Um workaround precisa de validade, proprietário e critérios de remoção; caso contrário pode tornar-se configuração permanente por esquecimento. Fechar o incidente exige critérios acordados de recuperação, incluindo resultados funcionais e trabalho pendente quando relevante. A investigação de causa e as ações de prevenção podem continuar num registo ligado, com responsabilidade explícita.
Aplicação guiada
Num exemplo fictício, um reinício autorizado restaurou o processamento, mas a mesma degradação ocorreu três vezes. O postmortem deve reconstruir condições contribuintes e a eficácia da deteção e resposta. Evita resumir a causa a erro humano: procura como o sistema permitiu a ação e que barreiras faltaram. Define ações concretas com responsável, prazo e evidência de conclusão, como alertar para tendência de ligações antes da saturação e exercitar o runbook num ambiente isolado. Mede recorrência e impacto além da velocidade de fecho de tickets. Atualiza a base de conhecimento com condições de aplicação, sinais de exclusão e passos de validação, preservando dados sensíveis.
Uma ação concluída apresenta evidência; um ticket fechado não demonstra prevenção.
Armadilhas comuns
Workaround sem dono; passagem sem aceitação; culpar pessoas; medir apenas tickets fechados.
Tópicos relacionados: Triagem orientada ao impacto · Hipóteses e evidências úteis · Diagnóstico por camada
Transfere responsabilidade explicitamente e acompanha a eficácia das melhorias.
Referência: Postmortem culture · Operational support; PostgreSQL 18, OpenSSL 3.5 and BIND 9.20.29 examples; reviewed 2026-09-30