Observabilidad y SLOs: presupuestos de error que se cumplen

Actualizado: 2026-05-03

SLOs (Service Level Objectives) y error budgets son conceptos clásicos de SRE popularizados por Google. La mayoría de equipos medianos los conoce, muchos los “tienen”, y pocos los gestionan de verdad. La diferencia está en si el error budget informa decisiones — si un feature freeze se dispara cuando el budget se agota, si la velocidad de deploy se ajusta cuando se consume rápido. Este artículo es sobre hacerlo funcionar de verdad, no solo documentar.

Puntos clave

• SLI mide algo relevante para el usuario; SLO define el objetivo; el error budget es la diferencia entre 100% y el SLO.
• La policy que se aplica cuando el budget se agota es donde se juega el valor real — si no hay consecuencias, el SLO no existe.
• Elegir buenos SLIs es lo más difícil: los SLIs puramente de infraestructura (CPU, memoria) no miden experiencia de usuario.
• Los antipatrones más comunes son SLOs aspiracionales, no respetar el freeze, y SLOs sin owner.
• Multi-window multi-burn-rate alerts son el estándar para evitar alert fatigue sin perder señal real.

El concepto básico

Tres definiciones que hay que tener claras:

• SLI (Service Level Indicator): métrica que mide algo relevante para el usuario. Ej.: “requests que completan en <500ms”, “availability” (uptime).
• SLO (Service Level Objective): objetivo para el SLI. Ej.: “99,9% de requests en <500ms durante 30 días”.
• Error budget: la diferencia entre 100% y el SLO. Si el SLO es 99,9%, el budget es 0,1% = 43 minutos al mes.

La parte potente: si el budget se agota, paras de desplegar features nuevas y enfocas en estabilidad.

Empezar sin ceremonia

No necesitas un comité de SLOs. Para cualquier servicio:

• Elige 2-3 SLIs relevantes: latencia p99 de los endpoints críticos, availability (requests exitosos / total), freshness (datos actualizados en X tiempo) si aplica.
• Define el SLO discutiéndolo con producto: “¿qué latencia degradaría la experiencia?”. Target: 99-99,9% para servicios críticos; 95-99% para menos críticos.
• Período: 30 días rolling como default.

No hace falta más para empezar. La sofisticación viene después si la necesitas.

Implementación con Prometheus

Ejemplo práctico para un API:

# SLI: fracción de requests exitosos en <500ms
- record: service:sli:success_fast:ratio_rate5m
  expr: |
    sum(rate(http_requests_total{service="api", status!~"5..", duration_bucket="0.5"}[5m]))
    /
    sum(rate(http_requests_total{service="api"}[5m]))

# Burn rate del error budget
- record: service:error_budget:burn_rate_1h
  expr: |
    (1 - service:sli:success_fast:ratio_rate5m) / 0.001  # 0.001 = SLO 99.9%

# Alerta si el burn rate es alto
- alert: ErrorBudgetBurnFast
  expr: service:error_budget:burn_rate_1h > 14.4  # 1h de 2% del budget
  for: 2m
  annotations:
    summary: "Consumiendo 2% del error budget mensual por hora"

Multi-window multi-burn-rate alerts (del SRE Workbook de Google) son el estándar: burn rate alto en corto = alerta urgente; burn rate sostenido = alerta moderada.

Error budget policy: la parte política

Definir el SLO es fácil. La policy que se aplica cuando se agota es donde se juega el valor real.

Política típica por niveles de consumo:

• >50% consumido: precaución, más revisión de deploys.
• >75% consumido: cautela, reducir cambios no esenciales.
• >100% consumido: feature freeze, solo fixes. Inversión en estabilidad.
• >150% consumido: escalado a management, auditoría de causas.

La clave es que la policy se respeta. Si cuando se dispara, producto anula la decisión, el SLO no existe de facto.

SLI design: el verdadero trabajo

