Методологии Брендана Грегга: задержки и профилирование без догадок

Зачем нужны методологии, а не «чуть подкрутим»

Когда система начинает «тормозить», первое желание — подправить конфиг, добавить кэша или «дать побольше ресурсов». Иногда это помогает, но чаще превращается в серию случайных действий: сегодня стало лучше, завтра — хуже, а причина так и не найдена.

Подходы Брендана Грегга ценны тем, что дают командам не набор трюков, а воспроизводимый способ думать о производительности. Грегг много лет исследует поведение Linux и продакшен‑систем и сформулировал простые методологии (например, USE и RED), которые помогают быстро сузить круг поиска и не утонуть в метриках.

Практический бонус: когда у команды появляется единый язык и алгоритм расследований, становится проще автоматизировать рутину — от типовых дашбордов до небольших внутренних инструментов. Например, такие вещи удобно быстро собирать в TakProsto.AI: через чат‑интерфейс можно накидать веб‑панель для просмотра RED/USE сигналов, сервис для хранения «симптом → причина → фикс», или утилиту для запуска контролируемых нагрузочных проверок без долгого программирования и согласований.

Почему «угадывание» перестаёт работать

В сложных системах (микросервисы, очереди, базы, сеть, виртуализация) симптом и причина редко совпадают. Медленный ответ API может быть следствием ожидания блокировок в БД, проблем с диском, нехватки сокетов, таймаутов на соседнем сервисе или неожиданных пауз из‑за сборщика мусора. Интуиция обычно опирается на прошлый опыт и «самые частые» причины, но продакшен любит редкие и комбинированные.

Что вы получите от методологий

Методологии превращают расследование в алгоритм:

• вы начинаете с наблюдаемых симптомов (задержки, ошибки, насыщение ресурсов);
• последовательно проверяете гипотезы по списку, а не по настроению;
• фиксируете шаги так, чтобы другой инженер мог повторить проверку и получить тот же результат.

Это особенно важно в командной работе: меньше споров «мне кажется», больше проверяемых фактов.

Ключевые термины на одном языке

• Задержка (latency) — время выполнения операции (важны не только средние, но и «хвосты»).
• Пропускная способность (throughput) — сколько операций система делает за единицу времени.
• Утилизация (utilization) — насколько занят ресурс (CPU, диск, сеть).
• Ошибки (errors) — любые сбои: 5xx, таймауты, ретраи, отказ очереди.

Дальше в статье эти слова будут опорными: USE помогает быстро проверить ресурсы, RED — сфокусироваться на качестве сервиса для пользователя.

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

Задержка — это не «сколько обычно», а «что чувствует пользователь в худшие моменты». Среднее значение легко сделать красивым: достаточно, чтобы большинство запросов проходили быстро. Но именно редкие медленные запросы ломают опыт: страница «подвисла», оплата не прошла, поиск думает вечность.

SLA/SLO/SLI: что именно вы обещаете

Начинайте с определения метрики.

SLI — конкретное измерение, например: «время ответа /api/search». SLO — цель по этому SLI: «p95 < 300 мс». SLA — внешнее обязательство с последствиями.

Важно, чтобы SLI отражал реальный путь пользователя: не только серверное время, но и то, что влияет на итог (очереди, зависимости, холодные кэши).

Почему p50 не спасает: хвосты распределения

p50 (медиана) отвечает на вопрос «как у половины запросов». p95/p99 — «как у самых медленных 5%/1%». Именно эти «хвосты» чаще всего создают жалобы и всплески ошибок.

Пример: p50 = 40 мс, p99 = 2 с. Формально «в среднем быстро», а фактически каждый сотый запрос — заметная боль.

Упрощённая модель: работа + ожидания + очереди

Полезно думать о задержке как о сумме:

• Работа: CPU, выполнение запросов, сериализация.
• Ожидания: диск, сеть, блокировки, внешние сервисы.
• Очереди: переполненные пул потоков, лимиты соединений, очереди в брокерах.

