Сервис сохраняет прежнее среднее время ответа, но его p99 вырос вдвое. Как интерпретировать это расхождение?
Среднее время ответа осталось прежним, потому что медленными стали лишь небольшая доля запросов. Рост p99 означает ухудшение задержки для худших 1% запросов, поэтому часть пользователей или операций испытывает существенно более медленный сервис, даже если средняя метрика выглядит нормально.
Среднее арифметическое удобно для общей оценки, но оно плохо описывает распределения с длинным хвостом. В распределённых системах задержка отдельных запросов может резко возрастать из-за очередей, сборки мусора, сетевых задержек, дисковых операций или редких блокировок.
Поэтому для анализа качества обслуживания стали использовать перцентили. Они позволяют видеть задержку, ниже которой укладывается заданная доля запросов: например, p95 характеризует границу для 95% запросов, а p99 — для 99%.
Предположим, 99% запросов обрабатываются примерно за 100 миллисекунд, а оставшийся 1% — за несколько секунд. Среднее может измениться незначительно, особенно при большом количестве быстрых запросов, но пользователи, попавшие в хвост распределения, столкнутся с тайм-аутами, повторными действиями или каскадными задержками.
Если ориентироваться только на среднее, команда может решить, что производительность стабильна, и пропустить деградацию редких, но критичных операций. Это особенно опасно для цепочек микросервисов: хвостовая задержка одного компонента может повышать вероятность медленного ответа всей цепочки.
p99 — это значение задержки, ниже которого находятся примерно 99% измеренных запросов. Рост p99 вдвое означает расширение хвоста распределения, но сам по себе не указывает точную причину: нужно дополнительно исследовать сегменты по endpoint, региону, типу операции, размеру запроса и экземпляру сервиса.
Среднее и перцентили отвечают на разные вопросы. Среднее показывает суммарную нагрузку на пользователя или систему в среднем, а p99 показывает опыт почти самых медленных запросов. Поэтому их нельзя считать взаимозаменяемыми.
Для диагностики полезно сопоставить p50, p95, p99 и, при необходимости, p99,9. Если растёт только p99, вероятны редкие события или неоднородность экземпляров; если одновременно растут p50 и p99, деградация носит более массовый характер.
Перцентили имеют ограничения. Их значение зависит от окна измерения и объёма выборки: на малом числе запросов p99 может быть нестабилен, а усреднение перцентилей по инстансам или регионам может скрыть реальный хвост. Корректнее рассчитывать распределение на общей выборке либо явно учитывать веса сегментов.
Для алертинга следует задавать целевые показатели задержки для конкретного класса запросов, а не полагаться на одну глобальную метрику. Компромисс состоит в том, что контроль высокого перцентиля требует больше данных и может реагировать на редкие выбросы, но именно он лучше отражает пользовательский риск.
После изменения маршрутизации среднее время ответа API осталось около 120 миллисекунд, но p99 вырос с 400 до 1800 миллисекунд. Анализ по экземплярам показал, что несколько узлов периодически обслуживали запросы через перегруженный канал к хранилищу.
Рассматривались три варианта. Можно было увеличить число экземпляров, но это временно снизило бы вероятность перегрузки и не устранило бы неисправный маршрут. Можно было поднять тайм-ауты, однако это замаскировало бы проблему и увеличило бы длительность занятых ресурсов. Можно было исключить проблемные узлы из обслуживания, но это уменьшило бы запас масштабирования.
Выбрали временное исключение неисправных узлов с последующим исправлением маршрутизации. Такое решение напрямую уменьшало хвост задержки, а не улучшало только среднее значение; после исправления p99 вернулся к прежнему уровню без постоянного увеличения числа экземпляров.
Не всегда. При малой выборке p99 фактически определяется несколькими наблюдениями и может сильно колебаться. При сравнении нужно учитывать объём данных, одинаковость окна, состава трафика и способ расчёта; иначе изменение метрики может быть статистическим шумом.
Это указывает на локальную неоднородность, а не обязательно на деградацию всего сервиса. Причинами могут быть перегруженное оборудование, неравномерное распределение трафика, проблемы с локальным кэшем, сетевой маршрут или зависимость конкретного узла. Средняя метрика по кластеру способна скрыть такой случай, поэтому метрики нужно разрезать по экземплярам.
Последовательный запрос к нескольким компонентам накапливает задержки, а вероятность попасть хотя бы в один хвост возрастает с числом компонентов. Даже если каждый сервис редко отвечает медленно, итоговая операция может часто превышать целевой порог. Поэтому для критического пути важны не только индивидуальные перцентили, но и распределение задержки всей пользовательской операции.