Módulo 6: Operating The Claude Code Incident

8. Proyecto: `TIMELINE.md` final de Andes Cargo para este caso

Siguiente →

Descripción

Seis lecciones construyeron cada pieza por separado: los hechos en orden (lección 2), la severidad con su justificación exacta (lección 3), la declaración con roles asignados (lección 4), la cadencia de comunicación (lección 5), el árbol de decisión de mitigación (lección 6), y el error budget recalculado con la calculadora real (lección 7). Este proyecto final no calcula ni investiga nada nuevo — reúne las cinco piezas técnicas en la versión final de incidents/2026-02-26-claude-code-destroy/TIMELINE.md: el documento completo que el Módulo 7 va a citar directamente, sin reconstruir ningún hecho desde cero, al escribir el postmortem sin culpa.

Conexión con el módulo

Este documento sigue el mismo principio de ensamblaje disciplinado que SLO.md (Módulo 2) e INCIDENT-RESPONSE-PLAN.md (Módulo 5) ya establecieron: ningún número ni ninguna cifra de este documento se calcula por primera vez aquí — cada uno ya fue verificado, citado o calculado en una lección anterior de este módulo. La única novedad genuina de esta lección es la disciplina de integrarlos sin contradicciones, en el mismo documento, en el orden en que un lector nuevo —alguien que nunca vio las seis lecciones anteriores— necesitaría encontrarlos.

Paso 1 — Por qué este documento cita, en vez de repetir, la lección 5

Fíjate en una decisión de diseño deliberada: este documento no incluye la tabla completa de cadencia de comunicación de la lección 5 (las siete actualizaciones internas, de T+~5min a T+24h00m). La razón es la misma que INCIDENT-RESPONSE-PLAN.md ya usó al citar SLO.md en vez de repetir su contenido: ese nivel de detalle narrativo pertenece a la lección que lo construyó, y este documento —pensado como la pieza de portafolio final, y como el insumo directo del postmortem del Módulo 7— necesita ser denso en hechos verificables, no una repetición completa de cada lección. La sección "Roles" de este documento sí resume, en una línea, la cadencia (de la lección 5), sin reproducir la tabla completa.

Paso 2 — El documento completo

En incidents/2026-02-26-claude-code-destroy/, reemplaza la versión de la lección 2 con la versión final:

# TIMELINE.md — 2026-02-26 Claude Code `destroy` Incident

**Status:** Final · **Governs:** input to Module 7's postmortem
**Real incident, external:** happened to DataTalks.Club, not to Andes Cargo. Operated here as a
drill against `INCIDENT-RESPONSE-PLAN.md` (Module 5) — see Module 6, lesson 1.
**Sources:** Alexey Grigorev, "How I Dropped Our Production Database" (alexeyondata.substack.com);
Hacker News #47278720; incidentdatabase.ai #1424; Tom's Hardware.

## A note on timestamps

All timestamps in this document are relative to `T+0`, the moment `terraform destroy
-auto-approve` executed. The primary source gives only approximate clock times; this document
never converts those into exact clock timestamps. Offsets marked `~` are inferred from the
sequence the source describes, not measured to the minute. The two precise offsets in this
document, both stated directly by the primary source: `T+0` itself (the destroy command), and
`T+24h00m` (the restoration — "Exactly 24 hours after the database had been deleted").

## Timeline

