SLOs, SLAs y SLIs: ponerle números a "funciona más o menos"

Publicado el 20 de febrero de 2026  •  8 minutos  • 1583 palabras

En casi todas las empresas hay una frase mágica que se usa para describir la salud de un sistema: “más o menos funciona”. Traducido al castellano plano: nadie sabe cuántas veces se cae, cuántas peticiones fallan, ni cuánto dinero se pierde cuando decide no funcionar. Pero, oye, “más o menos”.

SLI , SLO y SLA son la versión adulta de esa frase. Son la forma de pasar de “yo creo que va bien” a “esto es lo que aguanta, esto es lo que prometemos y esto es lo que nos estamos jugando”, sin tener que recurrir al clásico “confía en mí, soy ingeniero”.

Ponerle cara a las siglas (sin drama)

Vamos a quitarles la túnica mística a las tres letras.

Un SLI (Service Level Indicator) es, básicamente, lo que miras . Un número concreto que describe cómo se está portando tu servicio. Por ejemplo: qué porcentaje de peticiones terminan bien, cuánto tarda en responder la API de checkout para la mayoría de usuarios, cuántos errores por minuto estás devolviendo en login.

Un SLO (Service Level Objective) es el nivel al que aspiras para ese número. Es tu forma de decir “por debajo de esto consideramos que lo estamos haciendo mal”. Puede sonar así: “al menos el 99,9% de las peticiones a la API de pagos deben completarse con éxito cada 30 días”, o “el 99% de las búsquedas debe responder en menos de 400 ms”.

Y un SLA (Service Level Agreement) es cuando te casas… por contrato. Es el papel que mandas a tus clientes diciendo: “te prometo X nivel de servicio y, si no llego, pasa Y” (créditos, descuentos, penalizaciones). Un ejemplo típico: “99,9% de disponibilidad mensual o te devolvemos un 10% de la cuota”.

Google y compañía lo explican con mucha calma: el SLI es la métrica, el SLO es el objetivo interno y el SLA es lo que te puede costar dinero si fallas.

MiniFlix: tu plataforma de vídeo “más o menos estable”

Imagínate que montas MiniFlix, tu propia plataforma de streaming. Tienes un endpoint /play y usuarios que, por alguna razón, esperan que cuando le dan al botón de reproducir, el vídeo se vea. Gente rara.

En este contexto, un buen SLI podría ser:

• “Porcentaje de minutos en los que el servicio de reproducción responde correctamente (200 OK) a las peticiones de vídeo”.

Luego decides que, para dormir razonablemente bien, tu SLO interno será:

• “Queremos un 99,95% de disponibilidad mensual en reproducción de vídeo”. Eso significa que aceptas, como mucho, algo así como 22 minutos de caída total al mes.

Pero a tus clientes enterprise les firmas un SLA un pelín más laxo, del 99,9%, con créditos si bajas de ahí. No porque seas mala persona, sino porque quieres un pequeño colchón: si incumples el SLO pero sigues por encima del SLA, sabes que estás gastando tu error budget interno y que es hora de tomarse en serio la fiabilidad antes de que empiecen los créditos en la factura.

De repente, en vez de “MiniFlix hoy va un poco tonto”, puedes decir: “hemos consumido el 80% de nuestro error budget en 10 días, o aflojamos en cambios de riesgo o este mes incumplimos nuestro propio estándar”. Eso ya suena menos a barra de bar y más a decisión consciente.

Quizás alguien lo vea como un juego de trileros -y en malas manos podría serlo-, pero cuando los números son reales, al menos sabes debajo de qué cubilete mirar.

Del “va lento” a “el p95 se ha ido al carajo”

Una de las grandes ventajas de hablar de SLOs no es la sigla en sí, es el cambio de conversación.

Antes:

• “La web va lenta.”
• “¿Seguro? A mí me carga bien.”
• “Pues a mí no.”

Después:

• “El percentil 95 de la latencia del checkout ha pasado de 800 ms a 2,5 segundos esta semana. Nuestro SLO es p95 < 1,5 segundos. Y, casualidad o no, las conversiones han caído un 7%.”

Antes:

• “El sistema se cae a veces.”
• “Bueno, es que tenemos muchos usuarios, es normal.”

Después:

• “En 10 días hemos agotado el 60% del error budget de disponibilidad. Si seguimos así, no llegamos al 99,9% este mes. ¿Seguimos metiendo features de riesgo o levantamos el pie?”

En los materiales de SRE de Google se repiten dos ideas con bastante insistencia:

• Los SLOs tienen que estar anclados en la experiencia del usuario, no en métricas que solo entienden cuatro personas del equipo.
• Si tu SLI sube o baja y a los usuarios les da igual , probablemente estás mirando al sitio incorrecto.

El sueño húmedo del 100% (y por qué es una trampa)

Hay una fase peligrosa cuando descubres los SLOs. Sueles pasar por algo así como:

• “Queremos dar un servicio excelente.”
• “Pues pongamos 100% de disponibilidad.”
• “Claro que sí, campeón.”

La literatura seria sobre el tema es bastante unánime: el 100% es una fantasía cara . Incluso gigantes como Google o AWS hablan de 99,9%, 99,95%, 99,99%… y aún así, a veces, lo pasan mal.