Эта модель помогает перестать спорить «CPU или база?» и начать измерять вклад каждого компонента.

Когда важнее хвосты, а когда throughput

Если сервис интерактивный (UI, поиск, платежи), стабильность p95/p99 часто важнее максимального throughput: лучше чуть меньше запросов в секунду, но без секундных провалов.

Если задача пакетная (ETL, фоновые джобы), throughput может быть приоритетом, а хвосты допустимы — пока они не создают очереди, влияющие на другие компоненты.

Метод USE: быстрый скрининг ресурсов без лишнего шума

Метод USE (Utilization, Saturation, Errors) — это способ быстро «пробежать глазами» по базовым ресурсам системы и понять, где именно искать проблему производительности. Он хорош тем, что не требует догадок и не заставляет сразу прыгать в глубокое профилирование: сначала — короткая инвентаризация, потом — точечная работа.

Три вопроса к каждому ресурсу

Utilization (Утилизация) — насколько ресурс занят полезной работой.

Saturation (Насыщение) — есть ли очередь/ожидание из‑за нехватки ресурса (даже если средняя утилизация невысокая).

Errors (Ошибки) — происходят ли сбои, ретраи, дропы, коррекция ошибок, которые «съедают» время и пропускную способность.

Какие ресурсы проверять

Базовый набор почти всегда одинаковый: CPU, память, диск/хранилище, сеть и очереди (планировщик, очереди I/O, очереди в приложении/брокере, пул соединений и т.п.). В USE важно помнить: очереди — это отдельный объект наблюдения, а не «где‑то внутри».

Мини‑чеклист без привязки к вендорам

Для каждого ресурса задайте короткие вопросы:

• CPU: утилизация близка к потолку? есть ли очередь на выполнение? много ли переключений контекста/времени в системных вызовах? есть ли ошибки уровня ОС/процесса?
• Память: хватает ли RAM? есть ли давление на кэш/частые промахи? начинается ли своп или агрессивная очистка? возникают ли OOM/рестарты?
• Диск: растёт ли время операций? есть ли очередь запросов? наблюдаются ли ошибки чтения/записи, ретраи, деградация носителя?
• Сеть: упираемся ли в пропускную способность? есть ли очереди/буферблот? растут ли потери/ретрансляции, ошибки интерфейса, таймауты?
• Очереди (пулы/лимиты): растёт ли длина очереди? увеличивается ли время ожидания? есть ли отказы по лимитам (connection pool exhausted, rate limit)?

Как USE сужает поиск до 1–2 подсистем

Вместо «смотрим всё сразу» вы получаете карту: где есть насыщение или ошибки — туда и идём дальше. Часто достаточно найти одну доминирующую очередь (например, очередь диска или пул соединений), чтобы сузить расследование до 1–2 подсистем и уже там применять более детальные методы и инструменты.

Метод RED: фокус на сервисе и пользовательском опыте

Метод RED — это практичный способ смотреть на сервис так, как его «видит» пользователь. Вместо того чтобы тонуть в десятках системных метрик, мы фиксируем три сигнала, которые почти всегда объясняют, почему клиент доволен или раздражён: Rate, Errors, Duration.

Суть RED: Rate, Errors, Duration

• Rate (скорость/интенсивность): сколько запросов/сообщений/операций обрабатывает сервис за единицу времени.
• Errors (ошибки): доля или количество неуспешных операций (5xx, таймауты, отмены, бизнес‑ошибки — по договорённости).
• Duration (длительность): время выполнения операции. Важно измерять не только среднее, а перцентили (p95/p99), потому что «хвосты» чаще всего и формируют пользовательскую задержку.

Где RED особенно полезен

RED идеально ложится на сервисы и API, где есть чёткая операция «запрос → ответ». Но он не менее полезен для фоновых воркеров и конвейеров задач, если корректно определить «операцию» (например, обработка одного джоба).