| Offset | Event |
|---|---|
| T-~1h | Deployment work begins: migrating a static site into the existing Terraform project, without the correct state file |
| T-~15min | `terraform plan` shows resources marked for creation, not modification — first anomaly noticed |
| T-~10min | Agent explains the loaded state file made it believe "nothing existed"; `apply` stopped, but some resources already partially created |
| T-~5min | Agent proposes `terraform destroy` as the cleanest way to reverse what it had just created |
| T-~1min | Human does not stop the agent |
| **T+0** | **`terraform destroy -auto-approve` executes.** VPC, ECS cluster, load balancers, bastion host, RDS database, and all automated snapshots — destroyed. `courses_answer` (1,943,200 rows, 2.5 years of data) gone. |
| T+0 to T+~5min | Total outage, immediately and unambiguously visible |
| T+~5min | **Incident declared. SEV1.** Roles assigned: Ana (Incident Commander + Communications Lead), Bruno (Operations Lead) |
| T+~1h | Support ticket opened with AWS; upgrade to Business Support tier (~+10% monthly cost) |
| T+~1h30min | AWS confirms a snapshot exists on their end — not visible in the customer console |
| T+~2h to T+~3h | Phone call with AWS support; internal escalation for manual restoration |
| **T+24h00m** | **AWS restores the snapshot.** `courses_answer` restored intact, 1,943,200 rows confirmed. Incident resolved. |
| (8 days after T+0) | Grigorev publishes the full incident writeup publicly |

## Severity

**SEV1** — not by a burn-rate threshold (Module 6, lesson 3: burn rate is mathematically
undefined here, `0/0` — no infrastructure remains to generate measurable traffic) but by
`INCIDENT-RESPONSE-PLAN.md`'s independent SEV1 criterion: unrecoverable data loss without
external support intervention. Verified against four conditions (Module 6, lesson 3, Step 3):
real data loss (yes), recoverable with the team's own tools (no), required external support (yes),
system still responding to other requests (not applicable — nothing was responding at all, a case
more severe than the matrix's minimum bar for this tier).

## Roles

Assigned from `oncall/schedule.py`'s Week 1 rotation (2026-03-02, Ana primary / Bruno secondary),
applied to this incident as a deliberate exercise — the real incident predates the plan's
effective date by six days; see Module 6, lesson 4, Step 1 for the full honesty note.

- **Incident Commander + Communications Lead: Ana** — coordinates the response, owns this
  document, issues updates on a cadence (Module 6, lesson 5): every 15-30 minutes early on,
  spacing out to hours once escalated to AWS and no longer generating new information every few
  minutes.
- **Operations Lead: Bruno** — the only role that would have executed mitigation actions, had any
  been available under the team's own control.

## Mitigation decision tree

Two self-service paths checked and exhausted within minutes of `T+0`: reverting via Terraform
state (not applicable — the state itself was the cause, and the infrastructure it described no
longer existed) and locating an automated RDS snapshot in the account's own console (none —
automated snapshots were destroyed alongside the database). With both own-account paths
exhausted, the incident moved to escalation: AWS Business Support (`T+~1h`), confirmation of an
internal AWS-side snapshot not listed in the console (`T+~1h30min` — the single node in this tree
with genuine uncertainty until AWS responded), phone escalation for manual restoration (`T+~2h`
to `T+~3h`), and a wait outside the team's direct control until `T+24h00m`. Full branch-by-branch
detail: Module 6, lesson 6.

## Error budget

Measured against `SLO.md`'s real SLO (99.9% monthly, 43.2-minute budget) using
`error_budget_minutes()` from `scripts/error_budget_calculator.py` (Module 6, lesson 7 — same
function, same formula the rest of this guide uses, not a one-off calculation):

- **1,440 minutes consumed** (the full 24-hour incident) against a 43.2-minute monthly budget.
- **3,333.3% of the monthly budget consumed** — a deficit of -1,396.8 minutes.
- **Burn factor: 33.3x** the full monthly budget in a single event — the same result Module 1,
  lesson 6 first calculated with a hypothetical SLO, now confirmed against Andes Cargo's actual
  chosen SLO.
- Burn rate (the *rate* of consumption, not the total budget consumed) is not calculable for this
  incident — no measurable traffic exists once the infrastructure that would generate it is gone
  (Module 6, lesson 7, Step 4).

## What this document does not do

