6. Manos a la obra: el error budget que el incidente Claude Code se comió

Descripción

La lección 5 dejó una pregunta planteada, sin contestar: ¿qué hubiera dicho un error budget del incidente Claude Code? Esta lección la contesta con un número real, calculado a mano, con la misma aritmética exacta del libro de Google SRE que ya citaste en la lección 3. Es el primer cálculo ejecutado de toda esta guía —no una calculadora reutilizable todavía, eso llega en el Módulo 2—, sino la operación completa, determinista, corrida de verdad con un script Python corto que puedes ejecutar tú mismo y vas a obtener exactamente el mismo resultado, siempre.

Conexión con el módulo

Esta lección conecta tres piezas que ya tienes: el vocabulario de error budget de la lección 3 (error budget = 1 − SLO, en minutos sobre una ventana), las cifras exactas del incidente de la lección 5 (24 horas de recuperación), y la pregunta que la lección 5 dejó abierta. El resultado de este cálculo —un múltiplo entero del presupuesto mensual completo, no un pequeño exceso— es el número que vas a volver a ver, con el peso completo del vocabulario formal detrás, en el Módulo 6 de esta guía (lección 7 de ese módulo), cuando operes este mismo incidente de punta a punta.

Analogía: gastar 33 tarjetas prepagas completas en una sola compra

Ya conoces la analogía de la lección 3: un error budget es el saldo de una tarjeta prepaga que se carga una vez al mes, con un límite fijo, que no se repone antes de tiempo. El resultado de esta lección no es "la tarjeta se quedó sin saldo" — es gastar, en una sola compra, el saldo completo de 33 tarjetas prepagas mensuales seguidas, todas de golpe. No es un exceso menor que un equipo pueda absorber con disciplina extra el resto del mes. Es un evento que, medido en el vocabulario de esta guía, se comió más de dos años y medio de presupuesto de indisponibilidad en 24 horas.

Paso 1 — El SLO hipotético, y por qué es hipotético (todavía)

Antes de calcular nada, una honestidad importante: DataTalks.Club, en la realidad, no publicó ningún SLO formal antes del incidente —no hay evidencia de que existiera uno—. Esta lección usa un SLO hipotético e ilustrativo, no inventado al azar sino elegido con el mismo criterio que la lección 3 de este módulo ya explicó: 99,9% mensual, el nivel más común en la industria para un servicio web que no es de misión crítica —ni un sistema de pagos en tiempo real, ni soporte de vida, pero tampoco algo sin ninguna expectativa de disponibilidad—. El objetivo de esta lección no es determinar el SLO "correcto" de DataTalks.Club —eso ni siquiera tiene sentido para un incidente que ya pasó— es demostrar la aritmética completa con un número de referencia razonable, exactamente el mismo tipo de ejercicio que vas a repetir con el SLO real de Andes Cargo en el Módulo 2, lección 8, de esta guía.

   SLO = 99.9% mensual
   Ventana = 30 días = 43.200 minutos

Paso 2 — El error budget en minutos, con la fórmula exacta de Google SRE

La fórmula, ya citada en la lección 3: error budget = 1 − SLO, aplicada sobre la ventana de tiempo en minutos.

   error_budget = (1 − SLO) × minutos_de_la_ventana
   error_budget = (1 − 0.999) × 43.200
   error_budget = 0.001 × 43.200
   error_budget = 43,2 minutos

Este es el mismo número que ya viste en la tabla de nueves de la lección 3: a 99,9% mensual, el presupuesto completo del mes es 43,2 minutos de indisponibilidad permitida. Menos de tres cuartos de hora, para todo un mes.

Paso 3 — La duración real del incidente

Grigorev es preciso en su propio relato, citado textualmente: "Exactly 24 hours after the database had been deleted, AWS restored the snapshot." Veinticuatro horas exactas, de principio a fin, hasta la restauración completa.

   incidente = 24 horas = 24 × 60 = 1.440 minutos

Paso 4 — El cálculo completo, ejecutado

El script siguiente hace exactamente los cuatro pasos de esta lección, en código, sin ningún valor aleatorio ni dependiente del reloj de la máquina — corre este script hoy, mañana, o en un año, y el resultado es siempre el mismo, porque cada entrada es un dato fijo, no una medición en vivo.

# error_budget_manual_check.py
# Calculo manual, determinista: cuanto error budget se comio el incidente Claude Code

# --- Paso 1: el SLO hipotetico (ilustrativo, no el SLO real de Andes Cargo todavia) ---
SLO = 0.999  # 99.9% mensual
WINDOW_DAYS = 30
WINDOW_MINUTES = WINDOW_DAYS * 24 * 60  # minutos en la ventana de 30 dias

# --- Paso 2: el error budget en minutos ---
error_budget_minutes = (1 - SLO) * WINDOW_MINUTES

# --- Paso 3: la duracion real del incidente (Grigorev: "Exactly 24 hours") ---
INCIDENT_HOURS = 24
incident_minutes = INCIDENT_HOURS * 60

