Un presupuesto de errores (error budget) es la cantidad de fallos que tu SLO permite en un periodo: el 100 % menos el objetivo. Un SLO del 99,9 % en 30 días deja un presupuesto de errores de 43 minutos y 12 segundos de caída, o una petición fallida de cada mil. Mientras quede presupuesto, el equipo puede desplegar y asumir riesgos. Cuando se agota, el trabajo de fiabilidad pasa por delante hasta que la ventana se recupera.
Esa única regla convierte un objetivo de fiabilidad en decisiones. Esta guía explica cómo calcular un presupuesto de errores, qué debería consumirlo y qué no, cómo saber a qué ritmo lo estás gastando y cómo redactar una política para cuando se acabe.
Cómo calcular un presupuesto de errores
Necesitas dos cosas: un SLO, el objetivo de fiabilidad que te fijas tú mismo, y una ventana, el periodo en el que se mide. El presupuesto de errores es lo que queda entre el objetivo y la perfección.
Error budget = (100% − SLO) × window
Para un SLO del 99,9 % en 30 días (43.200 minutos): 0,1 % × 43.200 = 43,2 minutos, es decir, 43 minutos y 12 segundos. La tabla muestra el mismo cálculo para los objetivos más habituales, redondeado a la baja al segundo.
SLOPresupuesto en 30 díasPresupuesto en 90 días99 %7h 12m21h 36m99,5 %3h 36m10h 48m99,9 m 12s2h 9m 36s99,95 m 36s1h 4m 48s99,99 %4m 19s12m 57s
La calculadora de SLA y uptime hace este cálculo para cualquier objetivo y periodo. Usa el mes medio (un año dividido entre 12), así que muestra 43 minutos y 49 segundos para el 99,9 % en lugar de la cifra de 30 días de arriba.
Por tiempo o por peticiones
Un presupuesto de errores se puede contar en dos unidades, según el SLI que haya detrás de tu SLO:
Por tiempo: minutos de caída, medidos con comprobaciones desde fuera. Es sencillo, fácil de explicar y encaja con cómo se redactan la mayoría de los SLA con clientes. Un SLO mensual del 99,9 % permite unos 43 minutos.
Por peticiones: el porcentaje de peticiones que fallaron, contado a partir de los logs del balanceador de carga o de la aplicación. Con 2 millones de peticiones al mes y un 99,9 %, el presupuesto es de 2000 peticiones fallidas. Da más peso a las horas de mucho tráfico que a las tranquilas, lo que se acerca más a lo que perciben los usuarios, pero necesita unos logs en los que confíes.
Muchos equipos usan los dos: un presupuesto por tiempo basado en comprobaciones externas para el servicio en su conjunto, y presupuestos por peticiones para los endpoints más importantes, como el checkout o la API.
Para qué sirve un presupuesto de errores
Sin un presupuesto, la fiabilidad es una discusión. Producto quiere lanzar, ingeniería quiere frenar y gana quien habla el último. Un presupuesto sustituye la discusión por un número que ambas partes han acordado de antemano.
Convierte el 100 % en el objetivo equivocado. Un objetivo del 100 % no deja presupuesto, así que cada despliegue es un riesgo que nadie puede asumir. De todos modos, a través de su propia wifi y de las redes móviles, los usuarios no distinguen un 99,99 % de un 100 %.
Hace que el riesgo se pueda gastar. Una gran migración, una región nueva o un lanzamiento arriesgado se pueden planificar para que quepan en el presupuesto que queda este mes.
Decide las prioridades por ti. Cuando el presupuesto se acaba, la política dice qué pasa a continuación, así que nadie tiene que ganar una reunión para meter el trabajo de fiabilidad en el roadmap.
Qué consume el presupuesto
Todo lo que tu SLI cuente como malo consume presupuesto. Decídelo cuando redactes el SLO, no en mitad del incidente.
Caídas confirmadas: el servicio no respondió, respondió con un error o respondió con un contenido incorrecto.
Respuestas lentas, si tu SLI dice que una petición más lenta que un límite cuenta como fallida. Una página que tarda 30 segundos está disponible, pero no se puede usar.
Despliegues fallidos y rollbacks, por los minutos en que los usuarios vieron errores.
Caídas de tus proveedores. Si falla tu proveedor de pagos o tu hosting de DNS, tus usuarios siguen sin poder completar la compra. Consume tu presupuesto aunque la solución no dependa de ti, lo que es un buen motivo para vigilar los servicios de los que dependes.
Mantenimiento planificado, solo si el SLO lo indica. Muchos equipos excluyen las ventanas de mantenimiento anunciadas, con un límite al mes.
Lo que no debería consumirlo: los falsos positivos. Una única comprobación fallida por un fallo puntual de red no es una caída. Confirma un fallo con una segunda comprobación antes de contarlo, o tu presupuesto se irá en problemas que los usuarios nunca vieron.
Burn rate: a qué ritmo lo estás gastando
El presupuesto te dice cuántos fallos te puedes permitir. El burn rate (tasa de consumo) te dice a qué velocidad lo estás usando. El SRE workbook de Google lo define como la velocidad a la que el servicio consume el presupuesto de errores en relación con el SLO (Alerting on SLOs).
Un burn rate de 1 gasta todo el presupuesto justo al final de la ventana.
Un burn rate de 2 lo gasta en la mitad de la ventana: 15 días de un mes de 30.
Una caída total consume a un ritmo de 1000 frente a un SLO del 99,9 %, porque cada minuto caído equivale a mil veces el ritmo permitido. Veinte minutos así gastan el 46 % de un presupuesto de 30 días.
El punto de partida que recomienda el workbook para un SLO del 99,9 % avisa a alguien de guardia cuando se consume el 2 % de un presupuesto de 30 días en una hora (un burn rate de 14,4) o el 5 % en seis horas (un burn rate de 6), y abre un ticket cuando se consume el 10 % en tres días (un burn rate de 1). Cada alerta comprueba además una ventana corta, para que deje de saltar poco después de que se acabe el problema.
Ante una caída total, una alerta de burn rate y una alerta normal de «la web está caída» saltan más o menos a la vez. Los burn rates demuestran su valor en los fallos parciales: un 3 % de peticiones fallando durante horas, algo que nunca tira la web pero que, sin hacer ruido, se come el presupuesto del mes antes del miércoles.
Redacta una política de presupuesto de errores
Un presupuesto sin política no es más que un número en un dashboard. La política dice, de antemano, qué hace el equipo en cada nivel de consumo. Acordadla entre producto e ingeniería y dejadla por escrito donde ambos puedan encontrarla. Google publica un ejemplo de política de presupuesto de errores que vale la pena leer antes de escribir la tuya.
Una política sencilla para empezar
Queda presupuesto: se despliega con normalidad. El trabajo arriesgado planificado sigue adelante.
La mitad gastada antes de la mitad de la ventana: el responsable de guardias revisa los incidentes hasta la fecha y señala la causa principal.
Presupuesto agotado: solo se despliegan correcciones de errores y trabajo de fiabilidad hasta que la ventana se recupere. Las migraciones arriesgadas esperan.
Un solo incidente ha gastado más de una quinta parte del presupuesto: se redacta un postmortem con al menos una acción de seguimiento.
Las excepciones las deciden personas concretas, por ejemplo el responsable de ingeniería y el de producto juntos, y quedan por escrito.
Los umbrales son ejemplos, no normas. Elige unos que tu equipo vaya a respetar de verdad. Una política que se ignora la primera vez que aprieta es peor que no tener ninguna, porque enseña a todos que el SLO no importa.
Errores habituales
Fijar el SLO igual que el SLA. Así el presupuesto se agota justo cuando ya les debes a los clientes créditos de servicio. Mantén el SLO más estricto que el SLA, para que la alarma interna suene antes. SLA vs SLO vs SLI explica cómo encajan los tres.
Una ventana demasiado corta. Un presupuesto semanal se reinicia antes de que una mala semana pueda cambiar nada. Lo habitual son treinta días, móviles o por mes natural.
Olvidar cómo se reinicia la ventana. Un mes natural empieza de cero el día 1, así que una mala última semana se olvida en días. Una ventana móvil de 30 días la recuerda durante un mes, lo que es más estricto y más justo.
Mirar solo el total. Una caída de 40 minutos y cuarenta caídas de 1 minuto gastan el mismo presupuesto, pero la segunda situación interrumpe el trabajo de los usuarios a diario. Sigue el número de incidentes y el MTTR junto al presupuesto.
Medir solo desde dentro. Los logs del servidor no pueden registrar peticiones que nunca llegaron. Un certificado caducado o un registro DNS roto consumen un presupuesto que solo ve una comprobación externa.
Seguimiento de un presupuesto de errores por tiempo con Uptimecheck
Uptimecheck te da las cifras que necesita un presupuesto por tiempo. La monitorización de uptime comprueba hasta cada minuto desde Estocolmo, Londres y Nueva York, y confirma cada comprobación fallida desde una segunda ubicación, para que un fallo puntual no consuma presupuesto. Las ventanas de mantenimiento y el tiempo en pausa no cuentan en contra del uptime.
Los informes muestran el uptime, el tiempo de caída y los incidentes de cada monitor para este mes, el mes pasado o los últimos 7, 30 o 90 días, frente a un objetivo de SLA del 99 %, 99,5 %, 99,9 %, 99,95 % o 99,99 %, con descarga en CSV. El presupuesto que queda es el tiempo de caída permitido menos el tiempo de caída del informe. Consulta cómo generar informes frente a un objetivo de SLA.
Los incidentes guardan las pruebas y una cronología de cada comprobación, alerta y nota, que es justo lo que necesita un postmortem. Consulta gestión de incidentes.
Las ventanas de mantenimiento dejan el trabajo planificado fuera de las cifras. Consulta cómo programar ventanas de mantenimiento.
Para ponerle precio al presupuesto que gastas, prueba la calculadora del coste de las caídas. Para ver qué permite cada objetivo, lee qué significa un 99,9 % de uptime.
Sabe cuánto presupuesto te queda antes de que acabe el mes. Prueba Uptimecheck gratis durante 14 días, sin tarjeta de crédito.