Módulo 6: Operating The Claude Code Incident

1. Introducción: operar, no volver a narrar

Descripción

Si llegaste hasta aquí siguiendo el ecosistema completo, esto ya es la cuarta vez que te encuentras con el mismo incidente: un agente de Claude Code corrió terraform destroy -auto-approve contra la infraestructura de producción de DataTalks.Club, con un state desactualizado como referencia, y borró 2,5 años de datos —la tabla courses_answer, con 1.943.200 filas, entre ellos—. terraform-and-iac-guide lo narró como una lección sobre leer el plan completo. cloud-security-and-guardrails-guide lo narró como una lección sobre controles automatizados (conftest, prevent_destroy) que no dependen de la atención humana. El Módulo 1 de esta misma guía lo retomó una tercera vez, con el vocabulario nuevo de error budget, y calculó que las ~24 horas de recuperación consumieron 33,3 veces el presupuesto mensual completo de un SLO hipotético de 99,9%.

Este módulo no lo narra una quinta vez. Lo opera. La diferencia es completa, no de matiz: las lecciones 2 a 8 de este módulo no vuelven a contar qué pasó — toman el marco completo que el Módulo 5 acaba de terminar (INCIDENT-RESPONSE-PLAN.md: el ciclo de vida de cinco etapas, la matriz de severidad atada a burn rate, los tres roles, la rotación de guardia) y lo corren, paso por paso, contra este incidente real, exactamente como lo correrías contra cualquier incidente nuevo que le tocara resolver a Andes Cargo. El resultado no es una narración más completa — es una serie de documentos ejecutables: un TIMELINE.md con marcas de tiempo relativas, una clasificación de severidad con la aritmética a la vista, un mensaje de declaración con roles asignados, un árbol de decisión de mitigación mapeado contra el ciclo de vida, y un recálculo del error budget con la calculadora real, no con un script de un solo uso.

Conexión con el módulo

Todo lo que este módulo necesita ya existe, construido en los cinco módulos anteriores: SLO.md (Módulo 2) define el presupuesto de error contra el que la lección 7 mide el incidente; ALERTING-POLICY.md (Módulo 4) define los umbrales de burn rate que la matriz de severidad ya usa; INCIDENT-RESPONSE-PLAN.md (Módulo 5) define el ciclo de vida, la matriz de severidad, los roles y la rotación de guardia que las lecciones 2 a 6 de este módulo aplican, sin modificar ni una sola cifra. Este módulo no declara ningún recurso HCL nuevo, no corre ningún comando nuevo de LocalStack, no construye ninguna pieza de infraestructura — construye documentos operativos, el mismo tipo de artefacto que un incidente real de cualquier empresa produce mientras ocurre: un timeline, una declaración, un registro de decisiones de mitigación. El Módulo 7 toma el TIMELINE.md que este módulo termina y escribe, sobre él, el postmortem sin culpa completo — la pregunta de "por qué pasó" que este módulo, deliberadamente, no contesta todavía.

La analogía: un simulacro de incendio, con un incendio real ya documentado

Un cuerpo de bomberos entrena con simulacros — un edificio vacío, humo artificial, una situación diseñada para practicar el protocolo sin el riesgo real. Pero hay un segundo tipo de entrenamiento, más valioso todavía, que casi ningún cuerpo de bomberos se puede dar el lujo de tener: un incendio real, ya ocurrido, ya documentado con precisión forense completa —dónde empezó, qué tan rápido se propagó, qué decisiones tomó cada persona involucrada, cuánto tardó en controlarse—, que un equipo nuevo puede correr a través de su propio protocolo actual, paso por paso, como si estuviera ocurriendo ahora mismo. No hay ningún riesgo real —el incendio ya terminó, hace meses—, pero tampoco hay ninguna de las simplificaciones artificiales de un simulacro inventado: los hechos son reales, verificados, con una fuente primaria que cualquiera puede consultar.