Примеры метрик RED

Для HTTP/gRPC:

• Rate: RPS по роутам/методам, отдельно по статусам.
• Errors: доля 5xx, таймаутов, отмен (client cancel), ошибки бизнес‑валидации — отдельной серией.
• Duration: latency histogram по роутам/методам; ключевые перцентили p50/p95/p99.

Для очередей задач:

• Rate: jobs/sec (публикация и обработка), throughput по типам задач.
• Errors: retries, dead-letter, процент фейлов обработки.
• Duration: время выполнения job + отдельно «age/lag» (сколько задача ждала до старта), чтобы видеть реальную задержку для пользователя.

Как RED связывается с пользовательской задержкой и SLO

RED помогает быстро ответить на главный вопрос: мы медленные из‑за нагрузки, ошибок или длительности? Это напрямую переводится в SLO: например, «p95 Duration < 300 мс при Errors < 0,5%». Если Rate растёт и одновременно ухудшается Duration — вероятна перегрузка или блокировки. Если Errors растут без изменения Rate — ищите деградацию зависимости, конфигурации или релиза. Такой треугольник сигналов упрощает алерты и делает разборы инцидентов предметными.

Стратегия расследования: от симптома к причине

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

Два режима: снизу вверх (USE) и сверху вниз (RED)

USE — это быстрый скрининг ресурсов: CPU, память, диски, сеть. Он отвечает на вопрос: «Есть ли явная перегрузка или конкуренция за ресурс, которая объясняет симптом?» Это удобно, когда система «задыхается» целиком или вы не уверены, где искать.

RED — это взгляд со стороны сервиса: Rate (поток запросов), Errors (ошибки), Duration (длительность). Он отвечает на вопрос: «Что именно видит пользователь и на каком участке сервиса становится хуже?» RED особенно полезен при локальных деградациях, когда ресурсов вроде бы хватает.

На практике удобно стартовать с RED (симптом в терминах сервиса), а затем переходить к USE, чтобы подтвердить ресурсную причину. Или наоборот — если тревога пришла по CPU/IO.

Признаки, что вы ушли не туда

• Метрики «шумят» и растут, но не приближают к проверке гипотезы.
• Вы собираете всё больше данных «на всякий случай», но не можете сформулировать следующий шаг.
• Наблюдения объясняются несколькими причинами сразу, а вы не сужаете круг.

Как формулировать гипотезу, чтобы её можно было опровергнуть

Хорошая гипотеза звучит так: «Рост p99 Duration вызван ожиданием диска на узле X; если это так, то при пике увеличатся iowait и очередь диска, а на другом узле без очереди p99 будет нормальным». Здесь есть измеримые признаки и условия, при которых гипотеза рухнет.

Тактика «одна переменная за раз»

Меняйте один фактор и фиксируйте эффект: один флаг, один лимит, один узел, один тип нагрузки. Иначе вы получите улучшение (или ухудшение), но не узнаете, что именно его вызвало — и не сможете повторить результат в следующий инцидент.

Профилирование без мифов: какой профайлер нужен именно вам

Профайлер — не «волшебная кнопка ускорить», а способ честно ответить на вопрос, куда уходит время (и ресурсы). Важно не путать его с трассировкой и логированием: это разные инструменты для разных задач.

Профилирование, трассировка и логирование: что для чего

Профилирование показывает статистическую картину: какие функции/стеки чаще всего «держат» CPU, где чаще происходят аллокации, какие блокировки тормозят. Оно отлично отвечает на «почему медленно?» через распределение затрат.

Трассировка (tracing) показывает путь конкретного запроса: где именно он задержался по таймлайну. Она особенно полезна для «где теряем время в конкретной операции?» и для понимания взаимодействия сервисов.

Логи фиксируют события и контекст. Они полезны для диагностики ошибок и редких сценариев, но для задержек часто дают слишком шумную и неполную картину.

