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

Почему подход Брендана Грегга уменьшает гадания

Брендан Грегг — один из самых влиятельных авторов по производительности систем, особенно в мире Linux. Он написал широко используемые книги, создал практичные инструменты и — что важнее — поделился ясными методами расследования реальных проблем в продакшне. Команды принимают его подход потому, что он работает в условиях давления: когда задержки растут и все хотят ответов, нужен способ перейти от «возможно, это X» к «это точно Y» с минимальными драмами.

Что действительно означает «методология производительности»

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

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

• сужает проблему до конкретного ресурса, сервиса или пути кода
• измеряет происходящее в том же временном окне, что и инцидент
• подтверждает узкое место доказательствами до внесения изменений

Распространённая ошибка: чинить до измерений

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

Методы Грегга побуждают отложить «решения», пока вы не ответите на более простые вопросы: что насыщено? что даёт ошибки? что стало медленнее — пропускная способность, очередь или отдельные операции?

Что поможет сделать это руководство

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

Основы задержек: что измерить перед тюнингом

Задержка — это симптом: пользователи ждут дольше завершения работы. Причина обычно где-то ещё — конкуренция за CPU, ожидания диска или сети, конкуренция за локи, сборки мусора, очередь или задержки в удалённых зависимостях. Измерение только задержки показывает наличие боли, но не место её происхождения.

Пропускная способность, задержка и ошибки движутся вместе

Эти три сигнала связаны:

• Пропускная способность (запросы/сек) при росте может увеличить очереди, что повышает задержку.
• Ошибки могут уменьшить наблюдаемую задержку (быстрые отказы) или увеличить её (повторы и таймауты).
• Ограничение пропускной способности (rate limiting, backpressure) может улучшить хвостовую задержку, при этом сократив число успешных запросов.

Перед тюнингом захватите все три сигнала для одного и того же временного окна. Иначе вы можете «починить» задержку, просто сбросив нагрузку или заставив систему быстрее падать.

Не доверяйте средним: персентили и хвостовая задержка

Средняя задержка скрывает пики, которые запоминают пользователи. Сервис со средней 50 мс всё ещё может часто зависать на 2 с.

Отслеживайте персентили:

• p50: типичный опыт пользователя
• p95/p99: хвостовая задержка (здесь концентрируется большая часть боли)

Также следите за формой распределения: стабильный p50 с раcтущим p99 часто указывает на прерывистые зависания (например, contention на локах, I/O-скачки, паузы stop-the-world), а не на общее замедление.

Бюджеты задержки: куда можно потратить время

Бюджет задержки — простая модель учёта: «Если запрос должен уложиться в 300 мс, куда может тратиться это время?» Разбейте на корзины, например:

• время в вашем сервисе (вычисление + ожидание)
• время в downstream-сервисах
• время в базах/кэше
• сетевой транзит и TLS
• время в очередях (потоки, connection pool, балансировщики нагрузки)

Этот бюджет задаёт первую задачу измерения: найдите, какая корзина выросла во время всплеска, затем исследуйте эту область вместо слепого тюнинга.

Начните с чёткого вопроса и области исследования

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

Определите, что значит «медленно» (и для кого)

Запишите две фразы перед тем, как касаться инструментов:

• Что медленно? (загрузка страницы, API-эндпойнт, пакетная задача, вход, оформление покупки, конкретный SQL-запрос)
• Где наблюдается медлительность? (браузер клиента, мобильное приложение, один регион, один pod, один хост, внутренний сервис)

Это предотвратит оптимизацию не того слоя — например, CPU-хоста — когда боль локализована в одном эндпойнте или зависимости.

Выберите временное окно и область (scope)

Возьмите окно, соответствующее жалобе, и если возможно, включите период «хорошего» состояния для сравнения.

Явно ограничьте область исследования:

• Хост vs сервис vs эндпойнт: «Один Kubernetes-узел» отличается от «одного API-маршрута».
• Какой срез трафика: регион, уровень клиентов, только ошибочные запросы или все запросы.
• Какой сигнал вызвал тревогу: p95 задержка, таймауты, глубина очереди или пользовательские тайминги.

Точность на этом этапе ускорит дальнейшие шаги (USE, RED, профилирование), потому что вы будете понимать, какие данные должны измениться, если гипотеза верна.

