Наблюдаемость

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

Суть Фиксированный порядок воронки — SLO burn, затем RED, trace, profile, git blame — режет MTTR на 50–80%, устраняя случайную навигацию по дашбордам.

Высота — путь к senior

НольJuniorMiddleSenior

Ты на junior-высоте — поверхность

◷ 10 min

2 ночи. Срабатывает SLO burn alert. Открываешь четыре дашборда наугад, спрашиваешь в Slack кто деплоил последним, и тратишь 40 минут на охоту. Твой коллега, подключившийся к тому же звонку, следует пятишаговому чеклисту и закрывает инцидент за 8 минут. Разница не в инструментах — в порядке.

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

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

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

Воронка фиксирована. Инструменты меняются каждые два года; воронка не меняется пятнадцать.

Слой	Инструмент	Вывод (сужает до)
1. SLO burn alert	Alerting + SLO-дашборд	Какой сервис имеет user-facing impact
2. RED-дашборд	Grafana / Datadog	Что из Rate / Errors / Duration сдвинулось
3. Trace view	Jaeger / Tempo / Honeycomb	Какой сервис и span владеет временем
4. Profile	Pyroscope / Parca	Какая функция внутри span’а ела CPU
5. git blame	git	Коммит, автор, окно деплоя

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

Стартап перенял полный стек главы: 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’ы — в случайном.

Почему это работает

Представь приёмный покой больницы. Пациент в боли. Шаг 1: жизненные показатели (RED) — пульс, BP, температура. Шаг 2: известные ограничения (SLO) — стабилен или критичен? Шаг 3: визуализация (traces) — где в теле точно? Шаг 4: биопсия (profile) — из чего ткань состоит? Каждый шаг разные инструменты, но все отвечают на один вопрос: где резать? Production observability — то же самое.

Дисциплина воронки: что говорят числа

Снижение MTTR от дисциплины воронки: 50–80%
Снижение MTTR только от нового tooling: 10–20%
MTTR в примере (стартап, 6 месяцев): 45 мин → 8 мин
Типичный MTTD с burn-rate-алертами: 1–5 минут
Типичный MTTR с дисциплиной воронки: 3–10 минут

Викторина

В воронке production-debugging какой сигнал смотрит on-call первым?

Расставь шаги по порядку

Расставь production-debugging-воронку от широкого к узкому:

1 SLO burn-rate-алерт сработал — user impact идёт, бюджет тратится быстро
2 RED-дашборд затронутого сервиса — что из Rate / Errors / Duration сдвинулось?
3 Trace view, отфильтрованный на burn-окно — какой сервис и span владеет latency?
4 Profile, отфильтрованный по trace-id — какая функция внутри span'а ела время?
5 git blame на горячей функции — какой коммит и автор её ввели?

Закончи аналогию

Заполни пропуск: порядок воронки SLO → RED → trace → _______ → код.

Викторина

Что значит обещание OpenTelemetry 'один SDK, один wire-format' для engineering-org?

Вспомните перед уходом

01
Почему следование фиксированному порядку воронки режет MTTR больше, чем покупка лучших инструментов?
02
В сценарии SLO burn checkout что показал RED и какую форму это исключило?
03
Назови пять слоёв воронки в порядке и укажи, как вывод каждого слоя питает следующий.

Итог

Производственная debugging-воронка — пятислойная сужающаяся последовательность: SLO burn называет сервис, RED — сдвинувшийся сигнал, trace — span, profile — функцию, git blame — коммит. Вывод каждого слоя фильтрует запрос следующего, поэтому никакого обдумывания не требуется. Апгрейды инструментов дают 10–20% улучшения MTTR; дисциплина воронки — 50–80%, потому что большая часть потерь инцидента — навигация, не анализ. Стартап с полным observability-стеком и дисциплиной воронки увидел снижение MTTR с 45 до 8 минут за шесть месяцев — не от более быстрых инструментов, а от устранения случайного порядка. Воронка фиксирована; инструменты меняются каждые два года, воронка не меняется пятнадцать.

Связанные уроки

опирается на

открывает

Архитектура OTel: один SDK, четыре сигнала, один wire-форматmiddle

углубляется в

Архитектура OTel: один SDK, четыре сигнала, один wire-форматmiddle

встречается в202

Продолжить восхождение ↑Архитектура OTel: один SDK, четыре сигнала, один wire-формат