P95 y P99 en operación: SLOs, alertas y priorización de incidentes

El promedio de latencia es cómodo y casi siempre engañoso. Un dashboard que muestra 180 ms de respuesta puede ocultar que el 5% de las transacciones tardó más de dos segundos, y que ese 5% concentra los reclamos, los timeouts en integraciones y las escalaciones a operaciones. Para un gerente TI o una jefatura de infraestructura, la pregunta útil no es cuál es la latencia promedio, sino qué porcentaje de usuarios vive una experiencia degradada y cuánto tarda ese porcentaje. Ahí entran P95 y P99, no como conceptos estadísticos aislados, sino como insumos para decidir: qué alerta se dispara, qué incidente se prioriza y qué SLO se compromete con el negocio.

Este artículo asume que ya conoces la diferencia conceptual entre promedio y percentiles. El foco está en la aplicación operacional: cómo traducir P95 y P99 en decisiones concretas durante peaks, cómo evitar dashboards que dan falsa tranquilidad y cómo conectar estas métricas con un programa de Stress & Performance cuando la plataforma funciona bien en condiciones normales pero se degrada bajo tráfico real.

Qué mide cada percentil cuando llega un peak

Un percentil describe la posición de una observación dentro de una distribución. P95 indica el valor bajo el cual quedó el 95% de las mediciones; P99, el valor bajo el cual quedó el 99%. Dicho de otro modo: P99 es el umbral que solo supera 1 de cada 100 transacciones. En una plataforma que procesa 200.000 requests por hora, ese 1% son 2.000 transacciones por hora con una experiencia peor que el umbral. No es ruido estadístico: es volumen operacional.

Durante un peak, la distribución de latencia no se desplaza de forma uniforme. Lo típico es que la mediana se mantenga relativamente estable mientras la cola derecha se estira: P95 y P99 crecen mucho más rápido que el promedio. Ese comportamiento es la señal más útil que entrega un dashboard de latencia, porque anticipa saturación de recursos compartidos (pool de conexiones, colas de mensajes, CPU, I/O de disco, límites de un servicio downstream) antes de que el sistema entre en degradación generalizada.

Tres señales conviene observar en conjunto durante un peak:

• Separación entre P50 y P99. Si la brecha se amplía, hay heterogeneidad: algunos requests encuentran recursos libres y otros esperan. Suele apuntar a contención, no a falta de capacidad bruta.
• Pendiente de P95 en el tiempo. Un P95 que sube de forma sostenida durante 10–15 minutos es más accionable que un pico puntual. El pico puede ser un batch; la pendiente sostenida suele ser saturación.
• Correlación con errores y timeouts. Si P99 sube y los timeouts de clientes suben en paralelo, el problema ya es visible para el usuario. Si P99 sube pero los errores no, hay margen para actuar antes de que se note.

Errores frecuentes al leer dashboards de latencia

La mayoría de los problemas de interpretación no están en la métrica, sino en cómo se agrega y se presenta.

Promediar percentiles entre instancias. Si tienes 6 réplicas y promedias sus P99, el resultado no es el P99 del servicio. Un P99 agregado correctamente requiere recalcular sobre la distribución combinada o, como aproximación operacional, tomar el máximo entre instancias cuando el tráfico está balanceado. Promediar percentiles suaviza justamente lo que querías ver.

Ventanas demasiado largas. Un P99 calculado sobre una hora puede esconder un episodio de 4 minutos que generó la mayoría de los tickets. Para operación conviene mirar ventanas cortas (1–5 minutos) para detección, y ventanas largas (24 h, 7 días) para tendencia y capacidad. Son dos usos distintos y no se reemplazan.

Mezclar poblaciones heterogéneas. Si el mismo panel agrega endpoints de lectura cacheada con endpoints que escriben en base de datos, el P99 resultante no describe a ninguno de los dos. Segmentar por endpoint, por tipo de operación o por criticidad de cliente es lo que hace accionable el número.

Confundir latencia del servidor con latencia percibida. El tiempo medido en el backend no incluye DNS, TLS, red del cliente, renderizado ni reintentos. Un P99 de servidor de 300 ms puede corresponder a una experiencia de varios segundos en el navegador. Si el negocio mide experiencia, hay que instrumentar también el lado cliente o al menos el borde.

