Непрерывное профилирование в масштабе: затраты, CI-гейты, корреляция с трейсами и антипаттерны

Срабатывает SLO burn alert. В 2020 году дежурный открывает терминал, запускает ручной захват профиля, ждёт 60 секунд и смотрит на флейм-граф, который может представлять или не представлять трафик, вызывающий burn. В 2026 году кликает на алерт, кликает на медленный трейс, кликает на спан — и флейм-граф, отфильтрованный по этому конкретному trace-id, уже там.

Непрерывное профилирование: затраты и компромиссы

Постоянное профилирование с накладными расходами 2-5% — современный стандарт. Цена ненулевая и растёт со флотом.

Накладные расходы CPU: флот из 200 сервисов на 100 Гц, 2% накладных расходов = эквивалент постоянной работы ~4 дополнительных сервиса по CPU.

Накладные расходы хранилища: 30-секундные профили по ~200 КБ сжатыми × 240 в час × 24 часа × 200 сервисов ≈ 230 ГБ/день исходных данных. Дедупликация символов в Pyroscope 2.0 снижает это в 3 раза. Ступенчатое хранение (7 дней детально, 30 дней даунсемплированно, 90 дней сводно) снижает ещё в 5 раз суммарно. Итоговая цена на object storage: ~$25-100/месяц для 200 сервисов.

Паттерн внедрения: платить цену только тогда, когда у команды есть дисциплина использовать данные. Небольшая команда на старте может получить больше от профилирования по запросу (perf record, pprof-эндпоинт) и перейти на непрерывное профилирование позже. Критерий перехода: обращение к профилю уже стало рефлексом. Если команде нужно помнить о том, чтобы смотреть, непрерывное профилирование становится украшением.

Корреляция профиля с трейсом

Интегрированный рабочий процесс триажа:

SLO burn alert → клик → трейсы, отфильтрованные по burn-окну → выбрать медленный трейс → клик на спан → профиль, отфильтрованный по trace-id этого спана → флейм-граф конкретного запроса.

Drill от пейджера до git blame — менее 30 секунд.

Мост: штамповка trace-id внутри сэмплов профиля. Каждый сэмпл стека несёт активный trace-id в момент сэмплирования. При запросе бэкенд объединяет сэмплы профиля с трейсом. Сигнал profile в OpenTelemetry (бета по состоянию на 2026) стандартизирует эту штамповку.

Production-реализации:

• Grafana Tempo + Pyroscope
• Datadog APM + Continuous Profiler
• Honeycomb + OTel profile signal

Без штамповки trace-id дежурному нужно угадывать, какой сэмпл профиля соответствует медленному запросу. С ней ответ — одна фильтрация.

Profile-driven CI-гейты

Непрерывное профилирование позволяет обнаруживать регрессии до мерджа.

Паттерн: каждый PR запускает canary-деплой. 5-минутный нагрузочный тест под репрезентативным трафиком захватывает CPU-профиль и allocation-профиль. CI-задача сравнивает с baseline’ом ветки main. Если доля CPU любой функции растёт больше настроенного порога (обычно 10% абсолютных или 30% относительных), PR помечается для ревью.

Реализации: compare API Pyroscope, deploy comparison Datadog, кастомные пайплайны с pprof diff Go или JFR diff async-profiler.

Выигрыш: регрессии, которые попали бы в продакшен на p99, перехватываются в CI. Среднее время обнаружения perf-регрессий падает с дней (мониторинг продакшена в конце концов замечает) до минут (CI не проходит PR).

Операционные вызовы: (1) Шумный baseline — сам main постоянно меняется; обновляй baseline еженедельно, а не ежедневно. (2) Пороги дисперсии — начинай с широких (≥30% абсолютных) и сужай месяцами. (3) Несоответствие синтетической нагрузки — расширяй load profile на основе пропущенных регрессий, пойманных в продакшене. (4) Сопротивление инженеров — предоставь escape hatch /perf-override, требующий согласования с менеджером и логируемый для аудита.

Production-отказы: «профиль первым» оправдал себя

Stripe (2021): сервис на 80% CPU. Команда предполагала ретраи. Профиль показал 60% CPU в JSON-парсере, вызываемом на каждом health-check 100 раз/секунду. Фикс: кэшировать распарсенный конфиг. CPU упал до 30% за 8 минут.

GitHub (2020): Ruby-воркеры падали с OOM. Allocation-профиль указал на template-rendering, аллоцирующий 200 МБ на запрос.

Discord (2020): tail latency чата. Переключение JSON-сериализации снизило p99 хвост.

Контрпример (стартап 2019): два месяца переписывания Postgres-запроса для «медленной» admin-страницы. Профиль в итоге показал 90% в виджете третьей стороны. Изменение SQL ничего не сдвинуло.

Паттерн: с профилем узкое место называется за минуты. Без него команды сжигают недели на не том коде.

Антипаттерны

Пять распространённых антипаттернов в performance-работе:

1. Оптимизация холодного пути — функция, вызываемая один раз при старте, получает переписывание в 100x, пока per-request горячий путь игнорируется. Защита: «вызовов в секунду × цена на вызов», а не только цена на вызов.
2. Microbench-driven оптимизация — функция X в 10x быстрее в изоляции; продакшен в 1.03x. Защита: сначала доля production-профиля, потом любое переписывание по микробенчу.
3. «Профилировать продакшен слишком дорого» — отговорка, чтобы пропустить единственное честное измерение. Защита: накладные расходы непрерывного профилирования — 2-5%, намного ниже выигрыша от нахождения любого реального узкого места.
4. Single-run reporting — «этот PR на 12% быстрее» с одним измерением. Защита: настаивать на распределениях.
5. Регрессия по feature-флагу — улучшение производительности за флагом, который никогда не включается. Защита: CI profile-gate должен тестировать запуски с включённым флагом; иначе улучшение — постоянный мёртвый код.

# Production-метрики (5-минутное окно)
checkout_p99_ms          580
checkout_p99_ms_prev     820  # до деплоя
cpu_pct                  62
cpu_pct_prev             58

# go tool pprof -diff_base baseline.cpu prod.cpu
File: checkout
Type: cpu
Showing nodes accounting for -3.20s, 1.15% of -278.5s total

    flat  flat%   sum%        cum   cum%
  -1.80s  0.64%  0.64%    -1.80s  0.64%  net/http.(*conn).serve
  -1.40s  0.50%  1.15%    -1.40s  0.50%  encoding/json.Marshal
  +0.05s 0.018%  1.13%    +0.05s 0.018%  myapp/handlers.Checkout
  ... (другие сдвиги < 0.5s)