Cada organización que opera sistemas en producción tiene incidentes. Eso no es negociable. Lo que sí es negociable es si aprenden de ellos o los repiten hasta que alguien renuncia.
El postmortem es el mecanismo que conecta un incidente con una mejora real. Pero en la mayoría de las empresas que he visto, los postmortems se escriben para cumplir, no para aprender. Se redactan apurados, se archivan en una wiki que nadie visita, y los action items mueren en el backlog tres sprints después.
Por qué la mayoría de los postmortems no funcionan
El patrón es siempre el mismo: ocurre un incidente grave, alguien (generalmente el on-call) escribe un documento que describe qué pasó, se agenda una reunión de revisión, se identifican "mejoras", y en dos semanas nadie recuerda qué se decidió.
Esto falla por tres razones:
- Se escribe para cumplir, no para entender. El objetivo implícito es demostrar que "se hizo algo" después del incidente. No hay profundidad real en el análisis.
- Los action items son genéricos. "Mejorar el monitoreo" no es un action item. Es un deseo. Sin owner, sin deadline, sin definición de "hecho", es ruido.
- No hay follow-up. Los action items se crean pero nadie verifica si se ejecutaron. La próxima vez que el mismo tipo de incidente ocurre, están en la misma posición.
Cultura blameless: por qué culpar destruye la capacidad de aprender
Cuando un ingeniero sabe que el postmortem va a señalarlo como "el culpable", deja de ser honesto. Omite detalles, minimiza su participación, evita mencionar las decisiones que tomó bajo presión. El resultado es un documento que no refleja la realidad y que por lo tanto no puede generar mejoras reales.
La cultura blameless no significa que nadie es responsable. Significa que el análisis se enfoca en qué falló en el sistema, no en quién cometió el error. Un ingeniero que ejecutó un deploy que causó una caída no es "el culpable". Las preguntas correctas son: ¿por qué el pipeline permitió un deploy defectuoso? ¿Por qué no hubo canary? ¿Por qué el rollback no fue automático?
Si tu cultura culpa personas, tus postmortems son ficción. Y la ficción no previene incidentes.
Estructura de un postmortem efectivo
No necesitas una plantilla de 15 páginas. Necesitas cubrir estos elementos con honestidad y precisión:
1. Timeline
Cronología detallada del incidente: cuándo se detectó, qué acciones se tomaron, cuándo se resolvió. Sin interpretaciones, solo hechos con timestamps. Esta es la base de todo el análisis posterior.
2. Impacto
Medido, no estimado. Número de usuarios afectados, duración de la degradación, pérdida de revenue si aplica, SLOs violados. Si no puedes medir el impacto, tienes un problema de observabilidad que es más grave que el incidente en sí.
3. Causa raíz
No la causa superficial ("se cayó la base de datos") sino la raíz real ("el connection pool estaba configurado para 50 conexiones en un servicio que maneja 200 requests concurrentes, sin circuit breaker ni backpressure"). Usa la técnica de los 5 porqués si ayuda, pero no te quedes en el primer nivel.
4. Factores contribuyentes
Rara vez un incidente tiene una sola causa. Los factores contribuyentes son las condiciones que permitieron que la causa raíz se convirtiera en un incidente visible: falta de alertas, documentación desactualizada, ausencia de runbooks, deploy en viernes a las 5pm.
5. Action items
Aquí es donde la mayoría falla. Cada action item debe tener:
- Descripción específica: no "mejorar monitoreo" sino "agregar alerta cuando el connection pool supere el 80% de capacidad en el servicio X".
- Owner: una persona, no un equipo. Si es del equipo, nadie lo hace.
- Deadline: fecha concreta. Sin fecha, no existe.
- Prioridad: P0 (antes del siguiente deploy), P1 (esta semana), P2 (este sprint).
Errores comunes que matan la efectividad
- Action items genéricos. "Revisar la infraestructura" es un proyecto, no un action item. Descompón en tareas concretas y ejecutables.
- Sin owner. "El equipo de plataforma se encargará" significa que nadie se encargará. Asigna un nombre.
- Sin follow-up. Si no verificas que los action items se completaron, el postmortem fue un ejercicio de escritura creativa.
- Escribir demasiado tarde. Después de 72 horas, los detalles se difuminan. La memoria es poco confiable. Escribe el timeline dentro de las primeras 24 horas mientras los hechos están frescos.
- Confundir síntomas con causas. "El servidor se quedó sin memoria" es un síntoma. La causa es el memory leak en el servicio Y que nadie detectó porque no hay profiling en producción.
Hacer que los action items se ejecuten
Este es el paso que separa a las organizaciones que aprenden de las que repiten. Dos prácticas que funcionan:
Revisión semanal: incluye los action items de postmortems en la reunión semanal del equipo. No como agenda completa, sino como un checkpoint de 5 minutos: ¿qué se completó? ¿Qué está bloqueado? ¿Qué necesita re-priorización?
Vinculación con sprints: los action items P0 y P1 entran en el sprint actual sin negociación. Si no caben, algo más sale. Esto requiere apoyo de management, y conseguirlo es parte del trabajo del líder técnico. Si tus action items compiten con features y siempre pierden, el postmortem es decoración.
Algunas organizaciones van más allá: no permiten que un servicio involucrado en un incidente reciba nuevas features hasta que todos los action items P0 estén cerrados. Es agresivo, pero efectivo.
El postmortem como inversión
Un buen postmortem toma 2-4 horas de trabajo: escribir el timeline, analizar la causa raíz, definir action items concretos, revisarlo con el equipo. Esas horas son una inversión directa en la estabilidad del sistema.
El costo de no hacerlo es repetir el incidente. Y el segundo incidente siempre es más caro que el primero, porque ahora incluye el costo del incidente más el costo de la confianza perdida del equipo, del cliente y del management.
Un postmortem no es un castigo. Es una inversión en el sistema. Si lo escribes para cumplir, fallará. Si lo escribes para entender, transformará la forma en que tu equipo responde a los fallos.
