Módulo 6: Operating The Claude Code Incident
3. Manos a la obra: clasificando la severidad
Descripción
TIMELINE.md ya existe. La siguiente pregunta que un equipo real se hace, en los primeros minutos de cualquier incidente, es la que el Módulo 5 ya preparó para contestar con aritmética, no con instinto: ¿qué tan grave es esto? Esta lección aplica la matriz de severidad exacta de INCIDENT-RESPONSE-PLAN.md al incidente Claude Code, y llega a un veredicto que no admite ambigüedad —SEV1— por una razón que vale la pena entender con precisión, porque no es la razón más obvia.
Conexión con el módulo
La matriz de severidad de INCIDENT-RESPONSE-PLAN.md (Módulo 5, lección 5) ata cada nivel a un umbral exacto de burn rate: SEV1 en Page (fast), ≥ 14,4x. La tentación de esta lección sería calcular el burn rate del incidente Claude Code y confirmar que cruza ese umbral. Esta lección hace algo distinto, y más honesto: muestra por qué ese cálculo, para este incidente específico, no se puede hacer — y por qué la propia matriz de severidad ya anticipó exactamente este caso con un criterio independiente, citado textualmente en la lección 5 del Módulo 5.
Paso 1 — El intento de calcular burn rate, y por qué falla
Antes de aplicar el criterio correcto, vale la pena intentar el cálculo obvio, para entender con precisión por qué no funciona aquí. La fórmula de ALERTING-POLICY.md y de la matriz de severidad:
burn_rate = tasa_de_error_observada / tasa_de_error_permitidaPara calcular una tasa de error observada, hace falta un numerador y un denominador: invocaciones fallidas, sobre invocaciones totales, medidas por un sistema de observabilidad que está recibiendo y procesando esos datos en tiempo real —exactamente lo que process-shipment-manifest y el pipeline de CloudWatch/Prometheus del Módulo 3 y 4 de esta guía hacen para Andes Cargo—. El problema, en el incidente Claude Code: a partir de T+0, no existe ningún sistema corriendo que pueda generar esas invocaciones, ni ningún pipeline de métricas que pueda registrarlas. La VPC, el clúster de ECS, los balanceadores de carga —toda la infraestructura, incluida cualquier pieza de observabilidad que hubiera existido— fueron destruidos en el mismo comando.
POR QUE EL CALCULO DE BURN RATE NO APLICA AQUI
Un sistema con degradacion El incidente Claude Code
parcial (el caso tipico (destruccion total de infra)
que ALERTING-POLICY.md
mide)
Trafico SIGUE llegando -- NO HAY trafico -- no hay
una parte falla, una parte servidor que reciba una
tiene exito, ambas se solicitud, no hay pipeline
miden de metricas que la registre
│ │
▼ ▼
burn_rate = tasa observada / burn_rate = 0/0 --
tasa permitida -- un numero indefinido. No es "100%
real y calculable de errores", es LA AUSENCIA
TOTAL de cualquier medicionNo es que la tasa de error observada sea 100% —esa sería, de hecho, la interpretación más común y la incorrecta—. Un 100% de tasa de error todavía implica que hay invocaciones ocurriendo, todas fallando. Aquí no hay invocaciones en absoluto: no hay ningún sistema al que invocar. La fórmula de burn rate se rompe matemáticamente (0 / 0, indefinido), no porque el resultado sea extremo, sino porque sus dos entradas dejaron de existir.
Paso 2 — El criterio que sí aplica, ya anticipado por INCIDENT-RESPONSE-PLAN.md
El Módulo 5, lección 5 de esta guía —al construir la matriz de severidad, mucho antes de que este módulo existiera— ya dejó esto resuelto, con una precisión que vale la pena releer:
"[SEV1] no está reservado solo para 'el sistema está caído': también cubre pérdida de datos irreversible sin intervención de soporte externo, incluso si el sistema técnicamente sigue respondiendo a otras solicitudes — la distinción exacta, no casual, que el Módulo 6 de esta guía va a aplicar al clasificar el incidente Claude Code real."
Y la sección "Errores comunes" de esa misma lección, escrita antes de que este módulo se escribiera, anticipó exactamente el problema del Paso 1:
"Un escenario como el incidente Claude Code, donde la infraestructura completa fue destruida, puede no generar ningún burn rate medible en absoluto (no hay invocaciones que fallen si no hay infraestructura para invocar) — por eso esta matriz incluye la pérdida de datos irreversible como un criterio SEV1 independiente, que no espera a que ningún número cruce ningún umbral."
La fila de SEV1 en INCIDENT-RESPONSE-PLAN.md está escrita, literalmente, con un operador "O": Page (fast), >= 14.4x — OR unrecoverable data loss, regardless of measured burn rate. El incidente Claude Code no cruza el umbral de burn rate porque no hay ningún número que calcular — cruza el segundo criterio, el de pérdida de datos irrecuperable, de forma directa e inequívoca.
Paso 3 — Verificando el criterio, hecho por hecho
Antes de declarar SEV1, vale la pena confirmar que el incidente cumple, con precisión, la definición exacta de "pérdida de datos irrecuperable sin intervención de soporte externo" —no basta con que "se sienta grave"—:
| Criterio de la matriz | ¿Se cumple? | Evidencia del TIMELINE.md |
|---|---|---|
| ¿Hubo pérdida de datos real? | Sí | courses_answer, 1.943.200 filas, destruida en T+0 junto con todos los snapshots automáticos |
| ¿Era recuperable con las herramientas propias del equipo, sin ayuda externa? | No | El propio equipo no tenía ningún snapshot accesible desde su consola — la lección 6 de este módulo detalla por qué |
| ¿Requirió intervención de soporte externo (fuera del control directo del equipo)? | Sí | Escalación a AWS Business Support, un snapshot solo visible del lado interno de AWS, no del lado del cliente |
| ¿El sistema, técnicamente, seguía respondiendo a otras solicitudes durante este tiempo? | No aplica aquí, pero el criterio de la matriz es explícito en que no importa | Toda la infraestructura estaba destruida — un caso todavía más severo que el escenario que la matriz contempla como mínimo para SEV1 |
Las cuatro filas confirman, sin ambigüedad, el criterio independiente de SEV1: pérdida de datos real, no recuperable con medios propios, que exigió intervención externa. El incidente Claude Code no solo cumple el umbral mínimo de este criterio — lo excede: no es un caso límite donde el sistema seguía respondiendo pero los datos estaban en riesgo, es el caso más severo posible dentro de la misma categoría, donde absolutamente nada seguía funcionando.
Paso 4 — Veredicto
SEV1. No por un cálculo de burn rate —que, como el Paso 1 demostró, ni siquiera se puede realizar aquí— sino por el criterio independiente y explícito que INCIDENT-RESPONSE-PLAN.md ya incluyó, con precisión, para exactamente este tipo de caso: pérdida de datos irrecuperable sin intervención de soporte externo. La respuesta que ese nivel exige, según la misma tabla: "Page on-call immediately. Incident Commander assigned. All hands as needed." — página inmediata, Incident Commander asignado, todas las manos disponibles. La lección 4 de este módulo asigna, con nombre y rol concreto, quién responde a esa página.
Errores comunes
Intentar forzar un número de burn rate de todas formas, asumiendo que "100% de errores" es matemáticamente lo mismo que "sin datos" (de confundir dos escenarios distintos). Qué pasa: alguien calcula el burn rate del incidente Claude Code asumiendo una tasa de error del 100%, obteniendo un resultado (1.000x, el mismo número que el Paso 2 de la lección 5 del Módulo 5 ya calculó para el escenario hipotético de Shipments sin responder) sin notar que ese número no aplica aquí. Cómo detectarlo: si tu justificación de SEV1 para este incidente incluye un número de burn rate calculado. Cómo corregirlo: el Paso 1 de esta lección es explícito — un 100% de tasa de error todavía requiere que existan invocaciones que fallen; el incidente Claude Code no tiene ninguna invocación posible, porque no hay ningún sistema al que invocar. Son dos escenarios distintos, aunque ambos terminen en SEV1: uno cruza el umbral numérico de burn rate, el otro cruza el criterio independiente de pérdida de datos.
Asumir que, sin un número de burn rate calculable, la clasificación de severidad se vuelve subjetiva o discutible (de perder de vista que el criterio independiente es igual de riguroso). Qué pasa: alguien concluye que, como este incidente "no tiene un número exacto detrás", la clasificación SEV1 depende del criterio personal de quien lo evalúa. Cómo detectarlo: si tu argumento para SEV1 usa frases como "obviamente fue grave" en vez de citar el criterio explícito de la matriz. Cómo corregirlo: el Paso 3 de esta lección verificó, hecho por hecho contra el TIMELINE.md, cada condición del criterio independiente de SEV1 — pérdida de datos real, no recuperable con medios propios, que exigió intervención externa. El criterio es tan riguroso y verificable como cualquier umbral numérico; simplemente no depende de una fórmula aritmética.
Concluir, al ver que el criterio de burn rate no aplica, que ALERTING-POLICY.md (Módulo 4) tiene un hueco de diseño (de malinterpretar una limitación conocida como un error). Qué pasa: alguien argumenta que la alerta de burn rate de Andes Cargo "no hubiera detectado" un incidente como este, y lo presenta como una falla del sistema de alerting. Cómo detectarlo: si tu conclusión de esta lección es "hay que rediseñar ALERTING-POLICY.md para cubrir este caso". Cómo corregirlo: ningún sistema de alerting basado en métricas puede detectar la ausencia total de la infraestructura que reporta esas métricas — es una limitación física, no un defecto de diseño corregible. La razón por la que INCIDENT-RESPONSE-PLAN.md incluye el criterio independiente de pérdida de datos, en vez de depender solo de burn rate, es exactamente para cubrir este tipo de caso donde ningún sistema de métricas puede alertar sobre su propia inexistencia.
Ejercicios
Ejercicio 1 — Un colega propone que, ya que el sistema de Andes Cargo no puede calcular burn_rate cuando la infraestructura entera desaparece, debería declararse automáticamente SEV1 "por ausencia de datos", incluso cuando la ausencia se deba a un mantenimiento planeado. ¿Estás de acuerdo?
Ver solución
En desacuerdo. El criterio real de SEV1 en INCIDENT-RESPONSE-PLAN.md no es "ausencia de datos de burn rate" — es "pérdida de datos irrecuperable sin intervención de soporte externo". Un mantenimiento planeado también podría dejar sin datos de burn rate durante una ventana, pero no implica ninguna pérdida real de datos, ni necesita ninguna intervención externa de emergencia — es una condición conocida, controlada y reversible por diseño. Confundir "no hay número de burn rate disponible" con "esto es automáticamente SEV1" ignoraría exactamente la distinción que esta lección estableció: el criterio independiente exige pérdida de datos real, no simplemente la imposibilidad de calcular una fórmula.
Ejercicio 2 — Explica, usando el Paso 1 de esta lección, por qué burn_rate = 0/0 es una descripción más precisa del incidente Claude Code que burn_rate = infinito.
Ver solución
burn_rate = infinito implicaría que el numerador (la tasa de error observada) crece sin límite mientras el denominador se mantiene fijo — una descripción que sugeriría, incorrectamente, que sí hay algo midiéndose, solo que a un nivel extremo. burn_rate = 0/0 es la descripción matemáticamente correcta: tanto el numerador como el denominador —invocaciones fallidas e invocaciones totales— son cero, porque no hay ningún sistema generando ninguna invocación en absoluto. La distinción no es un tecnicismo: 0/0 comunica correctamente que el problema es la ausencia total de medición, no una medición extrema, exactamente el punto central del Paso 1 de esta lección.
Ejercicio 3 — Compara la severidad de este incidente con el ejemplo de SEV1 narrativo de INCIDENT-RESPONSE-PLAN.md (Shipments deja de responder por completo, burn rate de 1.000x). ¿Es el incidente Claude Code "igual de grave", "menos grave" o "más grave" que ese ejemplo? Justifica con el Paso 3 de esta lección.
Ver solución
Más grave, y la propia tabla de la lección lo confirma en su última fila. El ejemplo narrativo de Shipments sin responder es un caso de indisponibilidad total, pero sin pérdida de datos —una vez que Shipments vuelve a responder, los datos siguen ahí, intactos, esperando la próxima invocación exitosa—. El incidente Claude Code combina la indisponibilidad total (nada respondía) con la pérdida real de datos (courses_answer y todo lo demás, destruido, sin ningún snapshot accesible del lado del cliente). Ambos casos son SEV1, porque ambos cruzan el umbral mínimo de esa categoría, pero el incidente Claude Code lo hace por partida doble —indisponibilidad total y pérdida de datos real— mientras el ejemplo narrativo de INCIDENT-RESPONSE-PLAN.md solo cruza la primera condición. La matriz de severidad no tiene un nivel "SEV0" para distinguir esta diferencia; ambos casos reciben la misma respuesta máxima, exactamente como el Módulo 5, lección 3 ya explicó sobre por qué ambos criterios comparten el mismo nivel.
Resumen y siguiente paso
Esta lección clasificó el incidente Claude Code como SEV1, verificado con el criterio exacto de INCIDENT-RESPONSE-PLAN.md — no por un cálculo de burn rate, que esta lección demostró que resulta matemáticamente indefinido (0/0) cuando la infraestructura completa desaparece, sino por el criterio independiente de pérdida de datos irrecuperable sin intervención de soporte externo, ya anticipado con precisión en el Módulo 5, lección 5. Confirmaste, hecho por hecho contra el TIMELINE.md de la lección anterior, cada condición de ese criterio: pérdida real, no recuperable con medios propios, que exigió escalar a AWS.
Antes de avanzar deberías poder: explicar por qué el burn rate de este incidente no se puede calcular; citar el criterio independiente de SEV1 de INCIDENT-RESPONSE-PLAN.md; y comparar la severidad de este incidente con el ejemplo narrativo de Shipments sin responder.
La lección 4 toma esta clasificación y produce el siguiente documento operativo: el mensaje de declaración formal, con los roles de INCIDENT-RESPONSE-PLAN.md asignados a personas concretas de la rotación de guardia.
Recursos
- Este mismo repositorio, Módulo 5, lección 5 (
05-hands-on-andes-cargos-severity-matrix.md) — la matriz completa y el criterio independiente de SEV1, citado textualmente en esta lección. - Este mismo repositorio, Módulo 5, lección 8 (
08-project-andes-cargos-incident-response-plan.md) —INCIDENT-RESPONSE-PLAN.md, la fuente de la fila de SEV1 aplicada aquí. - Google SRE Workbook — Alerting on SLOs — la fórmula de burn rate cuyo límite esta lección demuestra con un caso real.
- Alexey Grigorev — How I Dropped Our Production Database — la fuente de los hechos verificados en el Paso 3.