Наблюдаемость
SLO и error budget: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту — арифметика error budget, вывод burn rate, AND-логика MWMBR, composite-потолки и организационные сбои.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый — это решение, которое ты принимаешь на реальном reliability-ревью: не определение для заучивания, а число, которое надо посчитать, и компромисс, который надо обосновать.
Цель
Убедись, что связываешь выбор SLI, арифметику бюджета, вывод burn rate, MWMBR-алертинг, composite-математику пути и организационный слой — тот синтез, к которому вели все восемь уроков.
Викторина
Completed
Сервис держит 99.9% SLO по доступности на окне 28 дней при 1M запросов/день. На 14-й день обслужено 14M запросов и накопилось 21 000 отказов. Насколько здоров бюджет?
Heads-up Важна позиция в окне. На 14-й день ожидаемая трата — половина бюджета (14 000). Потрачено 75% бюджета при оставшихся 50% окна — burn ~1.5x, который исчерпывает бюджет раньше срока.
Heads-up Большинство политик замораживают при нулевом остатке, а не при 75% траты. Команде стоит притормозить рискованные деплои и следить за burn, но триггер freeze ещё не достигнут.
Heads-up Error budget выводится из SLO и трафика, а не из SLA. Budget = (1 − SLO) × total_events; SLA — отдельное, более слабое обязательство перед клиентом.
Викторина
Completed
On-call копирует page-правило 1h+5m с сервиса на 99.9% SLO — expr (1 − ratio_rate1h) > (14.4 × 0.001) — на сервис с SLO 99.5%, не меняя выражение. Что ломается?
Heads-up Множитель burn (14.4x) тот же, но error rate, в который он отображается, равен burn × (1 − SLO). Скопированный 0.001 кодирует бюджет 99.9%; для 99.5% он должен стать 0.005, иначе алерт срабатывает ~в 5 раз охотнее.
Heads-up Он срабатывает чаще, а не реже. Оставшийся 0.001 ставит точку срабатывания на 1.44% error rate, который сервис на 99.5% SLO превышает рутинно — это противоположность «никогда не сработает».
Heads-up Оба окна сравниваются с одним и тем же захардкоженным budget rate. Именно поэтому рукописный PromQL подвержен ошибкам, а платформы вроде Sloth генерируют его из объявленной цели.
Викторина
Completed
MWMBR page-правило срабатывает, когда burn за 1h И burn за 5m оба превышают 14.4x. Во время инцидента 1h-burn = 18x, но 5m-burn упал до 9x. Должно ли пейджить и что говорит каждое окно?
Heads-up MWMBR намеренно требует ОБА окна. Короткое окно — это гейт «всё ещё происходит сейчас?»; при нём ниже порога AND ложно и page подавляется, избегая побудки на уже восстанавливающийся инцидент.
Heads-up 9x высок в абсолюте, но ниже порога page 14.4x. AND требует оба окна за чертой; падающее короткое окно — это recovery-сигнал, который держит page тихим.
Heads-up AND между двумя окнами живёт в самом PromQL-выражении. 'for' — отдельный механизм дебаунса и не реализует dual-window логику.
Викторина
Completed
Путь checkout проходит через API gateway, auth, inventory, payment и database, каждый держит независимый 99.9% SLO, все зелёные. Пользовательский success rate checkout — ~99.5%. Как это читать и чинить?
Heads-up Per-service SLO композируются как произведение, а не среднее или максимум. Пять независимых сервисов по 99.9% дают 0.999^5 ≈ 99.5%; дашборды все верны, просто меряют не тот слой для пользовательского пути.
Heads-up Математически работает (0.9999^5 ≈ 99.95%), но это дорогой рычаг — каждая лишняя девятка стоит 3-10x. Дешевле journey-level SLI плюс работа по Парето-доминирующим источникам или idempotent-ретраи / hedging на худшем хопе.
Heads-up Длина окна меняет скорость обнаружения, а не composite-потолок. Путь структурно ограничен ~99.5% при любом окне; поднимают его только journey-level измерение и архитектурные рычаги.
Викторина
Completed
SLI доступности checkout считает любой 2xx «хорошим». Он стабильно зелёный, но клиенты сообщают о двойных списаниях и 30-секундных «успешных» checkout. Почему SLO это пропускает и какой senior-фикс?
Heads-up Никакая цель не ловит отказ, который SLI не наблюдает. 99.999% SLO с SLI только по 2xx всё равно засчитает двойное списание как «хорошее». Дефект — в индикаторе, а не в цели.
Heads-up Пороги нерелевантны, когда SLI не считает отказ. Если ошибки корректности невидимы индикатору, никакой тюнинг алертов их не выловит.
Heads-up Композиция — другая задача. Здесь один SLI не отслеживает корректность и латентность; фикс — несколько SLI по пользовательским исходам, соединённых worst-of, а не нарезка per-service.
Викторина
Completed
Через полгода после раскатки SLO на 80 сервисов с корректно сгенерированными MWMBR-алертами и подписанной error budget policy половина команд игнорирует пейджи, а бюджеты уходят в минус без freeze. Какова наиболее вероятная корневая причина?
Heads-up Если SLI неверен, никакой порог это не чинит — идеально откалиброванный burn на бессмысленном индикаторе всё равно пейджит на не-проблемы, а подъём порогов задерживает реальное обнаружение. Вина — в определении SLI и enforcement политики.
Heads-up Лучший тулинг не чинит организационное бутылочное горло. Команды, меняющие инструмент без починки SLI и политики, получают те же дашборды, на которые никто не реагирует. Сначала контракт, потом инструменты.
Heads-up Укорачивание окна меняет каденс freeze, а не релевантность алертов и не зубастость политики. Отрицательный бюджет без freeze — это разрыв в enforcement, а не проблема длины окна.
Итог
Сквозная линия юнита — одна цепочка арифметики, ставшей организационной: SLI = good/total (и он обязан отслеживать боль пользователя, а не 2xx), SLO — это цель, error budget = (1 − SLO) × events, а burn rate нормализует трату. Алертинг выводится из burn = (budget_fraction × period) / window, срабатывает по длинному-AND-короткому окну, чтобы быть и устойчивым к шуму, и быстрым на сброс; не забудь пересчитать budget rate при смене SLO-цели. Пути перемножаются (0.999^5 ≈ 99.5%), iceberg SLI прячут корректность за 2xx, SLO обязан быть строже SLA, и фреймворк приносит пользу, только когда подписанная и исполняемая политика превращает число в решение.