Наблюдаемость
Profiling: от SLO до flame graph
Читать про workflow от SLO до профиля — не то же, что прогонять его под пейджером. Подними continuous profiling на маленьком сервисе, заложи реалистичный медленный путь и докажи, что можешь дойти от горящего SLO до точной горячей функции за менее чем 30 секунд — а затем поймать регрессию деплоя до того, как она дойдёт до пользователей.
Преврати ментальную модель юнита в воспроизводимую инженерную петлю: настрой continuous + trace-коррелированный профайлинг, выбирай верный тип профиля под каждый симптом, дрилься от алерта до flame graph и гейти деплои через differential profile — с доказательством на каждом шаге.
Подними continuous profiling с trace-id корреляцией на маленьком сервисе (своём или стартовом), заложи CPU-hotspot и off-CPU ожидание и докажи дрилл от SLO до flame graph за менее чем 30 секунд плюс поимку регрессии деплоя — всё с измеренными доказательствами, а не утверждениями.
- Измеренная цифра overhead работающего профайлера (цель ~2-5%), с указанным рядом sample rate и режимом символизации, которые ты использовал.
- Два профиля бок о бок для одного I/O-bound запроса: CPU-профиль, показывающий почти ноль on-CPU времени, и off-CPU/block профиль, приписывающий ожидание блокирующему вызову, с указанным отношением CPU/wall.
- Запись (или аннотированные скриншоты) дрилла от SLO до flame graph, показывающая алерт -> flame graph, отфильтрованный по trace-id -> названная горячая функция, с записанным затраченным временем.
- Differential flame graph (или вид compare-versions), ясно показывающий регрессировавший фрейм как новый/выросший после деплоя, плюс абзац-описание, называющий регрессировавшую функцию и как diff локализовал её там, где график латентности не смог.
- Добавь CI-гейт: на каждый деплой снимай 5-минутный canary-профиль, делай diff против предыдущей версии, постируй топ-5 изменившихся функций комментарием в PR и фейли сборку, если новая функция входит в топ-5 по self-CPU или любой топ-5 фрейм растёт больше чем на 15%.
- Добавь второй рантайм (например, JVM или Python-сервис) под тот же eBPF-агент и задокументируй разницу символизации — чистые Go-фреймы против [unknown]/частичных JVM/Python фреймов — затем почини один, добавив language-aware профайлер.
- Продемонстрируй слепую зону sampling: добавь функцию, вызываемую очень часто на длительность короче интервала, покажи, что она недопредставлена на 100 Hz, и восстанови её, подняв sample rate или используя точечное инструментирование.
- Напиши одностраничный on-call runbook: от пейджера — какой профиль открывать под симптом (CPU против off-CPU против heap), как фильтровать по trace-id, как читать ширину против алфавитной оси x и проверка деплоя через differential profile.
Это петля, которую ты будешь прогонять в каждом реальном инциденте профайлинга: держи continuous, trace-коррелированный профайлинг всегда включённым на 2-5%, выбирай тип профиля, которого требует симптом (CPU для вычислений, off-CPU для ожидания, heap для памяти), дрилься от SLO до flame graph, отфильтрованного по trace-id, за секунды, лови регрессии через differential profile на момент деплоя и относись к каждому профилю как к чувствительному артефакту. Сделав это однажды на маленьком сервисе, ты доводишь production-версию до мышечной памяти.