Otra trampa es inventarte objetivos sin mirar tu pasado. Si históricamente te has movido alrededor del 99,2%, plantarte un 99,99% “porque suena profesional” es básicamente prometerte a ti mismo que vas a vivir permanentemente en incumplimiento. Mejor mirar unos meses de datos , ver qué nivel estás ofreciendo de facto, y a partir de ahí decidir: ¿queremos mantenerlo? ¿Queremos subirlo un poco? ¿Tenemos margen técnico y económico para hacerlo?

Y luego está la escala equivocada. “Queremos p99 < 500 ms en /v1/search-details” suena muy concreto, pero no le dice nada a nadie fuera del equipo. “Queremos que el 99% de las búsquedas terminen en menos de 400 ms porque por encima de eso vemos que la gente abandona ” es otra historia: de golpe, negocio entiende por qué ese número importa.

Cuando las siglas sirven para hablar con personas

Donde de verdad brillan SLIs y SLOs es en la frontera con negocio. Sin ellos, la conversación suele ser un choque de religiones.

Escena sin SLOs:

• Negocio: “Necesitamos diez features nuevas este trimestre.”
• Ingeniería: “No da tiempo.”
• Negocio: “Siempre decís lo mismo.”
• Ingeniería: “Hay mucha deuda técnica.”
• Negocio: “Eso suena a excusa.”

Escena con SLOs y error budget encima de la mesa:

• Ingeniería: “Nuestro SLO de disponibilidad es 99,9%. Llevamos 12 días y ya hemos gastado el 70% del error budget.”
• Negocio: “¿Qué pasa si lo incumplimos?”
• Ingeniería: “Más incidencias, peor experiencia y posibilidad de incumplir SLA, lo que implica créditos a clientes y mala fama.”
• Negocio: “¿Qué opciones hay?”
• Ingeniería: “Podemos parar features de riesgo un sprint y dedicarlo a estabilidad, o seguir como estamos y asumir el riesgo explícitamente.”

No es que, de repente, todo el mundo se abrace, pero al menos hablas de riesgos y decisiones con números, no de “deuda técnica” como ente abstracto. Google describe justo eso: usar SLOs y error budgets como moneda para negociar cuánto estás dispuesto a sacrificar de fiabilidad para ir más rápido… y al revés.

El resumen que no cabe en una slide de ventas

Al final, estas tres letras no son un truco de consultor, son una especie de contrato contigo mismo:

• El SLI es “qué realidad miro”.
• El SLO es “qué nivel de realidad acepto como bueno”.
• El SLA es “qué parte de esa realidad prometo a otros, y qué pasa si no llego”.

A partir de ahí, o sigues viviendo en el “más o menos tira” de siempre, o aceptas que poner números incómodos sobre la mesa -aunque duelan un poco- es la única forma adulta de decidir cuándo correr, cuándo frenar y cuánto riesgo puedes permitirte .

Suena menos épico que “vamos a revolucionar la industria”, pero tiene una ventaja: funciona incluso cuando no hay nadie presentando el dashboard.

Glosario rápido

El mínimo viable para que nadie te pille con cara de “¿eso qué era?”.

• SLI (Service Level Indicator): métrica que refleja cómo experimenta el usuario tu servicio (disponibilidad, latencia, tasa de error…).
• SLO (Service Level Objective): objetivo interno que fija el umbral mínimo aceptable para un SLI (p. ej., 99,95 % de disponibilidad mensual).
• SLA (Service Level Agreement): contrato con el cliente que establece compromisos de nivel de servicio y las consecuencias (créditos, penalizaciones) si no se cumplen.
• Error budget: margen de fallo permitido antes de incumplir el SLO. Se calcula como 100 % - SLO. Por ejemplo, un SLO de 99,9 % deja un 0,1 % de presupuesto de error.
• p95 / p99 (percentiles): valores por debajo de los cuales cae el 95 % o el 99 % de las mediciones. Usados para medir latencia sin que unos pocos outliers escondan la experiencia real.
• SRE (Site Reliability Engineering): disciplina de ingeniería, popularizada por Google, que aplica principios de software a la operación de sistemas en producción.

Fuentes y referencias

Porque decir “más o menos me lo he inventado” no cumple ningún SLA razonable.

1. SRE fundamentals: SLIs, SLAs and SLOs - Google Cloud Blog
2. Service Level Objectives (SRE Book, Cap. 4) - Google
3. The Key Differences Between SLI, SLO and SLA in SRE - DZone
4. Implementing SLOs (SRE Workbook, Cap. 2) - Google
5. Embracing Risk (SRE Book, Cap. 3) - Google
6. What is a Service-Level Objective (SLO)? - Atlassian
7. SLAs: The What, the Why, the How - Atlassian
8. Example SLO Document (SRE Workbook) - Google
9. SLO Engineering Case Studies (SRE Workbook, Cap. 3) - Google
10. Example Error Budget Policy (SRE Workbook) - Google
11. Alerting on SLOs (SRE Workbook, Cap. 5) - Google
12. Web Vitals - Google / web.dev
13. The Calculus of Service Availability - ACM Queue
14. Error Budget - Atlassian