Observabilidad y SLOs: presupuestos de error que se cumplen

javi
Gráfico de líneas ascendentes representando métricas de servicio en tiempo real

SLOs (Service Level Objectives) y error budgets son conceptos clásicos de SRE popularizados por Google. La mayoría de equipos medianos los conocen, 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.

El concepto básico

  • 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 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 nuevos y enfocas en estabilidad.

Empezar sin ceremonia

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

  • Escoge 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. Sofisticación viene luego si la necesitas.

Implementación con Prometheus

Ejemplo práctico para un API:

# SLI: fraction 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]))

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

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

Multi-window multi-burn-rate alerts (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:

  • >50% budget 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: la policy se respeta. Si cuando se dispara, producto anula la decisión, el SLO no existe.

SLI design: el verdadero trabajo

Elegir buenos SLIs es lo más difícil. Red flags:

  • SLIs puramente de infra (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.
  • SLIs sin ventana de tiempo clara.

Mejor:

  • Métricas end-user visibles: latencia de endpoints públicos, errors que el usuario ve, datos correctos.
  • SLIs por dimensión: por endpoint, por tenant, por región — si importan.
  • Ventana consistente: rolling 30 días es práctico.

Multi-SLO: cuando hay varios servicios

Organizaciones medianas tienen 20+ servicios. Multiplicar SLOs per servicio es caótico. Patrón útil:

  • SLOs por “user journey” en vez de por servicio. Ej: “signup flow SLO” incluye backend, frontend, email delivery.
  • SLOs agregados por tenant — qué experiencia reciben los clientes que más te importan.
  • SLOs en niveles: “north star SLO” (customer-facing) + “component SLOs” técnicos.

No todos los servicios necesitan SLO formal; solo los customer-facing o aquellos con dependencias críticas.

Error budget como herramienta de conversación

El valor mayor de SLOs/budgets es alinear conversaciones:

  • Producto entiende que “ir más rápido” tiene coste cuantificable (más consumo de budget).
  • Engineering tiene un umbral claro para pedir tiempo de estabilización.
  • Management ve métricas que correlacionan con satisfacción cliente.

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

Alert fatigue y SLOs

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

Mejor patrón:

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

El objetivo es alertar cuando haya acción real, no cada spike.

Herramientas

Stacks típicos para SLOs:

  • Prometheus + Grafana + recording rules: DIY, flexible, requiere trabajo.
  • Sloth: generador de recording rules y alerts desde un YAML simple.
  • Pyrra: SLO as code + UI nativa.
  • Datadog SLOs: integrado, facil, pero vendor lock-in.
  • Google Cloud Service Monitoring: para GCP-native.
  • OpenSLO: propuesta de estándar, adoptivo.

Para equipos pequeños, Sloth + Prometheus es el punto dulce.

Antipatrones

Cosas que he visto romper SLOs:

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

Revisión trimestral

SLOs no son estáticos:

  • Cada quarter, revisar los SLOs con datos del trimestre.
  • ¿SLO demasiado laxo? (budget siempre disponible): apretarlo.
  • ¿SLO demasiado estricto? (siempre agotado): relajarlo o invertir en arquitectura.
  • ¿SLI todavía representa experiencia? Si el producto cambió, SLI puede haber dejado de correlacionar.

Conclusión

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; antes, que se respete lo básico.

Síguenos en jacar.es para más sobre SRE, observabilidad y fiabilidad de servicios.

Entradas relacionadas