Производительность
Горячие пути: диагностируй и почини две формы
Читать про пять форм — не то же самое, что вытащить сервис сразу из двух. Построй сервис с намеренно разными по форме hotspot’ами, затем прогони полный цикл на каждом: классифицируй по правильному профилю, найди место фикса через цепочку parent/child, примени одно изменение и докажи его числами — не угадывая инструмент.
Преврати дерево решений юнита в воспроизводимый инженерный цикл: заинструментируй, сними правильный профиль на каждый hotspot, классифицируй его в форму, найди слой фикса, примени подходящее семейство фиксов и подтверди и локальный фрейм, и headline-метрику — дважды, на двух разных формах.
Возьми HTTP-сервис (свой или стартовый, описанный ниже), засеянный минимум двумя hotspot'ами РАЗНОЙ формы — одним allocation-bound и одним memory-bound или false-sharing — и приведи каждый под контроль, сперва диагностируя форму, затем применяя только подходящее семейство фиксов, доказывая каждый шаг измерениями под идентичной нагрузкой.
- Таблица до/после на эндпоинт: p99, p99.9, CPU%, allocation rate и (для memory-bound пути) IPC и cache-miss rate — измеренные под идентичной нагрузкой, не оценённые.
- Каждый фикс обоснован своей классификацией: однострочное утверждение формы, решающего сигнала и почему выбранное семейство фиксов подошло (и почему очевидный неверный фикс — например 'сменить библиотеки' или 'переписать алгоритм' — недодал бы).
- Пересня́тые улики показывают, что форма разрешена: у аллокационного пути GC-фреймы и alloc rate упали ≥50%; у memory-bound пути IPC поднялся выше 2, а cache-miss rate упал ниже ~5% (или у false-sharing пути IPC восстановился и перестал ухудшаться с ядрами).
- Проверка fix-and-verify проходит для обоих: локальный фрейм сузился И headline-задержка (p99) улучшилась; если headline не сдвинулся, письменная заметка указывает следующий по ширине hotspot, который фикс вскрыл.
- Добавь одностраничный on-call triage-runbook: page → профиль за 60 с → широчайший лист → дерево решений категорий (GC-фреймы? низкий IPC + miss? off-CPU? kernel-фреймы? фреймы интерпретатора?) → чтение parent/child → lookup семейства фиксов → чеклист diff-verify, переносимый по навыку для полиглот-флота.
- Добавь security-гейт в runbook: прежде чем оптимизировать любой путь, проверь, не трогает ли он auth, крипто-сравнение или валидацию входа; продемонстрируй это, попытавшись (и отклонив) early-exit 'оптимизацию' constant-time сравнения токена.
- Добавь мониторинг хвостовой задержки: пер-эндпоинт гистограммы задержки, нарезанные до p99.9, и покажи, что намеренно внедрённый периодический стопор (периодический GC или всплеск лока) невидим на дашборде CPU%, но очевиден на панели p99.9.
- Добавь PR-time CI-гейт: нагрузи canary, сделай diff его профиля против main и завали сборку, если доля self-time любой функции выросла более чем на 30% относительно.
Это цикл, который ты запускаешь в каждом реальном инциденте, намеренно сделанный дважды: сперва заинструментируй, сними правильный профиль на каждый hotspot, классифицируй форму по решающему сигналу (не по ширине фрейма), найди место фикса через цепочку parent/child, примени только подходящее семейство фиксов и подтверди и локальный фрейм, и headline-метрику под идентичной нагрузкой. Сделать это сразу на двух разных формах — вот что превращает модель пяти форм из таблицы, которую ты заучил, в дерево решений, к которому ты тянешься под давлением.