Hay un ritual en casi todos los equipos de operaciones TI que se repite con una regularidad irritante. El servicio cae. El equipo lo arregla. El ticket se cierra en Jira. El jefe del equipo respira aliviado. Y todos siguen con su vida.
Dos semanas después, el mismo servicio vuelve a caerse por el mismo motivo.
La brecha entre lo que se dice y lo que se hace
de los líderes TI afirman que el aprendizaje post-incidente es "vital" para la organización — State of AI-First Operations 2026
el porcentaje que realmente consigue aprendizaje estructurado después de un incidente — State of AI-First Operations 2026
Esa brecha del 52% no es un problema de voluntad. Es un problema de definición. La mayoría de los equipos consideran que el post-mortem termina cuando se escribe el informe. Las empresas resilientes consideran que el post-mortem termina cuando se elimina la causa raíz de forma permanente.
Son dos mundos completamente distintos.
Cuándo se cierra el ticket de verdad
En los equipos que de verdad aprenden de sus incidentes, existe una norma no escrita pero sistemáticamente aplicada: el ticket de un incidente grave no se cierra cuando el servicio vuelve a funcionar. Se cierra cuando se cumple al menos una de estas tres condiciones:
- Se ha automatizado una alerta proactiva que hubiera detectado el problema antes de que afectara a los usuarios. El próximo incidente similar se detecta en minutos, no en horas.
- Se ha modificado la arquitectura para eliminar el punto de fallo. No un parche. Un cambio estructural que hace que ese mismo fallo no pueda volver a ocurrir de la misma forma.
- Se ha actualizado el runbook de L1 con los pasos exactos para resolver el problema en menos de la mitad del tiempo original. El conocimiento tácito del ingeniero senior que lo resolvió se convierte en conocimiento explícito del equipo.
Si no se cumple ninguna de las tres, el ticket está técnicamente cerrado pero el problema sigue abierto.
Por qué escribir el informe que todos saben que nadie va a leer
Se cae el sistema → se resuelve el incidente → alguien escribe un documento de 4 páginas en Confluence → el documento se comparte en el canal de Slack → tres personas lo leen → nadie cambia nada → en 6 semanas ocurre una variante del mismo problema → se repite el ciclo.
Lo peor no es que el informe no se lea. Lo peor es que todos en la sala saben que no va a cambiar nada y aun así lo escriben, lo presentan y lo archivan. Es energía colectiva quemada en una performance.
¿Por qué ocurre esto? Porque el incentivo está mal diseñado. Los equipos son evaluados por tiempo de resolución (el MTTR del que hablamos en la primera dosis de esta serie). No por incidentes evitados. Si resuelves rápido, eres héroe. Si inviertes tres horas en un post-mortem que evita el siguiente incidente, nadie te ve.
El cambio de mentalidad que distingue a los equipos resilientes
Los equipos que de verdad no repiten incidentes tienen una cosa en común: tratan cada incidente grave como una deuda técnica prioritaria, no como un evento puntual que hay que documentar y olvidar.
La resolución del incidente es la respuesta de emergencia. El post-mortem con impacto real es la respuesta estructural. Sin la segunda, la primera es solo un parche.
Aprender de la resolución salva el año."
Si tu equipo no tiene tiempo para los post-mortems con impacto real, no es un problema de tiempo. Es un problema de prioridades. Los incidentes que se repiten no son mala suerte. Son la consecuencia directa de un sistema que recompensa apagar fuegos y penaliza construir edificios ignífugos.
La pregunta que deberías hacerte al cerrar el próximo incidente no es "¿está el servicio operativo?". Debería ser "¿qué tiene que cambiar para que esto no vuelva a ocurrir?"
Serie: Operaciones TI sin humo
¿Tus post-mortems generan cambios reales o quedan en Confluence? Compártelo en LinkedIn
Compartir en LinkedIn¿Cuántos de tus incidentes del último año se repitieron?
Te ayudamos a convertir tus post-mortems en acciones concretas que eliminen los problemas de raíz.