O post-mortem como teatro corporativo: fechar o ticket no Jira não resolve o problema real

Há um ritual em quase todas as equipas de operações TI que se repete com uma regularidade irritante. O serviço cai. A equipa corrige-o. O ticket fecha-se no Jira. O responsável pela equipa respira aliviado. E todos continuam com a sua vida.

Duas semanas depois, o mesmo serviço volta a cair pelo mesmo motivo.

O fosso entre o que se diz e o que se faz

Esse fosso de 52% não é um problema de vontade. É um problema de definição. A maioria das equipas considera que o post-mortem termina quando o relatório é escrito. As organizações resilientes consideram que o post-mortem termina quando a causa raiz é eliminada de forma permanente.

São dois mundos completamente diferentes.

Quando o ticket é verdadeiramente fechado

Nas equipas que realmente aprendem com os seus incidentes, existe uma regra não escrita mas sistematicamente aplicada: o ticket de um incidente grave não se fecha quando o serviço volta a funcionar. Fecha-se quando pelo menos uma destas três condições é cumprida:

• Foi automatizado um alerta proativo que teria detetado o problema antes de afetar os utilizadores. O próximo incidente semelhante é detetado em minutos, não em horas.
• A arquitetura foi modificada para eliminar o ponto de falha. Não um patch. Uma mudança estrutural que impede que a mesma falha volte a ocorrer da mesma forma.
• O runbook de L1 foi atualizado com os passos exatos para resolver o problema em menos de metade do tempo original. O conhecimento tácito do engenheiro sénior que o resolveu converte-se em conhecimento explícito da equipa.

Se nenhuma das três for cumprida, o ticket está tecnicamente fechado, mas o problema continua em aberto.

Por que escrever o relatório que todos sabem que ninguém vai ler

O pior não é que o relatório não seja lido. O pior é que todos na sala sabem que nada vai mudar e ainda assim o escrevem, apresentam e arquivam. É energia coletiva queimada numa performance.

Por que acontece isto? Porque o incentivo está mal desenhado. As equipas são avaliadas pelo tempo de resolução (o MTTR de que falámos na primeira dose desta série). Não por incidentes evitados. Se resolve rápido, é herói. Se investe três horas num post-mortem que evita o próximo incidente, ninguém o vê.

A mudança de mentalidade que distingue as equipas resilientes

As equipas que verdadeiramente não repetem incidentes têm uma coisa em comum: tratam cada incidente grave como dívida técnica prioritária, não como um evento pontual para documentar e esquecer.

A resolução do incidente é a resposta de emergência. O post-mortem com impacto real é a resposta estrutural. Sem a segunda, a primeira é apenas um patch.

Se a sua equipa não tem tempo para post-mortems com impacto real, não é um problema de tempo. É um problema de prioridades. Os incidentes que se repetem não são má sorte. São a consequência direta de um sistema que recompensa apagar fogos e penaliza construir edifícios ignífugos.

A pergunta que deve fazer ao fechar o próximo incidente não é "o serviço está operacional?". Deve ser "o que tem de mudar para que isto não volte a acontecer?"

Série: Operações TI sem fumo