Módulo 7: Blameless Postmortems And Runbooks

8. Proyecto: el paquete de postmortem y runbooks de Andes Cargo

Descripción

Cuatro lecciones construyeron cuatro artefactos por separado: POSTMORTEM.md con causa raíz distinguida de disparador (lección 3), cuatro action items SMART con dueño y prioridad (lección 4), el primer runbook real de Andes Cargo (lección 6), y el resultado honesto del intento de backup/restore (lección 7). Este proyecto final no escribe ningún documento nuevo — reúne los cuatro en un solo paquete, con un índice que confirma que cada pieza cumple su función, y con la misma disciplina de verificación determinista que cada proyecto de esta guía ya exigió de sí mismo.

Conexión con el módulo

Este documento hace, por el paquete completo del Módulo 7, lo mismo que TIMELINE.md (Módulo 6, lección 8) hizo por los seis documentos de ese módulo: ensamblar sin inventar, citar sin repetir. El Módulo 8 —el capstone de esta guía— va a citar este paquete completo como la evidencia de que la máquina de confiabilidad de Andes Cargo (SLI → SLO → observabilidad → alerta → incidente → postmortem → runbook) funciona de punta a punta, no solo en la teoría de cada módulo por separado.

Paso 1 — El inventario completo, verificado archivo por archivo

Antes del documento de portafolio en sí, confirma que los cuatro artefactos existen exactamente donde DISENO.md los predijo:

find andes-cargo-infra/incidents/2026-02-26-claude-code-destroy -type f
find andes-cargo-infra/runbooks -type f

Qué esperar (literal — la estructura la creaste tú en las lecciones 3 y 6 de este módulo, más las lecciones 2 y 8 del Módulo 6):

andes-cargo-infra/incidents/2026-02-26-claude-code-destroy/TIMELINE.md
andes-cargo-infra/incidents/2026-02-26-claude-code-destroy/POSTMORTEM.md
andes-cargo-infra/runbooks/manifest-processor-error-rate.md

Tres archivos, dos directorios — TIMELINE.md (Módulo 6) y POSTMORTEM.md (este módulo) comparten carpeta porque documentan el mismo incidente desde dos ángulos distintos; runbooks/ es un directorio nuevo, hermano de incidents/, porque un runbook no pertenece a ningún incidente específico —existe para cualquier vez que la condición que describe se repita—. El resultado de la lección 7 (el intento de backup/restore) no produce un cuarto archivo nuevo: queda documentado dentro de la propia lección, la misma decisión que DISENO.md ya tomó al no listarlo entre los artefactos nuevos de esta guía.

Paso 2 — El documento de portafolio

En la raíz de andes-cargo-infra/, crea RELIABILITY-POSTMORTEM-PACKAGE.md:

# RELIABILITY-POSTMORTEM-PACKAGE.md — Module 7 Deliverable Index

**Status:** Final · **Governs:** the four artifacts this module produced, indexed together
**Built on:** `TIMELINE.md` (Module 6, lesson 8) — this package does not re-derive any fact
already established there or in `POSTMORTEM.md` itself.

## What this package contains

| Artifact | Path | Lesson | What it answers |
|---|---|---|---|
| Postmortem | `incidents/2026-02-26-claude-code-destroy/POSTMORTEM.md` | Module 7, lesson 3 | Why did this happen, at the system level — blameless, four root causes, distinguished from the trigger |
| Action items | (table inside `POSTMORTEM.md`, expanded in lesson 4) | Module 7, lesson 4 | What changes now, with an owner, a measurable criterion, and a deadline for each |
| Runbook | `runbooks/manifest-processor-error-rate.md` | Module 7, lesson 6 | What to do, step by step, the next time the Module 4 alarm fires |
| Backup/restore attempt result | Documented in lesson 7 itself, not a separate file | Module 7, lesson 7 | Whether Andes Cargo can recover `Shipments` on its own, without depending on an undisclosed provider-side mechanism |

## The four action items, current status

