SLIs, SLOs y SLAs — Compromisos Medibles

El problema de “el sistema funciona”

“¿Está funcionando el sistema?” es la pregunta equivocada. Un sistema puede “funcionar” y aún así tener:

• El 5% de las requests fallando
• La mitad de los usuarios experimentando latencias de 5 segundos
• Un componente crítico degradado que afecta a usuarios premium

La pregunta correcta es: “¿El sistema está funcionando lo suficientemente bien para nuestros usuarios?”

Los SLIs, SLOs y SLAs son el framework para responder esta pregunta de manera objetiva, medible y accionable.

---

SLI: Service Level Indicator

Un SLI (Service Level Indicator) es una métrica específica que mide un aspecto del servicio desde la perspectiva del usuario.

La clave es “desde la perspectiva del usuario”. El CPU al 20% no es un SLI — el usuario no experimenta el CPU directamente. La latencia de su request sí.

Características de un buen SLI

flowchart LR
    B1[¿El usuario lo experimenta?] --> B2[¿Podemos medirlo confiablemente?]
    B2 --> B3[¿Tiene unidades claras?]
    B3 --> B4[¿Discrimina bien vs. mal?]
    B4 --> GOOD[Buen SLI]

Los tipos más comunes de SLIs

Disponibilidad (Availability)

SLI = (requests exitosas / total de requests) × 100%

Ejemplo:
- Total requests en 24h: 1,000,000
- Requests con error (5xx): 5,000
- SLI = (995,000 / 1,000,000) × 100% = 99.5%

Latencia

SLI = % de requests que responden en menos de X ms

Ejemplo:
- SLI = % de requests con latencia < 200ms
- Si el p95 de latencia es 180ms, el SLI es "al menos 95%"

Calidad / Correctitud

SLI = % de responses que contienen datos correctos

Ejemplo para un motor de búsqueda:
- % de queries que devuelven al menos 1 resultado relevante en el top 3

Throughput

SLI = % del tiempo que el sistema puede procesar la carga demandada

Ejemplo:
- % del tiempo que el sistema procesa >1000 req/seg sin degradación

Lo que NO es un SLI

No es SLI	Por qué no	Sí es SLI
CPU < 80%	El usuario no experimenta CPU	Latencia de request < 200ms
0 pods restarting	Interno a la infra	% de requests exitosas
Uptime del servidor	Perspectiva de infra	Disponibilidad del servicio al usuario
Logs sin errores ERROR	Puede haber errores sin impacto real	Tasa de transacciones fallidas

---

SLO: Service Level Objective

Un SLO (Service Level Objective) es el objetivo que defines para tu SLI durante un período específico. Es la promesa interna del equipo de ingeniería sobre la calidad del servicio.

SLO = SLI + objetivo + ventana de tiempo

Ejemplo:
SLO: "Disponibilidad ≥ 99.9% medida en ventana rolling de 30 días"
SLO: "El p99 de latencia del checkout < 500ms durante el 95% de las ventanas de 5 min del último mes"

La magia del error budget

El error budget (presupuesto de error) es lo que hace a los SLOs tan poderosos. Es la cantidad de “fallas permitidas” antes de violar el SLO.

Error Budget = 100% - SLO

Si SLO = 99.9% disponibilidad:
Error Budget = 0.1% de tiempo de falla permitido

En 30 días:
- 30 días × 24h × 60min = 43,200 minutos
- 0.1% de 43,200 = 43.2 minutos de downtime permitido al mes

xychart-beta
    title "Consumo del Error Budget en 30 días"
    x-axis ["Día 1", "Día 5", "Día 10", "Día 15", "Día 20", "Día 25", "Día 30"]
    y-axis "Error Budget restante (%)" 0 --> 100
    line [100, 95, 85, 70, 60, 45, 30]

El error budget como herramienta de decisión

El error budget transforma debates subjetivos en decisiones objetivas:

Escenario 1: Error budget sano (>50% restante)

• El equipo puede desplegar features nuevas con más frecuencia
• Puede tomar riesgos calculados con experimentos
• Tiene margen para mantenimiento disruptivo

Escenario 2: Error budget en riesgo (10-50% restante)

• Mayor cautela en deployments
• Priorizar estabilidad sobre nuevas features
• Aumentar testing y canary deployments

Escenario 3: Error budget agotado (<10% o negativo)

