¿Qué es un SLO? Guía práctica para equipos de plataforma

¿Qué es un SLO? Un SLO (service level objective, objetivo de nivel de servicio) es la meta de fiabilidad de un comportamiento concreto que percibe el usuario, medida durante una ventana fija. «El 99.9% de las peticiones de pago se completan en menos de 800 ms, en 30 días» es un SLO. «La web debe ir rápido» es un deseo. El número importa menos que lo que controla: el SLO decide cuándo sigues desplegando y cuándo paras.

Son las 03:12. PagerDuty avisa de que la latencia del checkout está «elevada». Abres el dashboard y ves una línea de p99 que lleva cuarenta minutos subiendo. Nadie puede decirte si eso es un problema, porque nadie escribió nunca cuánta latencia es demasiada. La discusión que sigue, en una llamada y con un ojo puesto en Slack, es el coste de no tener un SLO.

SLI, SLO y SLA: tres palabras, tres dueños

Se usan como si fueran intercambiables. No lo son, y confundirlas es como acaban los equipos firmando un contrato que no pueden cumplir.

• SLI (service level indicator) es la medición. Una proporción de eventos buenos sobre eventos válidos: peticiones que devolvieron 2xx en menos de 800 ms, divididas entre todas las que debían responder así.

• SLO (service level objective) es la meta para esa proporción durante una ventana. 99.9% en 30 días.

• SLA (service level agreement) es el contrato con el cliente, con dinero en juego si se incumple. Siempre es más laxo que el SLO. Si tu SLA dice 99.9% y tu SLO también, no te queda margen para notar un problema antes de tener que pagar créditos.

El capítulo del libro SRE de Google dedicado a los objetivos de nivel de servicio traza la misma línea: el SLO es un objetivo interno, más exigente que cualquier cosa que prometas hacia fuera. Ingeniería es dueña del SLI y del SLO. Producto y legal son dueños del SLA.

Evita la tentación de añadir una cuarta palabra por cada métrica que ya recoges. CPU, memoria y profundidad de cola sirven para depurar. No son SLI, porque ningún cliente las experimenta directamente.

Cómo es un buen SLI en la práctica

Un buen SLI es una proporción, se mide lo más cerca posible del usuario y tiene una definición clara de qué es «bueno».

Para un servicio dirigido por peticiones, lo habitual son dos SLI: disponibilidad (respuestas que no son 5xx sobre todas las peticiones válidas) y latencia (peticiones por debajo de un umbral sobre todas las válidas). Usa un umbral, no una media. La media esconde la cola, y la cola es de donde salen los tickets de soporte.

Mide en el balanceador o en el edge, no dentro del servicio. Un servicio que se cae al arrancar reporta una tasa de error perfecta para las peticiones que nunca recibió. Las métricas del lado servidor son ciegas a ese fallo, y el usuario lo vive como una caída.

Sé explícito sobre lo que queda fuera. Los health checks, las sondas sintéticas de tu propia monitorización y los 4xx causados por entradas incorrectas del cliente normalmente no deberían contar en tu contra. Escribe las exclusiones junto al SLO. Cuando alguien discute la cifra en una revisión de incidente, la discusión debe ser sobre la definición, no sobre lo que el dashboard muestre por casualidad.

La aritmética que nadie hace antes de elegir los nueves

Cada nueve extra reduce a una décima parte el tiempo de caída permitido. Esta es la tabla que conviene tener en el documento.

• 99% en 30 días: 1% de error budget, 7.2 horas de caída total permitida.

• 99.9%: 0.1% de budget, 43.2 minutos.

• 99.95%: 0.05% de budget, 21.6 minutos.

• 99.99%: 0.01% de budget, 4.32 minutos.

Relee la última línea. Al 99.99%, un despliegue malo que tarda cinco minutos en detectarse y revertirse ya ha agotado el mes. Ninguna persona puede responder a un aviso, abrir el portátil y revertir en menos de cuatro minutos, así que ese objetivo solo es alcanzable con automatización: una puerta que frene el rollout antes de que el presupuesto se agote.

Elige el número que el servicio necesita de verdad. La mayoría de las APIs internas viven bien en 99.9%. Una ruta de pagos puede justificar más. Un job batch nocturno puede bastar con 99%. Elegir 99.99% porque suena serio es la forma en que un equipo se apunta a una guardia que no puede cubrir.

El error budget es el punto, no el SLO

Un SLO de 99.9% significa que puedes fallar el 0.1% del tiempo. Ese 0.1% es tu error budget, y es la idea más útil de toda la disciplina.