Alertar sobre el promedio. Una alerta basada en promedio se dispara tarde y con frecuencia por causas equivocadas. Las alertas útiles se construyen sobre percentiles altos, tasas de error y saturación de recursos, no sobre la media.

Cómo llevar P95 y P99 a SLOs, alertas y priorización

El valor operacional de los percentiles aparece cuando se convierten en compromisos y en reglas de decisión.

Definición de SLOs. Un SLO razonable se expresa como "el 95% de las solicitudes del endpoint de pago debe responder en menos de 400 ms, medido en ventana de 28 días". Es una frase verificable, con población definida, umbral y ventana. El P95 es el percentil natural para SLOs de experiencia general; el P99 se reserva para funciones donde la cola duele de forma desproporcionada (pagos, autenticación, APIs consumidas por clientes externos con SLA contractual).

Presupuesto de error. Si el SLO es 95% bajo 400 ms, el 5% restante es presupuesto consumible. Ese presupuesto permite decidir con criterio: mientras quede margen, se puede desplegar con más frecuencia; cuando se agota, se prioriza estabilización sobre features. Es una forma de convertir latencia en una conversación de gestión, no solo de monitoreo.

Alertas por quema de presupuesto. En lugar de alertar por un umbral puntual, se alerta cuando la tasa de consumo del presupuesto de error se acelera. Esto reduce falsos positivos y enfoca la atención en degradaciones que realmente comprometen el SLO.

Priorización de incidentes. Cuando hay varios frentes abiertos, el criterio puede ser: primero lo que afecta P99 de endpoints críticos con impacto en clientes externos; después lo que afecta P95 de endpoints internos; al final, degradaciones que solo mueven el promedio. Esta jerarquía evita que un incidente cosmético desplace a uno que sí está afectando transacciones.

Capacidad y pruebas. Los percentiles observados en producción son el insumo para diseñar escenarios de carga realistas. Probar solo contra el promedio de tráfico histórico subestima la cola. Un programa de pruebas de carga serio reproduce la distribución, no solo el volumen, y verifica cómo se comportan P95 y P99 cuando el sistema se acerca a sus límites. Ahí es donde el trabajo de Stress & Performance se conecta con la operación diaria: no se trata de romper el sistema, sino de saber dónde empieza a degradarse la cola antes de que lo haga en producción.

Criterio práctico para incorporarlo en tu operación

Antes de sumar más métricas, conviene ordenar lo que ya existe.

1. Elige 3 a 5 endpoints o flujos críticos. No instrumentes todo con el mismo rigor. Empieza por lo que, si se degrada, genera escalaciones o incumple compromisos con clientes.
2. Define para cada uno un SLO con percentil, umbral y ventana. Escríbelo en una frase. Si no cabe en una frase, no es un SLO, es una intención.
3. Asegura que la métrica se calcule sobre la población correcta. Segmenta por endpoint, por instancia y por tipo de cliente cuando aplique. Verifica que el sistema de observabilidad no esté promediando percentiles entre réplicas.
4. Configura alertas sobre quema de presupuesto de error, no sobre picos instantáneos. Ajusta la sensibilidad con datos de las primeras semanas.
5. Revisa P95 y P99 en los post-mortem. Un incidente sin lectura de percentiles deja sin aprender la parte más útil: cómo se estiró la cola y qué la estiró.
6. Valida los umbrales con pruebas de carga que reproduzcan la distribución real. Un SLO definido en una sala de reuniones y nunca contrastado con tráfico sintético representativo es una hipótesis, no un compromiso.

Un punto de gobernanza que suele pasarse por alto: los SLOs de latencia son también evidencia operacional. Si tu organización está preparando controles asociados a la Ley 21.719 en materia de disponibilidad y trazabilidad de servicios que tratan datos personales, contar con SLOs definidos, mediciones consistentes y registros de incidentes con su impacto en percentiles aporta trazabilidad. No garantiza cumplimiento por sí solo, pero sí documenta que la operación se gestiona con criterios verificables.

La latencia no se resuelve con una métrica. Se resuelve cuando el equipo acuerda qué percentil importa, con qué umbral, en qué ventana, y qué se hace cuando se cruza. P95 y P99 no son más precisos que el promedio por ser "más técnicos": son más útiles porque describen la parte de la experiencia que el promedio esconde, y esa parte es la que genera tickets, incumplimientos y conversaciones incómodas con el negocio.