Módulo 6: Operating The Claude Code Incident

2. Manos a la obra: reconstruyendo el timeline exacto

Descripción

Todo documento de respuesta a incidentes empieza en el mismo lugar: una secuencia ordenada de hechos, con marcas de tiempo, que cualquier persona nueva pueda leer y entender sin necesitar preguntarle a nadie qué pasó primero. Esta lección construye esa secuencia para el incidente Claude Code, en incidents/2026-02-26-claude-code-destroy/TIMELINE.md — la primera versión del documento central de este módulo, con cada hecho verificado contra la fuente primaria y, donde el registro público no da una hora exacta de reloj, una marca de tiempo relativa (T+0, T+~5min) en vez de una hora inventada.

Conexión con el módulo

La lección 1 prometió que este módulo produce documentos operativos reales, no una narración más. Este es el primero: un timeline formal que las lecciones 3 a 6 de este módulo van a enriquecer, no reescribir —la severidad de la lección 3, los roles de la lección 4, el árbol de decisión de la lección 6 se agregan sobre esta misma línea de tiempo, sin cambiar ni un solo hecho ya establecido aquí—. La lección 8, el proyecto final del módulo, entrega la versión completa e integrada de este mismo archivo.

Paso 1 — Por qué marcas de tiempo relativas, y no el reloj real del incidente

Una honestidad que vale la pena resolver antes de escribir una sola línea del timeline: la fuente primaria de este incidente —el relato de primera mano de Alexey Grigorev— sí incluye referencias aproximadas de hora ("alrededor de las 10 de la noche", "cerca de la medianoche"). Sería técnicamente posible reconstruir un timeline con esas horas aproximadas convertidas en marcas de reloj exactas. Esta lección, deliberadamente, no lo hace, por dos razones concretas.

Primera razón: las horas de la fuente son aproximadas, no exactas —el propio relato usa "alrededor de" y "cerca de", nunca un timestamp preciso al minuto—. Convertir "alrededor de las 10 de la noche" en un timestamp exacto como 22:00:00 fabricaría una precisión que la fuente misma nunca tuvo, exactamente el tipo de honestidad que este ecosistema completo exige desde su primera guía: nunca presentar como literal algo que en realidad es una aproximación.

Segunda razón, más importante: lo que este timeline necesita comunicar no es "a qué hora del reloj pasó cada cosa" — es "cuánto tiempo transcurrió entre cada etapa". Un timeline de incidente real, el tipo que un Incident Commander mantiene mientras el incidente está activo, casi siempre se lee y se usa en términos relativos —"llevamos 40 minutos sin respuesta del proveedor", no "son las 11:40 PM"— porque la pregunta operativa central durante una respuesta activa nunca es la hora del reloj, es cuánto tiempo ha pasado desde que el incidente empezó. Esta lección adopta esa misma convención: T+0 marca el momento en que el terraform destroy -auto-approve se ejecuta —el evento que causa la pérdida de datos, el punto de referencia más claro y verificable de todo el incidente—, y cada otro hecho se marca con su desplazamiento relativo a ese punto, con el símbolo ~ donde el desplazamiento exacto no está verificado con precisión de minuto.

Paso 2 — Los hechos, verificados contra la fuente primaria

Antes de construir el timeline, la lista completa de hechos que lo alimentan, cada uno trazable hasta una fuente citada (ya usadas en el Módulo 1 de esta guía, verificadas de nuevo para esta lección):