Elegir buenos SLIs es lo más difícil. Los red flags más comunes:

• SLIs puramente de infraestructura (CPU, memoria): no miden experiencia de usuario.
• SLIs que no correlacionan con usuario molesto: “200 responses” puede incluir respuestas vacías.
• SLIs agregados a nivel servicio para APIs con múltiples endpoints críticos y no críticos mezclados.
• SLIs sin ventana de tiempo clara.

Los mejores SLIs miden métricas end-user visibles: latencia de endpoints públicos, errores que el usuario ve, datos correctos. Si el producto cambió, el SLI puede haber dejado de correlacionar con la experiencia real — revisión trimestral es necesaria.

Error budget como herramienta de conversación

El mayor valor de los SLOs y error budgets es alinear conversaciones entre disciplinas:

• Producto entiende que “ir más rápido” tiene un coste cuantificable en términos de budget consumido.
• Ingeniería tiene un umbral claro para pedir tiempo de estabilización, sin necesitar “vender” el argumento.
• Management ve métricas que correlacionan con satisfacción del cliente.

Sin esto, las decisiones sobre “¿features o estabilidad?” son políticas. Con budgets, son basadas en datos.

El contexto de post-mortems blameless y SLOs son herramientas complementarias: los SLOs definen cuándo actuar; los post-mortems explican por qué se llegó hasta ahí y cómo no repetirlo.

Alert fatigue y SLOs

Un error común es convertir el burn rate alert en SEV-1. El resultado: equipos despertados cada diez días por ruido.

El patrón correcto:

• Multi-window multi-burn-rate: las alertas importan solo si el burn es persistente.
• SEV levels diferenciados: burn rate extremo = SEV-1; burn moderado = ticket para el día siguiente.
• Ticketing en vez de pager para casos no críticos.

El objetivo es alertar cuando hay acción real que tomar, no en cada spike puntual.

Herramientas

Stacks típicos para implementar SLOs:

• Prometheus + Grafana + recording rules: DIY, flexible, requiere trabajo inicial.
• Sloth^[1]: generador de recording rules y alertas desde un YAML simple — el punto dulce para equipos pequeños.
• Pyrra^[2]: SLO as code + UI nativa.
• Datadog SLOs: integrado, fácil, vendor lock-in.
• Google Cloud Service Monitoring: para entornos GCP-native.

Para Prometheus y métricas de los servicios, Loki a escala complementa la capa de logs con la misma infraestructura Grafana.

Antipatrones

Cosas que rompen los SLOs en la práctica:

• SLOs aspiracionales sin realismo: 99,99% cuando el servicio real está a 99%. Budget consumido siempre, policy ignorada siempre.
• No respetar el freeze cuando se agota: destruye la credibilidad del mecanismo de inmediato.
• SLOs sin owner claro: nadie los mantiene, se vuelven obsoletos.
• Demasiados SLOs: 20 SLOs por equipo = ninguno recibe atención real.
• SLIs manipulables: “los 500 no cuentan si vienen de ese endpoint” — el gaming destruye el sentido del sistema.

Revisión trimestral

Los SLOs no son estáticos. Cada quarter, revisar con los datos del trimestre:

• ¿SLO demasiado laxo? (budget siempre disponible): apretarlo para que sea exigente.
• ¿SLO demasiado estricto? (siempre agotado): relajarlo o invertir en arquitectura.
• ¿El SLI todavía representa la experiencia real? Si el producto cambió, puede haber dejado de correlacionar.

Conclusión

Los SLOs y error budgets funcionan cuando se aplican con rigor, no como documentación ornamental. El test es simple: ¿hay decisiones que cambian según el budget? Si la respuesta es sí, el sistema funciona. Si no, es teatro. Empezar con 2-3 SLIs bien elegidos, política clara de freeze y herramientas sencillas (Prometheus + Sloth) es lo más productivo. La sofisticación viene después; primero, que se respete lo básico.

1. Sloth
2. Pyrra