Какие бывают профили (и что они ловят)

• On-CPU: что выполнялось на процессоре. Лучший выбор, когда подозреваете вычислительную нагрузку.
• Off-CPU: где поток не выполняется, а ждёт (I/O, планировщик, очереди). Часто именно здесь прячутся «необъяснимые» задержки.
• Heap/alloc: кто и сколько выделяет памяти, что приводит к GC/фрагментации.
• Lock/contention: кто держит блокировки и кто простаивает в ожидании.

Сэмплинг vs инструментирование

Сэмплинг снимает «срезы» стека с заданной частотой: обычно достаточно точен, дешевле по накладным расходам и безопаснее для продакшена.

Инструментирование добавляет измерения в конкретные точки (функции/события): точнее для выбранных участков, но дороже, рискованнее и требует дисциплины (чтобы не превратить сервис в генератор телеметрии).

Как выбрать инструмент по цели

Если вопрос звучит как «почему медленно?» — начните с on-CPU и/или heap‑профиля (сэмплинг). Если вопрос «где теряем время ожидания?» — нужен off‑CPU или lock/contention‑профиль. А когда важно разложить задержку по этапам конкретного запроса — подключайте трассировку и сверяйте её выводы с профилем, чтобы не гадать.

Flame graph: чтение, интерпретация и частые ошибки

Flame graph (пламенный граф) — это способ быстро увидеть, где именно процесс тратит CPU‑время. Он помогает перестать спорить «кажется, тормозит база» и перейти к конкретным функциям и путям исполнения.

Что показывает flame graph — и чего не показывает

Он показывает распределение CPU‑сэмплов по стекам вызовов: какие цепочки функций чаще всего оказываются «на горячем пути».

Но он не отвечает на вопрос «почему запрос медленный», если задержка уходит в ожидание: блокировки, I/O, сеть, планировщик, очереди. В таких случаях CPU‑flame graph может выглядеть «спокойным», хотя пользователи страдают — это просто другой класс проблем.

Как читать: ширина, стек и «плоские вершины»

• Ширина блока = доля времени (точнее, доля сэмплов). Широкое — значит частое/долгое.
• Высота — это не «дороже», а глубже стек: кто кого вызвал.
• «Плоская вершина» (широкая полка на одном уровне) часто означает, что много времени уходит в одну функцию без заметного продолжения вверх по стеку. Это может быть как реальная «горячая» функция, так и артефакт (например, потерянные символы).

Типовые ловушки: инлайнинг, символы, агрегации, короткие всплески

Инлайнинг может «спрятать» логические функции, и граф покажет родителя вместо ожидаемого виновника.

Если нет символов (или неправильные), вы увидите безликие адреса — выводы будут шаткими.

Важны и агрегации: иногда разные пути сливаются в один блок и создают иллюзию «одного узкого места».

И наконец, короткие всплески: если проблема длится секунды, а вы собирали профиль минуту, пик растворится в среднем — нужен правильный интервал и точка измерения.

Мини‑процесс: собрать → сравнить «до/после» → подтвердить гипотезу

Соберите flame graph в момент симптома.

Сравните «до/после» изменения (или «плохой/хороший» период) — ищите изменившиеся широкие участки.

Сформулируйте гипотезу («эта функция съедает CPU из‑за X») и подтвердите её отдельным измерением: метрикой, логом, тестом нагрузки или повторным профилированием. Это дисциплина, которая экономит дни споров и случайных оптимизаций.

Off-CPU и ожидания: где прячется реальная задержка

Иногда графики выглядят «спокойно»: CPU занят на 20–30%, памяти хватает, ошибок нет — а пользователи жалуются на тормоза. Это классическая ситуация «нагрузка есть — а CPU не занят»: процесс не считает, а ждёт. И именно ожидания часто формируют хвосты задержки.

Почему так бывает

