Статистические baseline''''ы: почему один запуск — не измерение

«Этот PR делает сервис на 15% быстрее» — основано на одном прогоне на staging, добавлено к ревью. Это реально? Уровень шума в большинстве систем — 5-10% между идентичными прогонами. Без большего числа прогонов и перцентилей не понять.

Почему один прогон ненадёжен

Один и тот же сценарий, запущенный дважды, может отличаться на 5-10% из-за причин, не связанных с кодом:

• Временны́е отличия GC (окна stop-the-world смещаются между прогонами)
• Решения OS-планировщика (какое CPU-ядро, когда вытеснен)
• Состояние кэша на старте прогона (L3 холодный vs тёплый)
• Временные конкурентные обращения к сети или диску
• Масштабирование частоты CPU на ноутбуках (троттлинг при тепловой нагрузке)

«15%-ное ускорение» из одного прогона не отличить от этого шума. Это может быть реальная победа, может быть совпадение — не скажешь.

Что репортировать вместо этого

• Минимальное число прогонов: 5-10 для макробенча, 30+ для короткого микробенча.
• Репортируй: медиану, p95 и p99 — не среднее. Среднее захвачено выбросами; медиана устойчива к ним.
• Укажи разброс: стандартное отклонение или доверительный интервал.
• Как выглядит защищаемый результат: «p99 задержки упал с 480 мс до 320 мс в пяти 5-минутных прогонах, p50 с 60 мс до 55 мс, с 95% ДИ ±15 мс на каждое измерение».

«10%-ное ускорение» реально только если медиана улучшилась на ≥10% И p95/p99 не деградировали.

Почему среднее — неверная метрика

Распределения задержек имеют длинный хвост. Сервис, обрабатывающий 99% запросов за 50 мс, а 1% — за 2000 мс, имеет среднее около 70 мс — которое скрывает хвост в 2000 мс, испытываемый пользователями. Среднее захвачено выбросами в любую сторону. Медиана (p50) устойчива к выбросам; p99 описывает пользовательский опыт на хвосте.

Дисциплина: репортируй числа как учёный — с распределениями и неопределённостью, а не как маркетолог — с единственным процентным показателем.