В отчёте одна средняя задержка объединяет быстрые проверки здоровья и редкие пользовательские операции. Какой риск создаёт такое агрегирование?
Такое агрегирование может скрыть проблемы критичных операций: общая средняя задержка взвешивается по количеству запросов, а не по важности операции для пользователя. Если быстрые проверки здоровья многочисленны, они снизят среднее значение даже при неприемлемой задержке редких бизнес-операций. Поэтому производительность следует анализировать как минимум по типам операций и отдельно по значимым пользовательским сценариям.
Единый показатель задержки удобен для быстрого контроля системы, но он возник как грубая сводка большого потока измерений. По мере усложнения сервисов один продуктовый запрос стал включать операции с разной стоимостью, частотой и критичностью, поэтому одной средней величины оказалось недостаточно для оценки пользовательского опыта.
Предположим, что проверки здоровья выполняются очень часто и завершаются быстро, а оформление заказа выполняется редко и работает медленно. Общее среднее будет в основном отражать проверки здоровья, хотя именно оформление заказа определяет восприятие качества и бизнес-результат.
Неверный вывод может привести к выпуску версии, которая формально улучшает среднюю задержку, но ухудшает ключевой сценарий. Дополнительный риск возникает при сравнении тестов с разным составом нагрузки: одинаковое общее среднее ещё не означает одинаковое поведение операций.
Сначала нагрузку разделяют на однородные группы: например, чтение каталога, поиск, оформление заказа и проверки здоровья. Для каждой группы рассчитывают объём, среднюю задержку, выбранные перцентили, долю ошибок и пропускную способность. Группы должны определяться по поведению и требованиям, а не только по URL, если один маршрут обслуживает разные операции.
Средняя задержка по всем запросам является взвешенным средним: более частые операции сильнее влияют на итог. Это полезно для оценки средней стоимости одного запроса, но не для ответа на вопрос, укладывается ли каждый критичный сценарий в свой SLA.
Перцентили тоже не следует бездумно усреднять между группами. Для общего p95 нужны исходные наблюдения либо корректная агрегация распределений; среднее отдельных p95 не является общим p95. Однако даже общий перцентиль не заменяет разрез по операциям, потому что он может не показать редкий, но бизнес-критичный сценарий.
Практически задают отдельные критерии: например, SLA для поиска, оформления заказа и фоновых операций. Итоговый отчёт должен показывать и состав нагрузки, и метрики каждой группы, иначе изменение долей операций может ошибочно выглядеть как улучшение или ухудшение системы.
В тесте интернет-магазина 90% запросов составляли проверки доступности и простое чтение, а 10% — оформление заказа. После изменения системы общее среднее время ответа снизилось, но задержка оформления заказа выросла из-за дополнительной синхронной проверки.
Рассматривались два варианта. Оставить один общий показатель было проще, но он скрывал регрессию. Считать только метрики оформления заказа было бы информативно для бизнеса, однако это потеряло бы сведения о влиянии остальных сценариев на ресурсы системы. Выбрали раздельные метрики по группам и отдельные SLA для критичных операций, сохранив общий показатель как вспомогательный.
После этого регрессию обнаружили до выпуска: общий средний показатель оставался хорошим, но p95 оформления заказа превышал целевой порог. Решение позволило одновременно контролировать ресурсную нагрузку всей системы и пользовательское качество ключевого сценария.
1. Дополнительный вопрос: Почему изменение долей операций может изменить общее среднее даже без изменения самой системы?
Потому что общее среднее зависит от весов операций. Если доля быстрых запросов увеличилась, итоговая задержка снизится даже при неизменных задержках всех типов; если возросла доля медленных операций, среднее увеличится. Поэтому сравнение прогонов требует сопоставимого состава нагрузки либо нормализации результатов по фиксированным весам.
2. Дополнительный вопрос: Достаточно ли сравнить средние задержки каждой операции, чтобы подтвердить отсутствие регрессии?
Нет. Среднее не показывает форму распределения и хвост задержек. У операции может сохраниться прежнее среднее, но вырасти p95 или p99 из-за редких сильных замедлений, поэтому для SLA обычно анализируют перцентили, ошибки и объём наблюдений.
3. Дополнительный вопрос: Как сравнивать два теста, если состав нагрузки в них различается?
Нужно сначала сравнить результаты по одинаковым группам операций, а затем при необходимости рассчитать сводный показатель с одинаковыми весами. Иначе различие общего результата может быть вызвано не изменением производительности, а только тем, что в одном тесте было больше быстрых или медленных сценариев. При этом одинаковые веса должны соответствовать цели сравнения: реальному продакшен-профилю, бизнес-приоритетам или отдельному техническому сценарию.