Módulo 2: Slis Slos And The Error Budget

1. Introducción: del vocabulario a la matemática

Descripción

El Módulo 1 te dio tres cosas: el vocabulario completo de SRE, citado siempre de la fuente oficial; un inventario real de riesgo sobre andes-cargo-infra/, leído por primera vez con ojos de confiabilidad; y un número —33,3x— calculado a mano, una sola vez, sobre un solo incidente. Ese cálculo manual (lección 6 de ese módulo) fue deliberado: una operación completa, ejecutada de verdad, pero de un solo uso —cuatro variables fijas, un resultado, sin ninguna posibilidad de reutilizarla con un SLO distinto o un dataset de tráfico real sin reescribir el script entero—. Este módulo generaliza exactamente esa aritmética en una herramienta real: scripts/error_budget_calculator.py, que vas a construir en la lección 4 y extender en las lecciones 6 y 7, y que sigue corriendo, sin cambios de fondo, hasta el capstone del Módulo 8.

Este es, junto al Módulo 3, el módulo con más peso ejecutado de toda la guía. No hay ninguna lección de este módulo que describa la matemática de SRE en prosa sin correrla: cada fórmula que aparece aquí —SLI, error budget en minutos, burn rate— se traduce a código Python real, corrido con python3 sobre un dataset fijo y committeado, con la salida literal pegada en la lección. Vas a poder copiar cada script, correrlo tú mismo, y obtener exactamente el mismo resultado, siempre —la misma garantía de determinismo que ya viste en el Módulo 1, ahora aplicada a una herramienta completa, no a un cálculo de una sola vez.

Conexión con el módulo

Las ocho lecciones de este módulo siguen una progresión estricta, cada una construida sobre la anterior. La lección 2 da el vocabulario que falta para elegir un buen SLI —las cuatro señales doradas de Google SRE—, aplicado a process-shipment-manifest. La lección 3 aplica la fórmula exacta (eventos buenos ÷ eventos válidos) por escrito, decidiendo con criterio qué cuenta como cada cosa para ese Lambda específico —el paso que ninguna calculadora puede automatizar, porque depende de juicio de negocio, no de aritmética—. Recién en la lección 4 aparece el código: error_budget_calculator.py, corrido sobre un dataset fijo de 30 días de tráfico, con la primera salida literal del módulo. La lección 5 usa esa misma herramienta para comparar tres SLOs distintos sobre los mismos datos reales, mostrando en números —no en teoría— por qué el SLO importa tanto como el SLI. La lección 6 extiende la calculadora con burn rate, la pieza que el Módulo 4 va a convertir en una alerta real. La lección 7 corre la herramienta completa sobre un segundo dataset, diseñado a mano para representar una semana mala de verdad. Y la lección 8 cierra con SLO.md: el documento que fija, con evidencia y no con una corazonada, el SLI y el SLO reales de Andes Cargo —el mismo documento que RELIABILITY-CHARTER.md dejó como fila Open en su mapa, y que el Módulo 3 en adelante va a medir y citar sin volver a discutir.

Analogía: de la tarjeta prepaga al plan de datos móviles

Ya conoces la tarjeta prepaga del Módulo 1: un error budget es un saldo mensual fijo, que se gasta rápido o lento, pero que no se repone antes de tiempo. Esa analogía explica bien cuánto saldo queda. Lo que no explica tan bien es la pregunta que este módulo agrega, sobre todo en la lección 6: ¿a qué velocidad lo estás gastando ahora mismo?

Para eso, un plan de datos móviles es más útil que una tarjeta prepaga. Los dos representan un tope mensual fijo —digamos, 20 GB al mes, sin reponerse antes de tiempo—, pero un plan de datos tiene algo que una tarjeta prepaga no necesita: un medidor que revisas a mitad de mes para saber si vas bien. Si llevas 10 GB gastados el día 15, vas exactamente al ritmo esperado —llegarás justo a 20 GB el día 30—. Si llevas 18 GB gastados el día 5, algo cambió: a esa velocidad, te quedas sin datos antes de que termine la primera semana, mucho antes de que el saldo total llegue a cero. La cifra que importa en ese momento no es "cuánto queda" —todavía queda 2 GB, técnicamente—, es la velocidad a la que se está gastando, porque esa velocidad es la que te dice si vas a llegar a fin de mes o no. Esa velocidad, aplicada al error budget de un sistema, es exactamente lo que este módulo llama burn rate: no el saldo, sino la tasa de consumo, medida contra la tasa que el SLO permite.

