¿Qué es un SLO? Objetivos de Nivel de Servicio Guía

Si buscas "que es un slo", probablemente estés empezando a construir una práctica de confiabilidad. Un SLO (objetivo de nivel de servicio) es una meta de confiabilidad interna que tu equipo se fija a sí mismo. No es un contrato con clientes, ni una métrica bruta de tu stack de observabilidad. Un SLO responde una pregunta fundamental: ¿qué tan confiable necesita ser este servicio y cómo lo mediremos? Esta es la base sobre la que se construye cualquier práctica operativa de confiabilidad.

Un SLO completo se ve así: el 99,9% de las solicitudes HTTP a /api/checkout devuelven un estado de éxito y se completan en 300 ms, medido en una ventana móvil de 30 días. Tres componentes: la medición, la meta y la ventana. Los tres importan.

SLI, SLO, SLA: Tres Siglas Que Significan Cosas Diferentes

Estas tres palabras aparecen juntas constantemente. Los equipos las usan indistintamente. Describen cosas diferentes.

Un SLI (Indicador de Nivel de Servicio) es la medición bruta que produce tu sistema de monitoreo. Tasa de error como porcentaje de solicitudes totales. Latencia P99 en milisegundos. Porcentaje de escrituras exitosas en base de datos. El SLI es el número que sale de Datadog, Grafana o lo que sea que estés usando. Te dice qué pasó.

Un SLO (Objetivo de Nivel de Servicio) es la meta que defines encima del SLI. Responde: de todos los valores posibles que este SLI puede tomar, ¿cuál rango cuenta como aceptable? Si tu SLI es tasa de error y tu SLO es "tasa de error por debajo del 0,1% para el 99% de ventanas de cinco minutos", entonces tienes una prueba de aprobado/reprobado, no solo un número en un dashboard.

Un SLA (Acuerdo de Nivel de Servicio) es la versión externa de la misma lógica, con consecuencias contractuales. Tu SLA podría decir "99,5% de disponibilidad o emitimos un crédito de servicio del 20%". Tu SLO debe estar por encima de ese umbral, para que tu equipo sepa de una degradación antes de que una ruptura del SLA se convierta en una conversación con clientes.

La brecha entre SLO y SLA no es relleno para negligencia. Es un margen diseñado que convierte "nos estamos aproximando a una ruptura" en "tenemos tiempo para arreglar esto ahora".

Una distinción más importante: los SLIs se miden continuamente, pero los SLOs se evalúan en una ventana. La misma tasa de error medida en siete días frente a 30 días produce resultados de aprobado/reprobado muy diferentes. Una hora mala importa mucho en una ventana de siete días. En una ventana de 30 días, es aproximadamente el uno por ciento del período. Elegir la ventana correcta es tan importante como elegir la meta correcta.

¿Por Qué "¿Qué Tan Confiable?" No Es Una Pregunta Completa?

Antes de elegir un número, necesitas entender qué experimenta el usuario cuando el servicio se degrada. "Necesitamos cinco nueves" es una declaración de ambición, no una medición. Un API de checkout con disponibilidad del 99,999% significa aproximadamente 26 segundos de errores por mes. Para un servicio que procesa diez transacciones por segundo, eso podría ser aceptable. Para un servicio que maneja liquidación financiera en tiempo real, podría no serlo.

El SLO correcto depende de dos factores: el impacto en el usuario de una degradación y el costo operativo de mantener una meta más estrecha.

Si tu servicio ha registrado disponibilidad del 99,3% en los últimos 90 días, iniciar tu primer SLO en 99,9% es aspiracional, no calibrado. El enfoque práctico: extrae los últimos 90 días de datos de SLI, establece el SLO ligeramente más ajustado que el rendimiento actual, luego revisa trimestralmente. Un SLO del 99,5% con una política de presupuesto de errores real supera un SLO del 99,9% que se ignora cada vez que se rompe.

Objetivos comunes de SLO por tipo de servicio:

• APIs orientadas al usuario (checkout, autenticación): disponibilidad del 99,9%, latencia P99 por debajo de 500 ms

• Servicios internos (pipelines de datos, trabajos por lotes): tasa de éxito del 99,5%, medida en finalización del trabajo

• Herramientas administrativas: disponibilidad del 99% es a menudo suficiente

• Workers de fondo: SLO en tiempo de finalización del trabajo en lugar de estado HTTP

Al elegir qué SLI medir, usa las cuatro señales del libro de SRE de Google como punto de partida: disponibilidad (¿la solicitud tuvo éxito?), latencia (¿cuánto tiempo tomó?), rendimiento (¿cuántas solicitudes está manejando el sistema?) y tasa de error (¿qué fracción falló?). No todos los servicios necesitan los cuatro. La mayoría de los equipos obtienen señal real de disponibilidad más un percentil de latencia. Agregar más SLIs antes de tener una línea base confiable para los dos primeros es una forma común de crear ruido sin obtener información.

El Presupuesto de Errores: De Meta a Decisión Operativa

