SLI vs SLO vs SLA: diferencias y cómo configurarlos

En resumen: SLI es qué mides, SLO es qué objetivo quieres alcanzar, SLA es el compromiso contractual. Estos términos del libro de Google SRE están entre las frases más usadas en operación de servicios web - y a menudo se confunden.

En resumen: SLI es qué mides, SLO es qué objetivo quieres alcanzar, SLA es el compromiso contractual. Estos términos del libro de Google SRE están entre las frases más usadas en operación de servicios web - y a menudo se confunden.

SLI - Service Level Indicator

Métrica concreta con la que cuantificas la fiabilidad del servicio. Ejemplos:

% de requests que terminaron en HTTP 2xx o 3xx en los últimos 30 días
% de requests con response time bajo 500 ms
% de emails correctamente entregados (delivered, no bounced)
Proporción de transacciones de pago exitosas sobre todos los intentos

Propiedades clave de un buen SLI:

Medible - existe un método concreto de recolección de datos
Relevante para el usuario - refleja la experiencia real del cliente, no una métrica técnica interna
Específico - "uptime" es demasiado vago; "% de requests exitosos a /api/v1/orders en ventana de 5 minutos" es un SLI

SLO - Service Level Objective

Objetivo interno, qué valor debe alcanzar el SLI. Se expresa porcentualmente por ventana temporal.

Ejemplos:

"99,9 % de requests a /api/orders debe terminar en HTTP 2xx en 30 días"
"95 % de requests debe tener response time bajo 200 ms en 7 días"
"99,5 % de transacciones de pago pasan con éxito en mes calendario"

SLO es más alto que SLA para tener buffer. Si SLA dice 99,9 %, el SLO interno debería ser p.ej. 99,95 % - para tener reserva para incidentes inesperados.

SLA - Service Level Agreement

Compromiso contractual hacia los clientes. Define qué pasa cuando no cumples el SLO - típicamente:

Service credits - devuelves parte de la tarifa mensual (10-50% según magnitud de violación)
Termination rights - el cliente puede rescindir el contrato sin sanción
Obligación de reporting - debes publicar postmortem y reportes uptime

SLA tiene consecuencias legales. SLO es objetivo interno.

Error budget

Concepto clave de SRE: downtime que puedes permitirte sin violar SLO.

Ejemplo: SLO = 99,9 % uptime en 30 días. Eso es 0,1 % de downtime permitido. 0,1 % de 30 días = 43 minutos al mes. Este es tu error budget.

Implicaciones prácticas:

Si ya llevas 35 min de downtime en el mes, quedan 8 min para "violación de SLO". El equipo debería ser conservador en próximos deploys.
Si tienes 5 min de downtime, tienes 38 min de budget para riesgos - puedes hacer cambios más agresivos, pruebas A/B, experimentos.
Error budget resuelve el conflicto entre velocidad de innovación (dev team) y estabilidad (ops team). Ambos siguen el mismo número.

Ejemplo práctico: API e-commerce

SLI: % de requests HTTP a POST /api/checkout que terminaron en 2xx, medidas en buckets de 1 minuto en los últimos 30 días.

SLO: ≥ 99,9 % de requests exitosos en ventana rolling 30-day.

SLA (para clientes Enterprise):

≥ 99,5 % uptime en mes calendario
En 99,0-99,5 % = 10% credit de tarifa mensual
En 95,0-99,0 % = 25% credit
En < 95,0 % = 50% credit + derecho a rescindir contrato

Error budget: 99,9 % SLO significa 43 min downtime / mes en budget. SLA da aún mayor buffer antes de penalización económica.

Resumen: tabla

Término	Qué es	Para quién
SLI	Métrica concreta de fiabilidad	Equipo engineering
SLO	Objetivo interno para SLI	Engineering + product
SLA	Compromiso contractual	Cliente + legal
Error budget	Downtime que puedes permitirte antes de violación SLO	Engineering risk management

Errores prácticos

SLO demasiado ambicioso. 99,99 % requiere active-active redundancy en múltiples regiones. Irreal para empresa pequeña.
Solo uptime SLO. El web puede estar "up" y aun así inutilizable. Añade latency SLO y error rate SLO.
SLA sin medición automática. Un reporte SLA calculado manualmente no es fiable. Invierte en uptime tracking automatizado.
SLO sin consecuencias. Si la violación de SLO no interesa a nadie, nadie se preocupa por ella. Vincula a deploy freeze, on-call escalation, etc.

Conclusión

El framework SLI/SLO/SLA no es burocracia de papel - es el lenguaje con el que el equipo engineering comunica con business stakeholders sobre fiabilidad. Sin estos términos la discusión sobre estabilidad se vuelve subjetiva ("nuestro web es inestable"). Con ellos es numérica ("en los últimos 30 días alcanzamos 99,87 % SLI, que está bajo nuestro 99,9 % SLO - aquí está el plan de acción").

Mide SLI en tiempo real

ePulz.io proporciona registro histórico de uptime con rollup 30/90/365 días. Base para reporting SLO.

Iniciar monitorización →