Vas a ver esta distinción con números reales en la lección 6: dos días del mismo dataset, mismo SLO, con el mismo saldo mensual restante técnicamente positivo — pero uno de esos días gastó datos a una velocidad que, sostenida, habría agotado el mes entero en cuestión de horas.

El mapa de este módulo: las 8 lecciones

   MODULO 2 — SLIs, SLOs Y EL ERROR BUDGET
   de la formula en prosa a la calculadora que corre de verdad

   M2.1  Introduccion (esta leccion)         el mapa, la promesa de la herramienta
   M2.2  Las 4 senales doradas                que medir, con ejemplos reales de Andes Cargo
   M2.3  Tu primera definicion de SLI          bueno/valido, decidido por escrito
   M2.4  La calculadora de error budget         EJECUTADO: primera corrida real
   M2.5  Eligiendo un SLO que signifique algo    EJECUTADO: 3 escenarios, mismos datos
   M2.6  Burn rate: la velocidad, no solo el saldo EJECUTADO: la calculadora extendida
   M2.7  Un escenario real de Andes Cargo         EJECUTADO: segundo dataset, una mala semana
   M2.8  Proyecto: SLO.md                          EJECUTADO: el documento que M3-M8 miden

#	Lección	Qué construye
1	Introducción (esta)	El mapa; retoma el 33,3x del Módulo 1; promete la herramienta reutilizable
2	Las cuatro señales doradas	Latencia, tráfico, errores, saturación — cada una aplicada a `process-shipment-manifest`
3	Tu primera definición de SLI	Bueno vs. válido, decidido con criterio, aplicado por escrito
4	La calculadora de error budget	`scripts/error_budget_calculator.py`, corrido sobre 30 días de tráfico fijo
5	Eligiendo un SLO que signifique algo	La misma calculadora, tres SLOs, mismos datos reales
6	Burn rate	La calculadora extendida con la fórmula de `sre.google/workbook/alerting-on-slos/`
7	Un escenario real de Andes Cargo	La calculadora sobre un segundo dataset: una semana mala, diseñada a mano
8	Proyecto: `SLO.md`	El documento con el SLI, el SLO y el presupuesto de error reales de Andes Cargo

Lo que ya tienes, y lo que todavía falta

Antes de escribir una sola línea de Python, vale la pena ser preciso sobre qué heredas del Módulo 1 y qué es genuinamente nuevo aquí:

Ya tienes, del Módulo 1:

El vocabulario completo —SLI, SLO, SLA, error budget, toil, on-call, postmortem— citado de Google SRE (lección 7 de ese módulo).
La fórmula de error budget en minutos: error_budget = (1 − SLO) × minutos_de_la_ventana, ya aplicada a mano en la lección 6 de ese módulo.
Un número de referencia: con un SLO hipotético de 99,9% mensual, el presupuesto es 43,2 minutos —y el incidente Claude Code consumió 33,3 veces eso en un solo evento.
RELIABILITY-CHARTER.md, con una fila explícitamente marcada Open: "¿Qué SLI y SLO tienen sentido para process-shipment-manifest, con evidencia?" — la pregunta exacta que este módulo contesta.

Todavía falta, y es lo que este módulo construye:

Un SLI real, no hipotético, definido con criterio sobre qué cuenta como "bueno" y qué cuenta como "válido" para process-shipment-manifest —nunca copiado de un ejemplo genérico de un blog.
Una herramienta que reciba cualquier SLO, cualquier ventana de tiempo y cualquier dataset de tráfico —no un script de un solo uso como el de la lección 6 del Módulo 1.
La fórmula de burn rate, que el cálculo manual del Módulo 1 nunca necesitó (comparaba un solo incidente ya terminado contra un presupuesto fijo; burn rate existe, específicamente, para detectar un consumo peligroso mientras todavía está pasando).
El primer SLO real de Andes Cargo, con su justificación, escrito en SLO.md — no un valor hipotético "para demostrar la aritmética" como el 99,9% de la lección 6 del Módulo 1, sino la decisión real que gobierna el resto de esta guía.