Eso es exactamente lo que este módulo hace. El incidente Claude Code ya ocurrió, ya está completamente documentado —por la propia persona afectada, por una base de datos independiente de incidentes de IA, por cobertura técnica verificada—, y las cifras no admiten ambigüedad: 2,5 años de datos, 1.943.200 filas, 24 horas exactas de recuperación. Este módulo toma ese incendio real y lo corre contra el protocolo actual de Andes Cargo —INCIDENT-RESPONSE-PLAN.md, terminado en el Módulo 5— exactamente como correrías cualquier incidente nuevo: se detecta, se declara, se le asigna una severidad, se le asignan roles, se mitiga, se resuelve. La diferencia con un incidente nuevo es solo una: ya sabes cómo termina. Eso no le resta valor al ejercicio — le permite concentrarse por completo en si el protocolo mismo funciona, sin la incertidumbre adicional de un desenlace desconocido.

   DOS TIPOS DE ENTRENAMIENTO — Y POR QUE ESTE MODULO USA EL SEGUNDO

   SIMULACRO INVENTADO                    INCENDIO REAL, YA DOCUMENTADO
   ────────────────────                    ──────────────────────────────
   Escenario disenado a mano,              El incidente Claude Code destroy,
   sin datos reales de respaldo             con fuente primaria verificada
        │                                        │
        ▼                                        ▼
   Practica el protocolo en                Practica el protocolo EXACTO
   condiciones controladas,                contra hechos que ya ocurrieron,
   pero sin la textura real                con la textura completa de un
   de un evento real                        caso real (y sus zonas grises)
        │                                        │
        ▼                                        ▼
   Util para entrenar reflejos              Util para VALIDAR que el marco
   basicos                                  que ya construiste (Modulo 5)
                                             de verdad resuelve un caso real

Qué vas a construir en este módulo

Ocho lecciones, cada una un paso concreto del mismo recorrido — de la reconstrucción de los hechos hasta el documento final de portafolio que el Módulo 7 va a citar:

#	Lección	Qué produce
1	Esta introducción	El mapa completo del módulo, y por qué "operar" es distinto de "narrar"
2	Reconstruyendo el timeline exacto	`incidents/2026-02-26-claude-code-destroy/TIMELINE.md` — primera versión, hechos verificados, marcas relativas (`T+0`)
3	Clasificando la severidad	SEV1, con la aritmética (o la falta de ella) que lo justifica
4	Declarando el incidente	El mensaje de declaración, con roles asignados de `INCIDENT-RESPONSE-PLAN.md`
5	Comunicación interna frente a externa	Qué se comunicó en público de verdad, frente a qué debió comunicarse internamente primero
6	El árbol de decisión de mitigación	El mecanismo real de recuperación, mapeado contra las cinco etapas del Módulo 5
7	El error budget de este incidente, con el vocabulario completo	El mismo 33,3x del Módulo 1, ahora con `error_budget_calculator.py` real
8	Proyecto: el `TIMELINE.md` final	El documento completo — timeline + severidad + roles + mitigación, integrados

Cada lección corre una etapa distinta del ciclo de vida de cinco pasos que el Módulo 5 ya citó de Google SRE (detección → declaración → respuesta → mitigación → resolución), en el mismo orden en que ese ciclo ocurre de verdad:

   EL CICLO DE VIDA DEL MODULO 5, APLICADO AL INCIDENTE REAL

   DETECCION          DECLARACION         RESPUESTA           MITIGACION         RESOLUCION
   (Leccion 2,        (Leccion 4)         (Lecciones 4-5,     (Leccion 6)        (Lecciones 2, 6)
    parte del                              roles + cadencia
    timeline)                              de comunicacion)

   T+0: destroy        T+~5min:            Ana (IC+CL),        El arbol de        T+24h00m:
   ejecuta -- el       "esto es SEV1,      Bruno (OL)          decision real:      snapshot
   sistema entero      declarado"          coordinan la        self-service        restaurado,
   deja de responder                       respuesta            fallido -->         1.943.200
                                                                soporte AWS -->     filas intactas
                                                                snapshot interno

Por qué este módulo NO vuelve a narrar el incidente (y qué SÍ hace en su lugar)

Vale la pena ser preciso sobre la diferencia, porque es fácil confundir "operar" con "contar la historia con más detalle". No es eso. Las tres guías hermanas que ya usaron este caso —terraform-and-iac-guide, cicd-and-gitops-on-aws-guide, cloud-security-and-guardrails-guide— y el propio Módulo 1 de esta guía ya establecieron, con precisión completa, qué pasó: quién lo hizo, con qué comando, sobre qué infraestructura, con qué resultado exacto. Ese trabajo no se repite aquí.

Lo que este módulo agrega es una pregunta completamente distinta: si Andes Cargo tuviera que operar este mismo incidente hoy, con el marco que el Módulo 5 acaba de terminar, ¿qué produciría, paso por paso? No es una pregunta retórica — cada lección de este módulo produce el documento real que esa pregunta exige: un timeline formal, una clasificación de severidad con la matriz exacta de INCIDENT-RESPONSE-PLAN.md, un mensaje de declaración con roles asignados de la rotación real del Módulo 5, un árbol de decisión que documenta cada bifurcación de la respuesta real de 24 horas. Es la diferencia entre leer sobre un incendio y correr, con el cronómetro real corriendo, el protocolo completo de tu propio cuerpo de bomberos contra los hechos de ese incendio.

