Цикл performance: дисциплина, а не проект

Команда исправила p99 с 1,2 с до 200 мс. Они объявили задачу завершённой, выпустили релиз и занялись другим. Через шесть месяцев p99 снова 900 мс. Не одна регрессия — просто новые фичи, новые библиотеки, больший JSON-ответ от upstream-сервиса. Исправление было правильным. Не хватало дисциплины.

Почему performance деградирует по умолчанию

Каждая новая фича добавляет байты, запросы или аллокации. Каждое обновление зависимостей привносит новые code path. Каждое изменение схемы может превратить быстрый запрос в медленный. Без механизма для обнаружения этих добавлений performance непрерывно деградирует.

Разовая оптимизация имеет эффективный период полураспада три-шесть месяцев. После этого окна накопленные изменения от новых фич отменяют улучшения. Команды, которые воспринимают performance как проект, добиваются результата — и постепенно откатываются назад. Команды, которые воспринимают его как дисциплину, удерживают результат.

Разница — в одном механизме: цикле.

Восьмишаговый цикл performance

Каждое расследование производительности, независимо от слоя, следует одной структуре:

1. Observe — появляется симптом: SLO burn, RUM-регрессия, жалоба пользователя, алерт на дашборде. Это говорит о том, что что-то не так, но не что именно.
2. Profile — захватить данные, подходящие к симптому. Flame graph по CPU для CPU-спайков, allocation profile для роста памяти, network waterfall для медленных загрузок страниц, bundle analyzer для client-side раздутости.
3. Classify — назвать bottleneck по family: CPU-algorithmic, allocation-bound, cache-bound, lock-bound, I/O-bound (N+1), syscall-bound (batching), JIT-deopt, bundle-bound. Каждая family имеет известный набор исправлений.
4. Predict — использовать закон Амдала для оценки улучшения headline-метрики при устранении этого hotspot. Если прогноз ниже целевого SLO, это не тот hotspot — вернитесь к шагу 2.
5. Fix — из playbook family выбрать технику, соответствующую конкретной форме hotspot. Применить только предсказанное изменение; никакого scope creep.
6. Verify — повторно профилировать под той же нагрузкой. Подтвердить, что и локальный hotspot уменьшился, И headline-метрика улучшилась.
7. Enforce — добавить CI gate, алерт или запись в runbook, предотвращающую возврат именно этой регрессии.
8. Move on — найти следующий bottleneck. Цикл никогда не заканчивается; он перемещается между слоями.

Метафора с кухней

Performance похожа на уборку кухни, а не на покраску комнаты. Покрасить один раз — достаточно. Кухня, убранная однажды, снова загрязняется по мере приготовления еды; её убирают непрерывно.

Каждый из семи фрагментов этой главы — инструмент: профилировщик, классификатор горячих путей, средство исправления GC, детектор N+1, бэтчер, анализатор бандла. Ни один не удержит кухню чистой сам по себе; это делает цикл.

Квартал Беа и Свена

Беа приходит в команду, где год назад сервис был быстрым. Теперь p99 — 1,2 с вместо 200 мс. Свен объясняет ей цикл: профиль показывает GC pressure на 18%, N+1 в /orders добавляет 50 запросов на запрос, бандл /dashboard вырос на 800 КБ за шесть месяцев. Никакого единственного кризиса — три отдельных медленных накопления.

Они запускают цикл для каждого bottleneck поочерёдно: исправление аллокации логгера (неделя 1), дедупликация запросов (недели 2–3), code-split бандла (неделя 4). Через месяц p99 — 280 мс. CI gates удерживают работу живой в следующем квартале при поставке фич.