Off‑CPU время — это всё, что происходит, когда поток не выполняется на процессоре. Причины обычно приземлённые:

• I/O: ожидание диска (fsync, чтение, страничные промахи) или сети (TCP retransmit, медленный upstream).
• Блокировки и очереди: мьютексы/спинлоки, блокировки БД, пулы соединений, очереди задач.
• Планировщик: поток готов работать, но его не ставят на CPU из‑за конкуренции — растёт run queue.

Что искать в системе

Сфокусируйтесь на трёх местах, где «прячется» время:

1. Диск/файловая система: latency и очереди I/O, время в iowait, частые sync/fsync.

2. Сеть: RTT, потери, retransmits, очередь сокета, задержки на стороне зависимостей.

3. Scheduler: рост runnable threads, длительные задержки планирования (scheduling latency), пики load average при низком CPU.

Метрики: рядом «работа» и «ожидание»

Полезно видеть две составляющие в одной картине:

• CPU time vs wall time для запросов/операций (wall значительно больше — значит, ждём).
• Run queue length, context switches, iowait, latency диска/сети.
• В приложении — очереди (длина, время ожидания), pool saturation, lock contention.

Как привязать ожидание к коду

Ожидание нужно «приземлить» до конкретного места:

• Используйте off‑CPU profiling (профили, которые показывают, где поток спит/ждёт) и сопоставляйте стеки с типом ожидания (I/O, лок, таймер).
• Коррелируйте: «какой эндпоинт/запрос» → «какой ресурс ждёт» → «какая функция/операция в стеке».

Тогда вместо абстрактного «медленно» появляется конкретная цель: например, блокировка вокруг кэша, исчерпанный пул соединений или медленный DNS/диск.

eBPF в продакшене: как смотреть глубже и не навредить

eBPF полезен, когда обычные метрики и логи показывают «что-то не так», но не отвечают на вопрос «где именно теряется время». Его ценность — в доступе к системным событиям (планировщик, системные вызовы, сеть, блокировки) с очень низким overhead при правильной настройке. То есть вы можете наблюдать «на уровне ядра», не превращая диагностику в отдельную нагрузку.

Какие задачи eBPF закрывает лучше всего

Сетевые задержки. Можно измерять время на этапах TCP/UDP, очереди в стеке, ретрансляции, задержки при accept/connect и увидеть, где именно образуется хвост.

Системные вызовы и I/O. eBPF помогает понять, какие syscalls «виснут», сколько времени уходит на чтение/запись, fsync, работу с диском или сетевым хранилищем.

Contention и ожидания. Когда CPU «не занят», но запросы медленные, часто причина — ожидание: блокировки, очереди, конкуренция за ресурсы. eBPF умеет подсветить эти точки, включая off‑CPU время.

Как безопасно начать в продакшене

Начинайте как с хирургического инструмента, а не как с постоянного мониторинга:

• Ограниченные окна: 30–120 секунд во время инцидента или в заранее согласованные слоты.
• Фильтры: по PID/контейнеру/порту/эндпоинту, чтобы не собирать «всё подряд».
• Выборка (sampling): вместо трассировки каждого события.
• Контроль нагрузки: заранее измерьте overhead на стенде, держите лимиты на частоту событий и объём буферов.

Важно также учесть права доступа (capabilities), версии ядра и стандартизировать запуск через понятные процедуры, чтобы диагностика была повторяемой.

Когда eBPF излишен

Если проблема очевидна на уровне приложения (например, медленный запрос к базе виден в APM), или узкое место хорошо ловится метриками (CPU%, iowait, ошибки, saturation) и профилями приложения — eBPF может быть лишним. Используйте его, когда требуется доказательная детализация «почему хвост растёт» и где именно система ждёт.

Диагностика в продакшене: безопасность, стоимость, повторяемость

