Módulo 6: Operating The Claude Code Incident

4. Manos a la obra: declarando el incidente

Descripción

El Módulo 5, lección 2 ya distinguió detección de declaración: ver que algo está mal no es lo mismo que decir, formalmente, "esto es un incidente, y a partir de ahora se maneja como tal". Esta lección escribe ese mensaje —el acto formal de declaración— para el incidente Claude Code, siguiendo el mismo patrón que el Módulo 5 ya estableció: severidad ya clasificada (lección 3), roles asignados de la lista real de INCIDENT-RESPONSE-PLAN.md, primer estado conocido, y marcas de tiempo relativas, nunca un reloj real.

Conexión con el módulo

Esta es la primera lección del módulo donde entran personas concretas —no solo hechos y clasificaciones—. INCIDENT-RESPONSE-PLAN.md (Módulo 5) definió la estructura de roles (Incident Commander, Operations Lead, Communications Lead) sin asignarla a nadie en particular; la rotación de oncall/schedule.py (Módulo 5, lección 7) generó ocho semanas de titulares y respaldos reales, empezando el 2 de marzo de 2026. Esta lección hace lo que ninguna lección anterior hizo todavía: asignar esos roles a las personas concretas que la rotación real designa, y escribir el mensaje que un Incident Commander real enviaría en el primer minuto de un SEV1.

Paso 1 — Una honestidad de calendario, antes de asignar roles

Fíjate en un detalle que vale la pena resolver explícitamente, no ignorar: el incidente Claude Code ocurrió el 26 de febrero de 2026; la rotación de guardia de INCIDENT-RESPONSE-PLAN.md empieza formalmente el 2 de marzo de 2026 —seis días después—. Literalmente, schedule.py no tenía ninguna semana generada que cubriera el 26 de febrero.

Esta lección resuelve esa discrepancia con la misma honestidad que la lección 1 de este módulo ya estableció: este es un ejercicio deliberado de operar un incidente real con el marco de Andes Cargo, no una afirmación de que el incidente ocurrió dentro del calendario real de la rotación. Para este ejercicio, se trata la fecha del incidente como si cayera dentro de la Semana 1 de la rotación —la primera semana generada por schedule.py, con Ana como titular y Bruno como respaldo—, exactamente el mismo tipo de decisión de diseño explícita que la lección 1 ya distinguió de un hecho verificado del incidente real.

Week  Starts      Primary   Secondary
1     2026-03-02  Ana       Bruno          <- semana usada para este ejercicio
2     2026-03-09  Bruno     Carla

Paso 2 — Asignando los tres roles

La matriz de INCIDENT-RESPONSE-PLAN.md es explícita sobre la regla dura de un SEV1: "For a SEV1/SEV2, at minimum the IC and OL must be different people". Con dos personas de guardia esa semana —Ana (titular) y Bruno (respaldo)—, la distribución más razonable es la misma que el Módulo 5, lección 4, Ejercicio 2 de esta guía ya resolvió para exactamente este escenario de dos personas: una persona toma Incident Commander y Communications Lead (ambas son funciones de "vista completa", no de ejecución técnica directa), y la otra toma Operations Lead en solitario.

Rol	Persona	Por qué
Incident Commander (IC)	Ana	Titular de guardia esa semana; coordina la respuesta completa, no ejecuta cambios técnicos
Communications Lead (CL)	Ana (doble rol con IC)	Ambas funciones son de coordinación/comunicación, no de modificar el sistema — combinarlas no rompe la separación central de `INCIDENT-RESPONSE-PLAN.md`
Operations Lead (OL)	Bruno	Respaldo de guardia esa semana; el único que ejecutaría cualquier acción de mitigación, según la regla citada del Módulo 5: "el único grupo modificando el sistema durante un incidente"

Ninguna combinación fusiona IC con OL en la misma persona —la combinación que INCIDENT-RESPONSE-PLAN.md prohíbe explícitamente para un SEV1— así que esta asignación respeta la regla dura sin necesitar una tercera persona.

Paso 3 — El mensaje de declaración

Un mensaje de declaración real, corto y estructurado, cumple una sola función: eliminar cualquier ambigüedad sobre si el incidente "ya es oficial", quién está al mando, y qué se sabe hasta ese momento —nada más—. No es el lugar para especular sobre causa raíz (eso es el Módulo 7) ni para detallar la mitigación completa (eso es la lección 6 de este módulo).

# INCIDENT DECLARED — SEV1

**Time:** T+~5min (relative to `terraform destroy -auto-approve` execution — see `TIMELINE.md`)
**Declared by:** Ana (Incident Commander)

## Status

Complete infrastructure loss following an unintended `terraform destroy -auto-approve` execution.
VPC, ECS cluster, load balancers, bastion host, and the RDS database (including all automated
snapshots) are gone. `courses_answer` (1,943,200 rows) is affected. No service is currently
reachable.

## Severity

