Error budgets y políticas de despliegue

El Permiso para Fallar

En el primer capítulo, establecimos que un SLO del 100% es una mala idea. La diferencia entre nuestro objetivo (el SLO) y el 100% es el Error Budget o Presupuesto de Error.

Error Budget = 100% - SLO

Si nuestro SLO de disponibilidad es del 99.9%, nuestro Error Budget es del 0.1%. Este 0.1% no es solo un número; es una herramienta de negociación y toma de decisiones para todo el equipo. Representa la cantidad de “fallos” aceptables que nos podemos permitir durante un período determinado (ej. 30 días) sin incumplir la promesa hecha a nuestros usuarios.

¿Cómo Usamos el Error Budget?

El Error Budget es el recurso que el equipo “gasta” cuando quiere asumir riesgos. Estos riesgos son, en su mayoría, el lanzamiento de nuevo software. Cada despliegue, por muy probado que esté, tiene el potencial de introducir bugs y causar fallos que consuman el presupuesto.

Aquí es donde el Error Budget se convierte en una regla objetiva para balancear la innovación con la fiabilidad:

  • Si queda mucho Error Budget: ¡Luz verde! El equipo tiene un amplio margen para lanzar nuevas funcionalidades, hacer experimentos, realizar mantenimientos o probar nuevas configuraciones. La fiabilidad del servicio es alta y podemos permitirnos asumir riesgos.

  • Si el Error Budget se está agotando: ¡Luz ámbar! Es momento de ser cautelosos. Quizás los despliegues deban ser menos frecuentes o someterse a un escrutinio mayor. El equipo debe analizar por qué se está consumiendo el presupuesto. ¿Es por un bug reciente? ¿Inestabilidad en la infraestructura?

  • Si el Error Budget está agotado (o en negativo): ¡Luz roja! Se impone un “feature freeze” (congelación de funcionalidades). El equipo debe detener todos los lanzamientos de nuevo código y centrar el 100% de sus esfuerzos en mejorar la fiabilidad del servicio hasta que el Error Budget se recupere.

La Política del Error Budget

Para que este sistema funcione, todo el equipo (desarrolladores, SREs, Product Managers) debe estar de acuerdo en una Política de Error Budget. Esta política es un documento o acuerdo que define claramente las reglas.

Un ejemplo de política podría ser:

  1. SLO de Disponibilidad: 99.9% en los últimos 30 días.
  2. Error Budget: 0.1% de peticiones fallidas en 30 días (aprox. 43 minutos de downtime total).
  3. Condiciones de Despliegue:
    • > 50% del Budget restante: Se permiten despliegues automáticos a producción.
    • < 50% del Budget restante: Todos los despliegues requieren revisión manual y aprobación de un SRE lead.
    • < 10% del Budget restante: Se declara un “Code Yellow”. Se prohíben los despliegues de nuevas funcionalidades. Solo se permiten hotfixes para bugs críticos de fiabilidad.
  4. Fin del “Code Yellow”: El estado de alerta termina cuando el SLO vuelve a estar por encima del objetivo durante 7 días consecutivos.

Conclusión

El Error Budget es mucho más que una métrica. Es un mecanismo de auto-regulación que alinea a todo el equipo hacia un objetivo común. Elimina las discusiones subjetivas sobre si “ir más rápido” o “ser más estable” y las reemplaza con una decisión basada en datos: el estado actual de nuestro presupuesto de error.