Продакшен — лучшее место, чтобы увидеть реальную задержку и реальные «хвосты», но и самое рискованное. Хорошая диагностика здесь должна быть управляемой: заранее ограниченной по времени и объёму, безопасной для пользователей и повторяемой, чтобы результату можно было доверять.

Чеклист перед включением

Перед тем как запускать профилирование или точечный сбор, договоритесь о базовых правилах:

• Окно и лимиты: когда включаем (например, 10–15 минут), на каких хостах/поды, какой overhead допустим.
• План отката: как быстро выключить (feature flag, kill‑switch, удаление BPF‑программы, остановка агента), кто имеет доступ.
• Владелец: один ответственный человек на время эксперимента, чтобы не было «включили и забыли».

Так вы контролируете стоимость (CPU, I/O, объём логов) и снижаете шанс случайно ухудшить SLO.

Сбор только нужного

Самая частая ошибка — собирать «всё на всякий случай». Двигайтесь от гипотезы:

• Если подозреваете CPU — достаточно короткого профиля on‑CPU и базовых метрик загрузки.
• Если пахнет ожиданиями — добавьте off‑CPU/ожидания блокировок или сетевых/дисковых задержек, но не смешивайте всё в один забег.

Минимальный набор данных должен отвечать на вопрос: подтверждаем или опровергаем гипотезу? Если нет — сбор лишний.

Как документировать находку

Чтобы результат можно было повторить и проверить, фиксируйте в одном шаблоне:

симптом → данные → причина → фикс → эффект.

Важно хранить не только графики, но и условия эксперимента: время, выборка, версии, лимиты, команды/параметры. Тогда следующий инженер сможет воспроизвести и убедиться, что улучшение не случайность.

Этичная работа с данными

Диагностика не должна превращаться в утечку: не тяните персональные данные в логи/трейсы/профили. Если без payload не обойтись — маскируйте, агрегируйте, сокращайте срок хранения и ограничивайте доступ. Это дешевле, безопаснее и дисциплинирует процесс.

Три типовых кейса: как применять методы на практике

Ниже — три ситуации, в которых подход Грегга хорошо «приземляется» на реальные инциденты. Идея одна: сначала быстро описываем проблему языком RED (со стороны сервиса), затем проверяем «железо и ОС» языком USE (со стороны ресурсов), и только потом углубляемся профилированием.

Сценарий 1: рост p99 при нормальном среднем — как раскладывать по этапам

Симптом: среднее время ответа почти не меняется, но p99 (или p95) растёт — пользователи жалуются «иногда очень долго».

Что собрать по RED:

• Rate: не изменился ли профиль нагрузки (пики, другая смесь ручек/эндпоинтов).
• Errors: таймауты, ретраи, 499/504, рост отмен запросов.
• Duration: разнести задержку по этапам (очередь/балансировщик → приложение → внешние зависимости → БД).

Что проверить по USE:

• CPU: насыщение по ядрам, рост run queue, троттлинг.
• Memory: давление (page cache, swap), всплески major page faults.
• Disk/Network: очереди, ретраи, TCP retransmits.

Чем подтвердить: сверить хвосты по трассировкам/спанам и наложить на моменты насыщения ресурсов. Если p99 растёт только на одной ноде — это почти всегда указатель на локальную проблему (соседние noisy workloads, деградация диска, сетевые потери).

Сценарий 2: «всё медленно» после релиза — как быстро локализовать изменение

Симптом: после выкладки деградировали почти все запросы, графики выглядят «приподнятыми» целиком.

Что собрать по RED:

• Сравнение до/после: какие ручки ухудшились сильнее, изменились ли ошибки и ретраи.
• Разделение по версиям: метка релиза в метриках (canary vs stable), чтобы увидеть корреляцию.

Что проверить по USE:

• CPU: рост user/system, изменение частоты контекстных переключений.
• Memory: рост аллокаций, давление на кэш, увеличение RSS.
• I/O: больше обращений к диску/сети из‑за нового поведения.

