Наблюдаемость
SLO и error budget: заинструментируй путь от начала до конца
Читать про SLO — не то же самое, что быть разбуженным в 2 часа ночи алертом, которому доверяешь. Возьми небольшой многосервисный путь, определи SLI, отслеживающий реальную боль пользователя, сгенерируй MWMBR-алерты, докажи fire drill’ом, что они срабатывают и сбрасываются, и напиши политику, превращающую бюджет в решение.
Преврати ментальную модель юнита в работающий SLO-стек: journey-level SLI, набор MWMBR-алертов, сгенерированных платформой с корректными порогами burn, проверенный fire drill, composite-математику потолка пути и подписанную error budget policy — каждый шаг с доказательством.
Заинструментируй небольшой многосервисный пользовательский путь (свой или стартовый из 3-4 сервисов: gateway, order, payment, db) journey-level SLO, MWMBR burn-rate алертами, сгенерированными платформой, и подписанной error budget policy — затем докажи, что алерты срабатывают быстро и сбрасываются за 5 минут намеренным fire drill'ом.
- Документированная спецификация SLI с каждым индикатором, его запросом, bucket-границей на пороге латентности и worst-of join — с одной строкой плохого пользовательского исхода, который ловит каждый индикатор.
- Сгенерированные recording rules и MWMBR-алерты, закоммиченные в репо, с budget rate, видимо пересчитанным под выбранную SLO-цель (а не захардкоженным 0.001).
- Таймлайн fire drill (таймстемпы), доказывающий, что page сработал за минуты и сбросился за ~5 минут после фикса — измерено из Prometheus/Alertmanager, а не оценено.
- Расчёт composite-потолка для пути и абзац-аргумент, какой слой — авторитетный SLO.
- Подписанный документ error budget policy со всеми пятью обязательными секциями и списком исключений.
- Добавь второй severity-тир и покажи, что page 6h+30m ловит устойчивый умеренный burn (6x), который page 1h+5m пропустил бы, через slow-burn fire drill.
- Подними потолок пути одним архитектурным рычагом — idempotent-ретраи с idempotency key или parallel hedging на худшем хопе — и покажи success rate пути до/после и цену в латентности.
- Построй SLO meta-дашборд с тремя сигналами self-observability: детект NaN/нулевого знаменателя, стационарность 3d burn rate (цель ~1x) и budget-negative события vs активации freeze.
- Определи клиентский SLA слабее внутреннего SLO на 0.05-0.5pp, обоснуй размер буфера своим mean time to detect-and-fix и покажи на истории burn, что внутренний SLO срабатывает раньше, чем сработал бы SLA.
Это цикл, который ты запускаешь, когда приносишь SLO в реальный сервис: определи SLI из плохих пользовательских исходов (доступность, латентность на точном bucket, корректность), выставь консервативную цель на 28-дневном окне, сгенерируй MWMBR-алерты платформой, чтобы budget rate был корректно пересчитан, докажи fire drill’ом, что алерт срабатывает быстро и сбрасывается за 5 минут, защитись от NaN и низкого трафика и подпиши error budget policy, превращающую burn в организационное решение. Сделав это раз на маленьком пути, ты доводишь production-раскатку — и квартальное ревью, держащее SLO честным, — до уровня мышечной памяти.