It does not analyze root cause — that is Module 7's postmortem, built on top of this exact
document. It does not assign blame to any individual — the roles section names functions
performed in this exercise, not a judgment on how DataTalks.Club, a one-person team, actually
responded in real life (Module 6, lesson 5, Step 2, is explicit about that distinction). It does
not claim the mitigation path (an AWS-side snapshot not listed in console) is a reproducible
safety net for any future incident — Module 6, lesson 6's closing point, and Module 7's own
honest backup/restore attempt against LocalStack (lesson 7 of that module), exist precisely
because this mechanism was never guaranteed.

## Consequences

Module 7's postmortem cites this document directly for its summary, impact, and timeline sections
— it does not reconstruct any of these facts from scratch. Module 8's capstone runs a new,
synthetic incident through the same five-stage machine this document already proved works on a
real case.

Paso 3 — Verificando el documento

wc -l TIMELINE.md
grep -c '^## ' TIMELINE.md
grep -c 'T+' TIMELINE.md

Qué esperar (literal — el contenido lo ensamblaste tú, la forma es determinista):

102
8
16

Ciento dos líneas, ocho secciones (A note on timestamps, Timeline, Severity, Roles, Mitigation decision tree, Error budget, What this document does not do, Consequences), y dieciséis referencias a marcas de tiempo relativas — ni una sola hora de reloj real en todo el documento, el mismo patrón determinista de verificación que SLO.md y INCIDENT-RESPONSE-PLAN.md ya establecieron.

Cómo leer este documento, seis meses después

La misma prueba que SLO.md y INCIDENT-RESPONSE-PLAN.md ya superaron: frente a este documento, sin preguntarle a nadie ni releer ninguna lección de este módulo, un lector nuevo debería poder contestar cinco preguntas. ¿Qué pasó, y en qué orden? (sección Timeline, catorce hechos, cada uno con su marca relativa). ¿Qué tan grave fue, con un criterio verificable, no con una opinión? (Severity, con las cuatro condiciones del criterio independiente de SEV1 confirmadas). ¿Quién respondió, con qué rol, y con qué cadencia de comunicación? (Roles). ¿Cómo se recuperaron los datos, paso por paso, con cada bifurcación real? (Mitigation decision tree). Y ¿cuánto costó, en el vocabulario formal de esta guía? (Error budget, 33,3x, con la salvedad honesta de que burn rate no aplica aquí). Si alguna de esas cinco preguntas exige releer una lección completa de este módulo, el documento no cumplió su función.

El cierre del Módulo 6

Con TIMELINE.md terminado, este módulo entrega exactamente lo que prometió en la lección 1: no una quinta narración del incidente Claude Code, sino el marco completo de INCIDENT-RESPONSE-PLAN.md (Módulo 5) operado, paso por paso, contra ese incidente real —detección instantánea, declaración con roles reales asignados, respuesta que agotó las opciones propias en minutos, un árbol de mitigación con una sola bifurcación genuinamente incierta, y una resolución verificada a T+24h00m—, medido con el vocabulario formal completo de SLI/SLO/error budget que esta guía construyó desde el Módulo 1. El resultado —33,3x el presupuesto mensual, la misma cifra desde la primera vez que se calculó— ya no es solo un número aislado del Módulo 1: es el resultado consistente de una calculadora real, aplicada dos veces, sobre el mismo SLO que Andes Cargo eligió con evidencia.

Entras al Módulo 7 con todo lo que necesitas ya construido: TIMELINE.md es el insumo directo del postmortem sin culpa que ese módulo escribe — la pregunta de "por qué pasó" que este módulo, deliberadamente, dejó sin contestar.

Errores comunes

