Módulo 7: Blameless Postmortems And Runbooks
1. Introducción: del timeline al aprendizaje sistémico
Descripción
TIMELINE.md quedó terminado al cierre del Módulo 6: catorce hechos, severidad SEV1 verificada, roles asignados, el árbol de decisión de mitigación completo, y el error budget recalculado con la herramienta real —33,3x el presupuesto mensual—. Ese documento contesta, con precisión, qué pasó y en qué orden. Este módulo contesta una pregunta distinta, que el Módulo 6 dejó deliberadamente sin tocar: por qué pasó, a nivel de sistema, y qué cambia para que sea menos probable que vuelva a pasar. Esa pregunta tiene un nombre en la disciplina de SRE, y una forma muy específica de contestarse mal: un postmortem que termina señalando a una persona en vez de a un sistema.
Conexión con el módulo
Todo lo que este módulo necesita ya existe: TIMELINE.md (Módulo 6, lección 8) es el insumo directo de la lección 3, el postmortem central de esta guía. INCIDENT-RESPONSE-PLAN.md (Módulo 5) ya estableció los roles que redactan ese postmortem. cloud-security-and-guardrails-guide, Módulo 1, lección 6 ya nombró, con precisión, el hueco declarado que las lecciones 4 y 6 de este módulo convierten en un action item real y en un runbook real, respectivamente. Este módulo no recalcula nada del Módulo 6 —no vuelve a tocar el error budget, la severidad ni el árbol de mitigación—; construye, encima de ese trabajo ya terminado, los tres artefactos que le faltaban a Andes Cargo desde el Módulo 1: un postmortem sin culpa, action items que de verdad se cumplen, y el primer runbook operativo de todo el ecosistema.
La analogía: la caja negra de un avión, no el expediente de un piloto
Cuando un avión tiene un incidente serio, existe un organismo —en Estados Unidos, el National Transportation Safety Board; en la mayoría de países, una autoridad equivalente— cuyo único trabajo es investigar qué pasó. Ese organismo tiene acceso a la caja negra: el registrador de datos de vuelo, el registrador de voces de cabina, cada instrumento, cada palabra dicha en los minutos previos. Y sin embargo, la investigación no existe para determinar si el piloto "es culpable". Existe para reconstruir, con precisión forense, la cadena completa de condiciones —mecánicas, de procedimiento, humanas, regulatorias— que hicieron posible el resultado, y para producir recomendaciones que hagan menos probable que la misma cadena se repita en cualquier otro avión, con cualquier otro piloto, en cualquier otra aerolínea.
Esa investigación sí documenta que el piloto tomó una decisión específica en un momento específico —eso es un hecho, no una opinión, y ocultarlo produciría una investigación inútil—. Lo que esa investigación no hace es detenerse ahí. La pregunta que de verdad mueve la investigación no es "¿el piloto decidió mal?" —una pregunta que, aislada, no lleva a ningún cambio sistémico— sino "¿qué información tenía disponible en ese momento, qué presión operativa enfrentaba, y qué salvaguarda, de haber existido, habría hecho esa decisión imposible de tomar, sin importar quién estuviera en la cabina?". Un postmortem sin culpa hace exactamente esa misma pregunta sobre un incidente de software.
DOS INVESTIGACIONES DEL MISMO HECHO -- LA DIFERENCIA QUE IMPORTA
INVESTIGACION QUE BUSCA CULPABLE INVESTIGACION SIN CULPA (esta guia)
───────────────────────────────── ─────────────────────────────────
Pregunta central: Pregunta central:
"¿quien tomo la mala decision?" "¿que hizo posible que esa decision
pareciera razonable en el momento?"
│ │
▼ ▼
Termina en un nombre y una Termina en una lista de controles
consecuencia personal de sistema (Leccion 4: prevent_destroy,
politica extendida, runbook nuevo)
│ │
▼ ▼
La proxima persona, bajo la La proxima persona, bajo la misma
misma presion, puede tomar la presion, se encuentra con un
misma decision -- nada del sistema que hace la misma
sistema cambio decision mas dificil o imposibleQué vas a construir en este módulo
Ocho lecciones, con el segundo mayor peso EJECUTADO de toda la guía, junto al Módulo 3:
| # | Lección | Qué produce |
|---|---|---|
| 1 | Esta introducción | El mapa completo del módulo, y la distinción central entre un postmortem sin culpa y una investigación de culpables |
| 2 | Qué hace a un postmortem "sin culpa" | La definición citada de sre.google/sre-book/postmortem-culture/, aplicada al punto exacto donde el incidente Claude Code se pone a prueba: la aprobación humana del destroy |
| 3 | Manos a la obra: escribiendo el postmortem | incidents/2026-02-26-claude-code-destroy/POSTMORTEM.md — el documento central de esta guía, construido sobre TIMELINE.md |
| 4 | Action items que de verdad se cumplen | Criterio SMART aplicado a action items reales, con dueño y prioridad — incluido el hueco de prevent_destroy sobre Shipments que cloud-security-and-guardrails-guide dejó declarado |
| 5 | Qué es (y qué no es) un runbook | La distinción con un postmortem, con ejemplos de mercado citados |
| 6 | Manos a la obra: el primer runbook real | runbooks/manifest-processor-error-rate.md — qué hacer cuando la alarma del Módulo 4 dispara |
| 7 | Manos a la obra: el intento honesto de backup/restore | awslocal dynamodb create-backup/restore-table-from-backup sobre una copia desechable de Shipments, con el resultado real documentado tal cual salga |
| 8 | Proyecto: el paquete de postmortem y runbooks | Los cuatro artefactos integrados — la pieza de portafolio final de este módulo |
Por qué este módulo viene después del Módulo 6, y no antes ni junto con él
Podría parecer más eficiente escribir el postmortem al mismo tiempo que se reconstruye el timeline —total, ya estás mirando los mismos hechos—. Este ecosistema, deliberadamente, no lo hace así, por una razón de disciplina que vale la pena entender antes de escribir la primera línea del postmortem en la lección 3: reconstruir los hechos y analizar su causa son dos actividades distintas, con dos riesgos distintos si se mezclan. Si escribieras la causa raíz mientras todavía estás confirmando el orden exacto de los eventos, el sesgo retrospectivo (hindsight bias, ya nombrado en el Módulo 6, lección 6) contaminaría la reconstrucción misma: sabrías desde el principio "cómo termina la historia", y sin darte cuenta reordenarías o reinterpretarías hechos tempranos para que encajen mejor con la conclusión a la que ya llegaste. Separar los dos módulos —Módulo 6 reconstruye sin analizar causa, Módulo 7 analiza sobre una reconstrucción ya cerrada— es la misma disciplina que un investigador de incidentes de aviación aplica: primero la caja negra completa, sin interpretación; después, y solo después, el análisis de causa.
Una honestidad que sostiene todo este módulo
El incidente Claude Code, otra vez, le ocurrió a DataTalks.Club, no a Andes Cargo —la misma frontera que el Módulo 6, lección 1 ya estableció con precisión, y que este módulo hereda sin repetir la explicación completa—. El postmortem de la lección 3 analiza causa raíz del incidente real, con las mismas fuentes verificadas de siempre; los action items de la lección 4, en cambio, sí son reales para Andes Cargo —prevent_destroy sobre Shipments, el runbook de la lección 6— porque esta guía tiene la autoridad de construir controles nuevos sobre su propio proyecto, aunque no tenga la autoridad de cambiar lo que ya le pasó a DataTalks.Club. Cada lección de este módulo, donde haga falta, mantiene esa distinción visible.
Errores comunes
Empezar la lección 3 pensando que "sin culpa" significa "sin analizar la decisión humana" (de sobrecorregir hacia la vaguedad). Qué pasa: alguien, temeroso de sonar acusador, escribe un postmortem que evita por completo mencionar que un humano aprobó el destroy, dejando la causa raíz vaga e inútil ("hubo un problema de proceso"). Cómo detectarlo: si tu borrador del postmortem no puede señalar, con precisión, en qué paso exacto de la cadena una decisión específica cambió el resultado. Cómo corregirlo: la lección 2 de este módulo va a ser explícita en esto —un postmortem sin culpa sí documenta que el humano aprobó el destroy, como hecho verificado; lo que no hace es tratar esa aprobación como el fin del análisis. "El humano aprobó el destroy" es información necesaria; "el humano es culpable" es una conclusión que el postmortem sin culpa nunca escribe, porque no lleva a ningún cambio de sistema.
Tratar este módulo como una repetición del Módulo 6 con otro nombre (de perder la frontera entre reconstruir y analizar). Qué pasa: alguien, al leer el postmortem de la lección 3, espera encontrar de nuevo la tabla completa de catorce hechos con marcas de tiempo, ya presente en TIMELINE.md. Cómo detectarlo: si tu versión del postmortem repite el timeline completo en vez de citarlo. Cómo corregirlo: el mismo principio de ensamblaje disciplinado que INCIDENT-RESPONSE-PLAN.md y TIMELINE.md ya aplicaron —citar, no repetir— gobierna también el postmortem: la sección de resumen y de impacto se apoyan en TIMELINE.md, sin reconstruir sus catorce hechos desde cero.
Asumir que el objetivo final de este módulo es "encontrar a alguien responsable de que Andes Cargo agregue prevent_destroy" (de reintroducir culpa por la puerta trasera, a nivel de proyecto en vez de a nivel de persona). Qué pasa: alguien redacta los action items de la lección 4 con un tono de "esto se debió haber hecho antes", en vez de "esto es lo que el sistema necesita ahora". Cómo detectarlo: si tu redacción de un action item incluye alguna evaluación de por qué no se hizo antes, en vez de limitarse a qué se va a hacer, quién y cuándo. Cómo corregirlo: un action item SMART (lección 4) es, por diseño, una declaración hacia adelante —qué cambia, no por qué no cambió antes—; la misma disciplina sin culpa que gobierna el postmortem completo se extiende, sin excepción, a la forma en que se escribe cada uno de sus action items.
Ejercicios
Ejercicio 1 — Con tus propias palabras, explica la diferencia entre "el humano aprobó el destroy" y "el humano es culpable", usando la analogía de la caja negra de esta lección.
Ver solución
"El humano aprobó el destroy" es un hecho verificable, del mismo tipo que "el piloto activó el piloto automático en un momento específico" — información necesaria para entender la secuencia completa de eventos, sin la cual la investigación sería incompleta o directamente falsa. "El humano es culpable" es una conclusión que asigna responsabilidad moral o profesional a una persona, y que —igual que en la analogía de la aviación— no lleva a ningún cambio verificable del sistema: castigar o señalar a esa persona no hace que la próxima persona, bajo la misma presión y con la misma ausencia de salvaguardas automáticas, tome una decisión distinta. Un postmortem sin culpa retiene el primer tipo de afirmación (necesaria, verificable) y descarta explícitamente el segundo (no verificable, no accionable) — la misma distinción que separa la investigación de un organismo de seguridad de vuelo de una investigación disciplinaria interna de una aerolínea.
Ejercicio 2 — Explica por qué separar la reconstrucción de hechos (Módulo 6) del análisis de causa (Módulo 7) en dos módulos distintos protege contra el sesgo retrospectivo, en vez de simplemente ser una decisión organizativa arbitraria.
Ver solución
El sesgo retrospectivo (hindsight bias) hace que, una vez que se conoce el desenlace de un evento, sea casi automático reinterpretar los hechos tempranos como si hubieran sido "señales obvias" de ese desenlace — el Módulo 6, lección 6 ya nombró este riesgo al advertir contra tratar el camino hacia la recuperación como "obvio desde el principio". Si la reconstrucción de hechos y el análisis de causa ocurrieran en el mismo paso, quien escribe el documento ya sabría, desde la primera línea del timeline, "cómo termina esto" y "por qué pasó" — y esa certeza contaminaría, sin que la persona lo note, cómo describe los hechos tempranos: el orden se volvería sutilmente narrativo en vez de forense. Terminar el timeline completo primero, sin ninguna conclusión de causa todavía escrita (la disciplina exacta que el Módulo 6, lección 8 cerró con "no analiza causa raíz — eso es el Módulo 7"), obliga a que la secuencia de hechos se sostenga por sí sola, verificable independientemente de cualquier conclusión posterior.
Ejercicio 3 — Un compañero argumenta que, ya que Andes Cargo es un proyecto ficticio, los action items de la lección 4 de este módulo "no cuentan como reales" de la misma forma en que el postmortem del incidente sí analiza un caso real. ¿Estás de acuerdo?
Ver solución
En desacuerdo, con la distinción exacta que esta lección ya trazó. El postmortem (lección 3) analiza causa raíz de un incidente que le ocurrió a una empresa real (DataTalks.Club) — ahí, "real" se refiere a los hechos investigados. Los action items (lección 4), en cambio, son reales en un sentido distinto: son cambios genuinos que este módulo declara sobre la infraestructura real de Andes Cargo dentro de este ecosistema —prevent_destroy sobre Shipments, el runbook de la lección 6—, con el mismo nivel de ejecución (HCL válido, documento verificado) que cualquier otro artefacto de esta guía. Que Andes Cargo sea un proyecto ficticio no vuelve ficticios los artefactos que esta guía construye sobre él, de la misma forma en que un ejercicio de sistemas en un laboratorio de LocalStack no es "menos real" solo porque la cuenta AWS detrás (000000000000) no es una cuenta de producción de nadie.
Resumen y siguiente paso
Esta lección estableció la distinción central de todo el módulo: un postmortem sin culpa documenta hechos —incluida una decisión humana específica, cuando esa decisión es parte de la cadena— sin convertir esos hechos en una asignación de culpa personal, porque la culpa personal no produce ningún cambio de sistema verificable. Viste el mapa de las ocho lecciones, cada una construyendo un artefacto que Andes Cargo no tenía desde el Módulo 1 de esta guía, y la razón de diseño por la que este módulo viene después, no junto con, la reconstrucción de hechos del Módulo 6.
Antes de avanzar deberías poder: explicar, con tus propias palabras, la diferencia entre un hecho verificado y una asignación de culpa; nombrar los cuatro artefactos que este módulo va a producir; y explicar por qué separar reconstrucción de análisis protege contra el sesgo retrospectivo.
La lección 2 profundiza la definición misma de "sin culpa", citada directamente de la fuente que la acuñó como práctica formal de ingeniería: el libro de Google SRE.
Recursos
- Google SRE Book — Postmortem Culture — la fuente de la definición que la lección 2 cita completa.
- Este mismo repositorio, Módulo 6, lección 8 (
08-project-andes-cargos-final-timeline-for-this-case.md) —TIMELINE.md, el insumo directo de la lección 3. cloud-security-and-guardrails-guide, Módulo 1, lección 6 (06-blast-radius-revisited-what-would-have-stopped-it.md) — la fuente del hueco declarado deprevent_destroyque la lección 4 convierte en action item.- Alexey Grigorev — How I Dropped Our Production Database — la fuente primaria que sostiene cada hecho del postmortem de la lección 3.