Un bug menor elevó la tasa de errores un 0,05%. El primer instinto del ingeniero de guardia es revertirlo todo de inmediato. Pero un rollback bajo presión introduce su propio riesgo: un nuevo despliegue, una nueva superficie de fallo, una decisión tomada en modo pánico. El SRE experimentado hizo otra cosa — miró el error budget restante. Con el 98% del presupuesto mensual todavía disponible, había margen de sobra para un fix-forward tranquilo, y un rollback de emergencia solo habría añadido inestabilidad. Eso no es un fracaso — es imperfección planificada, exactamente para lo que existe el presupuesto.
Todo el valor del enfoque SLO descansa en una sola idea: antes de reaccionar a una desviación, mira el presupuesto. Un saldo alto significa tiempo para una corrección reflexiva. Uno bajo significa mitigar ahora y escribir el postmortem después. Un número en lugar de una discusión.
Un presupuesto para el riesgo, no para la perfección
SLI es una métrica medible de lo que el usuario realmente siente: la proporción de peticiones exitosas, la proporción de peticiones más rápidas que 200 ms. SLO es el valor objetivo de esa métrica en una ventana (digamos, 99,9% en 30 días). Y error budget = 1 − SLO es la «proporción de lo malo» admisible. Para un 99,9% en un mes, el presupuesto equivale a unos 43 minutos de indisponibilidad.
El cambio mental clave: esos 43 minutos no son algo de lo que avergonzarse — son un recurso que puedes gastar. En releases arriesgados, en experimentos, en migraciones. Agotar el presupuesto hasta cero es una señal, no una catástrofe.
De ahí se sigue también que perseguir los «cinco nueves» (99,999%) es casi siempre contraproducente. El coste de la fiabilidad crece de forma exponencial, y por encima del 99,9% topas con los SLO de tus propias dependencias — el balanceador de carga de la nube, el DNS, las APIs externas. Los objetivos realistas son más modestos: una herramienta interna de administración vive en el 99%, un sitio web público en el 99,9%, una API crítica en el 99,95%, los pagos en el 99,99%. Un objetivo de «99,999% y más rápido» no inspira a un equipo — lo desmoraliza.
La Error Budget Policy — una palanca, no un adorno
Por sí solo, el presupuesto es solo un número. Lo que le da fuerza es una política: acciones acordadas de antemano, ligadas a cuánto presupuesto queda.
- Más del 50% restante — desplegar features con libertad.
- 20–50% — exigir un periodo de reposo en staging antes de prod (un día, por ejemplo).
- Por debajo del 20% — congelar los cambios no críticos, foco en fiabilidad.
- Presupuesto agotado — congelación total, todo el sprint se dedica a trabajo de fiabilidad.
El sentido de esta tabla es que pone fin a la eterna discusión sobre «¿congelamos ahora?». La decisión está ligada a un número, no a quién grita más fuerte en el chat. El negocio obtiene una herramienta para gestionar el equilibrio entre velocidad y estabilidad sin tener que leer PromQL.
Pero una política sin dientes es inútil. Si el presupuesto está agotado y el equipo sigue desplegando features por «la fecha límite», el presupuesto es decorativo y toda la construcción pierde su sentido. Una política funciona solo en la medida en que la organización está dispuesta a seguirla.
Multi-burn-rate: cómo el presupuesto se convierte en alerta
Un error típico es montar una alerta para «el SLO cayó por debajo del 99,9%». Ese umbral salta ante una pérdida de menos de un punto porcentual y despierta a la guardia para nada. Mucho más preciso es medir la burn rate — la velocidad a la que se consume el presupuesto — en varias ventanas a la vez.
La lógica es simple. Si quemamos el 2% del presupuesto mensual en una hora, eso es crítico y un aviso en mitad de la noche está justificado (burn rápida, burn_rate_1h > 14,4 × 0,001, confirmada por una ventana corta de 5 minutos). Si el 5% se va en seis horas, es grave pero basta un ticket en horario laboral (burn lenta, burn_rate_6h > 6 × 0,001 con una confirmación de 30 minutos). La ventana doble — una larga más una corta de confirmación — filtra las falsas alarmas de un pico aleatorio.
Los multiplicadores 14,4 y 6 no son magia; son las tablas estándar del SRE Workbook para un SLO del 99,9%. Generadores como Sloth emiten estas reglas a partir de una breve especificación YAML, añadiendo recording rules para las ventanas de 5m/30m/1h/6h para que Grafana y las alertas lean métricas ya calculadas en lugar de computar PromQL pesado en cada render.
La misma burn rate funciona también como puerta de despliegue: una regla de «detener los rollouts ante una burn rate de 10×» es transparente para CI/CD. La aritmética convence — 10× para un 99,9% quema el presupuesto mensual en tres días; si despliegas una regresión en ese momento, el agotamiento total llega en horas. Esto encaja con la política: un presupuesto agotado significa una congelación total, una burn rate alta una preventiva.
En conjunto, SLO, error budget y multi-burn-rate no son tres prácticas separadas sino una sola cadena: la métrica mide el dolor del usuario, el presupuesto lo convierte en un recurso, y la política y las alertas convierten ese recurso en decisiones. El presupuesto se convierte en un lenguaje común en el que el negocio y los ingenieros pueden ponerse de acuerdo — sin pánico y sin discusiones.