Tratar este documento como el lugar donde se investiga la causa raíz, en vez de como el registro de hechos y respuesta que el Módulo 7 va a analizar (repetido del error ya nombrado en la lección 4, ahora aplicado al documento completo). Qué pasa: alguien, al terminar este documento, empieza a escribir conclusiones sobre "por qué" el humano no detuvo al agente, o "qué debería cambiar" en el proceso. Cómo detectarlo: si tu versión de TIMELINE.md incluye alguna sección de causa raíz o de acciones de seguimiento. Cómo corregirlo: la sección "What this document does not do" es explícita — el análisis de causa raíz y los action items pertenecen al postmortem del Módulo 7, construido sobre este documento, no dentro de él. Mezclar ambos documentos diluye la función específica de cada uno: este es el registro de hechos; el postmortem es el aprendizaje sistémico.

Copiar este documento sin haber corrido tú mismo el script de la lección 7, confiando en que las cifras de la sección "Error budget" son correctas (repetido del mismo error ya nombrado en SLO.md e INCIDENT-RESPONSE-PLAN.md). Qué pasa: alguien pega la sección "Error budget" de este documento sin haber verificado, corriendo su propia copia del script, que 33,3x y -1.396,8 minutos son el resultado real. Cómo detectarlo: si no puedes reproducir, ejecutando tu propio código, exactamente los mismos números citados aquí. Cómo corregirlo: cada cifra de la sección "Error budget" proviene de un script que tú ya escribiste y corriste en la lección 7 de este módulo — antes de dar por bueno este documento, confirma que tu propia ejecución produce, dígito por dígito, los mismos resultados.

Asumir que la sección "Roles" de este documento significa que Ana y Bruno son personas reales que respondieron al incidente de DataTalks.Club (repetido, por tercera vez en este módulo, del mismo error de frontera entre caso real y ejercicio). Qué pasa: alguien, al leer este documento de forma aislada, sin el contexto de las lecciones anteriores, concluye que el incidente tuvo un Incident Commander y un Operations Lead reales durante los hechos originales. Cómo detectarlo: si tu resumen de este documento no distingue entre lo que ocurrió realmente (la columna izquierda del "Timeline", hasta T+24h00m) y lo que este ejercicio le agrega (la asignación de roles de Andes Cargo). Cómo corregirlo: el encabezado del documento lo declara en la segunda línea —"Real incident, external: happened to DataTalks.Club, not to Andes Cargo"—, precisamente para que ningún lector futuro pierda esta distinción, aunque lea solo este documento sin ningún contexto adicional.

Ejercicios

Ejercicio 1 — Verifica la sección "Error budget" de este documento contra tu propia ejecución del script de la lección 7. Confirma que obtienes exactamente 33.3x como factor de consumo y -1396.8 minutos como presupuesto restante.

Ver solución

Corriendo el script de la lección 7 (error_budget_minutes(0.999, 43200) seguido de las operaciones sobre INCIDENT_MINUTES = 1440) se obtiene: budget_minutes = 43.2, minutes_consumed = 1440, minutes_remaining = 43.2 - 1440 = -1396.8, burn_factor = 1440 / 43.2 ≈ 33.3. Coincide exactamente con la sección "Error budget" de este documento. Este ejercicio confirma que el documento de portafolio que acabas de ensamblar es trazable hasta un script ejecutable, no una afirmación sin respaldo — cualquier persona que audite este documento puede correr el mismo código y llegar exactamente al mismo lugar.

Ejercicio 2 — Defiende la sección "Severity" de este documento frente a una objeción real. Un entrevistador técnico pregunta: "si no se puede calcular burn rate para este incidente, ¿cómo sabes con certeza que es SEV1 y no, por ejemplo, SEV2?". ¿Cómo respondes, usando el propio documento?

Ver solución

Una respuesta completa: "La sección Severity de este documento ya contesta eso directamente — la matriz de INCIDENT-RESPONSE-PLAN.md no depende únicamente de burn rate; incluye un criterio independiente para pérdida de datos irrecuperable sin intervención de soporte externo, exactamente pensado para casos como este donde no hay ningún tráfico medible. Verificamos las cuatro condiciones de ese criterio, hecho por hecho, contra el timeline: hubo pérdida real de datos, no era recuperable con las herramientas propias del equipo, requirió escalar a soporte externo de AWS, y el sistema ni siquiera estaba respondiendo a nada más —un caso más severo que el mínimo que la matriz exige para SEV1—. La ausencia de un número de burn rate no deja la clasificación en el aire; el criterio independiente es igual de riguroso, solo que verificable con hechos en vez de con una fórmula."

