¿Qué es un SLO? Guía práctica para devs en solitario
Resumen
¿Qué es un SLO? Es un objetivo interno de fiabilidad para un indicador medible, por ejemplo que el 99.9% de las peticiones funcione bien durante 30 días. La diferencia entre ese objetivo y el 100% es tu presupuesto de errores, unos 43 minutos al mes con 99.9%. Si desarrollas en solitario, empieza entre 99% y 99.5%, mide un camino real del usuario, avisa por burn rate y no por cada pico, y usa el presupuesto para decidir si lanzas o arreglas.
¿Qué es un SLO? Es un número que te prometes sobre cuántas veces tu servicio debe funcionar, medido en una ventana de tiempo fija. "El 99.9% de las peticiones salen bien en 30 días" es un SLO. Convierte "la web va bien" en algo que puedes comprobar, y te dice cuándo dejar de lanzar funciones y ponerte a arreglar cosas.
No necesitas un equipo de plataforma para esto. Un dev en solitario con una API y una base de datos Postgres puede escribir un SLO útil en una tarde. Aquí tienes qué significa el término, cómo elegir el número y dónde suele fallar.
A las 2 de la mañana nadie sabía si la app estaba rota
Imagina un side project con 400 usuarios semanales. Una noche, el endpoint de checkout empieza a devolver errores 500 durante unos 20 minutos. Nadie escribe en Twitter, nadie te manda un correo. Te enteras tres días después por un único mensaje de soporte.
¿Fue grave? Sin un objetivo no puedes responder. Con uno, sí: si tu SLO permite unos 43 minutos de fallos al mes y acabas de gastar 20, sabes que has usado casi la mitad de tu margen en una sola mala noche. Para eso sirve un SLO. Sustituye una sensación por un presupuesto.
SLI, SLO y SLA: los tres términos sin jerga
Mucha gente mezcla SLI, SLO y SLA todo el rato, así que va la versión corta.
Un SLI (indicador de nivel de servicio) es una medición. "Porcentaje de peticiones HTTP que devolvieron un estado distinto de 5xx en los últimos 30 días" es un SLI. Es una proporción de eventos buenos sobre el total.
Un SLO (objetivo de nivel de servicio) es la meta para esa medición. "Esa proporción debe mantenerse en 99.9% o más" es el SLO. Es interno: lo defines tú, lo puedes cambiar y nadie te demanda por él.
Un SLA (acuerdo de nivel de servicio) es un contrato con consecuencias, normalmente reembolsos o créditos. La mayoría de los side projects no tienen SLA, y no pasa nada. Puedes usar SLO sin tener ninguno. Si quieres la versión larga, el capítulo del workbook de Google SRE sobre cómo implementar SLO es la referencia estándar.
El orden importa: elige primero el SLI, luego el SLO, y piensa en un SLA solo si un cliente de pago lo exige por escrito.
Presupuesto de errores: la parte que cambia cómo trabajas
Un SLO del 99.9% también significa que el 0.1% de los eventos puede fallar. Ese margen es tu presupuesto de errores, y es la mitad útil de la idea.
En un mes de 30 días, una disponibilidad del 99.9% deja unos 43 minutos de caída permitida. La cuenta es 30 días × 24 horas × 60 minutos = 43 200 minutos, por 0.001. Un objetivo del 99% da unas 7.2 horas. Uno del 99.99% da unos 4.3 minutos.
Esos dos últimos números explican por qué la mayoría de proyectos pequeños no deberían apuntar alto. Cuatro minutos al mes significan que un despliegue malo y un rollback ya rompen el objetivo. Lo que suele pasar en la práctica es esto: cuanto más alto apuntas, más tiempo dedicas a defender el número en vez de construir el producto.
El presupuesto también te da una regla para decidir qué construir después. Si el presupuesto está casi intacto, lanza la funcionalidad arriesgada. Si lo has gastado, arregla primero lo que falla. Sin reunión, solo un número en un panel.
Cómo elegir un SLI que puedas medir de verdad
Empieza por lo que un usuario llamaría "roto". En una web, normalmente se reduce a dos preguntas: ¿la petición salió bien? y ¿fue lo bastante rápida?
En la mayoría de side projects, dos SLI cubren el 90% del valor:
Disponibilidad: peticiones buenas divididas entre peticiones totales, donde "bueno" significa una respuesta que no sea 5xx.
Latencia: el porcentaje de peticiones respondidas por debajo de un umbral, por ejemplo el 95% de las peticiones por debajo de 500 ms.
Fíjate en que la latencia se escribe como porcentaje de peticiones por debajo de un umbral, no como media. Las medias esconden la cola lenta, y la cola lenta es donde los usuarios se rinden. Pensar en percentiles importa aquí: una media de 300 ms puede convivir con un p99 de 4 segundos.
Mide en el borde de tu sistema, lo más cerca posible del usuario. Un health check que hace ping a /healthz desde dentro de la misma VPC te dice que el proceso está vivo, no que los usuarios pueden iniciar sesión. Si solo puedes permitirte una medición, prueba un camino real del usuario, como el login o el checkout, desde fuera.
¿Y no es esto simplemente monitorización de uptime con pasos extra? En parte, sí, aunque se solapan. Un monitor de ping te dice que el sitio respondió en un minuto concreto. Un SLO te dice qué porcentaje de peticiones reales de usuarios funcionó durante el mes y qué implica para tu siguiente decisión. Imagina dos semanas en las que el monitor de ping marca verde cada minuto, pero una consulta lenta a la base de datos hace que el dashboard agote el tiempo para el 3% de los usuarios con sesión iniciada. El monitor dice que todo va bien. El SLI dice que no has cumplido el objetivo de latencia. Solo uno de los dos cambia lo que haces el lunes. Conserva el monitor de ping de todos modos: es barato y detecta caídas totales rápido. Trátalo como una entrada más, no como la definición de "funciona".
Para empezar no necesitas proveedor. Escribe esto en tu repo, en un archivo llamado SLO.md:
service: checkout-api
window: 30d
slis:
availability:
good: http_status < 500
total: todas las peticiones salvo /healthz
latency:
good: response_time < 500ms
total: todas las peticiones salvo /healthz
objectives:
availability: 99.5%
latency: 95%
if_budget_burned:
- congelar las funcionalidades no urgentes
- corregir primero la principal fuente de erroresSi tu stack ya exporta contadores de peticiones, el SLI de disponibilidad en sintaxis tipo Prometheus cabe en una línea:
sum(rate(http_requests_total{status!~"5.."}[30d]))
/ sum(rate(http_requests_total[30d]))Ese cociente, comparado con tu objetivo, es todo tu panel de SLO. Lo demás es pulido. Bastan tres paneles: SLI actual, presupuesto restante y una línea de burn rate.
Elegir el número: empieza más bajo de lo que parece
La respuesta honesta para un proyecto nuevo es 99% o 99.5%. Mira tus últimos 30 días de datos, calcula lo que realmente entregaste, pon el SLO ligeramente por debajo de eso y ajústalo más adelante si los usuarios se quejan.
Una guía orientativa para un proyecto en solitario:
Herramienta personal, sin ingresos: 99% basta. Unas 7 horas de fallos al mes son invisibles para la mayoría de usuarios.
SaaS de pago con unas decenas de clientes: entre 99.5% y 99.9%, según lo sensible al tiempo que sea el producto.
Cualquier cosa de la que dependan clientes en horario laboral: 99.9%, y prueba tu camino de rollback antes de prometerlo.
Probado, no óptimo, y merece la pena igualmente: un SLO que cumples el 100% del tiempo está puesto demasiado bajo, y un SLO que incumples cada mes es un número en el que nadie confía. Procura fallarlo de vez en cuando, porque ahí es cuando el presupuesto hace su trabajo.
Alertar por burn rate, no por cada pico
El error que casi todo el mundo comete: avisar cada vez que la tasa de errores supera un umbral. Te despiertan a las 3 de la mañana por un pico de 90 segundos que costó el 0.2% del presupuesto del mes.
El burn rate lo arregla. Mide a qué velocidad consumes el presupuesto comparado 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 el presupuesto vacío y sin sorpresas. Un burn rate de 10 significa que te quedarás sin presupuesto en tres días.
Para una persona, una configuración sensata son dos alertas. Una rápida, por ejemplo un burn rate superior a 10 durante una hora, que te despierta. Y una lenta, por un burn rate de unas 2 veces durante un día, que se convierte en un ticket para la mañana. El capítulo del libro de Google SRE sobre objetivos de nivel de servicio explica el razonamiento detrás de esto, y la versión de ventanas múltiples está en el workbook enlazado arriba.
Puedes ejecutar SLO desde una hoja de cálculo y un cron durante un mes mientras aprendes qué te importa. Cuando los números empiezan a pesar, una herramienta se gana su sitio. Tres merecen una mirada, con la advertencia de que tu stack decide más que la lista de funciones.
Grafana es la opción por defecto para quien ya exporta métricas de Prometheus. El plan gratuito es generoso para un side project, y la función de SLO se apoya en datos que probablemente ya tienes. Sáltatela si aún no tienes una canalización de métricas y no te apetece montarla.
New Relic tiene un plan gratuito con 100 GB de ingesta de datos al mes y herramientas de SLO integradas en la plataforma. Encaja si quieres una instalación basada en agente con poca configuración. La contrapartida es que los costes se vuelven menos predecibles cuando superas la cuota gratuita.
Datadog es la opción más completa y también la más cara, con infraestructura, APM y logs facturados por separado. Merece la pena si alrededor tuyo crece un equipo. Para un proyecto en solitario, sáltatela, salvo que alguien más pague la factura.
Elijas lo que elijas, resiste la tentación de definir quince SLO el primer día. Uno de disponibilidad y uno de latencia por cada servicio visible para el usuario bastan para aprender.
Un mes completo con aritmética real
Digamos que tu SLO es 99.5% de disponibilidad en 30 días, y sirves unas 600 000 peticiones al mes. Ese objetivo permite un 0.5% de fallos, es decir, 3 000 peticiones fallidas antes de que el presupuesto se agote.
El día 9, una migración mala devuelve errores 500 durante 25 minutos y te cuesta 1 100 peticiones fallidas. Has gastado cerca del 37% del presupuesto en una sola tarde. El día 17, una API de terceros da timeout y se come otras 900. Ahora llevas aproximadamente un 67% gastado con 13 días por delante.
Ahí es donde el presupuesto se gana su sitio. No tienes que entrar en pánico, pero tampoco deberías lanzar la refactorización arriesgada que tenías planeada para el día 20. Añades un timeout y un fallback para esa llamada de terceros, escribes la comprobación de migración que te saltaste y pasas la refactorización al mes siguiente.
La lección no es que los fallos sean malos. Los fallos se esperan y ya están contemplados en el presupuesto. Lo que te da el número es una respuesta tranquila y compartida a "¿podemos permitirnos este riesgo ahora mismo?", aunque la única persona en la sala seas tú.
Tres errores que vuelven inútil un SLO
Medir lo que es fácil en vez de lo que siente el usuario. El uso de CPU no es un SLI. A los usuarios no les importa que tu CPU esté al 40%. Les importa que la página cargue.
Fijar el objetivo por ambición. "Queremos cinco nueves" suena serio y no significa nada si tu base de datos es una única instancia en una VM pequeña. Define el SLO a partir de la realidad observada, mejora el sistema y luego endurece el número.
No usar nunca el presupuesto. Si terminas cada mes con el 98% del presupuesto sin tocar, estás desplegando demasiado despacio o el objetivo es demasiado laxo. Un presupuesto sin usar es capacidad de asumir riesgo desperdiciada.
Revisa cada SLO una vez por trimestre, o después de cualquier mes en el que lo incumpliste con holgura o no llegaste a tocar el presupuesto. Incumplirlo dos meses seguidos significa que el sistema necesita trabajo de verdad o que el objetivo era ambicioso para tu etapa. Ambas cosas son datos útiles.
Y si algún día tienes clientes de pago, pregúntales qué significa "roto" para ellos. Quien usa un informe semanal se preocupa por el lunes por la mañana, no por un fallo de un sábado por la noche, y tu SLO puede reflejarlo con un objetivo más estricto durante sus horas de uso.
¿Qué pondrías tú primero bajo un SLO? Elige un endpoint que los usuarios notarían si se rompiera, escribe el SLI en lenguaje llano, fija el objetivo 0.5 puntos por debajo de lo que entregaste el mes pasado y revísalo dentro de 30 días. ¿Cuál de tus servicios te da más desconfianza ahora mismo?