SLO vs SLA: diferencia, SLI y presupuesto de error
8 min de lectura
Un SLA (acuerdo de nivel de servicio) es un contrato con un cliente que dice qué pasa cuando un servicio no alcanza un nivel prometido, normalmente un crédito de servicio. Un SLO (objetivo de nivel de servicio) es la meta interna con la que un equipo gestiona el servicio; el libro de SRE aconseja fijarla más estricta que el SLA para que los problemas se resuelvan antes de incumplir el contrato. Un SLI (indicador de nivel de servicio) es la medida en la que se expresan ambos, por ejemplo la proporción de peticiones que tienen éxito.
| SLI | SLO | SLA | |
|---|---|---|---|
| Qué es | Una medida | Una meta para un SLI | Un contrato basado en SLO |
| Lo fija | Ingeniería | El product owner e ingeniería | Los equipos de negocio y legal |
| Si se incumple | Nada por sí solo | Se gasta presupuesto de error | Créditos de servicio o penalizaciones |
| Ejemplo | Llamadas de pago con éxito | 99,95 % en cuatro semanas | 99,9 % al mes, o un crédito |
Los ejemplos son ilustrativos; las fuentes son el libro y el workbook de SRE de Google y el SLA de cómputo de AWS, comprobados el 1 de noviembre de 2026.
¿Qué significan SLI, SLO y SLA?
Service level indicator, service level objective y service level agreement: indicador, objetivo y acuerdo de nivel de servicio. El indicador es lo que mides, el objetivo es el valor al que apuntas y el acuerdo es lo que prometes a otra persona, con consecuencias.
El capítulo «Service Level Objectives» del libro de SRE define un SLA como «un contrato explícito o implícito con tus usuarios que incluye consecuencias por cumplir (o incumplir) los SLO que contiene». La prueba del capítulo es una sola pregunta: ¿qué pasa si no se cumplen los SLO? Si no hay una consecuencia explícita, casi seguro que estás ante un SLO.
El capítulo añade que la mayoría de la gente quiere decir SLO cuando dice SLA, y que una violación real de un SLA puede acabar en un pleito por incumplimiento de contrato. Así que, cuando una reunión se convierte en una discusión de SLA vs SLO, pregunta primero si hay una consecuencia, normalmente dinero, escrita en un contrato.
El libro de SRE aconseja mantener un margen de seguridad: «un SLO interno más estricto que el SLO anunciado a los usuarios te da espacio para responder a problemas crónicos antes de que se vean desde fuera». Su capítulo «Embracing Risk» aplica la misma idea a un contrato: un objetivo externo del 99,9 % respaldado por uno interno más exigente.
¿Qué es un presupuesto de error?
Es el 100 % menos el SLO: la parte de las peticiones o del tiempo que puede fallar dentro de la ventana. Mientras quede presupuesto, el equipo sigue publicando cambios; cuando se agota, el trabajo de fiabilidad va primero.
El capítulo «Implementing SLOs» del workbook de SRE hace la cuenta: con un SLO del 99,9 %, un servicio que recibe 3 millones de peticiones en cuatro semanas puede fallar 3.000, así que una caída con 1.500 errores gasta la mitad del presupuesto. El capítulo «Embracing Risk» del libro explica para qué sirve: la gestión de producto fija el SLO, la monitorización mide la disponibilidad real y la diferencia es el margen de falta de fiabilidad que queda para el trimestre. Cuando ese presupuesto se agota, los despliegues se detienen o se ralentizan.
¿Cuánto tiempo de inactividad permite el 99,9 %?
Unos 43 minutos en una ventana de 30 días. Cada nueve adicional divide el margen entre diez, así que el 99,99 % deja poco más de 4 minutos.
| SLO | Presupuesto de error | Inactividad en 30 días | Fallos por millón |
|---|---|---|---|
| 99 % | 1 % | 7 h 12 min | 10.000 |
| 99,5 % | 0,5 % | 3 h 36 min | 5.000 |
| 99,9 % | 0,1 % | 43 min 12 s | 1.000 |
| 99,95 % | 0,05 % | 21 min 36 s | 500 |
| 99,99 % | 0,01 % | 4 min 19 s | 100 |
Multiplica los 43.200 minutos de una ventana de 30 días por el presupuesto de error. Ten en cuenta la advertencia del workbook: cada nueve adicional cuesta más mientras su valor para los usuarios tiende a cero.
¿Cómo es un SLA real?
Indica un porcentaje medido, un periodo de facturación, una escala de créditos y lo que no cuenta. El SLA de cómputo de AWS es un ejemplo público y breve.
El Amazon Compute Service Level Agreement (actualizado el 25 de mayo de 2022; comprobado el 1 de noviembre de 2026) se compromete a un Monthly Uptime Percentage de al menos el 99,99 % por región para instancias EC2 repartidas en dos o más Availability Zones, y del 99,5 % para una sola instancia. La disponibilidad es el 100 % menos la parte de los minutos en que EC2 no estuvo disponible. Según el Region-Level SLA, por debajo del 99,99 % el crédito es el 10 % de la factura mensual de EC2 en la región, por debajo del 99,0 % es el 30 % y por debajo del 95,0 % es el 100 %; para una sola instancia, el tramo del 10 % empieza por debajo del 99,5 %. Los créditos se aplican a pagos futuros, hay que reclamarlos a través del soporte de AWS y son el recurso «único y exclusivo», salvo que el acuerdo con el cliente diga otra cosa.
Comparado con la tabla de inactividad, el tramo del 10 % del Region-Level SLA abarca de unos 4 minutos a unas 7 horas de indisponibilidad en un mes de 30 días. Un SLA limita lo que debe el proveedor; evitar que las caídas perjudiquen a tus usuarios es tarea de tus propios objetivos.
¿Cómo eliges SLI de latencia y de disponibilidad?
Mide la latencia como percentil y la disponibilidad como eventos buenos divididos entre todos los eventos, lo más cerca posible del usuario. Las medias y las cifras tomadas solo en el servidor esconden las peticiones de las que se queja la gente.
Latencia. El libro de SRE prefiere los percentiles a la media, porque una media puede quedarse plana mientras las peticiones más lentas se vuelven mucho más lentas. El workbook escribe los SLI de latencia como un cociente, por ejemplo las llamadas que terminan en menos de 100 ms divididas entre todas las llamadas. Así que «el 99 % de las llamadas de pago en menos de 400 ms» equivale a «p99 del pago por debajo de 400 ms» en la ventana, y pasa tal cual a una prueba. Nuestro artículo sobre la latencia de cola explica por qué el p99 importa en cuanto una página llama a varios servicios.
Disponibilidad. La disponibilidad por tiempo cuenta los minutos en funcionamiento, como hace el SLA de AWS. La disponibilidad por peticiones cuenta las peticiones con éxito: «Embracing Risk» describe un servicio con 2,5 millones de peticiones al día y un objetivo diario del 99,99 %, que puede devolver 250 errores y aun así cumplirlo.
¿Dónde fallan los SLO?
Casi siempre por exceso de objetivos, por metas del 100 % y por indicadores medidos donde no están los usuarios. Cada uno deja una cifra sobre la que nadie actúa, o una que parece buena mientras los usuarios lo pasan mal.
- Demasiados SLO. El libro de SRE aconseja tener los menos posibles: si citar un SLO nunca sirve para ganar una discusión sobre prioridades, probablemente no merece la pena.
- Metas del 100 %. El workbook dice que el 100 % es la meta equivocada: los componentes fallan, los cambios son la principal causa de caídas y un SLO del 100 % solo deja tiempo para reaccionar.
- Medir solo en el servidor. Las métricas del servidor no ven problemas que sí notan los usuarios, como un script lento en la página. El workbook propone medir en el balanceador de carga o en el cliente.
¿Qué tienen que ver las pruebas de carga con los SLO?
Un SLO le da a una prueba de carga sus criterios de aprobación, y una prueba en el pico esperado muestra si el SLO de latencia aguanta antes de que llegue ese tráfico. La monitorización en producción solo te lo dice después.
El libro de SRE señala que más peticiones por segundo (QPS) suelen traer latencias mayores y que es habitual que los servicios tengan un precipicio de rendimiento a partir de cierto umbral de carga. Una prueba de carga puede encontrar ese precipicio si se ejecuta en el pico esperado, con una mezcla realista de peticiones, y mide el mismo SLI que usa el SLO. Fija cada umbral de la prueba un poco más estricto que el SLO, como explica nuestra guía de criterios de aprobación en pruebas de carga. Una ejecución dura minutos, así que no puede medir la disponibilidad mensual.
LoadFocus, que publica este sitio, evalúa las pruebas de carga con umbrales de aprobación guardados en la prueba: Max P95 y Max P99 del tiempo de respuesta, una tasa de errores máxima y un rendimiento mínimo, para pruebas cloud, JMeter y k6. Su monitorización de API ofrece informes de SLA y SLO que fijan un objetivo SLO por monitor y muestran la disponibilidad, el presupuesto de error consumido y un estado OK o Incumplido.
FAQ
¿Qué significa SLO? Service level objective, u objetivo de nivel de servicio: un valor meta para un nivel de servicio medido, por ejemplo el 99,9 % de peticiones con éxito en cuatro semanas. Se fija internamente, entre producto e ingeniería, y por sí solo no conlleva ninguna penalización contractual.
¿Se puede tener un SLO sin un SLA? Sí. El libro de SRE pone como ejemplo la búsqueda de Google, un servicio importante sin SLA público que aun así se gestiona con SLI y SLO.
¿Debería un SLO ser alguna vez del 100 %? No. Un objetivo del 100 % no deja presupuesto de error, así que cualquier fallo lo incumple y ningún cambio es nunca seguro de publicar.
Lecturas relacionadas
- Criterios de aprobación en pruebas de carga: cómo fijarlos
- Latencia de cola: qué es y cómo medirla
- Puntuación Apdex: qué es y cómo se calcula
- Rendimiento vs latencia: cómo se relacionan bajo carga
Las afirmaciones técnicas de este artículo no se han revisado de forma independiente.