Calculadora de Error Budget
Calcula el error budget de un objetivo de SLO: downtime permitido y solicitudes fallidas.
- Error budget
- 0.100%
- Allowed downtime
- 43.2 min
- Allowed failed requests
- 1,000
Descripción general
Un SLO es una promesa expresada como proporción: esta fracción de peticiones va a tener éxito. Su corolario útil es el resto: el presupuesto de error, la cantidad de fallo que tienes permitida antes de haber roto la promesa.
Plantear la fiabilidad como un presupuesto cambia la conversación. «No rompas nada» no es un objetivo de ingeniería, porque pone el riesgo a precio infinito y por tanto prohíbe entregar. «Tienes 43 minutos de indisponibilidad este mes y ya te has gastado 12» sí es un objetivo con el que se puede planificar.
Esta calculadora convierte un SLO en tres cifras: el presupuesto como porcentaje, la indisponibilidad permitida en tu ventana y, si le das un número de peticiones, la cantidad de fallos individuales que caben dentro.
Cómo se usa
- Introduce el SLO al que te comprometes, como porcentaje.
- Fija la ventana en días. 30 es el mes móvil habitual; 7 funciona para un ciclo de realimentación más corto; 90 encaja con una revisión trimestral.
- Opcionalmente, introduce el volumen de peticiones de esa ventana para obtener el número de fallos.
Cómo se leen las cifras
El presupuesto de error es simplemente 100% − SLO. Parece
insignificantemente pequeño al lado del SLO, y de eso se trata: la diferencia
entre el 99,9 % y el 99,99 % es una reducción de diez veces en lo que tienes
permitido gastar, y por eso cada nueve adicional cuesta mucho más que el
anterior.
El tiempo de caída permitido es ese presupuesto aplicado a la ventana como tiempo de reloj. Es la cifra más útil para hablar con gente de fuera del equipo, porque «unos 43 minutos al mes» es concreto de una manera en la que «99,9 %» no lo es.
Las peticiones fallidas permitidas son el mismo presupuesto aplicado al volumen. Esta es la cifra con la que conviene planificar, porque se corresponde directamente con lo que puedes observar en tus métricas: un recuento de respuestas 5xx, o de peticiones por encima de tu umbral de latencia.
El presupuesto en tiempo y el presupuesto en peticiones no son lo mismo
Dos incidentes pueden consumir un presupuesto de tiempo idéntico y presupuestos de peticiones radicalmente distintos, y al revés.
Una caída total de cinco minutos a las 03:00 cuesta cinco minutos de indisponibilidad y muy pocas peticiones. Una degradación de un día entero en la que falla el 0,5 % de las peticiones casi no cuesta «tiempo de caída» según una definición ingenua, y puede agotar el presupuesto de peticiones de un mes.
Los usuarios viven la segunda. Si solo mides la disponibilidad como tiempo, subestimarás de forma sistemática los fallos que más molestan a la gente, porque los fallos parciales no llegan a registrarse como caída.
La salida habitual es definir el SLI como una proporción de eventos buenos sobre eventos válidos —peticiones correctas sobre peticiones totales, o peticiones rápidas sobre peticiones totales— y derivar una cifra en tiempo solo para comunicar.
Qué consume el presupuesto de verdad
El error es tratar el presupuesto como el margen reservado para incidentes. En la práctica se comparte con todo lo que hace fallar peticiones:
- Despliegues. Incluso una entrega limpia corta conexiones si no todas las capas drenan bien.
- Mantenimiento planificado. Si el usuario lo nota, cuenta, lo hayas anunciado o no.
- Fallos de dependencias. Tu presupuesto se lo gastan los incidentes de tu proveedor, y ahí no votas.
- La cola larga. Tiempos de espera aislados, reintentos que se agotaron, un nodo malo. Casi nunca llegan a ser incidentes y suman.
Por eso los equipos que presupuestan consumir el 100 % del presupuesto de error se pasan. Planifica gastar una fracción en incidentes y deja el resto para el coste ordinario de operar.
Ejemplos
- 99,9 % en 30 días: unos 43 minutos. Un despliegue malo con una reversión lenta puede gastarse casi todo el mes.
- 99,95 % en 30 días: unos 22 minutos. Aquí es donde la reversión manual deja de ser lo bastante rápida y necesitas automatizarla.
- 99,99 % en 30 días: unos 4 minutos. Solo es alcanzable con conmutación multirregión que se active sin una persona en medio.
- 99,999 % en 30 días: unos 26 segundos. Solo detectarlo suele llevar más que eso, así que la arquitectura tiene que tolerar los fallos en lugar de reaccionar a ellos.
Cada escalón es, a grandes rasgos, una reducción de diez veces en el fallo permitido y un salto de categoría en el coste. Elige el SLO a partir de lo que los usuarios necesitan de verdad, no de cuántos nueves suenan impresionantes: una canalización interna por lotes al 99,99 % es dinero gastado en beneficio de nadie.
Notas
La ventana se toma como exactamente el número de días que introduces, así que un mes de 30 días son 2.592.000 segundos. Los meses naturales varían hasta en tres días, lo que importa si estás cuadrando cuentas contra un contrato; una ventana móvil de 30 días es la elección operativa más común y esquiva el problema.
El recuento de peticiones fallidas se trunca, no se redondea, porque un fallo parcial no es algo que se pueda gastar.
Para la disponibilidad expresada como cifra contractual con tramos de penalización, usa la calculadora de SLA. Responde a la pregunta vecina —cuánto tiempo de caída permite una promesa de disponibilidad dada— sin la parte del volumen de peticiones.