Post-mortems sin culpables: cómo mejorar de verdad

Actualizado: 2026-05-03

“Hacer post-mortems sin culpables” es el mantra de SRE desde que Google lo popularizó. Todo el mundo asiente. Pocas organizaciones lo hacen bien. Entre el concepto y la práctica hay una distancia que la mayoría de equipos no consigue cerrar — y el resultado es un ritual vacío: plantillas rellenadas que nadie lee, action items que nadie ejecuta, y los mismos incidentes repitiéndose.

Este artículo es sobre cómo hacer post-mortems que realmente producen aprendizaje y cambios — con técnicas concretas, no buenas intenciones.

Puntos clave

• El blameless performativo — decir “no hay culpables” pero dejar clara la implicación de alguien — destruye el mecanismo.
• Los tres elementos no negociables son: timeline factual, análisis honesto de contribuyentes, y action items con owner y plazo.
• Los “5 porqués” asumen causalidad lineal; los incidentes reales son multicausales.
• La policy de error budget y los post-mortems son herramientas complementarias: ambas requieren que las decisiones cambien según los datos.
• El meta-post-mortem trimestral es lo que convierte el aprendizaje individual en resiliencia sistémica.

Por qué fracasan los post-mortems “oficialmente blameless”

Los patrones de fracaso son reconocibles:

• Blame disfrazado. El post-mortem dice “no hay culpables” pero la narrativa deja claro quién falló. La persona implicada lo sabe.
• Narrativa oficial sanitizada. Lo que ocurrió realmente se suaviza para no ofender stakeholders. El aprendizaje real queda en conversaciones privadas.
• Action items teatrales. “Añadir más monitoring” / “Mejorar documentación”. Vagos, sin owner, sin plazo. Nunca se cumplen.
• No leer los post-mortems antiguos. Cada incidente parece nuevo porque nadie mira si ya ocurrió antes.
• Solo los grandes van a post-mortem. Se pierde el aprendizaje de near-misses, que son más valiosos por ser más frecuentes.

Reconocer estos patrones es el primer paso para hacerlo bien.

Los tres elementos no negociables

Un post-mortem funcional tiene:

1. Una línea temporal factual de qué ocurrió, cuándo, quién lo vio primero, qué se hizo.
2. Un análisis honesto de contribuyentes — no solo “qué falló” sino “qué hizo fácil o posible que fallara”.
3. Action items específicos con owner y plazo, cuyo cumplimiento se rastrea en un sistema centralizado.

Sin los tres, es papel mojado.

Línea temporal: los detalles importan

La timeline debe responder a seis preguntas:

• T-0: qué sucedía antes del incidente. A menudo revela un trigger olvidado (deploy, cron, cambio de config).
• T + n: momento del fallo inicial. ¿Quién vio primero? ¿Cómo? (alerta, cliente, casualidad).
• Escalado: cómo llegó a la persona correcta. Si tardó demasiado, es proceso, no persona.
• Mitigación: qué funcionó, qué no, qué se intentó primero.
• Recuperación: cuándo volvió el servicio.
• Follow-up: cuándo se cerró oficialmente.

Tiempos en UTC o zona horaria declarada. Mejor demasiados timestamps que demasiado pocos.

El problema con los “5 porqués”

Los 5-whys son técnica tradicional: ¿por qué falló X? Por A. ¿Por qué A? Por B. Y así hasta la “causa raíz”. El problema es que asumen causa lineal y única. Los incidentes reales son multicausales: tres servicios se alinean mal a la vez, una alerta existía pero el pager estaba mal configurado, un runbook existía pero no se encontró.

La mejor alternativa es pensar en contribuyentes, no en causas raíz. Lista de factores que individualmente no hubieran causado el incidente, pero juntos sí. Cada uno merece su propio action item.

Técnicas de entrevista blameless

En la reunión de post-mortem, el facilitador marca la diferencia. Cinco técnicas que funcionan:

