SLOs que no mienten: medir lo que los usuarios sienten de verdad
La mayoría de los dashboards de fiabilidad están en verde mientras los usuarios maldicen su pantalla. El SLO dice 99,95%, las gráficas de CPU están tranquilas — y el checkout lleva diez minutos fallando. Ese margen es la señal: el SLO está midiendo el sistema, no a la persona que lo usa. Un SLO solo dice la verdad cuando mide lo que el usuario realmente siente.
Mide lo que siente el usuario, no la máquina
CPU, memoria y uptime del host no son experiencia de usuario. Una máquina puede estar al 30% de CPU mientras todas las peticiones dan timeout; puede ir al 95% y servir a todos a la perfección. El único juez de si tu servicio funciona es el usuario — así que el indicador tiene que venir de su lado del cable. Construye SLOs sobre el recorrido (¿tuvo éxito la petición, fue lo bastante rápida, la respuesta era correcta y reciente?), nunca sobre la infraestructura de debajo.
Un service level indicator (SLI) es uno de esos números: la proporción de eventos buenos sobre el total de eventos. La mayoría de los servicios necesita solo tres:
- Disponibilidad — la fracción de peticiones válidas que tuvieron éxito.
- Latencia — la fracción servida más rápido que un umbral que los usuarios notan, p. ej. 95% por debajo de 300 ms.
- Calidad o frescura — para datos y trabajo asíncrono, cuán correcto o cuán reciente es el resultado.
Dos hábitos mantienen esto honesto. Usa percentiles, no medias — una media sana esconde la cola lenta donde aterrizan los usuarios reales, así que cita p95/p99. Y mide lo más cerca del usuario que puedas — el load balancer, el edge, la monitorización de usuario real — porque las métricas del lado del servidor nunca ven fallos de DNS, problemas de CDN, ni la petición que nunca llegó.
Si los percentiles te resultan difusos: la latencia p95 es el tiempo de respuesta por debajo del cual entran el 95% de las peticiones — o sea, 1 de cada 20 usuarios espera más — y p99 es el 1% más lento. Una media mezcla la mayoría rápida y los pocos lentos en un único número que nadie experimenta en realidad; un percentil mantiene esa cola a la vista.
Las medias esconden a los usuarios rotos tan fácilmente como a los lentos. Una tasa de éxito del 99,5% se lee como a un redondeo de la perfección — pero a lo largo del tráfico real esa fracción es un flujo constante de gente topándose con fallos, normalmente amontonados en un segmento que el número global no puede ver. Ten siempre la capacidad de desglosar un SLI por recorrido, plataforma y región.
Un SLO por recorrido — con dueño y etiquetado
Los SLOs siguen recorridos de usuario, no tu organigrama ni servicios individuales. Define uno por recorrido — checkout, login, búsqueda — y resiste a fundirlos en un único número para todo el sitio: un SLO global se queda en verde mientras el checkout está roto, porque los assets estáticos sanos ahogan los fallos que importan. Y dale a cada recorrido el objetivo que merece; una ruta de pago y un widget de recomendaciones no necesitan la misma fiabilidad.
El presupuesto de error — el margen entre tu objetivo y el 100% — se convierte entonces en la moneda del equipo dueño. Los equipos están en buena medida aislados, y algunas superficies absorben mucho más fallo que otras, así que deja que cada equipo tenga y gaste su propio presupuesto: compra velocidad cuando hay margen y obliga a centrarse en la fiabilidad cuando se agota. Nada de esto funciona sin un etiquetado disciplinado — cada métrica, recurso y alerta etiquetado con servicio, equipo y recorrido — para que cada SLI agregue al dueño correcto y un presupuesto ardiendo apunte directo al equipo que puede arreglarlo.
Fija un objetivo que puedas defender
No vayas al 99,99% por reflejo. Cada nueve extra es exponencialmente más caro, y un objetivo que no vas a financiar de verdad es solo otra mentira en el dashboard. Elige el número que el recorrido genuinamente necesita — y mantén tu SLO interno más estricto que cualquier SLA que hayas firmado, para enterarte antes que el cliente.
Un SLO del 99,9% a lo largo de 30 días permite unos 43 minutos de 'malo' al mes. Ese número es justo el punto: convierte '¿somos lo bastante fiables?' de una discusión en una cuenta de aritmética.
Y no intentes clavar el número perfecto el primer día — no puedes. Ponlo demasiado alto y vives permanentemente fuera de presupuesto; demasiado bajo y no significa nada. Empieza midiendo dónde estás de verdad, fija el objetivo justo por encima de la realidad de hoy, y trátalo como un suelo móvil: en cada revisión semanal o mensual el equipo de SRE mira lo que aguantó y, si el servicio ha mejorado, sube el listón un nivel. El SLO sube como un trinquete sprint a sprint — cada paso un nivel que sostuviste de verdad, no uno que deseaste.
Haz del presupuesto una regla de decisión
Un presupuesto de error solo se gana el sueldo cuando cambia conductas, y la regla hay que acordarla de antemano. Queda presupuesto: lanza, haz la migración arriesgada, corre la prueba de carga en producción. Presupuesto gastado: congela los cambios arriesgados y mete el siguiente sprint en fiabilidad hasta volver al verde. Revisado cada semana, convierte la fiabilidad de una sensación en una decisión compartida y con dueño.
Alerta sobre el recorrido, navega hasta la causa
Como el SLO mide el recorrido, es lo único por lo que vale la pena recibir un aviso. La alerta salta ante un consumo de presupuesto visible para el usuario y abre el dashboard del recorrido — tasa de éxito, p95, presupuesto restante. Desde ahí navegas hacia abajo: a los dashboards de servicio de los componentes en la ruta, y luego a los recursos dependientes — base de datos, caché, cola, API upstream. Ver esas dependencias es valiosísimo para el diagnóstico; nunca es motivo para avisar. Unas etiquetas consistentes son lo que hace posible ese descenso — dejan que un dashboard en plantilla enlace con el siguiente, en vez de dejarte con un montón de pantallas desconectadas.
El SLO es también la entrada de tu alerting: alimenta la tasa de consumo del presupuesto en alertas multi-ventana, para que un breve hipo sea una nota al pie y un consumo sostenido sea un aviso (cubro ese mecanismo en 'Diseñar alertas que nadie ignora'). La cadena de dashboards te lleva entonces del aviso a la causa en tres clics, no treinta.
Calcúlalo automáticamente
Nada de esto debería mantenerse a mano. Calcula los SLIs a partir de la telemetría que ya tienes — Prometheus, Datadog, logs del load balancer — como recording rules, y muestra un panel por recorrido: SLI actual, objetivo, presupuesto restante, tasa de consumo. Si producir el número es manual, se pudrirá; si es automático, se convierte en lo primero que todos miran.
Por debajo, el SLI es una pequeña query: cuenta las peticiones, cuenta los errores, divide. Defínelo una vez como recording rule y cada dashboard y alerta reutiliza el mismo número.
# A — peticiones a lo largo de la ventana
- record: checkout:requests:rate5m
expr: sum(rate(http_requests_total{job="checkout"}[5m]))
# B — errores (HTTP 5xx) en la misma ventana
- record: checkout:errors:rate5m
expr: sum(rate(http_requests_total{job="checkout", code=~"5.."}[5m]))
# C — porcentaje de error = B / A (la parte "mala" del SLI)
- record: checkout:error_pct5m
expr: 100 * checkout:errors:rate5m / checkout:requests:rate5mRevisa y evoluciona
Los SLOs son promesas vivas, no una hoja de cálculo de una sola vez. Revisa los objetivos a medida que cambian el producto y las expectativas de los usuarios. Un presupuesto que nunca gastas significa que el objetivo es demasiado bajo — o que estás sobreinvirtiendo en una fiabilidad que nadie pidió; un presupuesto que revientas cada mes significa que el objetivo es irreal o que el servicio necesita trabajo de verdad. El SLO correcto se sitúa donde, de vez en cuando y de forma útil, duele.
Un SLO que mide al usuario, fijado en un número que de verdad vas a financiar, con dueño en el equipo que puede moverlo, y conectado a alertas que bajan directas a la causa — eso es un SLO que dice la verdad. Todo lo demás es una luz verde sobre un edificio en llamas.