Módulo 4: Alerting On Error Budget Burn Rate
2. *Burn rate* multi-ventana, multi-tasa: el patrón real de Google SRE
Descripción
La lección 1 dejó el problema sin resolver: un umbral estático dispara demasiado tarde sobre una ventana larga, o con demasiado ruido sobre una ventana corta. Esta lección presenta la solución real, tal como la publica sre.google/workbook/alerting-on-slos/ —no una simplificación ni una aproximación de esta guía—: el patrón multi-window, multi-burn-rate, que combina una ventana larga (confirma que el consumo es real, no una casualidad de cinco minutos) con una ventana corta (confirma que el consumo sigue activo ahora, no que ya se resolvió), evaluadas juntas, nunca por separado.
Conexión con el módulo
Esta lección no introduce ningún dato nuevo — ya conoces el resultado exacto que produce, porque el Módulo 2, lección 6 ya lo corrió, con una sola fila de la tabla completa (Ticket, adaptada a granularidad diaria). Lo que esta lección agrega es el patrón completo, con las tres severidades, citado directamente de la fuente, y la razón exacta —no solo el resultado— de por qué dos ventanas evitan tanto los falsos positivos como los falsos negativos. La lección 3 implementa este patrón completo en Python, con las tres severidades a la vez.
La analogía: confirmar una fuga con dos medidores, uno rápido y uno lento
Retoma el tanque de combustible de la lección 1, con un detalle más: imagina que el camión tiene dos medidores de nivel, no uno. El medidor lento (la ventana larga) promedia el consumo de las últimas horas — es estable, no reacciona a un bache o una curva brusca, pero por esa misma razón tarda en notar que algo cambió. El medidor rápido (la ventana corta) reacciona en segundos — nota una caída súbita casi de inmediato, pero por esa misma sensibilidad también reacciona a ruido sin importancia (una curva pronunciada que inclina el tanque un momento).
Ninguno de los dos medidores, solo, es confiable. El medidor lento, solo, tarda demasiado en avisar de una fuga real. El medidor rápido, solo, genera falsas alarmas por cada bache del camino. Pero los dos juntos, exigiendo que ambos confirmen el mismo problema al mismo tiempo, sí son confiables: si el medidor rápido dice "está bajando fuerte, ahora" y el medidor lento dice "sí, y lleva un rato bajando así, no es un bache aislado", hay una fuga real. Si solo uno de los dos lo confirma, no. Esa es, exactamente, la lógica que Google SRE formaliza para alertar sobre burn rate.
La fuente, citada directamente
"A simple error-rate threshold produces two critical problems. Too Slow: with a 10-minute window at 99.9% SLO, a 0.1% error rate for 10 minutes would alert, while consuming only 0.02% of the monthly error budget. Too Much Noise: the approach exhibits low precision because the alert fires on many events that do not threaten the SLO, potentially generating 144 alerts daily while still meeting the SLO."
Esta cita es la versión formal, con cifras exactas, del problema que la lección 1 ya introdujo con el ejemplo del día 17. "Demasiado lento" y "demasiado ruidoso" no son intuiciones — son dos fallas medibles del mismo umbral simple, cuantificadas: una alerta que dispara consumiendo apenas 0,02% del presupuesto (irrelevante) o que podría disparar 144 veces al día (ruido puro) mientras el sistema sigue cumpliendo su SLO.
Qué es burn rate, otra vez, con la cifra de referencia completa
"Burn rate is how fast, relative to the SLO, the service consumes the error budget. [...] A 99.9% SLO with constant 0.1% error rate has a burn rate of 1, exhausting the 30-day budget exactly. A 1,000x burn rate (100% errors) depletes budget in 43 minutes."
El segundo dato de esta cita —un burn rate de 1.000x agota el presupuesto de 30 días en 43 minutos— es un ancla útil de intuición: a burn rate 1x, el presupuesto dura exactamente los 30 días completos (por definición); a burn rate 1.000x (100% de errores, el peor caso posible), el mismo presupuesto se agota en menos de una hora. El burn rate de 43,41x que la "mala semana" del Módulo 2 alcanzó está, en esta escala, mucho más cerca del extremo grave que del extremo sano.
El mecanismo de dos ventanas, citado
"[The multi-window strategy reduces false positives by requiring both conditions simultaneously:] send a page-level alert when you exceed the 14.4x burn rate over both the previous one hour and the previous five minutes. [This dual requirement ensures] the alert fires only once you've consumed 2% of the budget, but exhibits a better reset time by ceasing to fire five minutes later."
Esta es la pieza central: ambas condiciones, a la vez, no una u otra. La ventana larga (1 hora) confirma que el consumo elevado no es un instante aislado — necesita sostenerse por una hora completa para contar. La ventana corta (5 minutos) confirma que ese consumo sigue activo ahora — en cuanto el problema se resuelve, la ventana corta cae por debajo del umbral en minutos, y la alerta deja de disparar, sin esperar a que la ventana larga completa "se limpie" (que tardaría hasta una hora completa en promediar el evento ya resuelto).
La tabla completa de severidades
Tabla 5-8, Google SRE Workbook — Alerting on SLOs:
| Severidad | Ventana larga | Ventana corta | Burn rate | % del presupuesto que consume |
|---|---|---|---|---|
| Page (urgente) | 1 hora | 5 minutos | 14,4x | 2% |
| Page (urgente) | 6 horas | 30 minutos | 6x | 5% |
| Ticket (no urgente) | 3 días | 6 horas | 1x | 10% |
Tres filas, no una — y el orden importa. Las dos primeras (Page) son alertas urgentes: alguien recibe una notificación que exige atención casi inmediata, porque a ese ritmo de consumo, ignorarlo por horas tiene un costo real de presupuesto. La tercera (Ticket) es deliberadamente menos urgente: un burn rate de apenas 1x sostenido por 3 días completos no es una emergencia de las 3 AM — es exactamente el ritmo al que el SLO permite gastar el presupuesto, sostenido más tiempo del que un evento agudo normalmente dura, lo suficiente como para que alguien lo revise en horario laboral, sin despertar a nadie.
Por qué tres filas, no una: cada una detecta un patrón distinto
LAS TRES SEVERIDADES DETECTAN TRES FORMAS DE CONSUMIR EL PRESUPUESTO
Page (1h/5min, 14.4x) -> un incidente AGUDO: algo se rompio de golpe,
consume el presupuesto muy rapido, muy pronto
(el dia 17 del Modulo 2, con 13.27x, casi cruza este umbral)
Page (6h/30min, 6x) -> un incidente SOSTENIDO PERO MENOS AGUDO: mas lento
que el anterior, pero todavia serio si se ignora
Ticket (3d/6h, 1x) -> un DETERIORO GRADUAL: nunca dispara la urgencia,
pero sostenido el tiempo suficiente como para
merecer revision -- exactamente el patron que
la "mala semana" del Modulo 2 mostro dia a diaEl dataset "mala semana" del Módulo 2, lección 7, ya es un ejemplo perfecto de por qué hace falta más de una fila: el burn rate diario de esa semana (57,47x el día 2, 75,61x el día 3, bajando gradualmente hasta 17,54x el día 7) habría cruzado las tres filas de esta tabla en algún punto de la semana — un incidente real, agudo al principio, que se convierte en un deterioro sostenido conforme la mitigación avanza. Un sistema de alerting con una sola severidad habría tenido que elegir entre alertar de más al principio o de menos al final; con tres filas evaluadas en paralelo, cada una dispara y deja de disparar en el momento que le corresponde.
Aplicando el patrón al ejemplo ya conocido del Módulo 2
El Módulo 2, lección 6 ya corrió una versión de este patrón —una sola fila, la de Ticket, adaptada a la granularidad diaria del dataset fijo de esa lección (ventana larga de 3 días, ventana corta adaptada a 1 día en vez de 6 horas)—. El resultado, ya verificado entonces:
--- Ticket tier (ventana larga 3d / ventana corta 1d, umbral 1.0x) ---
Dia 17: ventana larga=4.52x ventana corta=13.27x -> DISPARA
Dia 18: ventana larga=6.74x ventana corta=6.85x -> DISPARA
Dia 19: ventana larga=6.67x ventana corta=0.00x -> no disparaEl día 19 es el ejemplo más importante de ese resultado, y vale la pena repetirlo aquí porque es la prueba concreta de por qué existe la ventana corta: la ventana larga (que todavía incluye los días 17-18) seguía en 6,67x —muy por encima del umbral—, pero la ventana corta (el día 19 solo) ya estaba en 0,00x. Sin la ventana corta, la alerta habría seguido disparando el día 19, sobre un problema que ya se había resuelto — el falso positivo exacto que la cita de esta lección describe ("a better reset time by ceasing to fire [...] later").
La lección 3 de este módulo hace lo que la lección 6 del Módulo 2 no pudo hacer todavía: implementa las tres filas completas de la tabla —no solo Ticket—, y las aplica no a un dataset diario, sino a burn rates ya calculados, tal como los produciría una consulta real de Prometheus o CloudWatch, con las ventanas literales de horas y minutos que la Tabla 5-8 especifica.
Errores comunes
Pensar que "multi-ventana" significa "evaluar el mismo umbral varias veces con distinta frecuencia" (de confundir frecuencia de evaluación con longitud de ventana, el mismo error que el Ejercicio 3 de la lección 1 ya desmontó). Qué pasa: alguien asume que basta con correr la misma consulta de burn rate cada minuto en vez de cada hora. Cómo detectarlo: si tu explicación del patrón no menciona dos ventanas de longitud distinta evaluadas simultáneamente. Cómo corregirlo: el patrón exige dos ventanas de duración diferente (1 hora y 5 minutos, por ejemplo), ambas evaluadas en el mismo instante, ambas exigiendo cruzar el mismo umbral — no una sola ventana evaluada con más frecuencia.
Usar solo la ventana larga, y tratar la ventana corta como opcional (el error que produce el falso positivo del día 19). Qué pasa: alguien implementa la alerta solo con la condición de la ventana larga, razonando que "si la ventana larga ya está alta, eso basta". Cómo detectarlo: si tu implementación seguiría disparando sobre el día 19 del ejemplo de esta lección. Cómo corregirlo: la ventana corta no es un refinamiento opcional — es la mitad de la condición AND que hace que la alerta deje de disparar en cuanto el problema real termina. Sin ella, cualquier alerta de burn rate hereda el mismo problema de "demasiado lento para resetear" que un umbral de ventana única ya tenía.
Asumir que la fila Ticket (1x, no urgente) es menos importante que las filas Page, y se puede omitir para simplificar (de subestimar el deterioro gradual). Qué pasa: alguien, al implementar la alerta, solo construye las dos filas Page, razonando que "un burn rate de apenas 1x no es grave". Cómo detectarlo: si tu sistema de alerta nunca notificaría un consumo sostenido de exactamente el ritmo permitido por el SLO, mantenido varios días. Cómo corregirlo: un burn rate de 1x sostenido por 3 días completos consume el 10% del presupuesto mensual completo — sin la fila Ticket, ese consumo pasaría completamente inadvertido hasta que fuera demasiado tarde para actuar con calma, exactamente el escenario que un equipo de guardia real prefiere revisar en horario laboral, no descubrir de golpe.
Ejercicios
Ejercicio 1 — Sin mirar la tabla, explica de memoria qué exige la fila Page (1h/5min, 14,4x) para disparar. Usa las palabras "ventana larga", "ventana corta" y "simultáneamente" en tu explicación.
Ver solución
La fila dispara únicamente cuando el burn rate calculado sobre la ventana larga (la última hora completa) y, simultáneamente, el burn rate calculado sobre la ventana corta (los últimos cinco minutos) están ambos en 14,4x o más. Si solo una de las dos ventanas cruza el umbral —por ejemplo, un pico breve de cinco minutos que no alcanza a elevar el promedio de la hora completa, o al revés, una hora con un promedio elevado por un evento que ya terminó hace más de cinco minutos— la alerta no dispara. Ambas condiciones, al mismo tiempo, son obligatorias.
Ejercicio 2 — Usando la cita de esta lección ("a 1,000x burn rate [...] depletes budget in 43 minutes"), calcula en cuántos minutos un burn rate sostenido de 100x agotaría el presupuesto mensual completo de Andes Cargo (43,2 minutos a 99,9% mensual, del Módulo 2).
Ver solución
El presupuesto completo (43,2 minutos) se agota en un tiempo real inversamente proporcional al burn rate: a burn rate 1x, se agota en el tiempo completo de la ventana del SLO (30 días = 43.200 minutos). A burn rate 100x, se agotaría 100 veces más rápido: 43.200 / 100 = 432 minutos, es decir, 7,2 horas. Verificación con la cifra citada: a burn rate 1.000x, sería 43.200 / 1.000 = 43,2 minutos — coincide exactamente con los "43 minutes" que la cita de Google SRE da como referencia para ese caso extremo. Este ejercicio confirma que la fórmula de burn rate (tiempo hasta agotar el presupuesto = ventana del SLO / burn rate) es consistente entre la cifra citada de la fuente y el presupuesto específico de Andes Cargo.
Ejercicio 3 — Explica por qué la Tabla 5-8 usa umbrales de burn rate distintos para cada fila (14,4x, 6x, 1x) en vez del mismo umbral con solo ventanas distintas. ¿Qué relación hay entre el umbral y el porcentaje de presupuesto consumido de cada fila?
Ver solución
Cada fila está diseñada para que, si se sostiene exactamente en su ventana larga, consuma el mismo porcentaje objetivo del presupuesto declarado en la última columna — no es casualidad que las cifras se relacionen: a burn rate 14,4x sostenido durante 1 hora, el consumo es 14,4x × (1 hora / 720 horas del mes) ≈ 2% del presupuesto mensual completo; a 6x sostenido durante 6 horas, 6 × (6/720) = 5%; a 1x sostenido durante 3 días, 1 × (72/720) = 10%. Cada fila responde a una pregunta distinta de urgencia: "¿este ritmo, si sigue así una hora, ya se comió el 2% del mes?" es una pregunta que merece una página inmediata; "¿este ritmo, sostenido tres días, se comió el 10%?" es una pregunta que puede esperar a que alguien la revise sin salir de la cama. El umbral y la ventana, juntos, calibran cuánta urgencia real representa cada patrón de consumo.
Resumen y siguiente paso
Esta lección presentó el patrón completo multi-window, multi-burn-rate de Google SRE, citado directamente de sre.google/workbook/alerting-on-slos/: dos ventanas —una larga, que confirma que el consumo es real; una corta, que confirma que sigue activo ahora— exigidas simultáneamente, nunca por separado, en tres severidades (Page 14,4x/1h+5min, Page 6x/6h+30min, Ticket 1x/3d+6h). Verificaste, con el ejemplo ya conocido del Módulo 2, lección 6, exactamente por qué la ventana corta evita el falso positivo del día 19 — el sistema ya se había recuperado, y solo la ventana corta lo reflejó a tiempo.
Antes de avanzar deberías poder: citar de memoria las tres filas de la Tabla 5-8, con sus ventanas y umbrales; explicar por qué ambas ventanas deben cruzar el umbral a la vez, no una sola; y calcular, dado un burn rate y una ventana de SLO, en cuánto tiempo se agotaría el presupuesto completo.
La lección 3 implementa este patrón completo —las tres severidades, no solo Ticket— en scripts/burn_rate_evaluator.py, corrido de verdad sobre el escenario "mala semana" y el escenario "normal" del Módulo 2.
Recursos
- Google SRE Workbook — Alerting on SLOs — fuente exacta de todas las citas de esta lección: el problema del umbral simple, la definición de burn rate, el mecanismo de dos ventanas, y la Tabla 5-8 completa.
- Este mismo repositorio, Módulo 2, lección 6 (
06-hands-on-burn-rate-not-just-the-balance.md) — la primera implementación parcial de este patrón (Tickettier, adaptada a granularidad diaria), que esta lección extiende a las tres severidades. - Este mismo repositorio, Módulo 2, lección 7 (
07-hands-on-applying-the-calculator-to-a-real-andes-cargo-scenario.md) — el dataset "mala semana", cuyo burn rate diario cruza, en algún punto de la semana, las tres filas de la Tabla 5-8.