Рассматривайте недавние изменения как гипотезы, а не ответы

Отметьте деплои, изменения конфигурации, сдвиги трафика и события инфраструктуры — но не приписывайте им причинно-следственную связь. Записывайте их как «Если X, то мы ожидали бы Y», чтобы быстро подтверждать или отвергать.

Ведите лёгкий лог расследования

Небольшой лог предотвращает дублирование работы между коллегами и упрощает передачу дела.

Time | Question | Scope | Data checked | Result | Next step

Даже пять строк могут превратить стрессовый инцидент в повторяемый процесс.

Метод USE: быстрый обзор ресурсных узких мест

Метод USE (Utilization, Saturation, Errors) — быстрый чеклист Грегга для сканирования «большой четвёрки» ресурсов — CPU, память, диск (storage) и сеть — чтобы перестать гадать и начать сужать проблему.

Что это такое: чеклист по каждому ресурсу

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

• Utilization: насколько он сейчас загружен?
• Saturation: накапливается ли работа (очереди, время ожидания), даже если загрузка не максимальна?
• Errors: появляются ли ошибки или повторы, создающие задержки?

При последовательном применении это становится быстрым обзором, где существует «напряжение».

Как применять это на практике

Для CPU utilization — % занятости CPU, saturation проявляется как run-queue или потоки, ожидающие выполнения, а ошибки могут быть связаны с троттлингом (в контейнерах) или проблемными прерываниями.

Для памяти utilization — используемая память, saturation часто выглядит как свап/пайджинг или частые сборки мусора, а ошибки — ошибки выделения или OOM-события.

Для диска utilization — % занятости устройства, saturation — глубина очереди и время ожидания операций чтения/записи, а ошибки — I/O-ошибки или таймауты.

Для сети utilization — пропускная способность, saturation — дропы/очереди/задержки, а ошибки — ретрансляции, сбросы соединений или потеря пакетов.

Наиболее полезные сигналы при инцидентах задержки

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

USE дополняет метрики уровня сервиса (не заменяет их)

Метрики уровня сервиса (латентность запросов, уровень ошибок) показывают влияние. USE показывает, куда смотреть дальше, выявляя ресурс под нагрузкой.

Практическая петля:

1. Подтвердить влияние на пользователя (Duration/Errors)
2. Провести инвентаризацию по USE
3. Углубиться в подозрительный ресурс с помощью профилей, трассировок и статистики ядра

Метод RED: сигналы, ориентированные на сервис и влияние

Метод RED держит вас ориентированными на пользовательский опыт до углубления в графы хостов.

• Rate: сколько запросов в секунду обслуживает ваш сервис/эндпойнт
• Errors: сколько запросов завершается с ошибкой (и что «ошибка» значит для вашего приложения)
• Duration: сколько времени занимают успешные запросы (отслеживать персентиль, а не среднее)

Почему RED помогает приоритизировать

RED не даёт вам гоняться за «интересными» системными метриками, которые не влияют на пользователей. Он заставляет задать более точный цикл: какой эндпойнт медленный, для каких пользователей и с какого момента? Если Duration растёт только на одном маршруте при стабильном CPU, у вас уже есть более точная отправная точка.

Полезная практика: держать RED разбитым по сервисам и топовым эндпойнтам (или ключевым RPC-методам). Это помогает отличить широкое деградирование от локальной регрессии.

Соотнесение симптомов RED с проверками USE

RED показывает где болит. USE помогает проверить какой ресурс в этом виноват.

Примеры:

• Duration вверх + Rate стабилен → проверьте saturation/очереди: run queue CPU, задержка storage, connection pool к БД.
• Errors вверх + Duration вверх → проверьте таймауты и повторы: перегруженные downstream, пула потоков, сетевые потери.
• Rate вверх + Duration вверх → проверьте лимиты ёмкости: загрузка CPU, поведение балансировщика, задержку с autoscaling.

Минимальная «что изменилось?» панель

Сделайте макет сфокусированным:

1. Обзор RED: Rate, Errors и p50/p95/p99 Duration для сервиса.
2. Топ эндпойнтов: те же RED сигналы по эндпойнтам, отсортированные по трафику или худшему p95.
3. Зависимости: панели в стиле RED для важных downstream (БД, кэш, внешние API).
4. Одна строка корреляции: небольшой набор системных метрик (CPU, давление памяти, задержки диска, сетевые ретрансмиссии) чтобы ускорить переход от сервиса к корневой причине.

