Módulo 6: Operating The Claude Code Incident
7. El error budget de este incidente, con el vocabulario completo
Descripción
El Módulo 1, lección 6 de esta guía hizo el primer cálculo real de toda la guía: con un SLO hipotético de 99,9% mensual, las 24 horas de recuperación consumieron 33,3 veces el presupuesto mensual completo — un script de un solo uso, error_budget_manual_check.py, escrito antes de que existiera ninguna herramienta reutilizable. Esta lección repite ese cálculo, con dos diferencias que cambian por completo su peso: en vez de un script de un solo uso, usa las funciones reales de scripts/error_budget_calculator.py (Módulo 2, lección 4); y en vez de un SLO hipotético elegido solo para ilustrar la aritmética, usa el SLO real de Andes Cargo, el que SLO.md fijó con evidencia en el Módulo 2 — que, por una coincidencia que vale la pena examinar, es exactamente el mismo número.
Conexión con el módulo
Esta es la última lección técnica del módulo antes del proyecto final (lección 8). Reúne, en un solo lugar, cada pieza de vocabulario que esta guía construyó desde el Módulo 1: SLI, SLO, error budget, burn rate — con la distinción, ya establecida en la lección 3 de este módulo, entre lo que se puede calcular con datos reales (error budget en minutos) y lo que no se puede calcular en absoluto para este incidente específico (burn rate, porque no hay ninguna tasa de error observable cuando no queda ningún sistema que genere tráfico).
Paso 1 — Por qué esta vez el SLO no es hipotético
El Módulo 1, lección 6 fue explícita sobre una limitación honesta: el SLO de 99,9% que usó era "hipotético e ilustrativo", elegido porque es el nivel más común de la industria para un servicio como DataTalks.Club, no porque fuera "el SLO correcto" de nadie en particular —DataTalks.Club, en la realidad, nunca publicó un SLO formal—. Esta lección tiene algo que esa lección todavía no tenía: SLO.md, el documento real de Andes Cargo (Módulo 2, lección 8), con un SLO elegido después de correr la calculadora tres veces contra datos reales, no elegido por ser "el más común de la industria".
El resultado de SLO.md: 99,9% mensual — el mismo número, exactamente, que el Módulo 1 usó como ilustración. No es una coincidencia forzada por este diseño — es la confirmación, con evidencia real medida en el Módulo 2, de que la elección ilustrativa del Módulo 1 resultó ser razonable: 99,9% es, de hecho, el nivel que un sistema comparable a process-shipment-manifest puede sostener con datos reales, sin ser tan laxo que deje de significar algo (el problema que SLO.md descartó con 99%) ni tan estricto que el sistema lo incumpla constantemente (el problema que SLO.md descartó con 99,99%). Esta lección puede, con total honestidad, dejar de decir "hipotético" — el número ahora tiene la evidencia completa de SLO.md detrás.
Paso 2 — Reutilizando la función real, no un script nuevo
error_budget_calculator.py (Módulo 2, lección 4) ya tiene la función exacta que esta lección necesita: error_budget_minutes(slo, window_minutes), que implementa la fórmula de Google SRE, (1 - SLO) × minutos de la ventana. Esta lección no reescribe esa función — la reutiliza, exactamente como está, con los valores reales de SLO.md y la duración real del incidente:
# incident_error_budget_with_calculator.py
# Reutiliza error_budget_minutes() de scripts/error_budget_calculator.py (Modulo 2, leccion 4)
# -- misma funcion, misma formula -- ahora aplicada al incidente real con el SLO real de SLO.md
# (Modulo 2, leccion 8), no con un SLO hipotetico como en el Modulo 1, leccion 6.
def error_budget_minutes(slo, window_minutes):
"""error budget = (1 - SLO) x minutos de la ventana que el SLO promete.
Identica a la funcion de scripts/error_budget_calculator.py -- Modulo 2, leccion 4."""
return (1 - slo) * window_minutes
# --- El SLO real de SLO.md (Modulo 2, leccion 8) -- no hipotetico ---
SLO = 0.999 # 99.9% mensual, SLO.md
SLO_WINDOW_MINUTES = 30 * 24 * 60 # 43,200 minutos, la ventana que SLO.md promete
# --- La duracion real del incidente, verificada contra la fuente primaria ---
# Grigorev: "Exactly 24 hours after the database had been deleted, AWS restored the snapshot."
INCIDENT_MINUTES = 24 * 60 # 1,440 minutos
# --- El calculo completo, con el vocabulario formal de budget_report() ---
budget_minutes = error_budget_minutes(SLO, SLO_WINDOW_MINUTES)
minutes_consumed = INCIDENT_MINUTES # las 24 horas completas, contadas como presupuesto consumido
minutes_remaining = budget_minutes - minutes_consumed
consumed_pct = (minutes_consumed / budget_minutes) * 100
burn_factor = minutes_consumed / budget_minutes
print(f"SLO (SLO.md): {SLO:.1%}")
print(f"Error budget: {budget_minutes:.1f} minutes")
print(f"Incident duration: {INCIDENT_MINUTES} minutes (24 hours)")
print(f"Consumed: {minutes_consumed} minutes ({consumed_pct:.1f}% of budget)")
print(f"Remaining: {minutes_remaining:.1f} minutes")
print(f"Burn factor: {burn_factor:.1f}x the full monthly budget")Qué esperar (literal — corre este script exactamente como está, y este es el resultado, siempre, sin variación):
SLO (SLO.md): 99.9%
Error budget: 43.2 minutes
Incident duration: 1440 minutes (24 hours)
Consumed: 1440 minutes (3333.3% of budget)
Remaining: -1396.8 minutes
Burn factor: 33.3x the full monthly budget
Paso 3 — El mismo resultado, con más información que el Módulo 1 nunca calculó
33,3x — exactamente el mismo número que el Módulo 1, lección 6 obtuvo con su script de un solo uso. No es sorprendente: la fórmula es idéntica, el SLO es el mismo número (99,9%), y la duración del incidente es el mismo dato verificado (24 horas). Lo que esta lección tiene, que el Módulo 1 nunca calculó, son dos cifras adicionales que budget_report() de error_budget_calculator.py sabe producir y que ese script de un solo uso no incluía: presupuesto consumido como porcentaje (3.333,3%) y presupuesto restante (-1.396,8 minutos).
El presupuesto restante negativo es la cifra más honesta de las tres. Un presupuesto restante de -1.396,8 minutos no significa "presupuesto negativo" en el sentido de una deuda que se paga después con intereses —el error budget no funciona así, como SLO.md y el Módulo 2 ya establecieron—. Significa, con precisión aritmética: si el ciclo de treinta días de este SLO tuviera que absorber, dentro de sí mismo, tanto el presupuesto original (43,2 minutos) como el déficit adicional que este incidente generó (1.396,8 minutos más), el mes necesitaría casi 33 veces su duración normal solo para que el balance volviera a cero. Es la misma idea que el Módulo 1 ya comunicó con "33,3 meses de presupuesto en un solo día" — pero expresada ahora con el vocabulario formal completo de budget_report(), el mismo formato que cualquier corrida real de la calculadora sobre el tráfico normal de Andes Cargo (Módulo 2, lección 4) ya produjo.
Paso 4 — Por qué esta lección no calcula burn rate, otra vez
Sería tentador, en esta lección, extender el script del Paso 2 con la fórmula de burn rate del Módulo 4 —burn_rate = tasa_de_error_observada / tasa_de_error_permitida— para "completar el vocabulario". La lección 3 de este módulo ya explicó, con precisión, por qué eso no es posible aquí: burn rate necesita una tasa de error observada, medida contra tráfico real que sigue llegando a un sistema que sigue existiendo. Este incidente no tiene eso —desde T+0, no había ningún sistema al que enviar tráfico, y por lo tanto ninguna tasa de error que calcular—.
El error budget en minutos, en cambio, sí se puede calcular, porque no depende de una tasa de tráfico observada — depende solo de la duración de la indisponibilidad, un dato que sí existe con precisión (24 horas, verificadas por la fuente primaria). Esta es la razón real, con el vocabulario completo a la vista, de por qué esta guía usa dos herramientas distintas para preguntas distintas: error_budget_calculator.py mide el costo de una indisponibilidad conocida, sin necesitar tráfico en vivo; burn_rate_evaluator.py (Módulo 4) mide la velocidad de consumo de un sistema que sigue recibiendo tráfico, mientras lo recibe. El incidente Claude Code es, precisamente, un caso donde solo la primera herramienta aplica —y es exactamente la misma razón, con el mismo vocabulario, por la que la lección 3 de este módulo clasificó la severidad con el criterio independiente de pérdida de datos, no con un umbral de burn rate.
DOS HERRAMIENTAS, DOS PREGUNTAS -- POR QUE SOLO UNA APLICA AQUI
error_budget_calculator.py burn_rate_evaluator.py
(Modulo 2) (Modulo 4)
────────────────────────── ─────────────────────
Pregunta: "¿cuanto costo, Pregunta: "¿que tan rapido
en minutos de presupuesto, se esta consumiendo el
una indisponibilidad de presupuesto AHORA, con
duracion conocida?" trafico que sigue llegando?"
│ │
▼ ▼
Solo necesita: la duracion Necesita: trafico real,
de la indisponibilidad en vivo, siendo medido
│ │
▼ ▼
SI APLICA al incidente NO APLICA al incidente
Claude Code -- la duracion Claude Code -- no hay
(24 horas) es un dato real trafico que medir desde
y verificado T+0 en adelanteErrores comunes
Tratar el "33,3x" de esta lección como un número distinto o más autorizado que el "33,3x" del Módulo 1, en vez de reconocer que es el mismo resultado con más contexto (de sobrevalorar la repetición). Qué pasa: alguien presenta el cálculo de esta lección como si corrigiera o mejorara el resultado del Módulo 1, sin notar que el número es idéntico. Cómo detectarlo: si tu explicación de esta lección incluye la frase "el número real es distinto al del Módulo 1". Cómo corregirlo: el Paso 3 de esta lección fue explícito — el número es exactamente el mismo, 33,3x, porque la fórmula, el SLO (99,9% en ambos casos) y la duración del incidente (24 horas, verificada) son idénticos entre ambas lecciones. Lo que cambia no es el resultado — es la fuente del SLO (hipotético en el Módulo 1, real y con evidencia en SLO.md aquí) y la herramienta que lo calcula (un script de un solo uso frente a la función reutilizable de error_budget_calculator.py).
Intentar "completar" el vocabulario agregando un cálculo de burn rate inventado, en vez de aceptar que esa pieza del vocabulario no aplica a este incidente (de forzar una fórmula donde no corresponde). Qué pasa: alguien, incómodo con que la lección no calcule burn rate, inventa una tasa de error arbitraria (por ejemplo, asumiendo "100% de errores" durante las 24 horas) para poder completar el cálculo. Cómo detectarlo: si tu versión de esta lección incluye un número de burn rate que no está respaldado por ninguna tasa de tráfico real y verificada. Cómo corregirlo: el Paso 4 de esta lección, y la lección 3 de este módulo antes, ya establecieron por qué inventar una tasa de error aquí sería matemáticamente incorrecto — no hay ningún tráfico real que medir desde T+0. La ausencia de un cálculo de burn rate no es un hueco en el vocabulario de esta lección — es la aplicación correcta y honesta de una herramienta que, por diseño, no sirve para este caso específico.
Confundir "presupuesto restante: -1.396,8 minutos" con una deuda real que Andes Cargo o DataTalks.Club "deben" en algún sentido financiero o contractual (de tomar la analogía del presupuesto demasiado literal). Qué pasa: alguien interpreta el número negativo como si implicara alguna consecuencia contractual o financiera real, similar a un SLA incumplido con penalidades. Cómo detectarlo: si tu explicación del presupuesto restante negativo menciona algo que "hay que pagar" o "compensar" a alguien externo. Cómo corregirlo: el Módulo 1, lección 7 de esta guía ya distinguió con precisión un SLO (objetivo interno de ingeniería) de un SLA (contrato externo con consecuencias reales) — Andes Cargo, según RELIABILITY-CHARTER.md, no tiene SLA. El número negativo es una medida de magnitud del incumplimiento del objetivo interno, útil para decidir cuánta urgencia merece prevenir que se repita — nunca una obligación financiera o contractual real.
Ejercicios
Ejercicio 1 — Modifica, en prosa (sin ejecutar nada), el script del Paso 2 para calcular cuántos "meses completos de presupuesto" representa el déficit de -1.396,8 minutos, usando solo las variables ya definidas.
Ver solución
Como budget_minutes (43,2) ya representa un mes completo de presupuesto, dividir el valor absoluto del déficit entre budget_minutes da la respuesta directamente: deficit_in_months = abs(minutes_remaining) / budget_minutes. Con los valores de esta lección: 1396.8 / 43.2 = 32.3 meses adicionales de déficit, más allá del mes ya consumido por completo — una forma más de expresar la misma magnitud que burn_factor (33,3x) ya comunica, pero enfocada específicamente en cuánto más allá de cero cayó el balance, no en cuántas veces se consumió el total original.
Ejercicio 2 — Explica, usando el Paso 4, por qué la clasificación de SEV1 de la lección 3 de este módulo y la imposibilidad de calcular burn rate de esta lección son, en el fondo, la misma observación aplicada dos veces.
Ver solución
Ambas observaciones parten del mismo hecho técnico: desde T+0, no existe ningún sistema generando tráfico que se pueda medir. La lección 3 de este módulo usó ese hecho para explicar por qué la severidad no se puede clasificar con el umbral numérico de burn rate de la matriz —tuvo que recurrir al criterio independiente de pérdida de datos—. Esta lección usa el mismo hecho para explicar por qué burn_rate_evaluator.py no aplica a este incidente, mientras que error_budget_calculator.py sí, porque este último no depende de tráfico en vivo. Es la misma causa raíz técnica —ausencia total de infraestructura, y por lo tanto de telemetría— vista desde dos ángulos distintos del vocabulario de esta guía: severidad en la lección 3, herramienta de cálculo en esta lección.
Ejercicio 3 — Un entrevistador técnico pregunta: "¿por qué reutilizar error_budget_minutes() de error_budget_calculator.py en vez de simplemente correr de nuevo el script del Módulo 1?". Responde usando el Paso 2 de esta lección.
Ver solución
Una respuesta completa: "El script del Módulo 1 fue, deliberadamente, un cálculo manual de un solo uso, construido antes de que existiera ninguna herramienta reutilizable en esta guía — su propio resumen lo dice explícitamente. Reutilizar la función real de error_budget_calculator.py demuestra algo que el script original no podía demostrar por sí solo: que la misma herramienta que Andes Cargo usa para medir su tráfico normal (Módulo 2), su semana mala sintética (también Módulo 2), y que va a usar en el Módulo 8 contra un incidente nuevo, produce exactamente el mismo resultado matemático cuando se le da la duración de un incidente real ya ocurrido. No es solo una cuestión de no repetir código — es la prueba de que la calculadora generaliza correctamente, sin necesitar ningún ajuste especial, para el caso específico de un incidente histórico."
Resumen y siguiente paso
Esta lección recalculó el error budget del incidente Claude Code, reutilizando error_budget_minutes() de error_budget_calculator.py (Módulo 2, lección 4) en vez del script de un solo uso del Módulo 1, y usando el SLO real de SLO.md (99,9%, con evidencia completa) en vez de un valor hipotético. El resultado —33,3x el presupuesto mensual completo— es idéntico al del Módulo 1, confirmando que la elección ilustrativa de esa lección resultó ser razonable. Agregaste dos cifras nuevas que el cálculo original nunca produjo (3.333,3% consumido, -1.396,8 minutos de presupuesto restante), y confirmaste, con el vocabulario completo de SLI/SLO/error budget/burn rate, por qué esta lección calcula error budget pero deliberadamente no calcula burn rate para este incidente específico.
Antes de avanzar deberías poder: correr el script de esta lección y obtener exactamente los mismos números; explicar por qué el resultado es idéntico al del Módulo 1 a pesar de usar una fuente distinta para el SLO; y defender por qué burn rate no aplica a este incidente mientras que error budget sí.
La lección 8, el proyecto final de este módulo, integra todo lo que las lecciones 2 a 7 construyeron —timeline, severidad, roles, árbol de decisión, error budget— en la versión final y completa de TIMELINE.md, la pieza de portafolio que el Módulo 7 va a citar directamente en el postmortem sin culpa.
Recursos
- Este mismo repositorio, Módulo 1, lección 6 (
06-hands-on-the-error-budget-the-claude-code-incident-burned.md) — el cálculo original, con SLO hipotético, que esta lección recalcula con la herramienta real. - Este mismo repositorio, Módulo 2, lección 4 (
04-hands-on-the-error-budget-calculator.md) —error_budget_calculator.py, la fuente de la funciónerror_budget_minutes()reutilizada aquí. - Este mismo repositorio, Módulo 2, lección 8 (
08-project-andes-cargos-slo-md.md) —SLO.md, la fuente del SLO real (99,9%) usado en esta lección. - Google SRE Workbook — Implementing SLOs — la fórmula exacta de error budget aplicada en esta lección.