Post-Mortem de Despliegue

El Problema

El despliegue fallo, el incidente esta resuelto y todos quieren seguir adelante. Pero sin un post-mortem estructurado, el mismo patron de fallo se repetira — servicio diferente, dia diferente, misma causa raiz. La mayoria de equipos se saltan los post-mortems porque se sienten como sesiones de culpas, toman mucho tiempo para escribir o producen action items que nunca se completan. El resultado es un equipo que pelea los mismos incendios una y otra vez.

El Prompt

Eres un experto en analisis de incidentes especializado en post-mortems sin culpa. Ayudame a escribir un post-mortem de un despliegue fallido.

DETALLES DEL INCIDENTE:
- Que paso: [ej., "Deploy de v2.4.0 causo errores 500 en /api/checkout por 23 minutos"]
- Impacto: [ej., "~2,000 usuarios afectados, estimado $15k de ingresos perdidos"]
- Linea de tiempo: [pega eventos clave con timestamps]
- Causa raiz (si se conoce): [ej., "Migracion de BD bloqueo la tabla de ordenes"]
- Deteccion: [ej., "Alerta en tasa 5xx despues de 8 minutos, reporte de cliente despues de 3 minutos"]

Genera un post-mortem sin culpa:
1. **Resumen ejecutivo**: Resumen de 3 oraciones para liderazgo.
2. **Linea de tiempo**: Linea de tiempo anotada con que paso, cuando y quien respondio.
3. **Analisis de causa raiz**: Usa el metodo de los 5 Por Que para identificar la causa raiz verdadera.
4. **Factores contribuyentes**: Que mas empeoro la situacion.
5. **Que salio bien**: Reconocer lo que funciono.
6. **Action items**: Tareas concretas y asignables para prevenir recurrencia, con dueño y fecha limite.
7. **Lecciones aprendidas**: Que deberia cambiar en procesos, herramientas o cultura.

Ejemplo de Salida

Resumen ejecutivo:
Deploy v2.4.0 a las 14:32 UTC causo errores 500 en checkout por 23 minutos, afectando ~2,000 usuarios ($15k impacto estimado en ingresos). Causa raiz: migracion de BD bloqueo la tabla de ordenes durante trafico pico. Resuelto por rollback a las 14:55 UTC.

5 Por Que:
1. Por que fallo checkout? → Tabla de ordenes bloqueada
2. Por que estaba bloqueada? → ALTER TABLE agregando columna NOT NULL
3. Por que bloqueo? → 50M filas reescritas sin DDL online
4. Por que no se uso DDL online? → No hay proceso de revision de migraciones de BD
5. Por que no hay proceso de revision? → El equipo asumio que el ORM lo maneja seguro ← CAUSA RAIZ

Action Items:
[P0] Agregar revision de migracion de BD a checklist de PR — Dueño: @alice — Plazo: 22 Abr
[P1] Implementar congelamiento de deploys en horas pico (11-15 UTC) — Dueño: @bob — Plazo: 30 Abr

Cuando Usarlo

Usa este skill despues de cada despliegue fallido, incidente significativo o cuasi-accidente que pudo ser peor. El objetivo es aprender, no culpar.

Consejos Pro

• Sin culpa no significa sin responsabilidad — el punto es arreglar sistemas y procesos. “Alice desplego sin verificar” se convierte en “nuestro proceso de deploy no requiere un paso de checklist.”
• Escribe el post-mortem dentro de 48 horas — los detalles se desvanecen rapido.
• Los action items deben ser especificos y tener dueño — “mejorar monitoreo” no es un action item. “Agregar alerta en lock wait de tabla ordenes > 5 segundos, dueño @carol, plazo 15 May” si lo es.
• Comparte los post-mortems ampliamente — el valor de un post-mortem crece exponencialmente con la cantidad de personas que lo leen.