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

El SLI es lo que mide, el SLO es su objetivo, el SLA es el compromiso contractual. Explicación de los tres términos de Google SRE más confundidos.

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 tiempo de respuesta bajo 500 ms
% de emails correctamente entregados (delivered, no bounced)
Proporción de transacciones de pago exitosas sobre todos los intentos

Un buen SLI tiene tres propiedades clave:

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 una ventana de 5 minutos" es un SLI

SLO - Service Level Objective

Objetivo interno que define qué valor debe alcanzar el SLI. Se expresa de forma porcentual sobre una ventana temporal elegida.

Ejemplos:

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

El SLO suele ser más estricto que el SLA para que tengas un margen. Si el SLA dice 99,9 %, el SLO interno debería ser p.ej. 99,95 % - así te queda reserva para incidentes inesperados antes de incumplir el contrato.

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 la magnitud de la violación)
Termination rights - el cliente puede rescindir el contrato sin sanción
Obligación de reporting - debes publicar postmortem y reportes uptime

El SLA tiene consecuencias legales. El SLO, en cambio, es solo un objetivo interno.

Error budget

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

Ejemplo: SLO = 99,9 % uptime en 30 días. Eso es 0,1 % de downtime permitido, y 0,1 % de 30 días son 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 la violación del SLO. El equipo debería ser conservador en los próximos deploys.
Si solo llevas 5 min de downtime, tienes 38 min de budget para el riesgo - puedes permitirte cambios más agresivos, pruebas A/B y experimentos.
El error budget resuelve así el conflicto entre velocidad de innovación (dev team) y estabilidad (ops team). Ambas partes 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 un mes calendario
En 99,0-99,5 % = 10% credit de la tarifa mensual
En 95,0-99,0 % = 25% credit
En < 95,0 % = 50% credit + derecho a rescindir el contrato

Error budget: un SLO de 99,9 % significa 43 min de downtime al mes. El SLA da un margen aún mayor antes de cualquier 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

Un SLO demasiado ambicioso. 99,99 % requiere active-active redundancy en múltiples regiones. Irreal para una empresa pequeña.
Solo un uptime SLO. El web puede estar "up" y aun así inutilizable. Añade un latency SLO y un error rate SLO.
Un SLA sin medición automática. Un reporte SLA calculado manualmente no es fiable. Invierte en uptime tracking automatizado.
Un SLO sin consecuencias. Si la violación de un SLO no interesa a nadie, nadie se la toma en serio. Vincúlalo a un deploy freeze, una 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 se comunica con los 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 un registro histórico de uptime con rollup 30/90/365 días. Una base sólida para el reporting SLO.

Iniciar monitorización →