Errores comunes

Asumir que este módulo ya sabe cuál es el SLO de Andes Cargo desde la lección 1 (de anticipación). Qué pasa: alguien, al leer el mapa de este módulo, espera que la lección 2 o 3 ya mencionen un número de SLO concreto para Andes Cargo. Cómo detectarlo: si buscas un porcentaje de disponibilidad específico para Andes Cargo antes de la lección 5 de este módulo. Cómo corregirlo: el SLO real se elige recién en la lección 5, después de tener un SLI bien definido (lección 3) y una calculadora corriendo sobre datos reales (lección 4) — exactamente la misma disciplina que RELIABILITY-CHARTER.md ya defendió en el Módulo 1: ningún número se elige sin evidencia primero.

Tratar el cálculo manual del Módulo 1 y la calculadora de este módulo como cosas redundantes (de subestimar el salto). Qué pasa: alguien piensa "ya hice esta cuenta a mano, ¿para qué la vuelvo a hacer en Python?". Cómo detectarlo: si tu razonamiento es "el resultado va a ser el mismo de todas formas". Cómo corregirlo: el script de la lección 6 del Módulo 1 tenía cuatro variables fijas, hardcodeadas dentro del propio código — cambiar el SLO significaba editar el script línea por línea. La calculadora de este módulo recibe un dataset de tráfico real (no una sola cifra de "24 horas"), y sus funciones se reutilizan sin cambios en el Módulo 3 (con datos reales de CloudWatch), el Módulo 4 (con burn rate como alerta) y el Módulo 8 (capstone). La diferencia no es el resultado de un cálculo puntual — es que una es una herramienta y la otra fue, a propósito, un cálculo de una sola vez.

Pensar que burn rate es solo "otra forma de decir lo mismo" que el error budget (de fusionar dos conceptos distintos). Qué pasa: alguien, al llegar a la lección 6, asume que burn rate es simplemente el error budget expresado con otras palabras. Cómo detectarlo: si no puedes explicar la diferencia entre "cuánto presupuesto queda" y "qué tan rápido se está gastando ahora mismo" sin usar la palabra "budget" en la segunda parte. Cómo corregirlo: la analogía de esta lección lo separa con precisión — el saldo del plan de datos (error budget) y la velocidad de consumo (burn rate) son dos números distintos, calculados con fórmulas distintas, que pueden dar lecturas opuestas al mismo tiempo: un mes puede terminar con saldo positivo (error budget > 0) mientras tuvo, en algún momento, una racha de consumo peligrosamente rápida (burn rate alto) que un vistazo al saldo final nunca hubiera revelado. La lección 6 mide exactamente esa racha, con números reales.

Ejercicios

Ejercicio 1 — Explica, sin mirar atrás, qué le faltaba al script de la lección 6 del Módulo 1 para ser "la calculadora" que este módulo promete. Nombra al menos dos limitaciones concretas de ese script que la herramienta de este módulo va a resolver.

Ver solución

Dos limitaciones reales, entre varias posibles: (1) el SLO, la ventana y la duración del incidente estaban hardcodeados directamente en el código (SLO = 0.999, INCIDENT_HOURS = 24) — para probar un SLO distinto había que editar el script, no pasar un parámetro; (2) el script solo aceptaba una sola cifra de duración (24 horas), no un dataset de tráfico real con muchos días de datos —no había forma de calcular un SLI a partir de eventos buenos y válidos, porque el script nunca recibió ese tipo de dato—. La calculadora de este módulo resuelve ambas: sus funciones reciben un dataset de tráfico (lista de eventos válidos/buenos por día) y un SLO como parámetro, no como constante fija en el código.