Un presupuesto de errores es el inverso matemático de tu SLO. Si tu SLO de disponibilidad es 99,9%, entonces el 0,1% de solicitudes en la ventana de medición pueden fallar. Para un servicio que recibe un millón de solicitudes por mes, eso es 1.000 solicitudes fallidas antes de que se rompa el SLO.

El presupuesto de errores hace que los SLOs sean operacionalmente útiles. Sin él, un SLO es un umbral que se viola y luego se discute. Con una política de presupuesto de errores, se convierte en un marco de decisión.

Cuando el presupuesto de errores es saludable, digamos 80% restante con dos semanas en la ventana, el equipo puede enviar rápido. Nuevas características, experimentos, despliegues más arriesgados están todos en los límites. El presupuesto de errores es la señal de que la velocidad no es actualmente la restricción.

Cuando el presupuesto de errores se está agotando, el equipo cambia. Los cambios no críticos se ponen en espera. La política de despliegue se ajusta. Las correcciones de confiabilidad se priorizan. El presupuesto de errores tomó la decisión, no un juicio de gerente sobre si las cosas "se sienten lo suficientemente estables".

Un escenario concreto: un servicio de checkout tuvo una degradación de 12 minutos un martes por la tarde, consumiendo el 15% del presupuesto de errores mensual. Un segundo incidente el jueves consumió otro 12%. Con el 27% consumido en la primera semana del mes, la política de presupuesto de errores se activa: sin despliegues de nuevas características hasta que se complete un postmortem y se parche la causa raíz. Esa decisión no es una negociación entre producto e ingeniería. Es una lectura de los datos.

Google publicó su política de presupuesto de errores en el SRE Workbook: un único incidente que consume más del 20% del presupuesto de errores trimestral requiere un postmortem. Esa es una política concreta para adaptar.

Las alertas de velocidad de quema van más allá. En lugar de esperar hasta que el presupuesto de errores se agote casi completamente, una alerta de velocidad de quema se dispara cuando la velocidad de consumo sugiere que agotarás el presupuesto antes de que termine la ventana. Si tu servicio está consumiendo presupuesto de errores a 14 veces la velocidad normal, agotarás un presupuesto de 30 días en aproximadamente 50 horas. Una alerta a esa velocidad le da al equipo dos días para responder en lugar de una notificación de postmortem después de la ruptura. Herramientas como Datadog y Grafana soportan alertas multi-ventana y multi-velocidad de quema de serie. Configurarlo toma una tarde. No tenerlo significa descubrir ruptura de SLO después de que los clientes ya lo notaron.

Establecer Tu Primer SLO Sin Equivocarte Con El Número

El error más común es comenzar con la meta antes de establecer la medición.

Paso 1: Define el SLI. "Disponibilidad" no es un SLI. "Solicitudes HTTP que devuelven un estado sin error (2xx/3xx), divididas por todas las solicitudes HTTP" es un SLI. La medición debe ser producible a partir de la telemetría que ya tienes. Prometer instrumentar algo "pronto" significa que el SLO no tiene una fuente de datos.

Paso 2: Extrae datos históricos. Mira los últimos 60 a 90 días. ¿Cómo se ve realmente el SLI? ¿Cuáles fueron los dos o tres peores días? Esto te dice qué meta es alcanzable hoy y cuánto margen tienes antes de la primera ruptura.

Paso 3: Establece la ventana de medición. Las ventanas móviles de 30 días son las más comunes y te dan datos responsivos y siempre actuales. Las ventanas de mes calendario crean efectos acantilado en límites de mes. Las ventanas móviles de siete días son más sensibles pero pueden dispararse demasiado frecuentemente para equipos que aún están construyendo músculo de confiabilidad.

Paso 4: Escribe la política de presupuesto de errores antes de necesitarla. ¿A qué velocidad de quema de presupuesto de errores pausa el equipo cambios no críticos? ¿A qué velocidad de quema escala el oncall? Documenta esto antes del incidente, no durante.

Paso 5: Comienza con un servicio. Definir SLOs para 15 servicios a la vez produce 15 dashboards que nadie lee. Comienza con el servicio más visible para el usuario, ejecuta un trimestre, ajusta, luego expande.

Opciones de ventana de medición y sus compensaciones:

• 7 días móviles: retroalimentación rápida, más sensible a incidentes breves, puede crear fatiga de alertas

• 30 días móviles: más común, equilibra señal y ruido

• 90 días móviles: útil para operaciones infrecuentes pero críticas como trabajos por lotes

Un ejemplo trabajado: para un API de comercio electrónico, podrías establecer tu primer SLO como "el 95% de solicitudes a /checkout tienen éxito y se devuelven en 500 ms, medido en una ventana móvil de 28 días". Eso te da un SLI concreto (tasa de éxito combinada con latencia), una meta específica (95%) y una ventana definida (28 días). A partir de ahí, calculas el presupuesto de errores: el 5% de solicitudes totales pueden fallar o ser lentas. Si recibes 200.000 solicitudes por día, tu presupuesto de errores mensual es aproximadamente 280.000 solicitudes fallidas antes de que se rompa el SLO.