| # | Action item | Owner | Priority | Status as of this package |
|--:|---|---|---|---|
| 1 | `prevent_destroy` on `Shipments` | Bruno | P1 | Declared, not yet applied to `andes-cargo-infra/` — this guide's scope ends at the postmortem and runbook layer, not a new HCL commit to the shared infrastructure module |
| 2 | `no-destroy-shipments.rego` coverage for `terraform destroy` plans | Carla | P2 | Declared, verification test not yet written |
| 3 | `runbooks/manifest-processor-error-rate.md` | Ana | P1 | **Done** — delivered in full, Module 7, lesson 6 |
| 4 | DynamoDB backup/restore evaluation for `Shipments` | Diego | P2 | **Done, with an honest result** — Module 7, lesson 7 confirmed the network-level root cause directly, and documented the exact response shape a successful attempt would have, without confirming LocalStack's specific API coverage |

Two of four action items are fully delivered within this guide's own scope (#3, the runbook itself;
#4, the honest investigation it asked for). The other two (#1, #2) are infrastructure changes to
`andes-cargo-infra/` outside a documentation-and-runbook module's scope — declared with full SMART
detail, ready for whoever picks them up next, the same honest boundary `POSTMORTEM.md` already
drew between "root cause identified" and "root cause resolved."

## What a reader should be able to answer from this package alone

The same test `TIMELINE.md`, `SLO.md`, and `INCIDENT-RESPONSE-PLAN.md` already passed: **What
happened, and why, at the system level, without blaming a person?** (`POSTMORTEM.md`'s Root
cause(s) section, four causes, none a character judgment.) **What changes now, and who is
accountable for it?** (the action items table above, each with a single owner.) **What does
someone on call do the next time this specific alarm fires?** (`runbooks/manifest-processor-
error-rate.md`, seven steps, three branches.) **Can Andes Cargo recover this table on its own,
without relying on an AWS-side mechanism nobody knew existed?** (lesson 7's honest answer: partly
confirmed, partly still open, documented precisely which part is which.)

## What this package does not do

It does not re-run or re-verify any of the four artifacts' own content — this index trusts each
lesson's own verification (`POSTMORTEM.md`'s 171 lines / 10 sections, the runbook's 220 lines / 9
sections) rather than repeating it. It does not close action items #1 and #2 — those remain real,
open, SMART commitments against `andes-cargo-infra/`, not resolved by this guide's own scope. It
does not claim DataTalks.Club, the real company behind this incident, ever built or needed any of
these four artifacts — every one of them is Andes Cargo's own response, built on a real incident's
verified facts.

## Consequences

Module 8's capstone cites this package as evidence that Andes Cargo's reliability machine — SLI
(Module 2) measured with real data (Module 3), alerted on burn rate (Module 4), operated through
a real incident (Module 6), and closed with a blameless postmortem and a working runbook (this
module) — produces artifacts a real interview or a real on-call rotation could use unmodified.

Paso 3 — Verificando el paquete

wc -l RELIABILITY-POSTMORTEM-PACKAGE.md
grep -c '^## ' RELIABILITY-POSTMORTEM-PACKAGE.md
grep -c '^| [0-9]' RELIABILITY-POSTMORTEM-PACKAGE.md

Qué esperar (literal — el contenido lo ensamblaste tú):

57
5
4

Cincuenta y siete líneas, cinco secciones (What this package contains, The four action items, current status, What a reader should be able to answer from this package alone, What this package does not do, Consequences), y cuatro filas en la tabla de estado de action items — el mismo conteo de cuatro que POSTMORTEM.md ya estableció en la lección 3, ahora con una columna de estado agregada.

Paso 4 — Leyendo la honestidad más importante del paquete: dos de cuatro, no cuatro de cuatro