# --- Paso 4: cuantas veces el presupuesto mensual se consumio ---
burn_factor = incident_minutes / error_budget_minutes

print(f"Ventana:                {WINDOW_DAYS} dias = {WINDOW_MINUTES} minutos")
print(f"SLO hipotetico:         {SLO:.1%}")
print(f"Error budget:           {error_budget_minutes:.1f} minutos")
print(f"Incidente:              {INCIDENT_HOURS} horas = {incident_minutes} minutos")
print(f"Presupuesto consumido:  {burn_factor:.1f}x")

Qué esperar (literal — corre este script exactamente como está, sin ninguna dependencia externa, y este es el resultado, siempre, sin variación):

Ventana:                30 dias = 43200 minutos
SLO hipotetico:         99.9%
Error budget:           43.2 minutos
Incidente:              24 horas = 1440 minutos
Presupuesto consumido:  33.3x

El incidente Claude Code consumió 33,3 veces el presupuesto de error mensual completo de DataTalks.Club, con un SLO hipotético de 99,9% — en un solo evento de 24 horas. No "se excedió un poco". No "fue un mal día". Un evento que, medido con este vocabulario, equivale a haber gastado el presupuesto de indisponibilidad de casi tres años completos (33,3 meses) en 24 horas.

Profundización: ¿algún SLO razonable hubiera absorbido este incidente?

Vale la pena hacer una pregunta más, con la misma aritmética: ¿qué tan laxo tendría que haber sido el SLO de DataTalks.Club para que 1.440 minutos de indisponibilidad cupieran dentro del presupuesto de un solo mes? Es la misma fórmula, despejada al revés:

# ¿que SLO hace que el presupuesto mensual completo sea >= 1.440 minutos?
break_even_budget_minutes = incident_minutes  # 1440
break_even_slo = 1 - (break_even_budget_minutes / WINDOW_MINUTES)

print(f"SLO de equilibrio:      {break_even_slo:.4%}")

Qué esperar (literal):

SLO de equilibrio:      96.6667%

96,67% es, en la escala de nueves de la lección 3, menos de "dos nueves" — un nivel de servicio inusualmente bajo incluso para un proyecto educativo gratuito y de bajo presupuesto, el equivalente a permitir más de 24 horas de indisponibilidad por mes, todos los meses, como algo normal. Ningún SLO que cualquier equipo elegiría con criterio real —99%, 99,9%, ni siquiera algo tan laxo como 98%— hubiera absorbido este incidente dentro de un solo mes sin agotar el presupuesto por completo. Este no es un resultado sensible a qué SLO exacto se hubiera elegido: es un incidente que, con casi cualquier objetivo de confiabilidad razonable, se come el presupuesto de un mes entero y sobra.

Segunda extensión: el mismo cálculo, aplicado al segundo caso de la lección 5

La lección 4 de este módulo encontró que todo andes-cargo-infra/ vive en us-east-1, sin ninguna región de respaldo. La lección 5 nombró el outage real que esa región sufrió en octubre de 2025: aproximadamente 15 horas de interrupción. Vale la pena correr exactamente la misma aritmética sobre ese número, no porque le haya pasado a Andes Cargo —no le pasó—, sino para tener, con el mismo rigor, una idea concreta de qué representaría si le pasara:

# Extension: si Andes Cargo hubiera estado indisponible el mismo tiempo que
# el outage real de us-east-1 (octubre de 2025), cuanto de su presupuesto
# mensual (mismo SLO hipotetico de 99.9%) se hubiera consumido?
OUTAGE_HOURS = 15  # duracion real reportada del outage de us-east-1, oct-2025
outage_minutes = OUTAGE_HOURS * 60
outage_burn_factor = outage_minutes / error_budget_minutes

print(f"Outage us-east-1:       {OUTAGE_HOURS} horas = {outage_minutes} minutos")
print(f"Presupuesto consumido:  {outage_burn_factor:.1f}x")

Qué esperar (literal):

Outage us-east-1:       15 horas = 900 minutos
Presupuesto consumido:  20.8x

Un evento completamente fuera del control de Andes Cargo —una race condition interna de AWS, no un destroy mal aprobado— hubiera consumido, con el mismo SLO hipotético, 20,8 veces el presupuesto mensual completo. Menor que el 33,3x del incidente Claude Code, pero igual de catastrófico para cualquier presupuesto mensual razonable. Esta es, en números concretos, la razón por la que la lección 5 insistió en que ambos casos exigen la misma disciplina de medición —SLI, SLO, error budget, postmortem— aunque sus causas raíz no tengan nada en común: un error budget no le pregunta a un incidente por qué pasó antes de contar cuánto costó.

Errores comunes

