Cuando Lento Cuenta Como Caído: el Objetivo de Nivel de Servicio para la Latencia
Un servicio lento falla para quien lo usa y supera todas las alertas de disponibilidad. Dos tercios de los profesionales de fiabilidad ya tratan la degradación como una interrupción. Lo que falta en la mayoría de las operaciones es un objetivo propio para la latencia.
El panel muestra un 100% de disponibilidad. La comprobación de estado responde con normalidad. Ninguna alerta se disparó en toda la mañana. Y, sin embargo, cada solicitud de pago tarda varios segundos, parte de los usuarios abandona a mitad del proceso y el equipo de soporte empieza a recibir quejas antes de que el equipo técnico detecte que hay un problema.
Para quien usa el servicio, esto es un fallo. Para una monitorización diseñada en torno a "está en marcha o no lo está", no ha pasado nada.
Lo que dice la práctica en 2026
El informe reúne 418 respuestas de profesionales de distintos sectores, tamaños y geografías. La cifra mide la gravedad percibida, no el impacto medido, pero la percepción ya basta para cambiar una decisión: si dos tercios de quienes operan sistemas sitúan la lentitud al nivel de la interrupción, una gestión de la fiabilidad que solo mide la interrupción deja fuera la mitad del problema.
SLI y SLO, en términos sencillos
La ingeniería de fiabilidad de sitios (SRE) organiza este tema con dos conceptos.
Un indicador de nivel de servicio (SLI) es una medida cuantitativa, definida con cuidado, de un aspecto del servicio prestado. La latencia de una solicitud, la proporción de solicitudes con error o la disponibilidad son indicadores.
Un objetivo de nivel de servicio (SLO) es el valor objetivo, o el intervalo de valores, para ese indicador. "El 95% de las solicitudes de pago responde en menos de 800 milisegundos, medido a lo largo de 30 días" es un objetivo. La cifra concreta es un ejemplo y no una recomendación: el umbral adecuado depende del recorrido y de quién lo utiliza.
El capítulo sobre objetivos de nivel de servicio del libro de SRE de Google señala la latencia de las solicitudes como uno de los indicadores que la mayoría de los servicios tiene en cuenta. En la práctica, muchas operaciones tienen un objetivo de disponibilidad y ninguno de latencia. Ahí es donde la degradación pasa desapercibida.
Por qué la media engaña
La tentación es medir la latencia media. El problema es que la media oculta justo lo que importa.
Un servicio puede tener una media cómoda y, al mismo tiempo, una de cada veinte solicitudes tardando diez veces más. Esas solicitudes lentas no siempre son aleatorias: pueden concentrarse en las horas de mayor carga, en los usuarios con más datos o en las operaciones más pesadas, que a menudo son las de mayor valor.
Los percentiles lo resuelven. Medir el percentil 95 o el percentil 99 muestra la forma de la distribución y revela la cola lenta, donde está el usuario insatisfecho. El mismo capítulo del libro de SRE de Google defiende exactamente esta elección: los percentiles permiten ver lo que la media borra.
Un objetivo por recorrido crítico, y no un objetivo global para todo el servicio, es el paso siguiente. Consultar un saldo y enviar un pago no tienen la misma tolerancia a la espera.
Medir desde donde está el usuario
Un detalle de medición cambia el resultado. La latencia medida en el servidor no incluye la red, la región ni el camino que recorre la solicitud hasta llegar allí. Un servicio puede responder rápido dentro del centro de datos y llegar lento a quien está al otro lado.
El informe de Catchpoint insiste en este punto: sin monitorizar desde donde realmente están los usuarios, la visión de la fiabilidad queda incompleta. Para un objetivo de latencia, eso significa elegir el punto de medición con el mismo cuidado que el umbral.
Cuando la latencia consume el presupuesto de errores
Un objetivo de nivel de servicio crea, por definición, un presupuesto de errores: el margen de fallo que el objetivo acepta. Si la meta es que el 95% de las solicitudes quede por debajo del umbral, el 5% restante es el presupuesto.
La decisión que separa una operación madura de una operación solo monitorizada es esta: cuando la latencia consume el presupuesto de errores, el caso se trata como una indisponibilidad. La misma vía de alerta, el mismo responsable, la misma revisión posterior al incidente.
Falta aún vincular el objetivo al negocio. En el mismo informe, solo el 26% de los profesionales evalúa directamente si las mejoras de rendimiento afectan a métricas de negocio como los ingresos o la satisfacción del cliente. Un objetivo de latencia sin ese vínculo protege el servicio, pero no puede defender la inversión que exige. Es la misma lógica que ya aparece en las métricas DORA de estabilidad de la entrega: lo que no se mide en términos de negocio acaba perdiendo la discusión del presupuesto.
Cinco preguntas antes de declarar fiable un servicio
- ¿Están identificados y nombrados los recorridos críticos del servicio?
- ¿Cada recorrido crítico tiene un indicador de latencia definido, además de la disponibilidad?
- ¿El objetivo está expresado en un percentil y no en una media?
- ¿La latencia se mide desde donde están los usuarios, o solo desde el servidor?
- ¿Existe un responsable designado que actúa cuando la latencia consume el presupuesto de errores?
Conclusión
La fiabilidad no es solo estar en marcha. Es ser lo bastante rápido para poder usarse. Mientras la latencia no tenga un objetivo propio, con percentil, punto de medición y responsable, la degradación seguirá siendo el fallo que la operación no ve y que el usuario ve siempre.
Para definir estos objetivos en los recorridos críticos, con capacidad sénior que refuerza el equipo interno, como se describe en la comparación entre SRE como servicio y equipo interno, es posible reservar una Sesión de Orientación, sin compromiso.