Fíjate en algo que este documento no suaviza: solo dos de los cuatro action items de POSTMORTEM.md están completamente resueltos dentro del alcance de esta guía —el runbook (#3) y la investigación honesta de backup (#4)—. Los otros dos —prevent_destroy (#1) y la cobertura extendida de conftest (#2)— son cambios de infraestructura sobre andes-cargo-infra/ que, con precisión, exceden el alcance declarado de un módulo de postmortems y runbooks: son trabajo de HCL real, del mismo tipo que cloud-security-and-guardrails-guide construyó para sus propios controles, no de un módulo que documenta y opera. Declarar esto con la misma honestidad que cada documento de esta guía ya exige —"dos de cuatro, no cuatro de cuatro"— es más valioso que forzar una afirmación de "todo resuelto" que no sería cierta. Un action item declarado con precisión SMART, listo para que alguien lo tome, es un resultado real de este módulo, incluso si el HCL en sí no se escribe aquí.

Errores comunes

Escribir este paquete de forma que implique que los cuatro action items ya están resueltos, para que el proyecto "se vea más completo" (de inflar el resultado, el mismo error que TIMELINE.md ya advirtió contra "Resolved" sin matices). Qué pasa: alguien, al llenar la columna "Status" de la tabla del Paso 2, marca los cuatro como "Done", incluyendo prevent_destroy y la cobertura de conftest, que en realidad no se aplicaron dentro de este módulo. Cómo detectarlo: si tu tabla de estado no distingue entre "el HCL ya corrió" y "el action item está declarado con criterio SMART, listo para aplicarse". Cómo corregirlo: la misma disciplina que cloud-security-and-guardrails-guide ya aplicó al redactar la fila de RISK-MAP.md para CloudTrail —"no dice 'Resolved' sin más"— gobierna esta tabla: dos action items completamente entregados, dos declarados y listos, ninguno inflado.

Tratar la ausencia de un cuarto archivo nuevo (para el resultado del backup/restore) como un hueco de este paquete (de esperar simetría donde DISENO.md no la pidió). Qué pasa: alguien, al ver que el Paso 1 encuentra solo tres archivos en vez de cuatro, asume que falta crear un documento adicional para el resultado de la lección 7. Cómo detectarlo: si tu inventario de archivos incluye un archivo inventado, no listado en DISENO.md, solo para "completar" el patrón de un archivo por lección. Cómo corregirlo: DISENO.md es explícito sobre qué artefactos nuevos produce esta guía, y el resultado del intento de backup/restore no está entre ellos — queda documentado dentro de la propia lección 7, una decisión de diseño deliberada, no un descuido que este proyecto final deba corregir agregando un archivo que nadie pidió.

Reconstruir el contenido completo de POSTMORTEM.md o del runbook dentro de este documento de portafolio, en vez de citarlos por ruta (repetido, por quinta vez en esta guía, del mismo error de ensamblaje disciplinado). Qué pasa: alguien copia las secciones completas de POSTMORTEM.md dentro de RELIABILITY-POSTMORTEM-PACKAGE.md, para que el paquete "lo tenga todo en un solo lugar". Cómo detectarlo: si tu versión de este documento supera, por mucho, las 57 líneas del Paso 3. Cómo corregirlo: el mismo principio que TIMELINE.md, INCIDENT-RESPONSE-PLAN.md y SLO.md ya aplicaron gobierna este documento — un índice cita, con una tabla y una ruta de archivo, nunca repite el contenido completo de lo que indexa.

Ejercicios

Ejercicio 1 — Verifica el Paso 3 sobre tu propia copia de RELIABILITY-POSTMORTEM-PACKAGE.md y confirma que obtienes exactamente 57, 5 y 4.

Ver solución

Copiando el documento del Paso 2 exactamente como aparece, wc -l cuenta 57 líneas totales, grep -c '^## ' encuentra cinco encabezados de sección de nivel 2, y grep -c '^| [0-9]' encuentra las cuatro filas de la tabla de estado de action items que empiezan con un número. La verificación determinista de este documento es más corta que la de POSTMORTEM.md o el runbook porque, por diseño, es un índice — cita rutas y estados, no reconstruye contenido.

Ejercicio 2 — Un entrevistador técnico, mirando este paquete, pregunta: "¿por qué solo dos de cuatro action items están resueltos? ¿Este postmortem no funcionó del todo?". ¿Cómo respondes, usando el Paso 4 de esta lección?

Ver solución

Una respuesta completa: "El postmortem funcionó exactamente como debía — identificó cuatro causas raíz reales y produjo cuatro action items SMART, cada uno con dueño, criterio medible y plazo. Que dos de los cuatro requieran un cambio de infraestructura real sobre andes-cargo-infra/ —un bloque lifecycle de Terraform, una prueba nueva de conftest— y no se resuelvan dentro de un módulo que documenta postmortems y runbooks no es una falla del proceso, es una frontera de alcance declarada con precisión: este módulo entrega los dos action items que sí le correspondían por completo (el runbook, la investigación honesta de backup) y deja los otros dos listos, con todo el criterio necesario, para que quien construya la siguiente pieza de infraestructura de Andes Cargo los tome sin ambigüedad. Un postmortem que produce action items SMART reales, aunque no todos se resuelvan en el mismo módulo que los escribió, es más honesto y más útil que uno que finja resolverlos todos de inmediato."

Ejercicio 3 — Explica por qué la sección "What a reader should be able to answer from this package alone" del Paso 2 formula sus cuatro preguntas en el mismo orden en que las lecciones 3, 4, 6 y 7 de este módulo construyeron sus artefactos, en vez de un orden distinto.

Ver solución

El orden reproduce la secuencia lógica real de este módulo: primero se establece por qué pasó algo, a nivel de sistema, sin culpar a una persona (lección 3, la pregunta de causa raíz); después se decide qué cambia como consecuencia, con dueño y plazo (lección 4, la pregunta de action items); después se construye la herramienta operativa para la próxima vez que una condición similar —aunque no idéntica— se repita (lección 6, la pregunta del runbook); y por último se cierra el hueco más específico que el propio incidente reveló —la dependencia de un mecanismo de recuperación fuera del control del equipo— con una investigación honesta (lección 7). Cada pregunta depende, lógicamente, de la anterior: no tendría sentido preguntar "qué cambia" antes de saber "por qué pasó", ni preguntar "qué hace alguien de guardia" antes de saber "qué cambió". El orden de la sección no es arbitrario — es el mismo orden en que un postmortem real, bien construido, tiene que razonar.

Resumen y siguiente paso

Este proyecto final integró los cuatro artefactos del Módulo 7 en RELIABILITY-POSTMORTEM-PACKAGE.md: POSTMORTEM.md (causa raíz sin culpa), los cuatro action items SMART con su estado real (dos completamente entregados, dos declarados y listos), el runbook completo de Andes Cargo, y el resultado honesto del intento de backup/restore. Verificaste el paquete con el mismo patrón determinista de siempre —57 líneas, 5 secciones, 4 filas de estado— y confirmaste, sin inflar el resultado, que dos de cuatro action items exceden el alcance de este módulo de documentación y quedan declarados, no resueltos.

Antes de cerrar este módulo deberías poder: nombrar los cuatro artefactos de este módulo y su ubicación exacta en andes-cargo-infra/; explicar por qué solo dos de cuatro action items están completamente resueltos, sin que eso reste valor al postmortem; y defender, con las cuatro preguntas de este documento, que el paquete completo se sostiene sin necesitar releer ninguna lección individual.

Con esto, el Módulo 7 de sre-and-incident-response-guide queda completo: el incidente Claude Code, ya operado de punta a punta en el Módulo 6, ahora tiene su análisis sistémico sin culpa, sus action items con dueño real, y el primer runbook operativo de todo el ecosistema. El Módulo 8, el capstone de esta guía, corre un incidente sintético nuevo —determinista, nunca aleatorio— a través de la máquina completa que los siete módulos anteriores construyeron: SLI, SLO, observabilidad, alerta, ciclo de vida, y ahora, postmortem y runbook.

Recursos

Este módulo, lecciones 2 a 7 — la fuente directa de cada artefacto que este paquete indexa.
Este mismo repositorio, Módulo 6, lección 8 (08-project-andes-cargos-final-timeline-for-this-case.md) — TIMELINE.md, el documento sobre el que POSTMORTEM.md se construyó.
cloud-security-and-guardrails-guide, Módulo 1, lección 6 (06-blast-radius-revisited-what-would-have-stopped-it.md) — la fuente del action item #1 de este paquete.
Google SRE Book — Postmortem Culture y Google SRE Workbook — Postmortem Culture — la disciplina completa que gobierna cada artefacto de este módulo.

← Anterior7. Manos a la obra: el intento honesto de backup/restore Siguiente →1. Introducción al capstone