Postmortems sin culpa

Cuándo hacer uno

Define criterios objetivos de antemano para que no dependa de quién esté de guardia:

• Impacto visible para clientes por encima de un umbral (duración o porcentaje).
• Pérdida o corrupción de datos, o incidente de seguridad.
• Intervención manual de emergencia (rollback, failover).
• Consumo de más de un porcentaje acordado del error budget.
• Cualquier persona lo solicita.

Plantilla

Sección	Contenido
Resumen	Tres frases: qué pasó, impacto, estado
Impacto	Usuarios, transacciones, dinero, SLO afectados, duración
Cronología	Hechos con hora UTC: detección, escalado, mitigación, resolución
Causas contribuyentes	Técnicas, organizativas y de proceso; normalmente son varias
Qué funcionó	Detección, herramientas, coordinación que conviene reforzar
Dónde tuvimos suerte	Factores que evitaron un impacto mayor sin que fuera intencional
Acciones	Cada una con dueño, prioridad y fecha; enlazadas a tickets

Más allá de los «5 porqués»

Los 5 porqués tienden a una cadena lineal con una única causa. Los incidentes en sistemas complejos suelen tener causas contribuyentes que se combinan. Preguntas más productivas:

• ¿Qué sabían las personas en cada momento y qué les hizo pensar que la acción era correcta?
• ¿Qué señales había y por qué no se vieron?
• ¿Qué hizo que la detección o la mitigación tardaran?
• ¿Qué barreras existían y por qué no detuvieron el problema?

Acciones que funcionan

Débil	Más fuerte
«Tener más cuidado con las migraciones»	Linter en CI que detecta ALTER TABLE con bloqueo en tablas grandes
«Documentar el procedimiento»	Runbook automatizado, probado en un simulacro
«Formar al equipo»	Alerta de burn rate que habría detectado el problema en 5 min

Prefiere controles automáticos y cambios de diseño sobre recordatorios.

Rol del líder

Asiste, escucha y protege. Agradece la transparencia de quien ejecutó el cambio. Asegura que las acciones prioritarias entran en la planificación y revisa periódicamente su cumplimiento: un postmortem sin seguimiento enseña al equipo que el proceso es un trámite.

Ejemplo de postmortem resumido

# PM-2026-031: Desembolsos detenidos 40 minutos

**Resumen**: una migración de base de datos bloqueó la tabla `desembolsos` durante 40 min;
612 desembolsos se retrasaron. Sin pérdida de datos. Resuelto.

**Impacto**: 612 clientes con desembolso retrasado (máx. 46 min). 18 % del error budget mensual.

**Cronología (UTC)**

- 14:02 Se despliega v2.31 con migración `ALTER TABLE desembolsos ADD CONSTRAINT … FOREIGN KEY`.
- 14:03 La migración espera un bloqueo; las escrituras se encolan detrás.
- 14:09 Alerta de latencia p95 > 5 s en `api-desembolsos`.
- 14:15 La guardia identifica bloqueos en `pg_stat_activity`.
- 14:31 Se cancela la migración; las escrituras se reanudan.
- 14:42 Cola de desembolsos procesada. Fin del impacto.

**Causas contribuyentes**

- La FK se añadió validando toda la tabla, con bloqueo, en lugar de `NOT VALID` + `VALIDATE`.
- No hay `lock_timeout` en las migraciones.
- La revisión del PR no incluía un checklist de migraciones.
- La alerta se basaba en latencia, no en desembolsos pendientes (detección a los 7 min).

**Qué funcionó**: el runbook de bloqueos permitió diagnosticar en 6 minutos.
**Dónde tuvimos suerte**: ocurrió fuera del pico de las 17:00.

**Acciones**

| Acción                                                        | Dueño        | Fecha |
| ------------------------------------------------------------- | ------------ | ----- |
| `lock_timeout = '3s'` por defecto en el runner de migraciones | Plataforma   | 24/10 |
| Linter de migraciones (squawk) en CI                          | Equipo Pagos | 31/10 |
| Alerta por desembolsos pendientes > 5 min                     | Equipo Pagos | 24/10 |

Guion de facilitación (60 minutos)

Tiempo	Bloque	Nota para quien facilita
5 min	Encuadre: objetivo de aprendizaje, sin culpables	Leer en voz alta la regla de no culpar
15 min	Revisar y completar la cronología	Preguntar «¿qué viste?», «¿qué esperabas?»
20 min	Causas contribuyentes	Buscar varias; evitar quedarse en la primera
15 min	Acciones	Priorizar controles automáticos; dueño y fecha
5 min	Cierre	Agradecer; confirmar quién publica el documento

Frases a reconducir: «debería haber…» → «¿qué hacía que pareciera razonable en ese momento?»; «error humano» → «¿qué permitió que ese error tuviera impacto?».

Aprender de varios incidentes

Una vez al trimestre, revisa los postmortems juntos: causas que se repiten, acciones pendientes, tiempos de detección y de mitigación. Las tendencias revelan inversiones estructurales (observabilidad, pruebas de migraciones, formación en guardias) que ningún postmortem individual justificaría por sí solo.

Criterios de implementación

Escribe el borrador en 48 horas y revísalo en una reunión facilitada por alguien no implicado. Publícalo internamente con amplio acceso. Revisa trimestralmente las tendencias (causas recurrentes, tiempos de detección) y conecta los hallazgos con las métricas DORA de recuperación.