Ejercicio 3 — Explica por qué la sección "What this document does not do" incluye explícitamente "it does not claim the mitigation path... is a reproducible safety net for any future incident", en vez de dejar que esa conclusión se infiera de la sección "Mitigation decision tree".

Ver solución

Sin esa declaración explícita, alguien que lea solo el árbol de decisión de mitigación —que termina en una recuperación exitosa— podría inferir, incorrectamente, que el mecanismo que funcionó esta vez (un snapshot interno de AWS no listado en consola) es una garantía confiable para el futuro. El Módulo 6, lección 6 ya estableció, con precisión, que ese mecanismo nunca estuvo garantizado por ninguna configuración explícita del lado del cliente — fue, en gran medida, un desenlace favorable no planeado. Declarar esa limitación explícitamente, en vez de dejarla implícita, previene que este documento se lea como una recomendación de "confía en que AWS tendrá un snapshot de respaldo" — la misma disciplina de honestidad que cada documento de esta guía aplica a sus propios límites, y la razón directa por la que el Módulo 7 construye, con LocalStack, un intento explícito de backup/restore para Andes Cargo, en vez de depender de la misma suerte.

Resumen y siguiente paso

En este proyecto final del módulo ensamblaste la versión completa de TIMELINE.md: catorce hechos cronológicos con marcas de tiempo relativas (lección 2), la clasificación SEV1 con su criterio independiente verificado (lección 3), los roles asignados con su cadencia de comunicación (lecciones 4 y 5), el árbol de decisión de mitigación completo (lección 6), y el error budget recalculado con la herramienta real —33,3x, -1.396,8 minutos de déficit— (lección 7). Verificaste el documento con la misma disciplina determinista de todo este ecosistema: 102 líneas, 8 secciones, 16 marcas de tiempo relativas, ni una sola hora de reloj real.

Antes de cerrar este módulo deberías poder: recitar el timeline completo, de T-~1h a T+24h00m, sin mirar el documento; justificar la severidad SEV1 con el criterio independiente, no con burn rate; y explicar, con el propio documento, por qué "operar" este incidente produjo cinco artefactos distintos, ninguno de los cuales repite la narración que tres guías hermanas ya construyeron.

Con esto, el Módulo 6 de sre-and-incident-response-guide queda completo: el incidente Claude Code, operado de principio a fin a través del marco de respuesta a incidentes de Andes Cargo, con el ángulo específico que esta guía prometió desde el Módulo 1 —la recuperación, medida con el vocabulario formal completo de SRE—. El Módulo 7 toma TIMELINE.md, tal como quedó aquí, y escribe sobre él el postmortem sin culpa completo: la causa raíz, qué salió bien y qué salió mal, y los action items con dueño y prioridad que ningún módulo anterior todavía había construido.

Recursos

  1. Este módulo, lecciones 2 a 7 — la fuente directa de cada sección de este documento.
  2. Este mismo repositorio, Módulo 5, lección 8 (08-project-andes-cargos-incident-response-plan.md) — INCIDENT-RESPONSE-PLAN.md, el marco completo que este documento demuestra operado.
  3. Alexey Grigorev — How I Dropped Our Production Database — fuente primaria de cada hecho verificado de este documento.
  4. Google SRE — Incident Management Guide — el ciclo de vida de cinco etapas que este documento, de principio a fin, demuestra aplicado a un caso real.
← Anterior7. El error budget de este incidente, con el vocabulario completoSiguiente →1. Introducción: del timeline al aprendizaje sistémico