Dónde La Monitorización de SLO Se Conecta Con El Trabajo Del Código

Un presupuesto de errores que se agota más rápido de lo esperado es un problema de código más a menudo que uno de infraestructura. Los picos de latencia se remontan a consultas N+1 que pasaron desapercibidas en la revisión de código. Las caídas de disponibilidad se remontan a una excepción de puntero nulo en una ruta de código que solo se dispara bajo una combinación de carga específica. El SLO detecta los síntomas. El código contiene la causa.

Aquí es donde el tiempo entre "alerta se dispara" e "identificar causa raíz" se convierte en la restricción práctica. Cuando el servicio de checkout está consumiendo 30% de su presupuesto de errores en tres días y el ingeniero oncall tiene que buscar en un monorepo de 150.000 líneas para encontrar la lógica de reintento que se comporta diferente bajo carga, el SLO está haciendo su trabajo. Las herramientas para análisis de causa raíz no lo están.

Los equipos que han instrumentado búsqueda de código asistida por IA junto con su stack de observabilidad reportan tiempo significativamente más corto de diagnóstico a raíz durante incidentes. Una consulta en lenguaje natural sobre dónde el servicio de pago maneja reintentos en respuestas 503 expone la función relevante en segundos en lugar de los 20 minutos que toma leer a través de cinco archivos y una página de Confluence. Los 43 minutos de la ventana de presupuesto de errores se gastan en arreglar el problema, no en leer el código.

Cuatro Formas En Que Los Equipos Se Equivocan Con Los SLOs

Demasiados SLOs. Un equipo rastreando 12 SLOs simultáneamente tratará las alertas como ruido de fondo en dos meses. Tres a cinco SLOs enfocados en los comportamientos más visibles para el usuario es un techo manejable para un equipo de 10 ingenieros. Si necesitas más, organízalos en capas: SLOs críticos que disparan políticas de presupuesto de errores, e SLOs informativos que solo generan datos.

Medir infraestructura, no experiencia del usuario. Utilización de CPU, uso de memoria e I/O de disco son señales útiles de depuración. Son SLIs deficientes a menos que puedas probar que se correlacionan directamente con degradación visible para el usuario. Mide lo que experimenta el usuario: tasa de éxito de solicitud, tiempo de respuesta en P95 o P99, tiempo para renderizar la primera pieza significativa de datos.

SLOs establecidos sin análisis de costo operativo. Lograr disponibilidad del 99,99% típicamente requiere redundancia activa, conmutación por error multi-región y respuesta inmediata de oncall a cualquier hora. Si el equipo no puede operar sosteniblemente de esa manera, el SLO se romperá regularmente y luego se ignorará. Un SLO roto e ignorado es peor que ningún SLO: entrena al equipo para descartar alertas de confiabilidad.

Usar datos de presupuesto de errores para asignar culpa. Si la primera respuesta ante un presupuesto consumido es identificar quién envió el cambio que lo causó, la información dejará de ser honesta. Los presupuestos de errores son un recurso de equipo. Cuando el presupuesto se reduce, la pregunta es "¿qué arreglamos?" no "¿quién es responsable?"

La prueba de salud organizacional: ¿compartirías tu estado de presupuesto de errores actual en una reunión general de ingeniería sin que desencadene una discusión política? Si no, la cultura alrededor de los SLOs necesita más atención que los objetivos mismos. Las métricas de confiabilidad funcionan como herramientas de decisión solo cuando el equipo confía en que reportar un problema no crea un riesgo personal.

Los SLOs Necesitan Revisiones Trimestrales, No Anuales

Establecer un SLO no es una calibración única. Los servicios cambian, los patrones de tráfico se desplazan y el costo de mantener un nivel de confiabilidad dado cambia con ellos.

Cada 90 días, corre por cuatro preguntas:

1. ¿Se mantuvo el SLO? Si sí, ¿fue cómodo, sugiriendo que la meta podría ser más estrecha?

2. ¿Se consumió completamente el presupuesto de errores? ¿Qué incidentes condujeron a eso?

3. ¿El SLO produjo señal útil, o el equipo anuló la política de presupuesto de errores?

4. ¿La ventana de medición sigue siendo apropiada para cómo se está usando el servicio?

Si el equipo anuló la política de presupuesto de errores más de dos veces en un trimestre, el SLO probablemente esté mal calibrado. O bien la meta es demasiado ajustada, la ventana es demasiado corta, o la medición no refleja lo que los usuarios realmente experimentan.

Los SLOs son herramientas de calibración. Están diseñados para ser ajustados a medida que la confiabilidad mejora, a medida que el tráfico crece y a medida que el negocio cambia su tolerancia al tiempo de inactividad. Un equipo que revisa y ajusta sus SLOs trimestralmente está ejecutando una práctica de confiabilidad. Un equipo que los estableció una vez y no los ha tocado desde que tiene un dashboard con números que no significan nada para nadie.