¿Qué es un presupuesto de error y qué debería hacer un equipo cuando se agota?

Un presupuesto de error es la falta de fiabilidad que tu SLO permite. Si el SLO es del 99.9% en 28 días, el presupuesto es el 0.1% de las peticiones, unos 40 minutos de caída total. Los equipos lo gastan en lanzamientos arriesgados, migraciones y experimentos. Cuando se agota, la política escrita suele congelar las entregas de funcionalidades y redirigir al equipo a trabajo de fiabilidad hasta que el presupuesto se recupera en la ventana móvil.

El presupuesto no es más que el inverso del SLO. Con un 99.9% en 28 días teníamos unos 40 minutos de equivalente de caída total para gastar, y los gastábamos a propósito en cosas como una migración de base de datos o un despliegue arriesgado. Lo importante es la política, no el número. La nuestra decía que si quemábamos más de la mitad del presupuesto a mitad de ventana, los canarios se volvían más lentos y todo cambio necesitaba un segundo revisor, y si llegábamos a cero, las entregas de funcionalidades se paraban y el equipo trabajaba en fiabilidad hasta que la ventana móvil se recuperara. Eso lo aprobó la directora de producto antes de que hiciera falta, que es la única razón por la que aguantó la primera vez que lo invocamos. También teníamos alertas de tasa de consumo con varias ventanas, una rápida para un consumo de 14x en una hora y otra lenta para 6x en seis horas, así nos enterábamos durante el incidente y no a final de mes.