Ejercicio 2 — Aplica la analogía del plan de datos a una situación concreta, sin hacer ningún cálculo todavía. Un plan de datos de 20 GB mensuales muestra, el día 20 del mes, un consumo acumulado de 13 GB. Usando solo la intuición de esta lección (sin fórmulas todavía, esas llegan en la lección 6), ¿ese consumo por sí solo te dice si el ritmo actual es sostenible hasta fin de mes? ¿Qué información adicional necesitarías?

Ver solución

No, el saldo acumulado por sí solo no lo dice — 13 GB de 20 GB en el día 20 de, digamos, un mes de 30 días, en realidad va por debajo del ritmo esperado (esperarías 20 × 20/30 ≈ 13,3 GB si el consumo fuera perfectamente parejo), así que a primera vista parece sano. Pero esa misma cifra acumulada no distingue entre "se gastó parejo todo el mes" y "se gastaron 12 GB de golpe ayer, y el resto del mes casi no se usó nada" — dos historias completamente distintas con el mismo saldo acumulado. La información adicional que hace falta es, exactamente, la velocidad de consumo en una ventana reciente y corta (por ejemplo, las últimas 24 horas), no el acumulado desde el inicio del mes — la misma distinción entre error budget (acumulado) y burn rate (velocidad reciente) que la lección 6 de este módulo calcula con números reales.

Ejercicio 3 — Nombra, de memoria, el orden exacto de las ocho lecciones de este módulo y por qué ese orden no puede invertirse. En particular, explica por qué la lección 3 (definir el SLI) tiene que ocurrir antes que la lección 4 (correr la calculadora), aunque la calculadora, técnicamente, no necesite ningún texto de definición para ejecutarse.

Ver solución

El orden: (1) introducción, (2) cuatro señales doradas, (3) definición de SLI por escrito, (4) calculadora de error budget, (5) elegir SLO, (6) burn rate, (7) escenario real, (8) SLO.md. La lección 3 precede a la 4 no por una razón técnica del código —la calculadora, en efecto, solo necesita números, no le importa de dónde salieron— sino por una razón de rigor: sin haber decidido primero, con criterio explícito, qué cuenta como "evento bueno" y qué cuenta como "evento válido" para process-shipment-manifest, cualquier número que la calculadora produzca en la lección 4 sería aritméticamente correcto pero conceptualmente hueco — un SLI que nadie puede defender si alguien pregunta "¿por qué contaste esa invocación como buena?". La lección 3 existe para que, cuando la lección 4 corra el script, cada número del dataset ya tenga una justificación decidida de antemano, no inventada para que el resultado se vea bien.

Resumen y siguiente paso

Esta lección conectó el cálculo manual del Módulo 1 —33,3x, un solo incidente, un script de un solo uso— con la promesa de este módulo: una calculadora real, reutilizable, que recibe cualquier SLO y cualquier dataset de tráfico, construida en las próximas siete lecciones. Viste el mapa completo, la analogía que va a gobernar la lección 6 (el plan de datos móviles: no solo cuánto queda, sino qué tan rápido se gasta), y la lista precisa de qué heredas del Módulo 1 frente a lo que todavía falta construir.

Antes de avanzar deberías poder: nombrar las ocho lecciones de este módulo en orden; explicar, con al menos dos razones concretas, por qué el script de la lección 6 del Módulo 1 no era todavía "la calculadora"; y explicar la diferencia entre error budget (saldo) y burn rate (velocidad) usando la analogía del plan de datos, sin usar fórmulas.

La lección 2 empieza por el principio real de cualquier SLI: antes de medir nada, hay que saber qué medir — las cuatro señales doradas de Google SRE, cada una aplicada con un ejemplo concreto sobre process-shipment-manifest.

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 manual que este módulo generaliza.
Este mismo repositorio, Módulo 1, lección 8 (08-project-andes-cargos-reliability-charter.md) — RELIABILITY-CHARTER.md, con la fila Open que este módulo cierra en la lección 8.
Google SRE Workbook — Implementing SLOs — la fórmula de error budget que este módulo generaliza en código.
Google SRE Workbook — Alerting on SLOs — la fuente exacta de burn rate, formalizada en la lección 6 de este módulo.

← Anterior8. Proyecto: la carta de confiabilidad de Andes Cargo Siguiente →2. Eligiendo un buen SLI: las cuatro señales doradas