**SEV1** — unrecoverable data loss without external support intervention (Module 6, lesson 3;
matches `INCIDENT-RESPONSE-PLAN.md`'s independent SEV1 criterion, not a burn-rate threshold — no
burn rate is measurable, since no infrastructure remains to generate traffic).

## Roles

- **Incident Commander:** Ana — coordinates the response, owns this document and the timeline,
  does not run mitigation commands directly.
- **Operations Lead:** Bruno — the only person taking mitigation actions during this incident.
- **Communications Lead:** Ana (dual role with IC, per `INCIDENT-RESPONSE-PLAN.md`'s two-person
  guidance for a SEV1/SEV2).

## What we know right now (first known state)

- The destructive command has already run in full — this is not an ongoing degradation, it is a
  completed loss event.
- No self-service recovery path is currently known (see Module 6, lesson 6 for the full
  mitigation decision tree).
- Next update: within 15 minutes, or sooner if status changes materially.

## What this declaration does not claim

Root cause is not analyzed here — that is Module 7's postmortem, built on top of the finished
`TIMELINE.md` this module produces. This declaration exists only to make the incident official,
assign roles, and record the first known state.

Paso 4 — Por qué esta declaración funciona, aunque sea corta

Un mensaje de declaración real no necesita ser exhaustivo — necesita ser inmediato. Compáralo con la alternativa real que el Módulo 5, lección 2 ya nombró como el error más común: alguien ve la señal, empieza a investigar por su cuenta, y nunca comunica formalmente que el sistema está en modo incidente. El documento del Paso 3 evita ese error en menos de 200 palabras: declara la severidad de inmediato (sin esperar un análisis completo), asigna los tres roles sin ambigüedad, y establece el primer estado conocido sin inventar ningún detalle que todavía no se sabe con certeza —fíjate que la sección "What we know right now" es honesta sobre lo que no se sabe todavía ("no self-service recovery path is currently known"), en vez de proyectar una confianza que en ese momento no existía.

Errores comunes

Escribir la declaración después de investigar a fondo, en vez de en el primer minuto posible (de repetir el error que el Módulo 5, lección 2 ya nombró). Qué pasa: alguien, frente a un incidente real, pospone la declaración formal hasta tener un diagnóstico más completo, tratando la declaración como el resultado de la investigación en vez de su punto de partida. Cómo detectarlo: si tu declaración incluye detalles de causa raíz que, en un incidente real, todavía no se conocerían en el primer minuto. Cómo corregirlo: el documento del Paso 3 declara con la información mínima disponible en T+~5min — la escala del daño ya es evidente de inmediato (toda la infraestructura desapareció), pero el "por qué" no se investiga aquí. Declarar rápido, con información incompleta pero honesta, es mejor que declarar tarde con información completa.

Fusionar Incident Commander con Operations Lead en la misma persona, "porque de todas formas Ana sabe cómo arreglarlo técnicamente" (de romper la regla dura del Módulo 5 bajo presión). Qué pasa: alguien, al asignar los roles de un SEV1 real, decide que la persona más técnica debería coordinar y ejecutar al mismo tiempo, porque parece más eficiente en el momento. Cómo detectarlo: si tu asignación de roles tiene a la misma persona firmando como IC y también corriendo comandos de mitigación. Cómo corregirlo: INCIDENT-RESPONSE-PLAN.md es explícito — para un SEV1/SEV2, IC y OL deben ser personas distintas, sin excepción, precisamente porque mezclar decidir con ejecutar bajo presión es el mismo patrón que produjo el radio de explosión completo del incidente Claude Code real: una sola entidad con permiso de decidir y ejecutar a la vez, sin ninguna segunda persona coordinando la decisión.

Tratar la asignación de Ana y Bruno a la Semana 1 de la rotación como si fuera un hecho verificado del incidente real, no una decisión de diseño de este ejercicio (repetido del error ya nombrado en la lección 1 de este módulo, ahora con consecuencias concretas de nombres de personas). Qué pasa: alguien describe el incidente diciendo "Ana fue la Incident Commander del incidente Claude Code", como si eso fuera parte de los hechos verificados del caso real de DataTalks.Club. Cómo detectarlo: si tu resumen del incidente incluye nombres del roster de Andes Cargo como si fueran parte de la historia real de DataTalks.Club. Cómo corregirlo: DataTalks.Club, en la realidad, no tenía Incident Commander ni Communications Lead formalmente asignados —es, de hecho, parte de lo que este incidente revela sobre operar sin ese marco—. Ana y Bruno son la asignación de este ejercicio, aplicando la rotación de Andes Cargo al caso, exactamente lo que el Paso 1 de esta lección dejó explícito antes de asignar ningún nombre.

Ejercicios

Ejercicio 1 — Un compañero propone declarar este incidente como SEV2 en vez de SEV1, "para no alarmar innecesariamente al resto del equipo con una página inmediata". ¿Cómo respondes, usando el principio de la lección 3 de INCIDENT-RESPONSE-PLAN.md?

