Debugging-воронка: SLO → RED → trace → profile

Ментальная модель воронки

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

Debugging-воронка — это фиксированная сужающаяся последовательность. Вывод каждого слоя — входной фильтр следующего. В воронке пять слоёв:

1. SLO burn-rate alert — подтверждает user-facing impact и называет сервис. Без SLO burn команда ещё не знает, реальный ли симптом или flaky-тест.
2. RED-дашборд — Rate, Errors, Duration для названного сервиса. Одна из трёх переменных сдвинулась; форма (spike vs drift vs plateau) подсказывает класс причины.
3. Trace view — отфильтрованный на burn-окно. Находит какой сервис и какой span владеет latency или ошибками. Сужает с «что-то сломано в checkout» до «inventory.lookup занимает 1.3 с».
4. Profile — отфильтрованный по trace-id из шага 3. Flame graph показывает какая функция внутри span’а потребила CPU или I/O. Сужает с «inventory.lookup медленный» до «json.Marshal на новой схеме».
5. git blame — на функцию и строку из профиля. Называет коммит, автора и окно деплоя.

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

Конкретный проход

Стартап перенял полный стек главы: RED-дашборды, SLO с multi-window burn-rate алертами, OTel traces, continuous profiling. On-call-инженер получает пейджер: «checkout SLO burn 14x».

Она не открывает все дашборды. Она следует воронке.

• RED на checkout: p99 прыгнул с 200 мс до 1.5 с; Rate стабилен; Errors стабильны. Спайк только Duration — не краш, не проблема capacity.
• Trace view, отфильтрованный на burn-окно: один span доминирует в каждом медленном trace — inventory.lookup, 1.3 с из 1.5 с суммарных.
• Profile inventory-сервиса, отфильтрованный по тому trace-id: 1.1 с в json.Marshal — новый кодпуть, сериализующий слишком много.
• git blame на call site json.Marshal: коммит приземлился 30 минут назад, автор — inventory-команда, деплой совпадает со временем начала burn.

Время от пейджера до git blame: 90 секунд. Воронка сделала работу.

За полгода MTTR команды упал с 45 минут до 8. Не быстрее отдельные клики — просто без случайного порядка.

Почему апгрейд инструментов не режет MTTR

Tooling даёт 10–20% улучшения MTTR. Дисциплина воронки — 50–80%, потому что большая часть потерь — навигация: открытие какого дашборда последним видел on-call, вопросы в Slack, переключение сигналов без направления. Воронка устраняет обдумывание. Каждый клик определён предыдущим. Senior’ы, кажущиеся в 10x быстрее во время инцидентов, обычно не гоняют другие запросы; они гоняют те же в правильном порядке, пока junior’ы — в случайном.