• Freeze de features nuevas hasta que se recupere el budget
• Toda la energía del equipo en confiabilidad
• Postmortem obligatorio de los incidentes recientes

graph TD
    CHECK{¿Cuánto error budget\nqueda?} --> |>50%| SHIP[Desplegar features\nnuevamente]
    CHECK --> |10-50%| CAREFUL[Despliegues cuidadosos\ncanary releases]
    CHECK --> |<10%| FREEZE[Feature freeze\nFoco en confiabilidad]
    CHECK --> |Agotado| CRISIS[Modo crisis\nPostmortems obligatorios]

---

SLA: Service Level Agreement

Un SLA (Service Level Agreement) es un contrato formal entre el proveedor y el cliente que especifica las consecuencias de no cumplir los niveles de servicio prometidos.

SLA = SLO + consecuencias (típicamente económicas)

Ejemplo de SLA de AWS S3:
- SLO: 99.9% de disponibilidad mensual
- Consecuencia si falla:
  * 99-99.9%: crédito del 10% del costo mensual
  * 95-99%: crédito del 25% del costo mensual
  * <95%: crédito del 50% del costo mensual

La relación entre SLI, SLO y SLA

graph LR
    SLI[SLI\nMétrica medible] --> |define| SLO[SLO\nObjetivo interno]
    SLO --> |formaliza| SLA[SLA\nContrato con consecuencias]

    SLI --> |"ej: tasa de\néxito de pagos"| SLI
    SLO --> |"ej: ≥ 99.95%\nen 30 días"| SLO
    SLA --> |"ej: crédito si baja\nde 99.9%"| SLA

Regla práctica importante: Tu SLA debe ser más laxo que tu SLO, que debe ser más estricto que lo que realmente logras en promedio.

Realidad histórica: 99.97% de disponibilidad
SLO interno: 99.95% (permite margen para imprevistos)
SLA externo: 99.9% (permite margen adicional para el SLO)

Si defines el SLA igual que el SLO, cualquier incidente pequeño viola el contrato. El buffer es deliberado.

---

Definiendo buenos SLOs: el proceso

Paso 1: Identificar las journeys críticas del usuario

No todos los servicios son igual de críticos. Empieza por las journeys que tienen el mayor impacto en el usuario:

Para un e-commerce:

1. Completar checkout (alta criticidad)
2. Ver catálogo de productos (alta criticidad)
3. Ver historial de pedidos (media criticidad)
4. Actualizar perfil (baja criticidad)

Paso 2: Definir qué es “bueno” desde la perspectiva del usuario

Pregunta: “¿Cuándo diría el usuario que el servicio está degradado?”

• ¿Cuánto es demasiado lento? (latencia)
• ¿Cuántos errores son aceptables? (disponibilidad)
• ¿Qué funciones críticas nunca deben fallar? (correctitud)

Paso 3: Elegir los SLIs correctos

Para el checkout:

SLI 1: Disponibilidad
→ % de requests al endpoint POST /checkout que devuelven 2xx

SLI 2: Latencia
→ % de requests a POST /checkout que responden en < 3s

SLI 3: Correctitud (si aplica)
→ % de transacciones completadas que resultan en una orden creada

Paso 4: Establecer el objetivo inicial

Si no tienes datos históricos: empieza conservador. Es mejor cumplir el SLO holgadamente y ajustarlo después que fallar desde el primer mes.

Si tienes datos históricos: el SLO debería estar ligeramente por debajo de tu percentil 5 histórico. Si históricamente has estado a 99.95% el peor mes, pon el SLO en 99.9%.

graph LR
    HIST[Historial de 6 meses\npeor mes: 99.95%] --> SLO[SLO inicial: 99.9%]
    SLO --> REVIEW[Revisión a 3 meses]
    REVIEW --> |Si lo cumples con holgura| TIGHTEN[Ajustar más estricto]
    REVIEW --> |Si casi lo violas| LOOSEN[Ajustar más flexible\nhasta entender por qué]

Paso 5: Implementar la medición

El SLO solo vale si lo mides. En Prometheus:

