Парадокс инспекции: почему пользователи ждут дольше, чем показывают метрики

Сервис отчитывается о среднем времени ответа 100 мс, но пользователь ждёт в среднем 1 секунду. Оба правы. Причина заключается в парадоксе инспекции: заказчики не видят распределение задержек $f(t)$, а его взвешенную версию, где каждый момент времени ожидания имеет вес. Если среднее время ответа составляет $\mathbb{E}[X]$, то среднее время, которое воспринимает пользователь, равно $\mathbb{E}_a[X] = \frac{\mathbb{E}[X^2]}{\mathbb{E}[X]}$, или, упрощённо, $\mathbb{E}[X] + \frac{\mathrm{Var}(X)}{\mathbb{E}[X]}$.

Практический пример: если время восстановления при сбое имеет медиану 30 минут и 99-й перцентиль 600 минут (10 часов), то MTTR по метрикам составит чуть свыше часа. Но среднее время восстановления в опыте пользователя достигнет 6 часов. Это объясняется тем, что большую часть времени ожидания пользователь проводит в длинных хвостах распределения, которые доминируют в восприятии.

Ключевые факты

Метрики сервиса и опыт пользователя расходятся из-за различного взвешивания времени ожидания
Долгие задержки и сбои имеют непропорционально большой вес в восприятии клиента
Дисперсия выходит на первый план: длинный хвост распределения доминирует в среднем ожидании пользователя
Для времени восстановления нет способа скрыть задержку повторными попытками, как для обычных запросов
Тримированные средние (исключающие экстремумы) опасны при оценке SLA, так как скрывают критичный контекст хвоста

Ред. Дашборд говорит 100 мс, клиент чувствует секунду, и оба формально правы. Примерно так рождаются совещания.

Почему это важно

Расхождение между метриками и пользовательским опытом объясняет, почему умеренные SLA могут вызывать сильное раздражение клиентов. Пользователи помнят долгие ожидания и катастрофические сбои ярче, чем среднее случается. Решения, оптимизированные только на среднее значение, игнорируют эту асимметрию восприятия. Это касается как задержки обычных запросов, так и времени восстановления при инцидентах.

Ред. «Среднее у нас отличное» давно стало корпоративным способом не смотреть на p99.

Кому это важно

Инженерам, отвечающим за надёжность и производительность сервисов, особенно тем, кто полагается на чтение метрик при согласовании SLA с бизнесом. Менеджерам продукта, которые видят диссонанс между отчётами о MTTR и жалобами клиентов. Командам, работающим с критичными приложениями (финансы, здравоохранение, коммуникация), где даже небольшой процент долгих отказов резко снижает пользовательскую удовлетворённость.

Ред. Отдельный привет менеджерам, которые сверяют зелёный отчёт по MTTR с потоком гневных тикетов и не понимают, кто из них врёт. Никто.

Как это применить

Начните с анализа полного распределения задержек, а не только среднего и процентилей. Используйте интерактивный калькулятор для своих медиан и p99-параметров и сравните воспринимаемое среднее с метрикой сервиса. При установке SLA и целей надёжности учитывайте дисперсию распределения, а не только среднее. Для критичных операций ориентируйтесь на 99-й и 99.9-й перцентили. Отслеживайте и сокращайте именно правый хвост распределения, так как именно он определяет ощущение клиента.

Ред. «Просто смотрите на всё распределение» советуют ровно тем, кто годами оптимизировал одно число, потому что его удобно вешать на стену.

Можно ли доверять

Объяснение опирается на давно известный парадокс инспекции (inspection paradox), математически стройно. Автор использует логнормальное распределение для моделирования, но явно указывает, что это выбор ради удобства вычислений, а не утверждение о реальном виде распределения задержек в production. Цифры в примере (30 минут медиана, 600 минут p99) пересчитаны корректно. Рекомендация избегать тримированных средних обоснована связью с Little's Law и использованием ёмкости, хотя полный аргумент не раскрыт.

Ред. Автор честно признаётся, что логнормальное распределение взято для удобства счёта, а не потому что мир такой. Редкая откровенность для текста с формулами.

Риски и подводные камни

Логнормальная модель удобна математически, но может плохо описывать реальные хвосты задержек в сложных системах. Статья не обсуждает, как различаются восприятия пользователя при различных паттернах использования сервиса (один дорогой запрос в день против тысячи дешёвых). Для времени восстановления предлагается не прятать задержку повторами, но реальные архитектуры часто включают failover и circuit breaker, которые усложняют картину. Наконец, сократить дисперсию часто сложнее, чем снизить среднее, и требует понимания источников вариативности.

Ред. Снизить среднее легко, снизить дисперсию дорого. Поэтому все снижают среднее и удивляются, почему клиент всё ещё недоволен.

«Most of the time they're waiting, they're waiting for things that take a long time. This is (roughly) how humans experience time.»

— Marc Brooker, brooker.co.za