Ver solución

INCIDENT-RESPONSE-PLAN.md cita, textualmente, el principio de PagerDuty ya establecido en el Módulo 5, lección 3: "cuando haya duda sobre qué nivel corresponde, tratarlo como el más alto". Este caso, además, no tiene ninguna duda real que justifique bajar la severidad — el criterio independiente de SEV1 (pérdida de datos irrecuperable sin intervención externa) se cumple sin ambigüedad, según la verificación de la lección 3 de este módulo. Declarar SEV2 "para no alarmar" sería exactamente el error simétrico que el Módulo 5, lección 3 ya nombró: minimizar un incidente real porque se siente más cómodo, un error tan costoso como el opuesto (declarar SEV1 por cualquier cosa que se sienta urgente).

Ejercicio 2 — Reescribe la sección "What we know right now" del Paso 3 asumiendo que, en vez de T+~5min, la declaración se escribe en T+~1h (después de que el ticket de soporte con AWS ya se abrió). ¿Qué cambiaría, y qué seguiría igual?

Ver solución

Lo que cambiaría: la sección podría agregar que ya se abrió un ticket de soporte con AWS (Business Support), y que el equipo está esperando confirmación de si existe algún snapshot recuperable — información que a T+~5min todavía no existía. Lo que seguiría igual: la severidad (SEV1, sin cambios — el criterio que la justifica no depende del tiempo transcurrido), los roles asignados (Ana como IC/CL, Bruno como OL — no hay ninguna razón para reasignarlos solo porque pasó una hora), y la honestidad de no afirmar una causa raíz ni un plan de mitigación completo todavía —eso sigue siendo terreno de la lección 6 de este módulo y del Módulo 7—. Este ejercicio demuestra que la declaración inicial no necesita reescribirse por completo con cada actualización — se actualiza con hechos nuevos, sobre la misma estructura.

Ejercicio 3 — Explica por qué la sección "What this declaration does not claim" es una parte necesaria del documento, y no un simple disclaimer decorativo.

Ver solución

Esa sección existe para prevenir un error real y común: que alguien, leyendo la declaración inicial de un incidente, la interprete como el análisis completo de causa raíz, en vez de como el primer estado conocido. Sin esa sección explícita, un lector apurado podría asumir que "no self-service recovery path is currently known" es una conclusión final, o que la ausencia de una causa raíz mencionada significa que nadie la está investigando. Al declarar explícitamente qué NO cubre este documento —causa raíz, mitigación completa—, la declaración deja claro cuál es su función real (hacer oficial el incidente, asignar roles, fijar el primer estado) y remite, con precisión, a dónde vive el resto del trabajo (lección 6 de este módulo, y el Módulo 7 completo) — la misma disciplina de fronteras explícitas que cada documento de esta guía ya aplica.

Resumen y siguiente paso

En esta lección escribiste el mensaje de declaración formal del incidente Claude Code: SEV1, roles asignados de la rotación real de INCIDENT-RESPONSE-PLAN.md (Ana como Incident Commander y Communications Lead, Bruno como Operations Lead — respetando la regla dura de que IC y OL nunca son la misma persona en un SEV1), y el primer estado conocido, honesto sobre lo que todavía no se sabía en ese momento. Resolviste, explícitamente, la discrepancia de calendario entre la fecha real del incidente (26 de febrero de 2026) y el inicio formal de la rotación de guardia (2 de marzo de 2026), tratándola como la decisión de diseño de este ejercicio que es, no como un hecho del incidente real.

Antes de avanzar deberías poder: escribir un mensaje de declaración con la misma estructura para un escenario nuevo; explicar por qué IC y CL pueden combinarse en una persona pero IC y OL nunca; y defender por qué declarar rápido con información incompleta es mejor que declarar tarde con información completa.

La lección 5 cambia de ángulo: qué se comunicó realmente en público sobre este incidente —con fuentes citadas— frente a qué debería haberse comunicado internamente primero, con la cadencia que un Communications Lead real mantendría durante las 24 horas de respuesta.

Recursos

Este mismo repositorio, Módulo 5, lección 4 (04-roles-during-an-incident.md) — la definición de los tres roles y la regla dura sobre IC/OL, aplicada aquí por primera vez con personas concretas.
Este mismo repositorio, Módulo 5, lección 7 (07-hands-on-a-deterministic-on-call-rotation.md) — oncall/schedule.py, la fuente de Ana y Bruno como titular/respaldo de la Semana 1.
Este mismo repositorio, Módulo 5, lección 8 (08-project-andes-cargos-incident-response-plan.md) — INCIDENT-RESPONSE-PLAN.md, la regla exacta de dos personas para un SEV1/SEV2.
Google SRE — Incident Management Guide — la fase de declaración, ya citada en el Módulo 5, lección 2.

← Anterior3. Manos a la obra: clasificando la severidad Siguiente →5. Comunicación durante un incidente: interna frente a externa