Инженерия производительности снова уперлась в старый неприятный вопрос: что делать, если P99 на дашборде есть, а понимания системы нет. На P99 CONF Адриан Кокрофт, один из ветеранов Sun, Netflix, eBay и Amazon, предложил смотреть не на один процентиль, а на форму распределения задержек — особенно на пики гистограммы.
Об этом сообщает The New Stack в материале по итогам беседы Кокрофта с аналитиком RedMonk Рэйчел Стивенс. Сам контекст занятный: конференция P99 CONF уже пять лет называется в честь метрики, которую ее же спикеры регулярно разбирают на запчасти. В этот раз удар пришел не по самой идее измерять хвосты задержек, а по привычке сводить сложное поведение сервиса к одному числу.
Кокрофт говорит о производительности не как теоретик из презентаций. В Sun он разбирался с производительностью Solaris и многопроцессорных систем, позже участвовал в облачной трансформации Netflix и связан с такими практиками, как Chaos Monkey. В старые времена, вспоминает он, инженеры смотрели на вывод vmstat и пытались угадать, что именно означают числа. Документация помогала не всегда, поэтому он пошел в исходники ядра, выяснил происхождение метрик и описал это в книгах Sun Performance and Tuning и Resource Management.
Сейчас стек другой: трассировка, метрики, профилировщики, observability-платформы, автоматические алерты. Но проблема, по версии Кокрофта, почти не изменилась. Инструменты могут показывать, что все выглядит нормально, пока пользователи или бизнес уже видят странное поведение. В такие моменты инженерия производительности начинается не с еще одного среднего значения, а с поиска нового угла: более мелкой гранулярности, распределений вместо агрегатов, отдельных медленных запросов вместо красивой линии на графике.
Главный пример — распределение времени ответа. Команды часто смотрят на среднее, P95 или P99 и делают вывод: стало быстрее, стало медленнее, хвост вырос, хвост сжался. Но один процентиль не говорит, что именно происходит внутри. У распределения может быть не один пик, а несколько. Типичный случай: быстрый пик для cache hit и медленный пик для cache miss. Если меняется доля попаданий в кэш, среднее и P99 начинают прыгать, хотя реальные задержки внутри каждого режима могли вообще не измениться.
Для разработчиков это не академическая придирка, а ежедневная ловушка. Команда видит движение P99, открывает инцидент, начинает искать деградацию в коде, сети или базе данных, а на деле изменилась смесь запросов. Один и тот же сервис стал чаще ходить по медленному пути, но сам медленный путь не стал медленнее. В отчете для менеджмента это выглядит как ухудшение производительности; в инженерной реальности это может быть изменение профиля нагрузки, поведения кэша или маршрутизации трафика.
Кокрофт предлагает разбирать гистограммы как набор пиков и отслеживать, как они меняются во времени. Для этого он сделал открытый инструмент на R: тот ищет произвольное количество пиков в распределении и показывает их динамику, не сплющивая картину в среднее. Интересная деталь — сам инструмент он быстро собрал с помощью ChatGPT, хотя давно не работал с R. Здесь AI выступает не как магический автопилот для продакшена, а как ускоритель для персональных исследовательских утилит, которые раньше просто не доходили бы до реализации.
Это важный сдвиг для инженерных команд. Большинство компаний не страдают от нехватки графиков; они страдают от того, что графики отвечают на слишком общие вопросы. LLM-инструменты могут помочь быстро собрать анализ под конкретную аномалию: вытащить данные, построить альтернативную визуализацию, проверить гипотезу, сделать временный инструмент для одного расследования. Не вместо нормальной observability-платформы, а рядом с ней — как рабочая отвертка, которую инженер точит под странный винт.
Для бизнеса вывод тоже неприятно практичный. SLA и SLO, построенные вокруг одного процентиля, удобны для договоров и отчетов, но бедны для диагностики. Если продукт растет, трафик становится неоднородным: разные регионы, тарифы, устройства, кэши, модели данных, интеграции. В такой среде P99 полезен как сигнал тревоги, но слаб как объяснение. Когда метрика дернулась, следующий вопрос должен быть не только насколько, но и какой режим системы стал чаще встречаться.
Совет Кокрофта командам звучит почти старомодно: начинать с макроуровня, находить интересное, затем углубляться до конкретных медленных запросов end-to-end. Разница в том, что теперь путь от идеи анализа до рабочего инструмента стал короче. Инженерия производительности, похоже, будет меньше похожа на поклонение стандартному набору дашбордов и больше — на серию быстрых проверок гипотез. P99 останется на экране, но ему все чаще придется делить место с гистограммами, пиками и неудобными вопросами к данным.