El budget convierte una discusión en un número. Producto quiere lanzar la migración arriesgada. El SRE dice que es arriesgada. Sin budget, es opinión contra opinión, y gana el más veterano. Con budget, la pregunta pasa a ser: cuánto queda y cuánto puede consumir plausiblemente este cambio.

Dos reglas lo hacen funcionar.

1. Queda presupuesto: se despliega. Puedes asumir riesgo, así que asúmelo. Un equipo que nunca gasta su presupuesto invierte de más en una fiabilidad que los usuarios no pidieron.

2. Presupuesto agotado: congelación. El trabajo de funcionalidades se pausa hasta que el trabajo de fiabilidad devuelva el SLI por encima del objetivo. Esto solo funciona si la dirección lo aceptó antes del primer incidente, no durante él.

Si la segunda regla no se acordó de antemano, no tienes un SLO. Tienes un dashboard con una zona verde y una zona roja.

Alertar por burn rate, no por el SLI en sí

Aquí fallan la mayoría de los primeros intentos. Alguien configura una alerta para cuando la disponibilidad baja del 99.9%. La alerta salta cuando el daño ya está hecho, o parpadea con cada pequeño bache, o ambas cosas.

La señal mejor es el burn rate: a qué velocidad consumes el presupuesto en relación con el ritmo que lo agotaría exactamente al final de la ventana. Un burn rate de 1 significa que terminarás el mes con cero presupuesto. Un burn rate de 14.4 significa que, a ese ritmo, quemarás el presupuesto de todo el mes en unos dos días.

El Google SRE Workbook sobre alertas basadas en SLO recomienda combinar una ventana larga con una corta, para que la alerta sea significativa y siga ocurriendo. Para un SLO de 30 días, dos páginas son un buen punto de partida:

• Burn rate 14.4 en 1 hora, confirmado en 5 minutos: consume el 2% del presupuesto mensual. Avisa a alguien.

• Burn rate 6 en 6 horas, confirmado en 30 minutos: consume el 5% del presupuesto mensual. Avisa a alguien.

La aritmética es sencilla. Una ventana de 30 días son 720 horas. Quemar a 14.4x durante una hora consume 14.4 / 720 = 2% del presupuesto. La ventana corta evita que la alerta salte una hora después de que el problema ya haya terminado.

La primera regla, expresada como alerta de Prometheus y asumiendo que registras una tasa de error por ventana:

groups:
  - name: checkout-slo-burn
    rules:
      - alert: CheckoutErrorBudgetFastBurn
        expr: |
          job:checkout_error_ratio:rate1h > (14.4 * 0.001)
          and
          job:checkout_error_ratio:rate5m > (14.4 * 0.001)
        labels:
          severity: page
        annotations:
          summary: "Checkout está quemando el 2% de su error budget de 30 días por hora"

La constante 0.001 es la tasa de error permitida para un SLO de 99.9%. Si cambias el objetivo, esa constante cambia con él. Mantenla en un único sitio, o la alerta y el SLO se desincronizarán sin que nadie lo note.

Las quemas lentas no necesitan avisar a nadie. Un burn rate de 1 sostenido durante tres días va a un ticket para la mañana laborable siguiente. Despertar a alguien por una fuga lenta es la forma en que los equipos de guardia aprenden a ignorar el busca.

Dónde calcular el SLI sin comprar otra plataforma

No necesitas un producto de SLO dedicado para empezar. Necesitas un contador de eventos buenos, un contador de eventos totales y un sitio donde guardarlos durante 30 días.

Si tus métricas ya viven en una plataforma alojada, la función de SLO suele ser una capa fina sobre datos que ya pagas.

Datadog cubre los SLO de forma nativa, con alertas de burn rate, y es el camino fácil si tus trazas y métricas ya están ahí. La trampa es la factura: las métricas personalizadas y las etiquetas de alta cardinalidad se multiplican rápido, así que revisa el precio de las series de SLI antes de comprometerte.

Si usas Prometheus, Grafana cubre el mismo terreno mediante recording rules y sus herramientas de SLO, a costa de más configuración y de más de tu tiempo.

La comparación honesta es tiempo hasta la primera alerta útil frente a coste a escala. Datadog gana en lo primero. Grafana con Prometheus suele ganar en lo segundo. Elige según aquello en lo que tu equipo vaya más justo.

Conectar el SLO con el despliegue, la parte que más equipos se saltan

Un SLO que solo produce un informe se usa a medias. El paso que cambia el comportamiento es conectar el presupuesto con la ruta de despliegue, para que la release se detenga sola.