Если хотите согласованный рабочий процесс на инцидент, свяжите этот раздел с инвентаризацией USE в /blog/use-method-overview, чтобы перейти от «пользователи это чувствуют» к «этот ресурс ограничивает» с меньшим количеством метаний.

Приоритизация: выбирайте следующий лучший вопрос

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

Правило 80/20 для узких мест

Большинство проблем задержки доминируется одной стоимостью (или небольшой парой): один горячий лок, одна медленная зависимость, один перегруженный диск, одна паттерн пауз GC. Приоритизация означает сначала искать эту доминирующую стоимость, потому что уменьшение на 5% в пяти местах редко улучшит видимую пользователю задержку.

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

Сверху вниз vs снизу вверх: где начинать

Используйте сверху вниз, когда отвечаете на «Пострадали ли пользователи?». Начните с эндпойнтов (сигналы в стиле RED): задержка, пропускная способность, ошибки. Так вы избежите оптимизации того, что не на критическом пути.

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

Простое дерево решений, которое предотвращает метания

Когда срабатывает алерт, выберите ветку и оставайтесь на ней, пока не подтвердите или не опровергнете:

• Спайк задержки + спайк ошибок → «Это зависимость или событие ёмкости?» (таймауты, исчерпание connection pool, downstream 5xx)
• Спайк задержки + спайк CPU → «CPU выполняет полезную работу или застрял?» (on-CPU vs off-CPU time)
• Спайк задержки + высокий I/O wait → «Какое устройство или файловая система создаёт задержку?»
• Спайк задержки без пиков по ресурсам → «Где тратится время в ожидании?» (локи, планировщик, сеть, удалённые вызовы)

Избегайте перегруза метриками, оставайтесь системными

Ограничьте себя небольшим начальным набором сигналов, затем углубляйтесь только если что-то двинулось. Если нужен чеклист, чтобы держать фокус, привяжите шаги к ранбуку, например /blog/performance-incident-workflow, чтобы каждая новая метрика имела цель: ответить на конкретный вопрос.

Профилирование в продакшне без остановки системы

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

Что реально отвечает профилирование

Профилирование — инструмент учёта времени. Вместо споров («это БД» vs «это GC») вы получаете данные вида «45% CPU-сэмплов приходятся на JSON-парсинг» или «большинство запросов блокируются на мьютексе». Это сужает следующий шаг до одного-двух конкретных исправлений.

Распространённые типы, которые можно использовать в продакшне

• CPU-профайлинг: показывает, какой код выполняется on-CPU.
• Off-CPU (wait) профайлинг: показывает, где потоки проводят время в блокировках (I/O ожидания, задержки планировщика, sleep, сеть, диск).
• Профилирование локов: показывает contention — время, потерянное в ожидании локов, мьютексов и read/write-запросов.

Каждый отвечает на разный вопрос. Высокая задержка при низком CPU обычно указывает на off-CPU или время ожидания локов, а не на on-CPU-горячие точки.

Всегда включённое vs по требованию

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

Многие команды начинают с по требованию, затем переходят к всегда включённому, когда доверяют безопасности и видят повторяющиеся проблемы.

Безопасность: оверхед, сэмплинг и короткие окна

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

Flame-графы: как их читать и не делать неверных выводов

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

Что показывает flame-граф (и чего не показывает)

Обычно flame-графы представляют on-CPU сэмплы: время, когда программа действительно выполнялась на CPU. Они выделяют CPU-горячие пути, неэффективный парсинг, чрезмерную сериализацию или участки, которые действительно жгут CPU.

Они не показывают напрямую ожидания диска, сети, планировщика или время, заблокированное на мьютексе (это off-CPU время и требует иного профилирования). Также flame-граф сам по себе не доказывает причинно-следственную связь с пользовательской задержкой, если вы не связали его с чётким сценарием.

Как интерпретировать ширину и глубину стека

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

Частые ловушки

Самую широкую плашку легко обвинить, но спросите: можно ли её изменить или это просто «время в malloc, GC или логировании», потому что реальная проблема выше по потоку? Также следите за отсутствием контекста (JIT, inlining, символы), что может сделать плашку видимым виновником, когда она лишь «вестник».