Confundir el SLO hipotético de esta lección con el SLO real de Andes Cargo (de anticipación). Qué pasa: alguien asume que 99,9% mensual es "el SLO oficial de Andes Cargo", y lo cita como tal en una lección posterior. Cómo detectarlo: si mencionas "el SLO de Andes Cargo" antes de haber llegado al Módulo 2, lección 8, de esta guía. Cómo corregirlo: el 99,9% de esta lección es exclusivamente un valor de referencia para demostrar la aritmética sobre un incidente real que ya pasó, elegido porque es el más común en la industria para un servicio como DataTalks.Club — no una decisión tomada para Andes Cargo. El SLO real de Andes Cargo se elige, con su propia justificación de negocio, en el Módulo 2.

Redondear el resultado a "se excedió el presupuesto" sin retener la magnitud exacta (de pérdida de precisión). Qué pasa: alguien recuerda que "el incidente superó el presupuesto de error" pero no retiene el múltiplo específico —33,3x—, y lo trata como un exceso cualquiera, comparable a un incidente que consume, digamos, 1,2 veces el presupuesto. Cómo detectarlo: si tu descripción del incidente no incluye el número "33,3x" o su equivalente en meses (33,3 meses de presupuesto en un día). Cómo corregirlo: la magnitud exacta es el punto pedagógico central de esta lección — un error budget que se excede por 1,2x sugiere una respuesta distinta (revisar el proceso, ajustar el SLO) que uno que se excede por 33,3x (un fallo catastrófico y sistémico, no una variación normal). El número exacto, no la categoría "se excedió", es lo que un error budget aporta que una descripción cualitativa no aporta.

Pensar que este cálculo ya es "la calculadora de error budget" de esta guía (de anticipación de alcance). Qué pasa: alguien, después de correr el script de esta lección, asume que ya tiene la herramienta completa que el Módulo 2 promete construir, y se pregunta qué falta. Cómo detectarlo: si esperas que este script maneje datasets de tráfico real, distintos SLOs configurables, o el cálculo de burn rate multi-ventana. Cómo corregirlo: este es, deliberadamente, un cálculo manual de un solo caso —una sola entrada, un solo resultado, sin reutilización—. scripts/error_budget_calculator.py, el entregable real del Módulo 2, generaliza exactamente esta misma fórmula para que reciba cualquier SLO, cualquier ventana y cualquier dataset de tráfico, y la extiende con burn rate en el Módulo 4. Esta lección construyó la fórmula a mano, una vez, para que entiendas exactamente qué automatiza esa herramienta antes de usarla.

Ejercicios

Ejercicio 1 — Recalcula el factor con un SLO distinto, sin ejecutar el script. Si el SLO hipotético hubiera sido 99% mensual (en vez de 99,9%), ¿cuántos minutos de presupuesto habría, y cuántas veces se habría consumido con el mismo incidente de 1.440 minutos? Haz el cálculo a mano.

Ejercicio 2 — Explica, en tus propias palabras, por qué el SLO de equilibrio (96,67%) es una cifra reveladora, no solo un número curioso. ¿Qué te dice ese número sobre la severidad real del incidente, comparado con simplemente saber "duró 24 horas"?

Ejercicio 3 — Modifica el script para expresar el resultado en "meses de presupuesto" en vez de un factor sin unidad. Sin ejecutar nada todavía, escribe la línea de código que agregarías al script de esta lección para imprimir explícitamente "este incidente consumió el presupuesto de X meses completos", usando las variables ya definidas.

print(f"En meses de presupuesto: este incidente equivale a {burn_factor:.1f} meses de indisponibilidad permitida, consumidos en un solo dia.")

Resumen y siguiente paso

En esta lección hiciste el primer cálculo real de toda esta guía: con un SLO hipotético de 99,9% mensual (43,2 minutos de presupuesto), las 24 horas (1.440 minutos) de recuperación del incidente Claude Code consumieron 33,3 veces el presupuesto de error mensual completo — no un exceso menor, sino el equivalente a gastar el presupuesto de casi tres años en un solo día. Confirmaste, con una segunda extensión del mismo cálculo, que ningún SLO razonable —solo uno tan laxo como 96,67%, por debajo de cualquier estándar serio de la industria— hubiera absorbido este incidente dentro de un solo mes.

Antes de avanzar deberías poder: correr el script de esta lección y obtener exactamente 33.3x; explicar por qué el SLO de esta lección es hipotético, no el SLO real de Andes Cargo; y calcular a mano, sin el script, el factor de consumo para un SLO distinto al de esta lección.

La lección 7 formaliza todo el vocabulario que ya usaste en este módulo —SLI, SLO, SLA, error budget, toil, on-call, postmortem— en un glosario corto, citado de la fuente oficial de Google SRE.

Recursos

1. Alexey Grigorev — How I Dropped Our Production Database — fuente primaria de "Exactly 24 hours after the database had been deleted, AWS restored the snapshot", el dato central de esta lección.
2. Google SRE Workbook — Implementing SLOs — la fórmula exacta de error budget (1 − SLO) que esta lección aplica.
3. Google SRE Book, Capítulo 3 — Embracing Risk — el marco conceptual del error budget, ya citado en la lección 3 de este módulo.