5 min read
Son las 2:14am. Un despliegue rompió el proceso de cobros y durante 47 minutos ningún cliente pudo pagar. El incidente ya se resolvió, el servicio está de vuelta, y a la mañana siguiente el equipo se junta a “revisar qué pasó”.
La primera pregunta que se escucha en la sala es: “¿Quién hizo el deploy?”
En ese instante, la reunión ya se perdió. Todos entendieron el mensaje: acá se busca un culpable. Y a partir de ahí, la gente va a omitir detalles, suavizar su participación y evitar contar lo que realmente pasó.
El resultado es un incidente que se va a repetir, porque nadie dijo la parte importante en voz alta.
¿Qué es un post-mortem sin culpa?
Un post-mortem (análisis posterior al incidente) es una revisión estructurada de lo que pasó, por qué pasó y qué vamos a cambiar para que no vuelva a pasar.
Se llama sin culpa (blameless) porque parte de una premisa clave: las personas casi nunca causan incidentes por descuido; los causan sistemas que permiten que un error razonable llegue a producción.
Si un desarrollador pudo desplegar un cambio que rompió los cobros, la pregunta útil no es “¿por qué lo hizo?” sino “¿por qué el sistema le permitió hacerlo sin que nada lo detuviera?”. ¿Faltó una prueba automática? ¿No había un entorno de staging representativo? ¿El proceso de revisión no cubría ese caso?
Ahí están los cambios que realmente reducen el riesgo.
Guía paso a paso
Paso 1 — Escribilo mientras está fresco
Idealmente dentro de las 48 horas siguientes. La memoria se degrada rápido y los detalles que importan, como qué se intentó primero y qué se descartó, se pierden.
Paso 2 — Reconstruí la línea de tiempo con hechos
Hora por hora, qué pasó y qué se vio: alertas, mensajes del canal de incidentes, despliegues. Usá los registros del sistema (logs, métricas, historial de Slack) y no la memoria de nadie.
Paso 3 — Buscá causas, no culpables
La técnica de los 5 porqués ayuda: preguntá “¿por qué?” repetidamente hasta llegar a una causa del sistema. “El deploy rompió los cobros” → “no había una prueba para ese caso” → “la prueba de integración con la pasarela se desactivó por inestable” → “nadie tenía asignado arreglarla”.
Paso 4 — Definí acciones concretas con dueño y fecha
“Mejorar las pruebas” no es una acción. “Reactivar la prueba de integración de pagos y estabilizarla — María — 15 de noviembre” sí lo es. Una acción sin responsable ni fecha no se hace.
Paso 5 — Compartilo y hacé seguimiento
Publicalo para todo el equipo, no solo para quienes participaron. Y revisá en las semanas siguientes si las acciones se completaron: un post-mortem sin seguimiento es teatro.
Una plantilla simple
# Post-mortem: [título breve del incidente]
**Fecha:** 2026-11-03 **Duración:** 47 minutos **Severidad:** Alta
**Responsable del documento:** [nombre]
## Resumen
Una o dos frases: qué pasó y cuál fue el impacto.
## Impacto
Clientes afectados, ingresos perdidos, tickets de soporte generados.
## Línea de tiempo (hora local)
- 02:14 — Se despliega la versión 4.8.2
- 02:19 — Alerta: tasa de errores en /payments supera 20%
- 02:31 — Se identifica el despliegue como causa probable
- 03:01 — Rollback completado, servicio recuperado
## Causa raíz y factores contribuyentes
Los 5 porqués, en términos del sistema.
## Qué salió bien
Qué ayudó a resolverlo rápido (la alerta funcionó, el rollback estaba documentado).
## Qué salió mal
Dónde falló el sistema o el proceso.
## Acciones
| Acción | Dueño | Fecha |
|--------|-------|-------|
| Reactivar prueba de integración de pagos | María | 15/11 |
Para tener en cuenta
- El lenguaje importa: escribí “el despliegue se realizó sin una prueba que detectara el fallo” en lugar de “Juan desplegó sin probar”. Describí acciones y condiciones, no personas.
- Los líderes marcan el tono: si el gerente reacciona con enojo la primera vez que alguien admite un error, el equipo aprende a esconderlos. La seguridad psicológica se construye con la reacción a la primera mala noticia.
- Incluí lo que salió bien: reconocer qué funcionó, como una alerta que saltó a tiempo o un rollback ensayado, refuerza las buenas prácticas.
- “Sin culpa” no es “sin responsabilidad”: las personas siguen siendo responsables de aprender y de completar las acciones acordadas. Lo que se evita es el castigo, no el compromiso.
- No lo reserves para los grandes incidentes: los casi-incidentes (near misses) enseñan lo mismo con costo cero para los clientes.
Conclusión
Un equipo que teme equivocarse deja de contar lo que pasa, y lo que no se cuenta no se arregla. Un post-mortem sin culpa convierte cada incidente en una inversión: pagaste el costo de la caída, así que aprovechá hasta la última lección.
Recordá suscribirte aquí para recibir los próximos posts directamente en tu correo.
Referencias:
Site Reliability Engineering — Google, capítulo “Postmortem Culture: Learning from Failure”: https://sre.google/sre-book/postmortem-culture/
John Allspaw — “Blameless PostMortems and a Just Culture”
The Field Guide to Understanding ‘Human Error’ — Sidney Dekker