# Recording rule para disponibilidad de checkout
groups:
  - name: slo_availability
    interval: 1m
    rules:
      - record: checkout:requests:success_rate5m
        expr: |
          rate(http_requests_total{service="checkout", status=~"2.."}[5m]) /
          rate(http_requests_total{service="checkout"}[5m])

      - record: checkout:requests:error_rate30d
        expr: |
          1 - (
            sum_over_time(checkout:requests:success_rate5m[30d]) /
            count_over_time(checkout:requests:success_rate5m[30d])
          )

---

Burn rate: la velocidad de consumo del error budget

El burn rate es qué tan rápido estás consumiendo tu error budget. Es una de las métricas más importantes para alertas de SLO.

Burn rate = 1x → Consumirás exactamente todo el budget en 30 días (si el SLO es mensual)
Burn rate = 10x → Consumirás todo el budget en 3 días
Burn rate = 720x → Consumirás todo el budget en 1 hora (incidente grave)

Si tu SLO es 99.9% mensual y estás en un período de 2% de error rate:

Error budget = 0.1% en 30 días
Error rate actual = 2%
Burn rate = 2% / 0.1% = 20x

A 20x burn rate, agotarás el budget en: 30 días / 20 = 1.5 días

Alertas de multi-window, multi-burn-rate

Google recomienda alertas con dos ventanas de tiempo para evitar falsos positivos y asegurar detección rápida:

# Alerta de SLO - Burn rate alto
- alert: CheckoutSLOErrorBudgetBurning
  expr: |
    (
      # Burn rate en ventana corta (1h) muy alto
      checkout:requests:error_rate1h > (14.4 * 0.001)  # 14.4x burn rate
    ) and (
      # Confirmar con ventana más larga (5m)
      checkout:requests:error_rate5m > (14.4 * 0.001)
    )
  for: 0m
  labels:
    severity: critical
  annotations:
    summary: "Checkout SLO: error budget burning fast (>14.4x)"
    description: "At this rate, 30d error budget will be exhausted in ~2 hours"
    runbook: "https://wiki.example.com/runbooks/checkout-slo"

graph TD
    BR2[Burn rate ≥ 14.4x\nen 1h y 5m] --> |CRITICAL\nPage ahora| CRIT[Incidente activo\nResponder en minutos]
    BR6[Burn rate ≥ 6x\nen 6h y 30m] --> |WARNING\nPage pronto| WARN[Investigar en horas]
    BR1[Burn rate ≥ 3x\nen 3d y 6h] --> |INFO\nTicket] INFO[Planificar mejora]

---

SLOs para diferentes tipos de servicios

APIs síncronas (REST/gRPC)

SLI: Disponibilidad = 2xx / total_requests
SLO: ≥ 99.9% en ventana rolling de 30 días

SLI: Latencia = % de requests < 200ms (p99)
SLO: ≥ 95% de las ventanas de 5 min cumplen p99 < 200ms

Sistemas de procesamiento asíncrono (colas, workers)

SLI: Tiempo de procesamiento = tiempo desde enqueue hasta processed
SLO: 99% de mensajes procesados en < 5 minutos

SLI: Tasa de procesamiento exitoso
SLO: ≥ 99.5% de mensajes procesados sin error en 30 días

Sistemas de datos (pipelines, ETL)

SLI: Freshness = tiempo desde que el dato existe hasta que está disponible
SLO: 99% de los datos disponibles en < 1 hora de su creación

SLI: Completitud = % de registros esperados que están presentes
SLO: ≥ 99.9% de completitud en ventanas diarias

---

Revisión y evolución de los SLOs

Los SLOs no son estáticos. Deben evolucionar con el sistema y el negocio:

Cuándo hacerlos más estrictos:

• El equipo cumple el SLO consistentemente con margen amplio
• Los usuarios/clientes demandan mayor confiabilidad
• El producto maduró y la competencia es más confiable

Cuándo hacerlos más laxos:

• El equipo está constantemente en modo “crisis” por el SLO
• El SLO no refleja lo que los usuarios realmente esperan
• El costo de cumplir el SLO supera el beneficio para el usuario

Revisión recomendada: Trimestral para equipos maduros, mensual para equipos que están empezando con SLOs.

---

Referencias

• Google SRE Book — Service Level Objectives
• Google SRE Workbook — Implementing SLOs
• Sloth — SLO Generator for Prometheus
• OpenSLO — SLO Specification
• Alex Hidalgo — Implementing Service Level Objectives (O’Reilly, 2020)
• Burn Rate Alerts — Google SRE Workbook