• Preguntar “qué información tenías”, no “por qué tomaste esa decisión”. La decisión se explica por la información disponible, no al revés.
• Cronología antes de interpretación. Primero pactar qué pasó en cada momento; luego discutir por qué.
• Mencionar a la persona por rol, no por nombre, en el documento. “El on-call” en vez de “Juan”. Evita que leerlo meses después enfoque en quién.
• Normalizar errores humanos. “Cualquiera en esa posición con esa información habría hecho lo mismo” — si es cierto, decirlo explícitamente.
• Separar observaciones de juicios. “La alerta tardó 7 minutos en dispararse” (observación) vs “la alerta tardó demasiado” (juicio).

Un facilitador entrenado cambia el tono de toda la sala.

Action items que se cumplen

Los action items mal definidos son el cementerio de post-mortems. Los que se cumplen tienen cinco características:

• Owner específico. Una persona, no un equipo. Si es un equipo, nadie hace nada.
• Plazo acotado. “En Q1” es demasiado vago. “Para el 28 de febrero” aterriza.
• Criterio de cumplimiento claro. No “mejorar monitoring” — “añadir alerta X con threshold Y, revisada por Z”.
• Rastreo centralizado. Un sistema (Jira, Linear, GitHub Issues) donde todos los action items viven, con revisión mensual.
• Proporcionalidad. No 20 action items por incidente. Priorizar 3-5 que de verdad muevan la aguja.

Un action item sin plazo no se cumplirá. Con plazo pero sin seguimiento, tampoco.

Plantilla práctica

Una plantilla mínima viable:

## Resumen
[2 párrafos: qué pasó, impacto cliente, duración]

## Timeline
- 14:02 UTC - Deploy de servicio X versión 1.4.2
- 14:15 UTC - Primera alerta: latencia p99 >2s
- 14:17 UTC - On-call recibe page
- 14:20 UTC - Rollback iniciado
- 14:35 UTC - Servicio restaurado

## Impacto
- Clientes afectados: ~15% de tráfico
- Duración del impacto: 20 min

## Contribuyentes
1. Cambio incluía query N+1 no detectado en staging (load bajo).
2. Alerta de latencia configurada a 5 min de retraso.
3. Runbook de rollback desactualizado.

## Lo que funcionó bien
- On-call reaccionó rápido.
- Rollback procedure funcionó cuando se ejecutó.

## Action items
- [ ] @alice: añadir slow-query detection al CI, deadline 22/02.
- [ ] @bob: reducir delay de alerta p99 de 5min a 2min, deadline 15/02.
- [ ] @carol: actualizar runbook rollback con pasos actuales, deadline 20/02.

El meta-post-mortem trimestral

Trimestralmente, mirar los post-mortems acumulados es lo que separa a las organizaciones que aprenden de las que repiten ciclos. Preguntas clave:

• ¿Qué action items estaban abiertos y vencieron?
• ¿Qué patrones se repiten entre incidentes?
• ¿Hay inversiones estructurales que habrían evitado varios incidentes?
• ¿Estamos usando los SLOs y error budgets para priorizar esas inversiones?

Sin el meta-análisis, el ciclo es infinito. Con él, el foco se desplaza de apagar fuegos a construir resiliencia.

Incidentes pequeños también

La mayoría de organizaciones solo hace post-mortem de incidentes SEV-1. Pero los aprendizajes más baratos vienen de SEV-3 y near-misses — eventos donde casi pasa algo grave pero se detectó a tiempo.

Un modelo light para incidentes pequeños: cinco líneas de timeline, tres contribuyentes, uno o dos action items específicos, sin reunión formal. El volumen de aprendizaje pequeño, sumado, supera con frecuencia el de unos pocos grandes.

Cultura: el factor que no se ve

Las técnicas ayudan pero la cultura decide. Señales de cultura saludable:

• Un ingeniero junior puede decir “rompí producción” sin miedo a consecuencias.
• Los líderes hablan abiertamente de sus propios errores.
• Se celebran las lecciones aprendidas, no se ocultan.
• Los recursos para action items son prioridad, no afterthought.

Cambiar cultura lleva años. Empezar con técnicas es el camino — con el tiempo, la cultura se adapta a los rituales bien ejecutados.

Conclusión

Post-mortems blameless son una herramienta potente cuando se hacen bien. La diferencia entre teatro y aprendizaje real está en los detalles: timeline factual, análisis honesto de contribuyentes, action items con owner y plazo, seguimiento continuo y revisión trimestral del patrón. El coste mayor está en el rigor, no en la técnica.