Postmortems: Aprendiendo de los incidentes

Cuando las Cosas se Rompen

No importa lo fiable que sea un sistema, los incidentes ocurrirán. Un despliegue fallido, un bug inesperado, un fallo de hardware… La diferencia entre un equipo maduro y uno inmaduro no es si tienen incidentes, sino cómo responden y aprenden de ellos.

La herramienta fundamental de un SRE para aprender de los fallos es el Postmortem. Un postmortem es un documento escrito que se elabora después de un incidente para analizar qué pasó, cuál fue el impacto, qué acciones se tomaron para mitigarlo y, lo más importante, qué se puede hacer para evitar que vuelva a ocurrir.

La Clave: Una Cultura Sin Culpables (Blameless)

El principio más importante de un buen postmortem es que debe ser “blameless” (sin culpas).

La pregunta nunca es “¿Quién cometió el error?”, sino “¿Por qué el sistema permitió que ese error ocurriera y tuviera impacto?”. Si un ingeniero ejecutó un comando peligroso en producción, el problema no es el ingeniero. El problema es:

• ¿Por qué ese comando estaba disponible?
• ¿Por qué no había una confirmación de seguridad ("¿Estás seguro?")?
• ¿Por qué el sistema no tenía salvaguardas para limitar el “radio de la explosión” de un comando erróneo?

Una cultura sin culpas fomenta la honestidad y la transparencia. Si la gente tiene miedo a ser castigada, ocultará información y el equipo nunca llegará a la verdadera causa raíz del problema.

Anatomía de un Postmortem

Un buen postmortem suele tener la siguiente estructura:

1. Resumen: Un párrafo que describe el incidente, su impacto en los usuarios, y el tiempo que duró. (Ej: “El 25 de marzo a las 10:00 UTC, el servicio de login estuvo inaccesible durante 15 minutos para el 50% de los usuarios debido a una configuración errónea en el balanceador de carga”).

2. Impacto: Descripción detallada del impacto en los usuarios y en el negocio. ¿Se incumplieron los SLOs? ¿Cuánto Error Budget se consumió?

3. Cronología (Timeline): Una lista detallada de eventos con fecha y hora. Incluye el momento del despliegue, la primera detección del problema, la primera alerta, las acciones de mitigación, y la resolución final.

4. Análisis de Causa Raíz (Root Cause Analysis): Aquí se explica por qué ocurrió el incidente. Es importante usar la técnica de los “5 Porqués” para no quedarse en la superficie.

   • El servicio se cayó. ¿Por qué? Porque la base de datos no respondía.
   • ¿Por qué? Porque todas las conexiones estaban ocupadas.
   • ¿Por qué? Porque un nuevo proceso de reporting estaba haciendo queries muy pesadas.
   • ¿Por qué? Porque el nuevo proceso se desplegó sin un límite de conexiones. (¡Esta es una causa raíz accionable!).

5. Acciones de Mitigación: ¿Qué se hizo durante el incidente para restaurar el servicio? (Ej: “Se hizo un rollback del despliegue X”, “Se reinició el servicio Y”).

6. Acciones Correctivas (Action Items): Esta es la sección más importante. Es una lista de tareas concretas, asignadas a un responsable y con una fecha límite, para prevenir que el incidente se repita.

   • Mal Action Item: “Mejorar la monitorización de la base de datos”.
   • Buen Action Item: “[Juan Pérez, 30/04/2025] Añadir una alerta en Prometheus que se dispare cuando el pool de conexiones de la BD supere el 80% de su capacidad”.

Conclusión

Los incidentes no son fracasos, son oportunidades de aprendizaje gratuitas. Un postmortem bien hecho convierte un evento negativo en una mejora tangible y duradera para el sistema. Fomentar una cultura de postmortems sin culpas es una de las inversiones más rentables que un equipo de ingeniería puede hacer para construir sistemas verdaderamente fiables.