Наблюдаемость
Observability-капстоун: инструментируй сервис и продебажь инцидент
Читать про воронку — не то же, что провести реальный burn-алерт вниз до git-коммита. Поднимите небольшую систему из двух-трёх сервисов, инструментируйте её всеми четырьмя сигналами, сджойненными по trace-id, подключите SLO burn-rate-алерт, затем внедрите fault и разрешите его через воронку — с доказательством на каждом слое.
Превратить всю главу в одну рабочую систему: сервис, эмитящий коррелированные логи, метрики, трейсы и профили через OTel; SLO с multi-window burn-rate-алертом; trace propagation на каждом hop; continuous profiling; и задокументированный инцидент, проведённый от пейджа до root cause через воронку.
Собрать (или взять) небольшую мульти-сервисную систему — минимум frontend-вызыватель плюс два backend-сервиса, один вызывает другой — инструментировать её end-to-end через OpenTelemetry так, чтобы все четыре сигнала джойнились по trace-id, определить один SLO с multi-window burn-rate-алертом, затем внедрить реалистичный fault и разрешить его через воронку SLO → RED → trace → profile → git blame, доказав каждый шаг захваченным свидетельством.
- Один trace-id доказуемо джойнит все четыре сигнала для одного выбранного request — показать строку лога, exemplar метрики, дерево трейса и профиль, каждый несёт тот же trace-id.
- Multi-window burn-rate-алерт срабатывает в течение минут после внедрённого fault и гаснет после фикса; включить определение алерта и скриншоты/экспорты срабатывания и гашения.
- Разбор инцидента, проходящий SLO → RED → trace → profile → git blame, с одним захваченным артефактом на слой воронки, заканчивающийся на конкретном коммите/функции, вызвавшем burn.
- Trace propagation проверен на каждом hop (нет осиротевших span'ов, одно связное дерево трейса), и показано, что tail sampling держит падающие/медленные трейсы, сбрасывая baseline.
- Blameless-постмортем примерно на одну страницу: таймлайн от T+0 до разрешения, root cause, сформулированный как системный отказ, и отслеживаемые action item'ы.
- Добавить cost-дисциплину: ввести cardinality-бюджет метрик (отклонять неограниченные label'ы вроде user_id в CI), применить tiered log retention и отчитаться о стоимости observability на миллион запросов до и после.
- Добавить второй класс fault (спайк errors, а не latency) и показать, что та же воронка локализует его — доказывая, что порядок fault-агностичен.
- Провести запланированный game day: пусть коллега внедрит неизвестный fault, пока вы on-call, замерьте свои MTTD и MTTR и обновите runbook по тому, что вас замедлило.
- Добавить PII-scrubbing-процессор в collector и pre-commit-скан секретов/PII; продемонстрировать, что случайно залогированный email или db.statement редактируется, прежде чем покинет ноду.
- Посчитать ROI для вашей системы: оцените revenue/min, умножьте на MTTR-дельту, которую купила воронка против no-trace baseline, и напишите ответ CFO в один абзац.
Это глава как одна рабочая система и петля, которую вы будете прогонять в каждом реальном инциденте: инструментировать все четыре сигнала и сджойнить их по trace-id, пробросить traceparent на каждом hop, определить SLO с multi-window burn-rate-алертом, затем пройти SLO → RED → trace → profile → git blame до конкретного коммита — захватывая свидетельство на каждом слое и закрывая blameless-постмортемом. Соберите это однажды на игрушечной системе, и production-версия станет мышечной памятью; воронка фиксирована, даже когда тулинг меняется.