Сопоставляйте flame-графы с точным вопросом

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

Off-CPU время: скрытый источник задержек

Когда задержки растут, многие команды в первую очередь смотрят на %CPU. Это понятно — но часто это вводит в заблуждение. Сервис может иметь «всего 20% CPU» и при этом быть ужасно медленным, если потоки большую часть времени не выполняются.

Почему только %CPU вводит в заблуждение

%CPU отвечает на вопрос «насколько загружен процессор?» Он не отвечает на «куда ушло время моего запроса?». Запросы могут простаивать, пока потоки ждут, блокируются или остаются приостановленными планировщиком.

Ключевая мысль: wall-clock время запроса включает и on-CPU работу, и off-CPU ожидание.

Частые причины off-CPU времени

Off-CPU время обычно скрывается за зависимостями и contention:

• Disk I/O: синхронные чтения/записи, fsync, медленное хранилище, промахи в page cache.
• Сетевое ожидание: DNS, TCP-ретрансмиссии, перегруженные upstream-сервисы.
• Конкуренция за локи: потоки блокируются на мьютексах, reader/writer-lock, contention аллокатора.
• Очереди: ожидание в thread pool, connection pool или внутренних очередях работы.

Симптомы, за которыми стоит следить

Несколько сигналов часто коррелируют с off-CPU узкими местами:

• растущее время в очереди (запросы ждут, прежде чем начать выполнение)
• увеличение runnable threads (больше конкуренции за CPU)
• повышенный I/O wait и более долгие задержки диска/сети

Эти признаки говорят «мы ждём», но не чего мы ждём.

Как off-CPU профайлинг показывает «куда ушло время»

Off-CPU профайлинг атрибутирует время к причине того, почему вы не выполнялись: блокировка в системных вызовах, ожидание локов, sleep или дескетулирование. Это мощно для работы с задержками, потому что превращает расплывчатые замедления в действительные категории: «блокируется на mutex X», «ждёт read() с диска», «застрял в connect() к апстриму». Назвав ожидание, вы можете измерить его, подтвердить и исправить.

Подтверждайте узкое место доказательствами, а не интуицией

Работа с производительностью часто проваливается в одном месте: кто-то увидел подозрительную метрику, объявил её «проблемой» и начал тюнинг. Методы Грегга заставляют вас притормозить и доказать, что именно ограничивает систему, до внесения изменений.

Узкое место, горячая точка и шум

Узкое место — ресурс или компонент, который в данный момент лимитирует пропускную способность или вызывает задержку. Если вы его облегчите, пользователи увидят улучшение.

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

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

Докажите это сравнениями и контролируемыми изменениями

Начните с чистого снимка до: пользовательский симптом (задержка или уровень ошибок) и ведущие кандидаты (CPU-сатурация, глубина очереди, I/O диска, contention локов и т.д.). Затем внесите контролируемое изменение, которое, по идее, должно повлиять только на подозреваемую причину.

Примеры причинно-следственных тестов:

• Добавьте ёмкость подозреваемому ресурсу (ещё один worker, больше CPU-шер, больший connection pool) и проверьте, улучшилась ли задержка.
• Временно уменьшите нагрузку (ограничьте шумный эндпойнт, проиграйте меньшую нагрузку) и посмотрите, ослабло ли подозреваемое ограничение.

Корреляция — это подсказка, а не вердикт. Если «CPU растёт вместе с задержкой», проверьте, изменится ли задержка при изменении доступности CPU или сокращении CPU-работы.

Документируйте, что вы доказали

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

Постройте повторяемый рабочий процесс для инцидентов производительности

Инциденты по производительности ощущаются как срочные, и именно тогда чаще всего появляется гадание. Лёгкий повторяемый рабочий процесс помогает перейти от «что-то медленное» к «мы знаем, что изменилось» без метаний.

Цикл инцидента: обнаружить → классифицировать → измерить → исправить

Обнаружить: алертить по пользовательской задержке и уровню ошибок, а не только по CPU. Пейджить, когда p95/p99 задержка пересекает порог в устоявшемся окне.

Классифицировать: сразу ответьте на три вопроса: что медленно, когда началось и кто пострадал? Если вы не можете назвать область (сервис, эндпойнт, регион, когорта), вы не готовы оптимизировать.

