Módulo 2: Slis Slos And The Error Budget
7. Manos a la obra: aplicando la calculadora a un escenario real de Andes Cargo
Descripción
Las lecciones 4 y 6 corrieron la calculadora sobre un mes real, mayormente sano, con dos días de deterioro puntual. Esta lección la corre, sin cambiar una sola línea de las funciones que ya construiste, sobre un segundo dataset —siete días, diseñados a mano para representar una semana genuinamente mala—: un cambio desplegado en process-shipment-manifest que rompe el procesamiento para un subconjunto de manifiestos, detectado el mismo día, pero cuya mitigación completa tarda casi toda la semana en confirmarse. La herramienta no necesita ningún cambio de código para esto — ese es, precisamente, el punto de haber construido una calculadora en vez de un cálculo de una sola vez como el del Módulo 1.
Conexión con el módulo
Esta lección no enseña ninguna función nueva. Reutiliza budget_report, print_report y burn_rate_of exactamente como quedaron al final de la lección 6, sobre un dataset distinto. Lo que se practica aquí es la lectura, no la construcción: enfrentarte a un resultado real, sin la guía paso a paso de las lecciones anteriores, y saber interpretarlo con el mismo criterio. La lección 8, el proyecto que cierra este módulo, va a citar los números de esta lección como parte de la evidencia detrás del SLO real de Andes Cargo.
El escenario: una semana mala, diseñada con una causa concreta
El día 1 de esta semana es tranquilo — el sistema arranca en su estado normal. El día 2, un cambio se despliega en process-shipment-manifest que introduce un error de parseo para manifiestos que incluyen un campo nuevo, usado por un subconjunto de transportistas de Andes Cargo. El error se detecta el mismo día 2 (algunos manifiestos empiezan a fallar), el cambio se revierte, pero la reversión no limpia por completo el problema de inmediato — algunos manifiestos en cola siguen procesándose con la versión rota durante los días siguientes, y el equipo tarda hasta el día 7 en confirmar que la tasa de error volvió a niveles normales.
# Este es el dataset nuevo de esta leccion. Las funciones (budget_report,
# print_report, burn_rate_of) son exactamente las mismas de las lecciones
# 4 y 6, sin ningun cambio.
from error_budget_calculator import budget_report, print_report, burn_rate_of
BAD_WEEK = [
(1, 420, 418),
(2, 435, 410),
(3, 410, 379),
(4, 428, 400),
(5, 440, 421),
(6, 300, 292),
(7, 285, 280),
]
report = budget_report(BAD_WEEK)
print_report(report, "process-shipment-manifest -- semana mala (7 dias)")
print()
print("--- Burn rate diario ---")
for row in BAD_WEEK:
br = burn_rate_of([row])
print(f"Dia {row[0]}: eventos validos={row[1]:>3} eventos buenos={row[2]:>3} burn rate={br:.2f}x")
print()
print("--- Burn rate de la semana completa (ventana de 7 dias) ---")
br_week = burn_rate_of(BAD_WEEK)
print(f"burn rate={br_week:.2f}x")python3 bad_week_scenario.pyQué esperar (literal — el SLO usado sigue siendo el mismo de referencia, 99,9% mensual, aunque el dataset solo tenga 7 días; budget_report compara siempre contra la ventana completa que el SLO promete, no contra la cantidad de días del dataset, exactamente como confirmaste en el ejercicio 3 de la lección 4):
--- process-shipment-manifest -- semana mala (7 dias) ---
Eventos validos: 2718
Eventos buenos: 2600
SLI medido: 95.6586%
SLO objetivo: 99.9%
Presupuesto (mensual): 43.2 minutos
Consumido en el periodo: 1875.50 minutos (4341.4% del presupuesto)
Presupuesto restante: -1832.30 minutos
--- Burn rate diario ---
Dia 1: eventos validos=420 eventos buenos=418 burn rate=4.76x
Dia 2: eventos validos=435 eventos buenos=410 burn rate=57.47x
Dia 3: eventos validos=410 eventos buenos=379 burn rate=75.61x
Dia 4: eventos validos=428 eventos buenos=400 burn rate=65.42x
Dia 5: eventos validos=440 eventos buenos=421 burn rate=43.18x
Dia 6: eventos validos=300 eventos buenos=292 burn rate=26.67x
Dia 7: eventos validos=285 eventos buenos=280 burn rate=17.54x
--- Burn rate de la semana completa (ventana de 7 dias) ---
burn rate=43.41x
Leyendo el resultado, sin ayuda: la práctica de esta lección
El presupuesto restante es -1.832,30 minutos. Una sola semana, no un mes completo, dejó el presupuesto mensual en un déficit de más de 1.800 minutos —más de 30 horas de indisponibilidad "de más" sobre lo que el SLO permite para los 30 días completos—. El 4.341,4% de presupuesto consumido significa, en otras palabras, que esta única semana gastó más de 43 veces el presupuesto de error de un mes entero. Esta cifra, calculada por una calculadora genérica sobre un dataset nuevo, aterriza casi exactamente sobre el mismo orden de magnitud que el 33,3x del incidente Claude Code que calculaste a mano en el Módulo 1 — una coincidencia útil de recordar: no hace falta un incidente catastrófico de 24 horas ininterrumpidas para consumir el presupuesto de un mes muchas veces; una semana de deterioro parcial y sostenido, con el sistema funcionando "la mayor parte del tiempo", logra exactamente el mismo tipo de daño al presupuesto.
El patrón diario de burn rate cuenta la historia completa del incidente, sin que nadie tenga que describirla en prosa. El día 1 (4,76x) ya muestra algo elevado —el tráfico normal de este dataset nunca fue perfecto—, pero el salto real ocurre el día 2 (57,47x), el día del despliegue roto. El pico llega el día 3 (75,61x) —probablemente el punto donde más manifiestos en cola todavía se procesaban con el código con falla, antes de que la reversión terminara de propagarse—, y de ahí en adelante el burn rate diario decrece de forma consistente cada día (65,42x → 43,18x → 26,67x → 17,54x): la firma numérica exacta de una mitigación que funciona, gradualmente, en vez de una que falla y se estanca. Ni el día 7, el mejor de la semana, logra bajar de 17x — la semana completa termina sin haber vuelto todavía a un burn rate saludable (cercano a 1x o menos), aunque la tendencia sea claramente positiva.
El burn rate de la ventana completa (43,41x) no es el promedio simple de los siete valores diarios. Vale la pena notar por qué: burn_rate_of sobre la ventana completa recalcula la tasa de error agregando todos los eventos válidos y buenos de los siete días juntos, no promedia siete números ya calculados por separado —los días de mayor tráfico (por ejemplo, el día 5, con 440 eventos válidos) pesan más en ese cálculo agregado que los días de menor tráfico (el día 7, con 285)—. Esta es la misma lógica de compute_sli que ya usaste desde la lección 4: sumar eventos, no promediar tasas ya calculadas — una distinción que importa porque promediar tasas directamente puede dar un resultado ligeramente distinto y, en general, menos correcto que agregar los eventos crudos primero.
Errores comunes
Interpretar "-1.832,30 minutos" como un error de cálculo porque "no puede haber presupuesto negativo" (repetido de la lección 5, con una magnitud mayor). Qué pasa: alguien, viendo un déficit tan grande, asume que el script tiene un bug. Cómo detectarlo: si tu reacción es desconfiar del número en vez de leerlo como "cuánto se excedió el presupuesto". Cómo corregirlo: ya viste en la lección 5 que un presupuesto puede consumirse por encima del 100% — esta lección simplemente lleva esa misma aritmética a un escenario más severo. El número negativo es información real: cuantifica, en minutos, cuánto más allá del límite permitido llegó esta semana específica.
Asumir que el burn rate decreciente día a día significa que el sistema ya volvió a la normalidad el día 7 (de leer solo la tendencia, no el valor absoluto). Qué pasa: alguien ve la secuencia 75,61x → 65,42x → 43,18x → 26,67x → 17,54x y concluye "el problema ya casi terminó, el sistema está sano". Cómo detectarlo: si tu conclusión sobre el día 7 no menciona que 17,54x sigue siendo diecisiete veces más rápido de lo que el SLO permite. Cómo corregirlo: una tendencia positiva (el burn rate bajando cada día) no es lo mismo que un valor saludable (burn rate cercano o por debajo de 1x). El día 7 de este dataset todavía está muy lejos de 1x — la mejora es real, pero el sistema, según esta lectura, todavía no había vuelto a un ritmo de error normal para cuando termina la semana que este dataset cubre.
Recalcular manualmente el 43,41x de la ventana completa como el promedio de los siete valores diarios (de aplicar la fórmula equivocada). Qué pasa: alguien suma los siete valores de burn rate diario y divide entre 7, esperando obtener 43,41. Cómo detectarlo: si tu cálculo manual no coincide con la salida del script. Cómo corregirlo: el promedio simple de los siete valores diarios de esta lección da un número distinto (más cercano a 41) porque no pondera por la cantidad de eventos válidos de cada día — burn_rate_of sobre la ventana completa suma todos los eventos primero (2.718 válidos, 2.600 buenos) y calcula un único burn rate sobre esos totales agregados, no un promedio de tasas ya calculadas por separado. Es la misma distinción, aplicada aquí, entre "promediar razones" y "sumar numeradores y denominadores por separado antes de dividir" — la segunda es, casi siempre, la correcta cuando los días tienen volúmenes de tráfico distintos.
Ejercicios
Ejercicio 1 — Calcula a mano cuántas veces el presupuesto mensual completo consumió esta semana, usando solo el porcentaje del reporte. El reporte dice "4341.4% del presupuesto". Exprésalo como un múltiplo, en el mismo formato que el 33,3x del Módulo 1.
Ver solución
4.341,4% equivale a 4.341,4 / 100 = 43,414 veces el presupuesto mensual completo — coincide, como es de esperar, con el burn rate=43.41x de la ventana completa que el script ya calculó por separado (con una pequeña diferencia de redondeo entre las dos formas de leerlo, ambas correctas). En el mismo formato que el Módulo 1: esta única semana consumió el equivalente a 43,4 meses de presupuesto de error, en apenas 7 días — un ritmo de consumo todavía más rápido, en términos relativos, que el propio incidente Claude Code (33,3x, pero en 24 horas de indisponibilidad casi total, no en una semana de deterioro parcial).
Ejercicio 2 — Identifica, sin ejecutar nada, en qué día el burn rate diario cruzaría el umbral "Page" de Google (14,4x, la fila más urgente de la Tabla 5-8 de la lección 6) por última vez antes de bajar por debajo de él. Usa los valores ya impresos en el "Qué esperar" de esta lección.
Ver solución
Los valores diarios, en orden: 4,76x (día 1), 57,47x (día 2), 75,61x (día 3), 65,42x (día 4), 43,18x (día 5), 26,67x (día 6), 17,54x (día 7). El umbral de 14,4x se cruza hacia arriba entre el día 1 y el día 2, y se mantiene por encima de 14,4x en todos los días siguientes, incluido el día 7 (17,54x > 14,4x) — esta semana, según el dataset de esta lección, nunca vuelve a bajar del umbral más urgente de Google en ningún día completo que el dataset cubra. Esto refuerza la lectura de la sección "Leyendo el resultado": la tendencia es positiva, pero el sistema todavía no había alcanzado, para el día 7, ni siquiera el nivel de severidad "Page" a la baja — mucho menos un burn rate saludable cercano a 1x.
Ejercicio 3 — Explica, usando este escenario, por qué esta guía diseñó una "semana mala" en vez de reutilizar el mismo tipo de incidente de dos días de los días 17-18 del dataset de la lección 4. ¿Qué le enseña este segundo dataset que el primero no podía enseñar?
Ver solución
El incidente de los días 17-18 (lección 4) fue agudo y breve: dos días de deterioro claro, seguidos de una recuperación completa e inmediata (el día 19 vuelve a cero errores, como confirmó la lección 6). Este segundo dataset enseña un patrón distinto y, en muchos sistemas reales, más común: un deterioro que no se resuelve de golpe, sino que mejora gradualmente durante varios días, mientras el sistema sigue, técnicamente, "funcionando" (nunca cae a cero eventos buenos ningún día). Este patrón es más difícil de leer con una sola cifra de resumen —"¿ya se arregló o no?" no tiene una respuesta binaria clara mientras el burn rate todavía baja de 75x a 17x sin llegar a 1x— y es exactamente el tipo de escenario donde tener burn rate diario, no solo un SLI acumulado del mes, resulta más útil: permite ver la trayectoria completa de una mitigación en progreso, no solo si terminó o no.
Resumen y siguiente paso
En esta lección corriste la calculadora completa —sin cambiar ninguna función— sobre un segundo dataset: una semana diseñada a mano con una causa concreta (un despliegue roto, revertido el mismo día, con una mitigación que tarda toda la semana en confirmarse). El resultado: un SLI de 95,66%, un déficit de presupuesto de -1.832,30 minutos, y un patrón de burn rate diario que cuenta la historia completa del incidente —pico de 75,61x el día 3, bajando de forma consistente hasta 17,54x el día 7, sin llegar todavía a un nivel saludable—. Practicaste leer un resultado real sin la guía paso a paso de las lecciones anteriores, y confirmaste que 43,4 veces el presupuesto mensual, consumido en una sola semana de deterioro parcial, es del mismo orden de magnitud que el 33,3x de un incidente catastrófico de 24 horas.
Antes de avanzar deberías poder: correr la calculadora sobre un dataset nuevo sin modificar ninguna función existente; leer un déficit de presupuesto de varios miles de minutos sin desconfiar del resultado; y explicar por qué un burn rate diario decreciente no es lo mismo que un sistema ya recuperado.
La lección 8 cierra este módulo con SLO.md: el documento que reúne toda la evidencia de las siete lecciones anteriores —la definición de SLI de la lección 3, el SLO candidato de la lección 5, el comportamiento de burn rate de las lecciones 6 y 7— en la decisión formal que el resto de esta guía va a medir y citar, sin volver a discutirla.
Recursos
- Este mismo repositorio, Módulo 2, lecciones 4 y 6 (
04-hands-on-the-error-budget-calculator.md,06-hands-on-burn-rate-not-just-the-balance.md) — las funciones que esta lección reutiliza sin cambios. - Este mismo repositorio, Módulo 1, lección 6 (
06-hands-on-the-error-budget-the-claude-code-incident-burned.md) — el 33,3x con el que se compara el 43,4x de esta lección. - Google SRE Workbook — Alerting on SLOs — la fuente de burn rate, aplicada aquí a un segundo escenario real.