SLI, SLO y error budgets

Conceptos

Término	Definición	Ejemplo
SLI	Proporción de eventos buenos sobre eventos válidos	Peticiones 2xx/4xx en < 500 ms ÷ peticiones totales
SLO	Objetivo para un SLI en una ventana	99,5 % en 28 días
Error budget	1 − SLO: cuánto fallo es aceptable	0,5 % ≈ 3 h 22 min en 28 días
SLA	Compromiso contractual con consecuencias; más laxo que el SLO	99 % mensual con penalización

Elegir buenos SLI

Mide lo más cerca posible del usuario (balanceador o cliente, no el pod) y según el tipo de servicio:

Tipo de servicio	SLI habituales
API síncrona	Disponibilidad, latencia
Pipeline / batch	Frescura (edad del dato), completitud, corrección
Almacenamiento	Durabilidad, latencia de lectura
Flujo de negocio	Proporción de solicitudes resueltas en < 24 h

Tabla de referencia del error budget (30 días)

SLO	Indisponibilidad permitida
99 %	7 h 12 min
99,5 %	3 h 36 min
99,9 %	43 min
99,95 %	21 min 36 s
99,99 %	4 min 19 s

Cada nueve adicional multiplica el coste: redundancia multirregión, guardias, procesos de cambio más lentos.

Alertas por burn rate

El burn rate es la velocidad de consumo del budget: 1 significa agotarlo justo al final de la ventana. El SRE Workbook recomienda alertas multiventana, por ejemplo para un SLO a 30 días:

Severidad	Burn rate	Ventana larga / corta	Budget consumido
Página	14,4	1 h / 5 min	2 %
Página	6	6 h / 30 min	5 %
Ticket	1	3 d / 6 h	10 %

La ventana corta evita seguir alertando cuando el problema ya se resolvió.

Política de error budget

El valor del SLO está en la política acordada de antemano entre producto e ingeniería:

• Budget sano → se despliega con normalidad, se experimenta.
• Budget agotado → se prioriza fiabilidad: solo correcciones y mejoras de estabilidad hasta recuperarlo.
• Un solo incidente que consume más del 20 % → postmortem obligatorio.

SLO como código (Sloth / Prometheus)

version: prometheus/v1
service: api-pagos
slos:
  - name: disponibilidad
    objective: 99.9
    description: Peticiones de pago respondidas sin error de servidor.
    sli:
      events:
        error_query: sum(rate(http_server_requests_seconds_count{app="api-pagos",status=~"5.."}[{{.window}}]))
        total_query: sum(rate(http_server_requests_seconds_count{app="api-pagos"}[{{.window}}]))
    alerting:
      name: ApiPagosDisponibilidad
      page_alert: { labels: { severity: critica } }
      ticket_alert: { labels: { severity: aviso } }

Sloth genera las reglas de grabación y las alertas multiventana de burn rate. En Google Cloud, Service Monitoring permite definir el mismo SLO sobre métricas de Cloud Run o del balanceador sin infraestructura adicional.

SLO de latencia bien definido

SLI: proporción de peticiones POST /v1/pagos con respuesta en < 800 ms
     medida en el balanceador, excluyendo respuestas 4xx de validación
SLO: 99 % en 28 días móviles

Medir latencia como proporción de peticiones «suficientemente rápidas» (y no como un percentil promedio) permite calcular un error budget igual que con la disponibilidad.

Revisión mensual de fiabilidad

Pregunta	Fuente
¿Cuánto budget consumimos y en qué incidentes?	Panel de SLO, postmortems
¿El SLO refleja lo que perciben los usuarios?	Quejas, tickets de soporte, NPS
¿Es demasiado estricto (frena sin aportar) o laxo?	Tendencia de 3–6 meses
¿Qué acciones de fiabilidad entran en la planificación?	Política de error budget

Errores frecuentes

• SLO para todo: decenas de objetivos que nadie revisa. Empieza por los recorridos críticos del usuario.
• SLO = SLA: si el objetivo interno coincide con el contractual, se incumple el contrato antes de reaccionar.
• Medir desde dentro del servicio: no captura fallos del balanceador, DNS o red.
• Política de budget que nadie aplica: si al agotarse no cambia nada, el SLO es solo un gráfico.

Criterios de implementación

Empieza con uno o dos SLO por servicio crítico, con valores basados en el rendimiento histórico y no en aspiraciones. Revisa los SLO cada trimestre. Relaciónalos con las métricas DORA: la estabilidad de la entrega afecta al budget. Instrumenta con OpenTelemetry y define los SLO como código (OpenSLO, Sloth o el servicio gestionado de tu nube).