Чем подтвердить: дифф профилей (до/после) и дифф ключевых счётчиков (например, QPS к БД, количество сериализаций, количество обращений к внешнему API). Если деградация линейна относительно нагрузки — чаще ищите «дорогую» операцию на запрос; если скачкообразна — ищите блокировки/очереди.

Сценарий 3: периодические стоп‑паузы — как отличать GC/IO/локи

Симптом: раз в N минут сервис «подвисает», потом возвращается в норму. Средние значения мало что показывают.

Что собрать по RED:

• Duration в разрезе времени: короткие пики, синхронизированные между инстансами или локальные.
• Errors: всплеск таймаутов/отмен и последующий «догоняющий» трафик.

Что проверить по USE:

• CPU: провалы/пики, рост iowait.
• Disk/Network: всплески latency, глубина очереди.
• Memory: признаки GC/компакции (паузы, рост/падение heap), увеличение page faults.

Чем подтвердить: сопоставить пики задержки с событиями рантайма (паузы GC), ожиданием I/O или ожиданием блокировок. Практический маркер: если CPU низкий, но p99 высокий — часто виноваты ожидания (I/O, локи, сеть), а не «нехватка процессора».

Встраиваем подход в процессы: мониторинг, алерты, разборы

Методологии Грегга работают лучше всего, когда становятся «скучной нормой»: любой инженер знает, какие графики открыть, какие вопросы задать и какие данные собрать — без героизма и охоты за случайными метриками.

Как превратить методологии в привычку команды

Закрепите единый «порядок действий» для типовых ситуаций: рост задержки, деградация конкретного сервиса, периодические пики. Важно, чтобы USE/RED и профилирование были не отдельной экспертизой одного человека, а шагами в командном чек‑листе.

Практики, которые обычно приживаются:

• короткий плейбук (1–2 страницы) «что смотреть сначала»;
• дежурный шаблон для описания симптома: что именно медленно, у кого, с какого времени, как измеряем;
• правило: прежде чем «оптимизировать», подтвердить узкое место измерениями.

Базовые дашборды и алерты без перегруза

Минимальный набор лучше, чем «стена графиков». Для старта держите два слоя:

1. Пользовательский слой (RED): RPS/трафик, доля ошибок, перцентили задержки (p95/p99) по ключевым эндпоинтам или операциям.

2. Ресурсный слой (USE): CPU, память, диск, сеть — но с акцентом на насыщение и очереди/ожидания, а не на средние значения.

Алерты делайте «редкими, но точными»: триггер на устойчивый рост p95/p99 + подтверждение ростом ошибок или очередей. Иначе команда быстро перестанет им доверять.

Если не хватает времени на инфраструктуру вокруг наблюдаемости (внутренние панели, небольшие админки, сервисы для заметок по инцидентам), имеет смысл разгрузить команду за счёт быстрых инструментов. В TakProsto.AI, например, такие прикладные вещи можно собрать через чат: веб‑интерфейс на React, бэкенд на Go и PostgreSQL, с возможностью развернуть, подключить домен, а при неудачных изменениях — откатиться через снапшоты и rollback. Это не заменяет APM, но помогает закрывать «пустоты» между процессом и практикой.

Ритуал после инцидента: короткий разбор

После любого заметного инцидента проведите 20–30 минут:

• фиксируем симптом (какая метрика и где ухудшилась);
• фиксируем причину (что оказалось узким местом и чем подтверждено);
• обновляем плейбук: какие графики/срезы/команды добавить, какие алерты исправить.

Главная цель — сделать следующий разбор быстрее, а не написать «идеальный отчёт».

«Следующие шаги» по мере роста

По мере усложнения системы добавляйте слои: распределённую трассировку для критичных путей, регулярные профили (в том числе off‑CPU), затем аккуратное использование eBPF в продакшене. Важно внедрять по одному улучшению за раз и проверять, что оно реально сокращает время до нахождения причины, а не просто увеличивает объём данных.