A Alice no le gusta esperar

• Aunque el tiempo promedio de solicitud del servicio sea de 100ms y el MTTR sea menor a 1 minuto, los usuarios sienten el tiempo promedio de espera como mucho más largo porque quedan atrapados más tiempo en solicitudes largas y caídas prolongadas
• Los operadores agrupan solicitudes e incidentes por evento, pero usuarios como Alice y Alex calculan la espera según el tiempo percibido en segundos y minutos
• Esta diferencia se debe a la paradoja de la inspección (inspection paradox), y la distribución que experimentan los usuarios no es la distribución original de latencia f(t), sino una distribución ponderada por t
• En una distribución lognormal con mediana de tiempo de recuperación de 30 minutos y p99 de 600 minutos, aunque el MTTR apenas supere 1 hora, el tiempo promedio de recuperación percibido por el cliente puede aumentar hasta unas 6 horas
• La latencia de cola y los tiempos largos de recuperación pueden dominar la experiencia del cliente, y la media recortada (trimmed mean) corre el riesgo de descartar información importante de la cola derecha

---

La brecha entre el promedio por solicitud y el promedio percibido por el usuario

• Alice usa un servicio web y, como la mayoría de las personas, percibe el tiempo en segundos y minutos
• El operador puede ver que una solicitud promedio termina en 100ms, pero el tiempo promedio de espera de Alice puede ser de 1 segundo
• En las caídas ocurre la misma diferencia
  • El operador puede decir que el MTTR es de menos de 1 minuto
  • El tiempo promedio de caída que percibe Alex puede ser de 1 hora
• Ambas mediciones pueden ser correctas al mismo tiempo
  • Las solicitudes largas o las caídas prolongadas cuentan como un solo evento en el agregado del operador
  • En el tiempo del usuario, pesan más según cuánto duren

La distribución ponderada por t que produce la paradoja de la inspección

• Este fenómeno puede entenderse como la paradoja de la inspección
• El usuario no experimenta la distribución de latencia f(t) en sí, sino una versión ponderada por t
• Cuando el MTTR o el tiempo promedio de solicitud es E[X], el promedio que experimenta el usuario es el siguiente
  • E_a[X] = E[X²] / E[X]
  • E_a[X] = E[X] + Var(X) / E[X]
• Cuanto mayor sea la varianza, más se aleja el promedio percibido por el usuario del promedio de las métricas operativas

Ejemplo con mediana de 30 minutos y p99 de 600 minutos

• Si se usan la latencia mediana o el tiempo de recuperación mediano junto con el valor del percentil 99, se puede ajustar una distribución lognormal y comparar las métricas del servicio con los valores percibidos por el cliente
• Los valores del ejemplo son los siguientes
  • TTR mediano: 30 minutos
  • TTR p99: 600 minutos, es decir, 1 de cada 100 eventos tarda 10 horas en recuperarse
• En este caso, el MTTR supera apenas 1 hora, pero el tiempo promedio de recuperación que experimenta el cliente se vuelve de unas 6 horas

La latencia de cola y la trampa de la media recortada

• Hay varias razones para entender la latencia de cola y los tiempos largos de recuperación, y multiple samples es una de ellas
• En el tiempo de servicio, timeout-and-retry puede ocultar parte de la latencia
  • Eso sí, la solicitud en ejecución no debe estar reteniendo locks u otros recursos exclusivos
• En el tiempo de recuperación, ese ocultamiento no es posible, así que la pesadez de la cola se refleja de forma más directa en la experiencia del cliente
• Las medidas recortadas como trimmed mean tienen el problema de ocultar la forma de la cola derecha, que domina la experiencia del cliente
• Otra razón para no preferir medidas recortadas tiene que ver con la Ley de Little y el uso de capacidad, y se trata en un texto anterior

Precauciones sobre el uso de la distribución lognormal

• La distribución lognormal se elige por conveniencia en el cálculo numérico
• Tiene la propiedad de que lognormal(μ, σ²) pasa a ser lognormal(μ + σ², σ²), y funciona bien cerca de 0
• No necesariamente es una opción especialmente buena para métricas de latencia o tiempos de recuperación
• En general, parece mejor abordar este tipo de problemas con métodos no paramétricos

[GN⁺]

Comentarios en Lobste.rs

• Tal vez sería mejor cambiar el título por algo con más información, como Latency and the inspection paradox
  El título actual, en la práctica, transmite casi cero información 😅

  • Desde la perspectiva del autor, un título un poco ambiguo es bastante útil
    porque reduce las respuestas de gente que solo leyó el título y no el contenido

• Es interesante, pero no se entiende tan bien porque el autor no explica por qué esto es cierto más allá del término t-weighted y la fórmula
  Ojalá lo explicara más claramente para que también lo entienda alguien que olvidó su curso de estadística de la universidad hace mucho tiempo

  • Supongamos que hay un dashboard de monitoreo; normalmente se calcula la latencia promedio tratando todas las solicitudes por igual

    mean = (sum of all latencies) / (number of requests)  
    

    Eso es E[X], y el peso de cada solicitud es 1/N
    La latencia que percibe Alice está basada en el tiempo, así que supongo que de ahí sale lo de ponderado por tiempo (t-weighted)
    Si Alice envió M solicitudes con latencias x_1, x_2, ..., x_M, podemos preguntar: “Si eliges un segundo cualquiera del tiempo total de espera de Alice, ¿cuál es la latencia de la solicitud que está esperando en ese momento?”
    En ese caso, la solicitud i contribuye en proporción a x_i / (Σ_j x_j), así que las solicitudes largas se reflejan más
    Por eso el promedio ponderado por tiempo queda así

    E_a[X] = Σ_i x_i (x_i / Σ_j x_j) = Σ_i x_i^2 / Σ_j x_j  
    = (Σ_i x_i^2 / N) / (Σ_j x_j / N)  
    = E[X^2] / E[X]  
    

    Como ejemplo simple, si hay una solicitud con latencia de 1 segundo y otra de 10 segundos, el promedio normal es 5.5 s, pero el promedio ponderado por tiempo sería 1 * (1 / 11) + 10 * 10 / 11 = 9.18s

• Relacionado con esto, también vale la pena leer The Inspection Paradox is Everywhere

• Yo también he pensado algo parecido en la práctica
  Creo que el ejemplo más fácil para entender este problema es una encuesta donde se les pregunta a los pasajeros de autobús cuántas personas van en el autobús
  Entonces obtendrás muchas más respuestas de “el autobús va lleno”, pero cuando el autobús está vacío no puedes preguntarle a nadie
  Todos los autobuses podrían ir vacíos y solo uno estar lleno
  Si el objetivo es analizar la situación desde la perspectiva del usuario, creo que esta estadística es correcta

  • En teoría de grafos hay un resultado parecido: casi todos tienen amigos con más amigos que ellos mismos
    porque los nodos con muchas conexiones aparecen más seguido que los de pocas conexiones en la lista de adyacencia de otros nodos

• Si este tema te resuena, recomiendo mucho Gil Tene's "How not to measure latency"