Hecho	Fuente
El agente reemplazó el `terraform.tfstate` activo con una versión vieja, extraída de un `.zip` archivado	Grigorev, relato primario
`terraform plan` mostró una lista larga de recursos como "a crear", no "a modificar" — la primera señal de que algo estaba mal	Grigorev: "My first clue that something was off was when I saw a long list of resources being created."
El humano preguntó por qué; el agente explicó que, según el `state` que tenía cargado, la infraestructura "no existía"	Grigorev: Claude respondió que "Terraform believed nothing existed"
El `apply` se detuvo, pero algunos recursos ya se habían creado parcialmente antes de detenerlo	Grigorev, relato primario
El agente propuso `terraform destroy` como la vía "más limpia" para revertir lo ya creado	Grigorev: "I cannot do it. I will do a `terraform destroy`. Since the resources were created through Terraform, destroying them through Terraform would be cleaner and simpler than through AWS CLI."
El humano no detuvo al agente	Grigorev: "So I didn't stop the agent from running `terraform destroy`."
`terraform destroy -auto-approve` se ejecutó, destruyendo VPC, clúster de ECS, balanceadores de carga, bastion host, la base de datos RDS y todos sus snapshots automáticos	Grigorev, relato primario; corroborado por Tom's Hardware e incidentdatabase.ai #1424
La tabla `courses_answer` (1.943.200 filas, 2,5 años de datos) desapareció con el resto de la infraestructura	Grigorev, relato primario
El autor abrió un ticket de soporte con AWS, actualizando a Business Support (~10% más de costo mensual)	Grigorev: "Around midnight, I opened a support ticket... I upgraded, which added about 10% to my cloud costs."
El soporte de AWS confirmó la existencia de un snapshot en sus propios sistemas, no visible en la consola del cliente	Grigorev: "They found a snapshot on their end that I couldn't see in my console."
Hubo una llamada telefónica y una escalación interna en AWS para gestionar la restauración	Grigorev, relato primario
Exactamente 24 horas después de que la base de datos fue borrada, AWS restauró el snapshot	Grigorev, cita textual: "Exactly 24 hours after the database had been deleted, AWS restored the snapshot."
El autor publicó el relato completo en público el 6 de marzo de 2026 —unos ocho días después del incidente—	Fecha de publicación del artículo, verificada

Paso 3 — El documento

En la raíz de andes-cargo-infra/, crea el directorio incidents/2026-02-26-claude-code-destroy/ y, dentro, TIMELINE.md:

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

**Status:** Draft (this document) -> completed in Module 6, lesson 8
**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.

## A note on timestamps

All timestamps in this document are **relative to T+0**, the moment `terraform destroy
-auto-approve` executed -- the clearest, most verifiable reference point in the entire incident.
The primary source gives only approximate clock times ("around 10 PM", "around midnight"); this
document never converts those into exact clock timestamps, which would fabricate a precision the
source itself does not have. Offsets marked `~` are inferred from the sequence the source
describes, not measured to the minute. The one offset that IS precise, stated verbatim by the
primary source: exactly 24 hours between T+0 and resolution.

## Timeline

| Offset | Event | Source |
|---|---|---|
| T-~1h | Deployment work begins: migrating a static site into the existing Terraform project (reusing it instead of a separate one, to save $5-10/month), without the correct state file -- it was on an old computer, never loaded | Grigorev |
| T-~15min | `terraform plan` output shows a long list of resources marked for **creation**, not modification -- first anomaly noticed | Grigorev: "My first clue that something was off..." |
| T-~10min | Human asks why; agent explains the loaded state file made it believe "nothing existed" | Grigorev: "Terraform believed nothing existed" |
| T-~10min | `apply` stopped -- but some resources had already been partially created before the stop | Grigorev |
| T-~5min | Agent proposes `terraform destroy` as the cleanest way to reverse what it had just created | Grigorev, verbatim quote in TIMELINE.md sources |
| T-~1min | Human does not stop the agent from proceeding | Grigorev: "So I didn't 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. | Grigorev; Tom's Hardware; incidentdatabase.ai #1424 |
| T+0 to T+~5min | Total outage, immediately and unambiguously visible -- every service down at once | Inferred directly from the scope of what T+0 destroyed |
| T+~1h | Support ticket opened with AWS; upgrade to Business Support tier (~+10% monthly cost) | Grigorev: "Around midnight, I opened a support ticket..." |
| T+~1h30min | AWS support confirms a snapshot exists on their end -- not visible in the customer console | Grigorev: "They found a snapshot on their end that I couldn't see in my console." |
| T+~2h to T+~3h | Phone call with AWS support; internal escalation within AWS for manual restoration | Grigorev |
| **T+24h00m** | **AWS restores the snapshot.** `courses_answer` restored intact, 1,943,200 rows confirmed. | Grigorev, verbatim: "Exactly 24 hours after the database had been deleted, AWS restored the snapshot." |
| (8 days after T+0) | Grigorev publishes the full incident writeup publicly | Publish date verified: Mar 06, 2026 |

## What this version does not include yet