Измерить: собрать доказательства, сужающие узкое место. Предпочитайте захваты, ограниченные по времени (например, 60–180 секунд), чтобы сравнить «плохо» и «хорошо».

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

Стандартизируйте небольшой набор графиков

Держите общий дашборд, которым пользуются все во время инцидентов. Пусть он будет скучным и однообразным:

• Задержка: p50 / p95 / p99 (по критичным эндпойнтам)
• RED сигналы: Rate, Errors, Duration (вид сервиса в первую очередь)
• Несколько метрик USE: utilization, saturation, errors для CPU, диска и сети

Цель не в том, чтобы графать всё; цель — сократить время до первого факта.

Определите «золотые сигналы» для критичных эндпойнтов

Инструментируйте эндпойнты, которые имеют значение (checkout, login, search), а не каждый эндпойнт. Для каждого согласуйте: ожидаемый p95, максимальный уровень ошибок и ключевую зависимость (БД, кэш, сторонний сервис).

Решите, что захватывать во время инцидентов

До следующего простоя договоритесь о комплекте захвата:

• Профили (CPU и off-CPU), плюс flame-графы
• Трейсы для медленных эндпойнтов
• Логи ошибок/таймаутов (с семплингом)

Задокументируйте это в коротком ранбуке (например, /runbooks/latency), включая кто может запускать захваты и где хранятся артефакты.

Где Koder.ai вписывается в рабочий процесс по Греггу

Методология Грегга по сути про контролируемые изменения и быструю верификацию. Если ваша команда строит сервисы с помощью Koder.ai (чат-ориентированная платформа для генерации и итерации web, backend и mobile-приложений), две функции хорошо соотносятся с этим подходом:

• Planning Mode помогает превратить «возможно, это X» в явную гипотезу и небольшой тестируемый набор изменений до касания продакшна.
• Snapshots and rollback поддерживают безопасные эксперименты с одной переменной: внесли изменение, замерили RED/USE сигналы и быстро откатились, если доказательства говорят «нет».

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

Практический разбор: от всплеска задержки до подтверждённого исправления

Сценарий: p99 прыгает во время пикового трафика

10:15 утра — дашборд показывает рост p99 задержки API с ~120 мс до ~900 мс во время пика. Уровень ошибок стабильный, но пользователи жалуются на «медленные» запросы.

Шаг 1 — начните с RED, чтобы найти влияние на пользователей

Начните с сервиса: Rate, Errors, Duration.

Разбейте Duration по эндпойнтам и увидите, что один маршрут доминирует в p99: POST /checkout. Rate вырос в 2×, ошибок нет, но Duration растёт именно при увеличении конкурентности. Это указывает на очереди или contention, а не на явную ошибку.

Далее проверьте, является ли задержка вычислительным временем или временем ожидания: сравните «время обработчика» приложения и общее время запроса (или upstream vs downstream спаны, если есть трассировка). Время обработчика низкое, общее время высоко — запросы ждут.

Шаг 2 — примените USE к подозреваемым хостам

Инвентаризация потенциальных узких мест: Utilization, Saturation, Errors по CPU, памяти, диску и сети.

Загрузка CPU ~35%, но run queue и контекстные переключения растут. Диск и сеть выглядят спокойно. Это несоответствие (низкий %CPU, высокий wait) — классический намёк: потоки не сжигают CPU — они блокированы.

Шаг 3 — выберите профилирование по симптомам

• Если CPU высок — берите CPU-профайлинг (on-CPU flame-графы) чтобы увидеть, где тратится время.
• Если запросы ждут — берите off-CPU профайлинг, чтобы увидеть, на чём блокируются потоки (локи, I/O, планировщик).

Вы сняли off-CPU профиль во время спайка и обнаружили много времени в мьютексе вокруг общего кэша «promotion validation».

Шаг 4 — исправьте и верифицируйте

Заменили глобальный лок на лок по ключу (или добавили lock-free путь для чтения), задеплоили и наблюдаете, как p99 возвращается к базовой линии при той же Rate.

Чеклист пост-инцидента:

• Записать точные RED-симптомы и суженный эндпойнт.
• Сохранить профиль и временное окно.
• Добавить алерт по специфическому сигналу saturation (например, ожидание на лок/run queue).
• Записать «следующий вопрос», если это повторится.