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

Сервис отчитывается о среднем времени ответа 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, так как скрывают критичный контекст хвоста

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

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

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

Инженерам, отвечающим за надёжность и производительность сервисов, особенно тем, кто полагается на чтение метрик при согласовании SLA с бизнесом. Менеджерам продукта, которые видят диссонанс между отчётами о 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