Severity classification (Module 6, lesson 3), the declaration message and assigned roles (Module
6, lesson 4), and the mitigation decision tree (Module 6, lesson 6) are not part of this draft --
they are added, without changing any fact already established here, in the final version this
module's project (lesson 8) produces.

Paso 4 — Leyendo el timeline: lo que un solo minuto revela

Fíjate en una fila específica: T+0 to T+~5min, con la nota "impacto total, inmediato e inequívoco — cada servicio caído a la vez". Esta fila no viene de una cita textual con hora exacta —viene de una inferencia directa, explícitamente marcada como tal, sobre el alcance de lo que T+0 destruyó—. Si la VPC completa, el clúster de ECS y los balanceadores de carga desaparecen en el mismo comando, no hace falta ningún dato adicional para saber que el impacto fue inmediato y total: es una consecuencia lógica directa de qué se destruyó, no una medición independiente. Distinguir, con precisión, entre "esto es un hecho citado textualmente" y "esto es una inferencia razonable a partir de hechos citados" es exactamente la misma disciplina que este ecosistema completo exige desde cloud-security-and-guardrails-guide: nunca presentar una inferencia como si fuera una cita.

Errores comunes

Convertir las horas aproximadas de la fuente ("alrededor de las 10 PM") en timestamps exactos de reloj, "para que se vea más profesional" (de fabricar precisión falsa). Qué pasa: alguien, al copiar este documento, reemplaza T-~1h por una hora de reloj inventada como 21:00, asumiendo que un timeline "de verdad" necesita horas exactas. Cómo detectarlo: si tu versión de TIMELINE.md incluye algún timestamp de reloj (HH:MM) en cualquier fila. Cómo corregirlo: el Paso 1 de esta lección explicó la razón exacta — la fuente primaria nunca da una hora exacta, solo aproximaciones ("alrededor de"), y convertir una aproximación en un número exacto fabrica una precisión que no existe. Un timeline honesto usa ~ donde la fuente es aproximada, y nunca disfraza esa aproximación con un número que parece más preciso de lo que realmente es.

Tratar cada offset ~ de este documento como si tuviera la misma certeza que T+24h00m (de perder la jerarquía de confianza entre los hechos). Qué pasa: alguien cita "T+~1h: se abre el ticket de soporte" con la misma confianza que "T+24h00m: se restaura el snapshot", sin notar que el primero es una inferencia aproximada y el segundo es una cita textual verificada. Cómo detectarlo: si tu resumen del incidente no distingue entre los hechos con cita textual exacta y los hechos con offset aproximado. Cómo corregirlo: el propio documento marca esta diferencia con el símbolo ~ — dos filas de este timeline, T+0 y T+24h00m, son las únicas con una fuente que da una duración exacta y verificada (el comando que ejecuta, y la cita textual de "exactly 24 hours"); todo lo demás es una reconstrucción razonable, no una medición exacta, y el documento lo señala así a propósito.

Reescribir el orden de los hechos para que la historia "fluya mejor", sin verificar que el orden reconstruido coincide con la fuente (de narrar en vez de reconstruir). Qué pasa: alguien reorganiza el timeline para que, por ejemplo, la advertencia de Claude Code aparezca justo antes del destroy, sin confirmar contra la fuente si esa fue realmente la secuencia exacta. Cómo detectarlo: si tu timeline no puede señalar, fila por fila, qué cita o qué inferencia razonable respalda ese orden específico. Cómo corregirlo: cada fila de la tabla del Paso 3 tiene una columna "Source" — antes de mover cualquier fila, confirma que el orden que estás construyendo sigue la secuencia real que Grigorev describe, no una versión reordenada por conveniencia narrativa. El valor de un timeline reconstruido depende, por completo, de que sea trazable hasta la fuente, no de que se lea bien.

Ejercicios

Ejercicio 1 — Usando solo la tabla de hechos del Paso 2, calcula cuántos minutos aproximados transcurrieron entre la primera anomalía notada (terraform plan mostrando creaciones) y la ejecución del destroy. Explica por qué tu respuesta debe llevar el símbolo ~.

Ver solución

Según el timeline del Paso 3, la primera anomalía se marca en T-~15min y el destroy en T+0 — una diferencia aproximada de 15 minutos. La respuesta debe llevar ~ porque ninguno de los dos puntos tiene un timestamp exacto de reloj en la fuente primaria: ambos son inferencias razonables sobre la secuencia narrada por Grigorev, no mediciones directas. Presentar "15 minutos exactos" sin el símbolo ~ implicaría una precisión que ni la fuente ni esta reconstrucción realmente tienen — exactamente el error que la primera entrada de "Errores comunes" de esta lección advierte.

