La mayoría de postmortems son arqueología: un registro exacto de algo que nadie va a cambiar. Uno útil produce un número pequeño de cosas que efectivamente se hacen.
El propósito de un postmortem no es documentar lo que pasó. Es hacer que el siguiente incidente sea menos probable o menos dañino. Todo lo que hay en el documento debería servir a eso, y lo que no, es ceremonia.
Sin culpables es un mecanismo, no una forma de trato
Los postmortems sin culpables se explican a menudo como una amabilidad. Eso los infravalora. Existen porque la gente que espera culpa oculta información — y la información oculta es justamente la que habría evitado la repetición.
Una estructura que funciona
- Resumen — tres frases: qué se rompió, durante cuánto, a quién afectó. La mayoría de lectores para aquí, así que tiene que sostenerse solo.
- Impacto — duración, usuarios afectados, consecuencias de ingresos o datos, en números cuando sea posible
- Cronología — hechos con marcas de tiempo, desde el primer síntoma hasta la resolución, incluyendo cuándo se enteraron las personas
- Factores contribuyentes — en plural, y honestos con los de proceso, no solo con el disparador técnico
- Qué salió bien — genuinamente útil para reforzar la detección o la respuesta que funcionó
- Acciones — cada una con responsable y fecha
La causa raíz suele ser una historia, no una línea
«El despliegue causó la caída» es donde se detiene el análisis cuando la reunión va con prisa. Los factores contribuyentes reales suelen verse así:
| Capa | Hallazgo de ejemplo |
|---|---|
| Disparador | Se desplegó un cambio de configuración |
| Por qué se rompió | El cambio era sintácticamente válido pero semánticamente erróneo |
| Por qué nada lo detectó | Ningún entorno de staging replicaba la configuración de producción |
| Por qué tardaron 40 minutos en notarlo | Las alertas vigilaban la CPU, no la tasa de éxito del pago |
| Por qué la recuperación fue lenta | El rollback nunca se había probado para cambios solo de configuración |
Cuatro de esos cinco son problemas de proceso. Arregla solo el disparador y la misma clase de incidente vuelve con otra ropa.
Acciones: la parte que decide si algo de esto importó
- Tres a cinco elementos máximo — una lista de veinte es una lista de cero
- Cada uno con un responsable con nombre, no un equipo
- Cada uno con fecha, seguido en el mismo sistema que el trabajo normal
- Prefiere elementos que eliminen una clase de fallo (una barandilla) frente a los que arreglan una instancia
- Revísalos en el siguiente postmortem — los pendientes de la vez anterior son el punto más importante del orden del día
Un postmortem sin acciones completadas antes del siguiente incidente no es un proceso. Es una costumbre de archivado.
Momento y audiencia
- Borrador en 48 horas — la exactitud se degrada rápido
- Reúnanse 30-45 minutos, no más; el documento hace la mayor parte del trabajo
- Incluye a todos los implicados, más una persona que no lo estuvo (hace las preguntas obvias que los de dentro se saltan)
- Compártelo ampliamente — la transparencia interna sobre el fallo es cómo las organizaciones mejoran en esto
Verificar las acciones de prevención
Un postmortem debe cambiar un control o una decisión. Cada acción necesita evidencia de finalización además de fecha.
- Distinguir hechos, hipótesis y condiciones contribuyentes.
- Relacionar cada acción con el mecanismo de fallo.
- Verificar mediante prueba, simulación de alerta o restauración.
Preguntas frecuentes
¿Cuánto después de un incidente debe hacerse el postmortem?
Borrador en 48 horas y reunión dentro de la semana. El recuerdo de la secuencia exacta y del razonamiento se degrada deprisa, y los detalles que más importan — qué creía alguien en ese momento y por qué — son los primeros en irse.
¿Qué hace que un postmortem sea sin culpables en la práctica?
Preguntar cómo el sistema permitió el fallo en lugar de quién lo causó. En la práctica: sin nombres asociados a errores en el documento, preguntas formuladas sobre mecanismos en vez de decisiones, y acciones que añaden barandillas en lugar de pedir a la gente que tenga más cuidado.
¿Cuántas acciones debe producir un postmortem?
Tres a cinco, cada una con responsable con nombre y fecha. Listas más largas son señal fiable de que no se hará nada — y los pendientes deben ser el primer punto del orden del día de la siguiente revisión.
¿Cuándo está completa una acción del postmortem?
Cuando se aporta y revisa la evidencia acordada. Cerrar un ticket o actualizar un documento no demuestra necesariamente que cambió el comportamiento del sistema.
¿Los incidentes se repiten?
Eso es un problema de proceso, no de mala suerte. Auditamos la práctica de entrega e incidentes y arreglamos el mecanismo.
Para seguir leyendo
Cómo gestionar una caída de producción: manual para equipos pequeños
En una caída el problema técnico rara vez es lo difícil. La coordinación sí lo es. Esta es la secuencia que evita que un equipo pequeño lo empeore.
Auditoría de procesos de ingeniería: qué miramos y por qué
Cuando un equipo entrega lento, la causa casi nunca son los ingenieros. Suelen ser cuatro o cinco fricciones concretas que nadie ha medido.