Нагрузочный отчёт показывает нормальный p95, хотя часть запросов завершается тайм-аутом: тайм-ауты исключены из выборки. Как это искажает вывод о соблюдении SLA?
Исключение тайм-аутов делает p95 оптимистичным: он рассчитывается только по завершившимся запросам и не отражает задержку неуспешных операций. Такой отчёт может ошибочно показать соблюдение SLA, хотя фактическая доля запросов, уложившихся в целевое время, существенно ниже.
Тайм-ауты нужно учитывать как неуспешные наблюдения с задержкой не меньше установленного лимита, а их долю отдельно показывать в отчёте. Точный способ расчёта зависит от формулировки SLA, но исключать такие запросы из анализа без явного пояснения нельзя.
Метрики задержки традиционно строились по завершённым операциям: для них известен фактический момент окончания и можно вычислить длительность. Не завершившийся вовремя запрос часто попадал в отдельный счётчик ошибок, из-за чего отчёты разделяли latency и reliability.
Такой подход удобен для диагностики, но опасен при оценке пользовательского качества. Если анализировать только успешные ответы, метрика отвечает на вопрос «насколько быстры успешные запросы», а не «какая доля всех операций обслужена в пределах SLA».
Предположим, SLA требует, чтобы не менее 99% операций завершались за 500 миллисекунд. В тесте 9 900 запросов завершились за 100 миллисекунд, а 100 запросов получили тайм-аут через 2 секунды.
Если исключить тайм-ауты, p95 будет около 100 миллисекунд, и сервис будет выглядеть полностью соответствующим SLA. Но фактически только 99% запросов завершились успешно, а если хотя бы часть успешных операций превысила 500 миллисекунд, требование уже нарушено.
Риск особенно велик при перегрузке: именно самые медленные запросы чаще всего превращаются в тайм-ауты и исчезают из распределения. В результате ухудшение системы может сопровождаться улучшением отображаемого p95.
Нужно разделять как минимум три показателя: долю успешных запросов, распределение задержек завершившихся запросов и долю операций, завершившихся в пределах SLA. Для SLA вида «99% запросов быстрее 500 мс» последний показатель является главным: в его знаменателе должны быть все операции, включая тайм-ауты и другие неуспешные результаты.
Если тайм-аут установлен на 2 секунды, для агрегированного распределения можно считать такой запрос наблюдением с задержкой 2 секунды или больше. Точное значение после тайм-аута неизвестно, поэтому это не обычное измерение, а ограниченное снизу наблюдение; однако для проверки порога 500 миллисекунд уже достаточно знать, что запрос его превысил.
Полезно публиковать отдельные ряды: p50, p95 и p99 среди завершившихся запросов, количество и долю тайм-аутов, а также долю всех операций, уложившихся в SLA. Нельзя бездумно складывать такие метрики между компонентами или этапами: нужно заранее определить, где начинается и заканчивается измерение сквозной операции.
Следует также проверить, где возникает тайм-аут. Клиент может прекратить ожидание раньше, чем сервер завершит работу, поэтому серверные журналы и клиентские метрики способны считать разные операции успешными и неуспешными. Для корректного анализа нужны единые идентификаторы запросов, согласованные границы измерения и явное правило обработки отменённых операций.
Компромисс состоит в том, что включение тайм-аутов в общую метрику лучше отражает пользовательский результат, но скрывает точную задержку после момента тайм-аута. Поэтому цензурированное значение используют для проверки SLA, а отдельный анализ причин тайм-аутов выполняют по очередям, зависимостям, загрузке ресурсов и серверным журналам.
Интернет-магазин проверяли при целевой нагрузке. Отчёт показывал p95 180 миллисекунд, но 3% запросов к оформлению заказа завершались клиентским тайм-аутом через 3 секунды. Сначала команда решила, что проблема связана только с редкими ошибками и не влияет на latency.
Рассматривались два варианта. Можно было оставить текущий отчёт и добавить рядом процент ошибок: это быстро, но не даёт единой метрики соблюдения пользовательского SLA. Другой вариант — считать операцию нарушившей SLA при тайм-ауте, независимо от того, успел ли сервер позже завершить её; этот вариант лучше отражает пользовательский результат, но требует согласовать границы операции и устранить двойной учёт повторных попыток.
Выбрали второй вариант: для каждой исходной операции учитывали итог, наблюдаемый клиентом, а тайм-ауты включали в расчёт нарушения SLA. Дополнительно отдельно показали p95 завершившихся запросов и долю тайм-аутов. После такого пересчёта выяснилось, что быстрые успешные ответы действительно не ухудшились, но целевой показатель успешного оформления заказа нарушался из-за ожидания блокировки в зависимости.
Дополнительный вопрос: Можно ли просто заменить каждый тайм-аут задержкой, равной значению тайм-аута?
Ответ: Для проверки превышения порога SLA — обычно да, если тайм-аут больше этого порога: достаточно зафиксировать факт, что операция не уложилась. Для точного расчёта среднего времени или хвостовых процентилей это приближение недостаточно, поскольку реальная серверная работа могла продолжаться дольше, а могла быть прекращена сразу после отмены клиента.
Дополнительный вопрос: Как учитывать повторную попытку после тайм-аута?
Ответ: Нужно различать логическую операцию пользователя и отдельные сетевые попытки. Если каждая попытка попадёт в знаменатель одинаково, одна пользовательская операция может искусственно увеличить объём и исказить SLA. Обычно отдельно измеряют результат логической операции, число попыток и их задержки, заранее определив, считается ли успешная повторная попытка восстановлением пользовательского SLA или первоначальный тайм-аут уже является нарушением.
Дополнительный вопрос: Почему высокий p99 среди успешных запросов не заменяет показатель доли операций в SLA?
Ответ: Процентиль описывает положение в распределении выбранной выборки, а не обязательно долю всех операций, включая исключённые ошибки. При исключении тайм-аутов p99 может быть низким даже при значительном количестве недоступных или слишком медленных запросов. Показатель доли операций в SLA непосредственно учитывает весь поток и поэтому необходим для вывода о выполнении договорного требования.