Ejercicio 2 — Explica por qué T+0 se define como el momento en que terraform destroy -auto-approve se ejecuta, y no, por ejemplo, el momento en que el humano decidió "no detener al agente". ¿Qué hace que el primer punto sea una mejor referencia que el segundo?

Ver solución

terraform destroy -auto-approve es un evento técnico discreto y verificable: un comando específico que se ejecutó, con un resultado observable y documentado (la infraestructura destruida). "El momento en que el humano decidió no detener al agente", en cambio, es un evento interno, sin ningún artefacto técnico que lo marque con precisión — no hay ningún log, ningún timestamp de sistema, que capture exactamente cuándo terminó esa decisión y empezó la ejecución del comando. Usar el evento técnico verificable como T+0 da al resto del timeline un punto de referencia sólido, del mismo tipo que un sistema real usaría (el momento en que un comando destructivo se ejecutó, no el momento en que alguien "decidió" algo, que rara vez deja rastro técnico).

Ejercicio 3 — Un compañero argumenta que este timeline "no sirve para nada real" porque no tiene horas de reloj exactas, y que un Incident Commander de verdad necesitaría saber la hora exacta para coordinar con otros equipos. ¿Estás de acuerdo? Usa el argumento del Paso 1 de esta lección.

Ver solución

En desacuerdo, con un matiz importante. Un Incident Commander respondiendo a un incidente en curso, en tiempo real, sí necesita coordinarse con hora de reloj (para acordar cuándo hacer la siguiente llamada, por ejemplo) — pero ese no es el caso de este documento: este TIMELINE.md se construye después del incidente, como reconstrucción histórica para fines de aprendizaje y portafolio, no como el documento de coordinación en vivo que el propio Incident Commander mantendría mientras el incidente ocurre. Para ese propósito retrospectivo, lo que importa no es la hora exacta del reloj —que, de todas formas, esta lección ya estableció que la fuente primaria nunca dio con precisión— sino la secuencia relativa correcta y la duración total verificada (T+24h00m, la cifra más importante de todo el documento). Un timeline retrospectivo honesto sobre lo que sabe con certeza es más útil que uno que finge una precisión de reloj que nunca existió.

Resumen y siguiente paso

En esta lección construiste la primera versión de incidents/2026-02-26-claude-code-destroy/TIMELINE.md: catorce hechos verificados contra la fuente primaria de Grigorev, corroborados por Hacker News e incidentdatabase.ai #1424, ordenados con marcas de tiempo relativas a T+0 —el momento en que terraform destroy -auto-approve se ejecutó— en vez de cualquier hora de reloj real, que la propia fuente nunca dio con precisión. Confirmaste el único punto de referencia genuinamente exacto de todo el incidente: exactamente 24 horas entre la pérdida de datos y la restauración completa.

Antes de avanzar deberías poder: explicar por qué este timeline usa T+0 en vez de un reloj real; distinguir, en la tabla del Paso 3, qué filas son citas textuales y cuáles son inferencias razonables; y recitar de memoria la secuencia completa, de T-~1h a T+24h00m.

La lección 3 toma este mismo timeline y le hace la pregunta que la matriz de severidad de INCIDENT-RESPONSE-PLAN.md (Módulo 5) ya sabe contestar: ¿qué tan grave fue esto?

Recursos

Alexey Grigorev — How I Dropped Our Production Database — fuente primaria de cada hecho de esta lección.
Hacker News — hilo original del incidente (#47278720) — corroboración pública independiente.
incidentdatabase.ai — Incident 1424 — registro estructurado independiente, citado ya en el Módulo 1 de esta guía.
Google SRE — Incident Management Guide — el marco de fases (preparar, responder, aprender) que este timeline empieza a poblar.
Este mismo repositorio, Módulo 1, lección 5 (05-two-real-incidents-two-different-questions.md) — la narración original del incidente que esta lección reformatea, sin repetir, como timeline formal.

← Anterior1. Introducción: operar, no volver a narrar Siguiente →3. Manos a la obra: clasificando la severidad