Un rollout progresivo con puerta de SLO funciona así. Despliega al 1% del tráfico detrás de un flag. Observa el SLI de esa cohorte frente a la línea base. Si el burn rate de la cohorte canary supera tu umbral, revierte automáticamente. Si aguanta, pasa al 5%, luego al 25% y después al 100%.

Eso es muy distinto de un dashboard que alguien debería estar mirando a las 03:12. A las 03:12 no quieres pensar. Quieres un botón, o mejor, no tener que pulsar nada.

Aquí es donde los feature flags se ganan su sitio, porque un flag convierte una reversión en un cambio de configuración que tarda segundos, en lugar de un redespliegue que tarda diez minutos.

LaunchDarkly y plataformas similares te dan el rollout por porcentaje y el kill switch. Lo que la mayoría deja en tus manos es la decisión: qué SLI leer, qué umbral cuenta como malo y quién puede anularlo. Esa es la brecha que un piloto automatizado con auto-rollback sobre SLO pretende cerrar, y es el ángulo que tomamos en upstreamapi. LaunchDarkly gana en amplitud de SDKs y en controles empresariales, y lo decimos.

Así se ve la puerta en TypeScript. La lógica de decisión es la parte que merece la pena escribir tú mismo, sea cual sea tu sistema de flags:

type Cohort = { good: number; total: number };

const SLO_TARGET = 0.999;
const BUDGET = 1 - SLO_TARGET; // 0.001
const PAGE_BURN_RATE = 14.4;

function burnRate(c: Cohort): number {
  if (c.total === 0) return 0;
  const errorRatio = 1 - c.good / c.total;
  return errorRatio / BUDGET;
}

export function rolloutDecision(canary: Cohort): "advance" | "hold" | "revert" {
  if (canary.total < 500) return "hold"; // muestra insuficiente para juzgar
  return burnRate(canary) > PAGE_BURN_RATE ? "revert" : "advance";
}

Fíjate en la rama hold. Un canary del 1% de un servicio tranquilo puede ver cuarenta peticiones en diez minutos, y un solo error sobre cuarenta es una tasa de error del 2.5%. Sin una muestra mínima, la puerta revierte por ruido y el equipo aprende a desconfiar de ella.

Errores que vemos en equipos de 80 ingenieros

Los mismos fallos aparecen en equipos distintos, y casi ninguno es técnico.

• Demasiados SLO. Veinte objetivos por servicio significan que nadie recuerda ninguno. Dos o tres por recorrido de usuario bastan.

• SLO que nadie acordó. Un ingeniero los escribe solo un fin de semana. Producto nunca los ha visto, así que la política de presupuesto se derrumba la primera vez que dice «no» a un lanzamiento.

• SLO fijados en el rendimiento actual. Si el servicio funciona hoy al 99.97%, fijar el objetivo en 99.97% no deja presupuesto y garantiza un incumplimiento. Ponlo donde los usuarios empiezan a estar descontentos, que casi siempre es más bajo.

• Tratar el SLO como algo permanente. Revisa la cifra cada trimestre. Si nunca gastas el presupuesto, endurece el objetivo o despliega más rápido. Si lo incumples cada mes, arregla el sistema o admite que el objetivo era una fantasía.

• Contar lo fácil en lugar de lo que se siente. Una respuesta 200 con un carrito vacío es un éxito en tus logs y un fallo para el cliente. Define «bueno» desde el lado del usuario.

Quién debe escribir el primero esta semana

No necesitas un programa. Elige el recorrido que haría que el CEO llamara a alguien si se rompiera. Define para él un SLI de disponibilidad y un SLI de latencia. Fija el objetivo en 99.9% para el primer trimestre, escribe la política de congelación en dos frases y consigue que producto responda «de acuerdo» por escrito.

Después añade una alerta de burn rate y un sitio donde todo el equipo pueda ver el presupuesto restante.

Si necesitas un lugar ligero para empezar antes de comprometerte con una plataforma completa, Better Stack cubre la monitorización de uptime y el aviso de incidentes con una configuración mucho más pequeña, aunque no te dará gratis las cuentas del presupuesto.

La primera versión estará equivocada. Es aceptable. Lo que importa es que la siguiente revisión de incidente parta de una cifra que escribiste de antemano, y no de una sensación.

Y tu 03:12, ¿cómo se ve ahora?

Piensa en el último incidente de tu equipo. ¿Había un número escrito que dijera si importaba? Si la respuesta honesta es no, ese es tu primer SLO, y el post-mortem ya te dijo qué medir.