Jesús L.C. – Apuntes de un aprendiz

El incidente ya pasó. El fuego se apagó. El servicio volvió a la normalidad. Silencio en Slack. Paz, por fin.

Y justo cuando te dan ganas de olvidarlo todo… alguien dice las temidas palabras:
«¿Cuándo hacemos el postmortem?»

Sí, ya sé lo que estás pensando. Suena a castigo. A reunión eterna para hablar de lo mal que salió todo. Pero no debería ser así. Un buen postmortem no va de buscar culpables. Va de aprender.

¿Qué es un postmortem, realmente?

Un postmortem es un documento (y una reunión) donde analizamos un incidente técnico:
qué pasó, por qué pasó, qué impacto tuvo y cómo podemos evitar que vuelva a pasar.

El postmortem es el espacio donde una organización mira de frente sus errores, entiende qué falló (más allá del bug puntual) y define cómo mejorar para que ese mismo error no vuelva a ocurrir. El objetivo no es cerrar un ticket.

Leer más: Postmortem: no se trata de culpas, se trata de aprender

Hacemos Postmortem porque los errores son inevitables. Lo que marca la diferencia no es evitarlos, sino lo que haces después de que ocurran. La idea es no volver a tropezar con la misma piedra, no quedarnos con el parche, sino analizar que pasó y mejorar el sistema para que no vuelva a ocurrir.

No es opcional. Es una parte clave del ciclo de vida de cualquier sistema en producción.
Es el momento donde transformamos el error en conocimiento.

¿Cuándo y cómo se hace?

Idealmente, dentro de las 48h siguientes al incidente. Si lo dejas pasar más tiempo, se olvidan detalles, se enfría la motivación, se pierde el foco.

En nuestro equipo usamos una plantilla de postmortem, con secciones obligatorias, para guiar el análisis.

Y sobre todo: lo documentamos y lo compartimos. No se queda en la sala del incidente. Va al equipo, al departamento, a quien pueda beneficiarse de ese aprendizaje.

¿Qué esperamos de un postmortem?

Un buen postmortem responde a estas preguntas:

• ¿Qué pasó? (línea de tiempo, contexto, links a datadog, )
• ¿Qué impacto tuvo? (usuarios afectados, duración, datos perdidos,…)
• ¿Por qué pasó? (causa raíz, no síntomas)
• ¿Cómo lo resolvimos? (acciones, decisiones, cómo se comunicó)
• ¿Qué podríamos haber hecho mejor? (prevención, detección, respuesta)
• ¿Qué vamos a cambiar ahora? (acciones concretas)

Y lo más importante: todo esto debe hacerse con honestidad radical y cero culpas.

Porque si alguien tiene miedo de contar lo que hizo o lo que vio, estás jodido. El aprendizaje real desaparece.

¿Quién tiene que ir al postmortem?

Todos los que estuvieron involucrados o afectados por el incidente:
– La persona que detectó el problema
– Quien lo arregló
– Quien lo sufrió (soporte, producto, usuarios)
– Quien podría haberlo evitado
– Un auditor externo que vele porque no nos desviamos del tema

Porque un incidente no siempre es culpa del código. A veces es comunicación, procesos o contexto: una falta de contexto, una decisión de roadmap, una mala comunicación.

Dinámicas que usamos para encontrar la causa raíz

No sirve decir “se cayó porque alguien hizo deploy sin probar”. Para no quedarnos en la superficie (“se cayó el servidor”, “alguien metió mal un flag”), usamos algunas técnicas que ayudan a rascar un poco más:

📌 Los 5 porqués

Preguntar “¿por qué?” cinco veces seguidas. Ejemplo real:

1. ¿Por qué se cayó el servicio? → Porque se saturó la base de datos.
2. ¿Por qué se saturó? → Porque había un proceso que hacía demasiadas queries.
3. ¿Por qué ese proceso hacía tantas queries? → Porque duplicaba un cálculo innecesario.
4. ¿Por qué se duplicaba? → Porque el diseño del sistema lo permitía.
5. ¿Por qué nadie lo detectó antes? → Porque no teníamos monitoreo a ese nivel.

Ejemplo:

Se cayó el sistema → porque un microservicio se bloqueó → porque recibía peticiones mal formadas → porque el cliente no validaba los datos → porque nadie definió claramente el contrato → porque no tenemos documentación compartida.

Ahí es donde aparece el aprendizaje real. No en el primer “por qué”, sino en el cuarto o quinto.

Algunos tips

• No conviertas la reunión en una caza de brujas. Nadie quiere hablar si sabe que lo van a juzgar. Foco en sistemas, no en personas.
• Evita el “ya sabemos lo que pasó”. A veces parece que todo está claro, pero no lo está. Siempre hay una capa más.
• No te quedes en la superficie. “Hubo un bug” no es una causa raíz. Es el principio de la conversación, no el final.
• Define acciones. De verdad. No cierres el postmortem sin acciones claras, due dates y responsables.
• Haz seguimiento. Un postmortem sin cambios posteriores es para nada, nosotros ponemos una reunión la semana después del postmortem para ver que ha pasado con los action items.

Conclusiones

Los errores cuestan. En dinero, en confianza, en foco.
Pero también son una inversión en aprendizaje… si haces bien el postmortem.

No lo veas como un trámite. Véelo como lo que es:
una de las herramientas más potentes para construir sistemas más sólidos y equipos más fuertes.

Porque el código se rompe.
Pero lo que no se puede romper es nuestra capacidad de entender y mejorar.

Recursos útiles: plantillas de postmortem

Aquí tienes algunos enlaces que puedes usar para inspirarte o adaptar tu propia plantilla:

• El que usamos nosotros
  https://docs.google.com/document/d/1-yLSLk6VepFGNGQDu6QULEAvljfORz0IHTUSsr0PBTk/edit?usp=sharing
• Template de Google SRE (Postmortem Format)
  https://sre.google/workbook/postmortem/
• Incident.io’s Postmortem Guide
  https://incident.io/blog/how-to-write-an-incident-postmortem
• Blameless Postmortem Template (Notion)
  https://www.notion.so/Postmortem-Template-8d6f88584534475fa9bfc089d7a5a3aa
• GitLab Incident Review Template
  https://about.gitlab.com/handbook/engineering/quality/incident-management/#incident-review