Módulo 6: Operating The Claude Code Incident
6. Manos a la obra: el árbol de decisión de mitigación
Descripción
El incidente ya está declarado (lección 4), con roles asignados. Esta lección reconstruye la parte más técnica de las 24 horas reales: el camino de decisiones que llevó de "toda la infraestructura destruida, sin ningún camino de recuperación visible" a "1.943.200 filas restauradas, íntegras". No es una lista lineal de pasos —es un árbol de decisión real, con bifurcaciones donde una respuesta distinta hubiera llevado a un camino distinto—, mapeado, etapa por etapa, contra las cinco fases del ciclo de vida que el Módulo 5, lección 2 ya citó de Google SRE.
Conexión con el módulo
La lección 2 de este módulo construyó TIMELINE.md con los hechos en orden cronológico. Esta lección no repite esos hechos — los reorganiza como un árbol de decisión, la forma que de verdad importa cuando alguien se pregunta "¿y si algo hubiera sido distinto?". El árbol que esta lección construye se integra, sin cambiar ningún hecho ya establecido, a la versión final de TIMELINE.md que la lección 8 (proyecto de este módulo) entrega.
Paso 1 — Por qué un árbol, y no solo una lista de pasos
Una lista cronológica —lo que TIMELINE.md ya tiene— responde "¿qué pasó, en qué orden?". Un árbol de decisión responde una pregunta distinta y más útil para aprender del caso: "¿en qué punto exacto había una alternativa real, y qué hizo que la respuesta tomara el camino que tomó?". La mitigación de este incidente no fue una ejecución lineal de un plan preexistente —no había ningún runbook escrito para "recuperar una infraestructura completa después de un destroy accidental"—, fue una serie de decisiones bajo incertidumbre, cada una condicionada por el resultado de la anterior. Reconstruir esas bifurcaciones, no solo la secuencia final, es lo que un árbol de decisión aporta que una lista cronológica no puede.
Paso 2 — El árbol completo
ARBOL DE DECISION DE MITIGACION -- INCIDENTE CLAUDE CODE DESTROY
T+0: destroy ejecuta -- VPC, ECS, load balancers, bastion host,
RDS + snapshots automaticos, todos destruidos
│
▼
¿Existe algo que revertir con el propio Terraform state?
│
┌───────────────┴───────────────┐
NO (no aplica: el state
│ mismo fue la causa,
│ y la infra ya no existe)
▼
¿Hay un snapshot automatico RDS visible
en la consola propia de AWS?
│
┌───────────────┴───────────────┐
NO -- los snapshots (los snapshots
automaticos tambien fueron automaticos NO
destruidos junto con la DB sobreviven un
│ destroy de RDS
│ sin proteccion)
▼
DECISION: escalar mas alla de self-service
(T+~1h -- abrir ticket, actualizar a
AWS Business Support, ~+10% costo mensual)
│
▼
¿AWS confirma algun mecanismo de
recuperacion del lado de ellos?
│
┌───────────────┴───────────────┐
SI (T+~1h30min) -- un snapshot (si la respuesta
interno, NO visible en la hubiera sido "no",
consola del cliente no habria ningun
│ camino de
│ recuperacion --
│ el peor desenlace
│ posible de este
│ incidente)
▼
DECISION: escalar la restauracion
(T+~2h a T+~3h -- llamada telefonica,
escalacion interna dentro de AWS)
│
▼
Esperar a que el equipo interno de AWS
ejecute la restauracion -- fuera del
control directo de DataTalks.Club
desde este punto en adelante
│
▼
T+24h00m: snapshot restaurado.
VERIFICACION: courses_answer, 1.943.200
filas, confirmadas integras
│
▼
INCIDENTE RESUELTOPaso 3 — El árbol, mapeado contra las cinco etapas del Módulo 5
| Etapa (Módulo 5, lección 2) | Dónde encaja en este árbol |
|---|---|
| Detección | Inmediata y total desde T+0 — cada rama del árbol empieza después de que la detección ya ocurrió (lección 3 de este módulo). |
| Declaración | T+~5min — la declaración formal (lección 4 de este módulo) ocurre antes de que el árbol de decisión de mitigación empiece a ramificarse. |
| Respuesta | Los dos primeros nodos del árbol ("¿existe algo que revertir?", "¿hay un snapshot visible en la consola propia?") — la fase donde el equipo coordina qué opciones propias existen, antes de escalar fuera de su control directo. |
| Mitigación | Desde la primera decisión de escalar (T+~1h, abrir ticket con AWS) hasta la confirmación del snapshot interno (T+~1h30min) y la escalación telefónica (T+~2h a T+~3h) — el trabajo activo de limitar el daño y buscar un camino de restauración, sin que la causa raíz completa esté todavía resuelta. |
| Resolución | T+24h00m — el snapshot restaurado y verificado íntegro; la condición que disparó el incidente (datos perdidos, sin camino de recuperación conocido) deja de estar activa. |
Fíjate en un detalle honesto que este mapeo revela: la fase de "Mitigación" de este incidente no fue, en ningún punto, una acción técnica que el propio equipo ejecutó con sus propias manos —a diferencia del ejemplo hipotético del Módulo 5, lección 2 (revertir un despliegue roto de process-shipment-manifest)—. Toda la mitigación real de este incidente consistió en escalar —pedir ayuda fuera del control directo del equipo— y esperar, porque las herramientas propias (el state, la consola de AWS, cualquier snapshot visible del lado del cliente) ya se habían agotado por completo en los dos primeros nodos del árbol.
Paso 4 — La bifurcación que de verdad importó
De las cuatro decisiones marcadas en el árbol del Paso 2, una sola determinó si este incidente terminaba en una recuperación completa o en una pérdida permanente de 2,5 años de datos: la confirmación de AWS, en T+~1h30min, de que existía un snapshot en su lado, invisible desde la consola del cliente. Las otras tres decisiones —revertir con Terraform (no, no aplica), buscar un snapshot propio (no, destruido), escalar a soporte (sí, decisión tomada)— tenían un solo camino razonable cada una, dado el estado del sistema. Esta, en cambio, era genuinamente incierta hasta que AWS respondió: si la respuesta hubiera sido "no, no hay ningún snapshot recuperable de ningún lado", el árbol completo hubiera terminado ahí, sin ningún camino hacia la resolución.
Esto es, honestamente, el punto más importante que este árbol revela sobre el propio incidente: la recuperación de DataTalks.Club dependió de un mecanismo de retención de snapshots del lado de AWS que ni el propio afectado sabía que existía, y que no estaba garantizado por ninguna configuración explícita que él hubiera activado. No fue el resultado de una salvaguarda diseñada por el equipo —esas salvaguardas (deletion protection, snapshots gestionados explícitamente) son, precisamente, las que Grigorev implementó después del incidente, como parte de sus medidas preventivas—. Fue, en gran medida, buena fortuna operativa combinada con la persistencia de escalar hasta encontrarla.
Errores comunes
Presentar este árbol como si el camino hacia la resolución hubiera sido obvio o garantizado desde el principio (de perder la incertidumbre real que el Paso 4 describe). Qué pasa: alguien lee el árbol completo, del inicio al final, y concluye que "la recuperación siempre iba a funcionar", porque en retrospectiva conoce el desenlace. Cómo detectarlo: si tu descripción del árbol trata el nodo de "¿AWS confirma algún mecanismo de recuperación?" como una formalidad, en vez de como el punto genuino de mayor incertidumbre. Cómo corregirlo: el Paso 4 de esta lección es explícito — hasta que AWS respondió, en T+~1h30min, no había ninguna garantía de que existiera ningún camino de recuperación. Tratar el desenlace favorable como "esperado desde el principio" es un sesgo retrospectivo real (hindsight bias), exactamente el tipo de distorsión que un postmortem sin culpa (Módulo 7) debe evitar al reconstruir cualquier incidente.
Confundir "mitigación" con "una acción técnica que el equipo ejecuta con sus propias manos", después de ver que este incidente rompe ese patrón (de generalizar mal a partir de un solo caso). Qué pasa: alguien concluye, después de esta lección, que "mitigar" siempre significa escalar y esperar, en vez de aplicar un cambio técnico directo. Cómo detectarlo: si tu definición general de "mitigación", después de esta lección, ya no incluye el ejemplo estándar del Módulo 5 (revertir un despliegue roto). Cómo corregirlo: el Paso 3 de esta lección señaló, explícitamente, que este incidente es un caso donde la mitigación consistió en escalar y esperar — no porque esa sea la definición general de mitigación, sino porque las herramientas propias del equipo ya se habían agotado. La mitigación de process-shipment-manifest con un despliegue roto (el ejemplo del Módulo 5, lección 2) sí es una acción técnica directa; ambos casos son mitigación, con mecanismos completamente distintos según qué opciones sigan disponibles.
Asumir que, porque AWS tenía un snapshot interno no listado en consola, cualquier incidente similar en el futuro tendría la misma red de seguridad (de generalizar una circunstancia específica como una garantía). Qué pasa: alguien concluye que "AWS siempre tiene un snapshot de respaldo interno, así que un destroy accidental nunca es realmente catastrófico". Cómo detectarlo: si tu plan de recuperación ante desastres depende, implícita o explícitamente, de que AWS tenga algún mecanismo interno no documentado que rescate los datos. Cómo corregirlo: el Paso 4 de esta lección fue explícito en que este mecanismo no estaba garantizado por ninguna configuración explícita. Confiar en la posibilidad de que exista un mecanismo similar, sin activarlo explícitamente (deletion protection, backups propios con versionado, point-in-time recovery), es exactamente el error que las medidas preventivas que Grigorev adoptó después del incidente —citadas en el Módulo 1 de esta guía— existen para corregir. El propio Módulo 7 de esta guía (07-hands-on-the-honest-backup-restore-attempt.md) construye, con LocalStack, un intento real de backup/restore explícito de DynamoDB para Andes Cargo — precisamente para no depender de la misma suerte.
Ejercicios
Ejercicio 1 — Usando el árbol del Paso 2, identifica el nodo donde el incidente hubiera podido resultar en una pérdida permanente de datos, sin ninguna posibilidad de recuperación. Explica qué condición, si hubiera sido distinta, habría cambiado ese resultado.
Ver solución
El nodo crítico es "¿AWS confirma algún mecanismo de recuperación del lado de ellos?" (T+~1h30min). Si la respuesta hubiera sido "no" —si el snapshot interno no listado en consola simplemente no hubiera existido, o si las políticas de retención de AWS lo hubieran purgado ya para ese momento—, el árbol completo habría terminado ahí, sin ningún camino restante hacia la resolución: no había ningún otro nodo de decisión pendiente que ofreciera una alternativa. La condición que determinó el resultado no fue ninguna decisión tomada por el equipo de DataTalks.Club — fue la existencia, fuera de su control y conocimiento, de ese mecanismo interno específico de AWS.
Ejercicio 2 — Explica, usando el Paso 3, por qué la fase de "Respuesta" de este incidente terminó tan rápido —solo dos nodos del árbol— comparada con la fase de "Mitigación".
Ver solución
La fase de "Respuesta", según la definición del Módulo 5, es sobre coordinación —qué opciones propias existen y quién las evalúa—, y en este incidente esas opciones se agotaron casi de inmediato: no había ningún state de Terraform que revertir (la infraestructura ya no existía), y no había ningún snapshot visible en la consola propia (destruido junto con la base de datos). Con ambas opciones propias descartadas en minutos, no quedaba ningún trabajo de coordinación interna adicional que hacer — el único camino restante era escalar fuera del control directo del equipo, que es exactamente donde empieza la fase de "Mitigación" de este árbol. La brevedad de la fase de Respuesta no refleja un equipo desorganizado — refleja cuán rápido se agotaron las opciones propias en un incidente de esta magnitud.
Ejercicio 3 — Un colega argumenta que este árbol de decisión "no sirve para nada práctico", porque cada nodo describe una decisión que ya no se puede repetir de la misma forma (AWS podría no tener el mismo mecanismo interno la próxima vez). ¿Cómo respondes, usando el Paso 4 y la última entrada de "Errores comunes" de esta lección?
Ver solución
El valor de este árbol no está en que sus nodos específicos (el snapshot interno de AWS) se puedan repetir de forma confiable — el Paso 4 y la última entrada de "Errores comunes" ya establecieron que ese mecanismo específico no estaba garantizado. El valor real está en la estructura de decisión que revela: agotar primero las opciones propias verificables (Terraform, consola propia), escalar rápido y sin demora una vez agotadas, y no asumir que la ayuda externa llegará a tiempo o de la forma que llegó esta vez. Esa estructura —agotar, escalar, verificar, nunca asumir— es la parte reutilizable, no el mecanismo específico de AWS que resolvió este caso en particular. Es la misma razón por la que el Módulo 7 de esta guía construye un intento explícito de backup/restore para Andes Cargo, en vez de asumir que un mecanismo similar al de este incidente estaría disponible si algo parecido volviera a pasar.
Resumen y siguiente paso
Esta lección reconstruyó el árbol de decisión completo de la mitigación real del incidente Claude Code: dos opciones propias agotadas en minutos (revertir con Terraform, buscar un snapshot visible), la decisión de escalar a soporte de AWS (T+~1h), la confirmación crítica e incierta de un snapshot interno no listado en consola (T+~1h30min), la escalación telefónica (T+~2h a T+~3h), y la espera hasta la resolución verificada (T+24h00m). Mapeaste cada nodo contra las cinco etapas del Módulo 5, y confirmaste una honestidad incómoda: la mitigación de este incidente no fue una acción técnica propia — fue escalar y esperar, porque las herramientas propias ya se habían agotado, y el desenlace favorable dependió de un mecanismo interno de AWS que nadie del lado de DataTalks.Club sabía que existía.
Antes de avanzar deberías poder: recitar el árbol completo, de memoria, en orden; identificar el nodo de mayor incertidumbre real; y explicar por qué este incidente no es un buen ejemplo del patrón estándar de mitigación técnica directa.
La lección 7 vuelve al vocabulario formal de esta guía: el mismo cálculo de 33,3x del Módulo 1, ahora corrido con error_budget_calculator.py real —el vocabulario completo de SLI, SLO y error budget detrás del número.
Recursos
- Alexey Grigorev — How I Dropped Our Production Database — fuente primaria de cada nodo de este árbol.
- Este mismo repositorio, Módulo 5, lección 2 (
02-the-incident-lifecycle.md) — las cinco etapas contra las que este árbol se mapea. - Este mismo repositorio, Módulo 6, lección 2 (
02-hands-on-reconstructing-the-exact-timeline.md) —TIMELINE.md, la fuente cronológica que este árbol reorganiza como decisiones. - Google SRE Book — Managing Incidents — la definición de mitigación citada en el Módulo 5, aplicada aquí a un caso donde la mitigación fue escalar, no ejecutar.