Una honestidad que hay que dejar clara desde esta primera lección: el incidente Claude Code le ocurrió a DataTalks.Club, no a Andes Cargo. Andes Cargo es un proyecto ficticio de este ecosistema; DataTalks.Club es una plataforma real, con datos reales, afectada por un incidente real. Este módulo no pretende que el incidente "le pasó" a Andes Cargo — toma los hechos verificados de un caso real y externo, y los corre a través de la maquinaria operativa de Andes Cargo como ejercicio deliberado, exactamente el mismo tipo de ejercicio que cualquier equipo de SRE real hace cuando estudia el postmortem público de otra empresa para poner a prueba su propio protocolo. Cada lección de este módulo, donde haga falta, marca con precisión esta frontera —qué es un hecho verificado del incidente real, y qué es una decisión de diseño de este ejercicio (como qué persona de la rotación de Andes Cargo asumió cada rol)—.

Errores comunes

Esperar que este módulo revele un dato nuevo sobre el incidente que las tres guías hermanas no mencionaron (de expectativa mal dirigida). Qué pasa: alguien llega a este módulo buscando una cifra distinta, una causa raíz alternativa, o algún ángulo que contradiga lo que ya se estableció en terraform-and-iac-guide o cloud-security-and-guardrails-guide. Cómo detectarlo: si tu lectura de este módulo busca "qué hay de nuevo sobre qué pasó" en vez de "qué hay de nuevo sobre cómo se opera". Cómo corregirlo: las cifras centrales —2,5 años, 1.943.200 filas, 24 horas exactas, 26 de febrero de 2026— son las mismas en las cuatro guías, porque son hechos verificados contra la misma fuente primaria, no una narración que varía. Lo nuevo de este módulo nunca es un hecho adicional sobre el incidente — es el proceso operativo completo que corre sobre esos mismos hechos.

Tratar el ejercicio de este módulo como si el incidente literalmente le hubiera ocurrido a Andes Cargo (de perder la frontera entre caso real y ejercicio). Qué pasa: alguien, en una conversación técnica o una entrevista, describe el incidente Claude Code como "algo que le pasó a Andes Cargo", en vez de a DataTalks.Club. Cómo detectarlo: si tu resumen del módulo dice "Andes Cargo sufrió un incidente donde..." en vez de "operamos, con el marco de Andes Cargo, un incidente real que le ocurrió a DataTalks.Club". Cómo corregirlo: esta lección lo dejó explícito — Andes Cargo es el proyecto ficticio de este ecosistema; DataTalks.Club es la empresa real afectada. El valor del ejercicio no depende de que el incidente le haya pasado a Andes Cargo, depende de que los hechos sean reales y verificables, y de que el marco que se les aplica (INCIDENT-RESPONSE-PLAN.md) también lo sea.

Asumir que "operar" significa reescribir el desenlace, o imaginar cómo Andes Cargo lo hubiera evitado (de confundir este módulo con el de prevención). Qué pasa: alguien empieza a diseñar controles preventivos nuevos —un prevent_destroy adicional, una política de conftest distinta— como si ese fuera el trabajo de este módulo. Cómo detectarlo: si tu entregable de alguna lección de este módulo es una regla de seguridad nueva, en vez de un documento de respuesta a incidentes. Cómo corregirlo: la prevención ya se resolvió, en otra guía —cloud-security-and-guardrails-guide, con conftest y prevent_destroy—, y esta guía, desde RELIABILITY-CHARTER.md en el Módulo 1, ya estableció que un error budget "es un mecanismo de medición, nunca un control preventivo". Este módulo asume que la prevención ya falló —el destroy ya se ejecutó— y construye la disciplina de respuesta, no de prevención: qué se hace, en qué orden, con qué roles, una vez que algo ya se rompió.

Ejercicios

Ejercicio 1 — En tus propias palabras, explica la diferencia entre "narrar" y "operar" un incidente, usando el ejemplo concreto de este módulo. ¿Qué produciría una narración del incidente Claude Code que una operación del mismo incidente no produciría, y viceversa?

Ver solución

Una narración produce una historia completa y precisa de qué pasó —el detalle técnico de cómo el state desactualizado engañó al agente, la secuencia exacta de comandos, las cifras del daño— optimizada para que quien la lee entienda la magnitud y la causa del incidente. Una operación, en cambio, no necesita repetir esa historia con más detalle (ya existe, en tres guías hermanas) — produce los documentos que un equipo real generaría mientras responde al incidente: un timeline con marcas de tiempo, un mensaje de declaración con roles asignados, un registro de las decisiones de mitigación en el orden en que se tomaron. La narración responde "¿qué pasó?"; la operación responde "¿qué haría, paso por paso, un equipo con un protocolo real, si tuviera que responder a esto?". Este módulo, deliberadamente, no repite la narración — asume que ya la conoces, de las tres guías hermanas y del Módulo 1 de esta guía, y se concentra por completo en la segunda pregunta.

