Производительность
Сначала профиль: прогони цикл на обманчивом сервисе
Читать про profile-first — не то же самое, что поймать интуицию на лжи. Построй сервис, чей очевидный на вид боттлнек — приманка, затем прогони полный измерительный цикл, пока профиль — не твоё чутьё — не назовёт реальную стоимость, и докажи каждый шаг числами.
Преврати ментальную модель юнита в воспроизводимый инженерный цикл: квантифицируй жалобу, воспроизведи под реалистичной нагрузкой, прочитай flame graph, предскажи выигрыш через Amdahl, почини реальную горячую точку и подтверди статистически валидными метриками до/после — подтвердив, что интуиция ошибалась, прежде чем довериться измерению.
Возьми HTTP-сервис с намеренно обманчивым медленным эндпоинтом (свой или стартовый ниже) и прогони полный цикл profile-first — квантифицируй, воспроизведи, профилируй, предскажи, почини, верифицируй — доведя p99 до целевого, доказав профилем, что очевидный подозреваемый НЕ был боттлнеком.
- Таблица до/после: p50, p95, p99 задержки эндпоинта по ≥5 прогонам каждый, с 95% CI — измеренные под идентичной нагрузкой, а не оценённые, и показывающие, что p99 достиг заявленной цели.
- Короткий разбор: до-профильная интуиция, профиль, ей противоречащий, реальная горячая точка с её CPU (или off-CPU) долей и предсказанный по Amdahl vs фактический общий speedup.
- Дифф профиля чётко показывает сжатие фрейма реальной горячей точки после фикса (перепрофилировано, а не предположено), а подозреваемый-приманка подтверждён как малая доля на всём протяжении.
- Доказательство проверки observer effect: headline-метрика с выключенным vs включённым профайлером, в пределах ~5%.
- Добавь одностраничный triage-runbook: как квантифицировать жалобу «тормозит», выбрать scope измерения (micro/macro/prod), читать формы flame graph и верифицировать выигрыш статистически — цикл, которому должен следовать новый on-call.
- Подключи CI-гейт на дифф профиля: деплой PR-ветки на canary, 5-минутный нагрузочный тест, снятие CPU + off-CPU профилей, дифф против еженедельно обновляемого baseline main и провал сборки, если доля CPU любой функции выросла ≥10% абсолютных или ≥30% относительных.
- Добавь анализ hardware counters (perf stat -e cycles,instructions,cache-misses) на реальной горячей точке; сообщи её IPC и реши по числу, должен ли следующий фикс целиться в data layout или алгоритм.
- Добавь cold-start профиль (первые 30–60 с после запуска) рядом со steady-state и покажи, что горячие точки различаются — затем назови cold-start-специфичный фикс (eager warmup, прогрев пула соединений или AOT), который steady-state профиль никогда бы не подсказал.
Это цикл, который ты будешь запускать в каждом реальном расследовании производительности: квантифицируй жалобу в цель, воспроизведи под реалистичной нагрузкой, проверь, что профайлер не лжёт (observer effect), читай flame graph по форме прежде имён, дай измерению опровергнуть твою интуицию, предскажи потолок через Amdahl, почини одну реальную горячую точку и подтверди через median/p95/p99 по нескольким прогонам. Построив это раз на сервисе, чей очевидный боттлнек — приманка, ты доводишь «сначала профиль, потом меняй код» до мышечной памяти, а не лозунга.