Ejercicio 2 — Explica por qué la analogía del simulacro con un incendio real, en vez de un simulacro inventado, es más precisa para describir este módulo que una analogía de "practicar con un caso de estudio genérico". ¿Qué propiedad específica del incidente Claude Code hace que esta analogía funcione mejor que un ejemplo hipotético?

Ver solución

Un caso de estudio genérico o inventado permite ajustar los hechos a voluntad para que el ejercicio "salga bien" — se puede simplificar cualquier detalle incómodo, omitir cualquier zona gris, y el resultado es, casi por diseño, más limpio de lo que un incidente real jamás es. El incidente Claude Code, en cambio, tiene la textura completa de un evento real: una decisión humana de continuar a pesar de una advertencia explícita del propio agente, una secuencia de eventos que no siguió el guion más "educativo" posible, y un desenlace que dependió de un mecanismo de recuperación (un snapshot interno no listado en consola) que ningún caso inventado incluiría por accidente. Correr el protocolo de Andes Cargo contra hechos reales, con toda su textura, es una prueba mucho más honesta de si ese protocolo funciona que correrlo contra un caso diseñado para que funcione bien.

Ejercicio 3 — RELIABILITY-CHARTER.md (Módulo 1) estableció que un error budget "es un mecanismo de medición, nunca un control preventivo". Explica por qué ese mismo principio es la razón por la que este módulo no intenta rediseñar ninguna salvaguarda preventiva.

Ver solución

Si un error budget mide el daño después de que ocurrió, en vez de prevenirlo, entonces todo el marco de respuesta a incidentes que este módulo opera —ciclo de vida, severidad, roles, mitigación— hereda la misma naturaleza: existe para responder bien después de que algo ya falló, no para evitar que falle en primer lugar. Rediseñar una salvaguarda preventiva (un prevent_destroy nuevo, una política de conftest adicional) sería trabajo legítimo, pero pertenece a una disciplina distinta —la que cloud-security-and-guardrails-guide ya construyó— y mezclarlo con este módulo diluiría la pregunta específica que este módulo contesta: dado que el destroy ya se ejecutó, sin ninguna posibilidad de deshacerlo con una salvaguarda, ¿qué hace un equipo bien preparado en las siguientes 24 horas? Esa es una pregunta de respuesta, no de prevención, y este módulo la sostiene sin desviarse.

Resumen y siguiente paso

Esta lección estableció la diferencia central de todo el módulo: operar un incidente ya conocido significa correr el marco completo de INCIDENT-RESPONSE-PLAN.md (Módulo 5) contra sus hechos verificados, produciendo documentos operativos reales —no repetir, una quinta vez, la narración que tres guías hermanas y el Módulo 1 de esta guía ya construyeron—. Viste el mapa completo de las ocho lecciones, cada una un paso del ciclo de vida de cinco etapas de Google SRE aplicado, en orden, al incidente Claude Code real; y la honestidad que sostiene todo el módulo: el incidente le ocurrió a DataTalks.Club, no a Andes Cargo, y este módulo es un ejercicio deliberado de correr hechos reales a través de un marco real, no una ficción de que le pasó a un proyecto ficticio.

Antes de avanzar deberías poder: explicar, con tus propias palabras, la diferencia entre narrar y operar un incidente; nombrar las cinco etapas del ciclo de vida que este módulo va a recorrer, en orden; y explicar por qué este módulo no rediseña ninguna salvaguarda preventiva.

La lección 2 empieza el recorrido con el primer documento real de este módulo: TIMELINE.md, reconstruido con los hechos verificados de la fuente primaria, con marcas de tiempo relativas —nunca un reloj real— exactamente donde el registro público no ofrece precisión de minuto.

Recursos

Alexey Grigorev — How I Dropped Our Production Database — la fuente primaria de todo este módulo, ya citada en el Módulo 1 de esta guía.
Google SRE — Incident Management Guide — el ciclo de vida de cinco etapas que este módulo aplica, ya citado completo en el Módulo 5.
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 las lecciones 2-6 de este módulo van a operar sin modificar.
Este mismo repositorio, Módulo 1, lecciones 5-6 — la narración original del incidente y el primer cálculo manual del error budget, base de este módulo.

← Anterior8. Proyecto: `INCIDENT-RESPONSE-PLAN.md` de Andes Cargo Siguiente →2. Manos a la obra: reconstruyendo el timeline exacto