SLO-based alerting: почему дежурный глушит уведомления
Алерты на порогах срабатывают, когда отдельная метрика пересекла заданную границу — загрузка узла, длина очереди, доля ошибок за минуту. Сам по себе такой сигнал не говорит, страдают ли пользователи: всплеск повторов в очереди гасится повторными попытками, а короткий рост доли ошибок сервис переживает незаметно.
За сутки дежурный получает сотни уведомлений, из которых действия требуют единицы. Он перестаёт читать канал — важное теряется в потоке, а настоящая деградация сервиса развивается медленно и не переходит ни один порог резко. Обнаруживают её по жалобам пользователей, а не по мониторингу: пропущенный инцидент растягивает время реакции с минут до часов.
SLO-based alerting меняет точку отсчёта: триггером становится не порог метрики, а расход бюджета ошибок. Сервис поднимает дежурного только тогда, когда текущая деградация грозит исчерпать допустимую долю неуспешных запросов за окно наблюдения.
Работает это через скорость выгорания бюджета на нескольких окнах сразу. Короткое окно ловит резкий всплеск и поднимает дежурного немедленно, длинное — устойчивое медленное сползание, которое пороговые алерты пропускают. Оба сигнала указывают на один инцидент вместо десятков уведомлений по смежным метрикам, и алерт приходит с контекстом: какой SLO под угрозой, за какое окно и как быстро тратится бюджет.
Шум дежурств падает в разы, но главное — меняется класс отказов, которые команда ловит до пользователей. Ниже разбираем, как такой контур настраивается и что для него нужно со стороны сервиса.
Что даёт бюджет ошибок: меньше шума, быстрее реакция
Бюджет ошибок переводит надёжность сервиса из спора о вкусах в измеримую величину. На окно наблюдения задан допустимый объём отказов, и правило срабатывает не на любое отклонение метрики, а на скорость выгорания этого запаса: дежурный получает страницу тогда, когда при текущем темпе бюджет будет исчерпан до конца окна.
Многооконные правила с быстрым и медленным окном разводят два разных сценария. Короткое окно ловит резкое падение за минуты, длинное — медленный дрейф, который по одиночным замерам не виден. Порог привязан к вопросу «успеем ли исчерпать бюджет», поэтому статичные границы, годами дававшие ложные срабатывания, уходят.
Что меняется измеримо:
- доля уведомлений, по которым инженер начинает работу, вместо «посмотрел и закрыл как известный шум»;
- время до обнаружения деградации — от первых аномальных ответов до страницы дежурному;
- классы отказов, которые перестают доходить до пользователя: частичная деградация становится видна раньше полного отказа.
Правила строятся на симптомах — доле успешных запросов, задержке, доступности ключевых сценариев, — а не на причинах вроде загрузки отдельного узла. Этот разворот описан в Google SRE: страница приходит на то, что заметил пользователь, а не на то, что просто подозрительно выглядит на графике.
Сравнение подходов к оповещению о деградации
Выбор механизма оповещения определяет не количество уведомлений, а то, заметит ли команда деградацию раньше пользователей. Статические пороги дёшевы и предсказуемы, но ничего не знают о сезонности и постепенном росте нагрузки; аномальные модели ловят незнакомое, зато шумят на каждом релизе и всплеске спроса; цели по надёжности с бюджетом ошибок привязывают сигнал к пользовательскому опыту, но требуют посчитанного бюджета и полного покрытия телеметрией.
| Подход | Когда уместен | Где ломается |
|---|---|---|
| Статические пороги | Ресурсы с ровным профилем: свободное место, длина очереди, абсолютное число ошибок | Порог приходится пересматривать при каждом росте трафика, а медленная деградация границу не пересекает вовсе |
| Аномальные оповещения по историческим данным | Сезонная нагрузка и сбои, которые заранее не описать правилом | Период обучения с деградацией закрепляет сбой как норму, а релизы дают поток ложных срабатываний |
| Многоконные политики на бюджете ошибок | Пользовательские сервисы с явной целью по надёжности | Нужны посчитанный бюджет, разметка быстрого и медленного окна и покрытие метриками — иначе уведомления теряют смысл |
| Комбинация слоёв | Зрелая система, где критические пути отделены от вспомогательных | Требует ревизии существующих правил и роли ответственного за пересмотр целей |
На практике подходы не конкурируют, а расходятся по слоям: многоконные политики закрывают критические пользовательские пути, статические пороги — ресурсы и фоновые очереди, аномалии остаются вспомогательным слоем для того, что ещё не описано целью. Совмещение даёт меньше уведомлений при большей чувствительности.
Внедрение: от инвентаризации сервисов до графика дежурств
Порядок этапов неслучаен: если начать с порогов, не разобравшись, какие сервисы критичны и как они связаны между собой, алерты начнут срабатывать на всё подряд — и дежурный быстро перестанет на них смотреть. Идём от инвентаризации к передаче дежурной команде, на каждом шаге есть проверяемый результат.
- Инвентаризация сервисов. Список сервисов с владельцами, критичностью и тем, что считаем ошибкой с точки зрения пользователя, а не по внутренней метрике.
- Карта зависимостей. Отмечаем общие узлы: деградация одного из них даёт лавину алертов, и пять команд просыпаются из-за одной причины.
- Согласование целей. С владельцем сервиса фиксируем целевой уровень доступности, правило расчёта и бюджет ошибок на скользящем окне.
- Настройка политик. Короткая вспышка ошибок и устойчивая деградация — разные сигналы, поэтому быстрый и медленный порог считаются отдельно, с разной скоростью уведомления.
- Маршруты эскалации. Определяем, кто получает уведомление первым, через сколько подключается вторая линия и где ведётся история инцидента.
- Учебный инцидент. Намеренно деградируем сервис и проверяем цепочку: алерт дошёл, дежурный нашёл причину по инструкции, эскалация сработала. Замеряем время до реакции.
- Передача дежурной команде. Регламент дежурств, инструкции по разбору, разбор ложных срабатываний и подстройка порогов в первые недели.
Что передаём на руки: конфигурации, дашборды, регламенты
Передаём не набор правил в чужой панели, а конфигурацию под версионным контролем: описание сервисов, политики и маршруты лежат рядом с кодом, изменение проходит ревью и откатывается одной правкой. Такой набор остаётся рабочим без нас — новый сервис подключается по инструкции, пороги правятся осознанно, а не «кто-то когда-то настроил».
- Описание сервисов — перечень критичных сервисов с владельцами, зависимостями и целевыми уровнями доступности и задержки, из которых считаются бюджеты ошибок.
- Политики оповещения — какие правила срабатывают, на какой скорости расхода бюджета, окна ожидания и глушение, чтобы дежурного не поднимал единичный сбой.
- Маршруты эскалации — кто первый в очереди, через сколько минут подключается вторая линия и в какой момент автоматика уступает ручному решению.
- Дашборды дежурства — остаток бюджета, текущий расход, горящие алерты и последние изменения; открываются одной ссылкой с любого устройства.
- Регламент разбора инцидентов — порядок фиксации, критерии заморозки релизов при сгоревшем бюджете и формат записи причин, чтобы выводы не терялись.
- Документация и передача знаний — где хранятся конфигурации, как подключить новый сервис, как согласовать смену порога и кто отвечает за ревизию.
Отдельным пунктом идёт процедура периодической ревизии: раз в квартал сверяем, какие правила ни разу не срабатывали, а какие шумят, и убираем лишнее. Без этого любой набор алертов зарастает и теряет доверие дежурных.
Кейс: как SLO-политики снизили шум дежурств
Дежурство держалось на статических порогах: отдельное правило под каждую метрику, значения выставлены при запуске сервиса и не пересматривались при росте нагрузки. За смену приходило 60–80 уведомлений, и большая часть описывала короткие всплески, которых пользователи не замечали. Дежурный учился фильтровать поток на глаз и вместе с шумом отбрасывал сигналы о настоящей деградации.
Что изменили
Пороги по отдельным метрикам заменили бюджетом ошибок: уведомление поднимается не при разовом отклонении, а когда скорость его выгорания устойчиво выше нормы — и подтверждается сразу в двух окнах, коротком и длинном. Короткое ловит резкий сбой, длинное — медленное накопление ошибок, которое одиночный порог пропускал. Метрики надёжности собирали в Prometheus, правила описывались как код и проходили проверку вместе с изменениями сервиса.
Переключение политик шло поэтапно. Несколько недель система работала в теневом режиме: новые уведомления уходили в отдельный канал и сверялись с ручными разборами инцидентов. Затем сервисы переводили по одному, оставляя прежние пороги страховкой, пока точность новых правил не подтверждалась на живых сбоях.
| Показатель | До | После |
|---|---|---|
| Уведомлений за смену дежурства | 60–80 | 8–12 |
| Доля ложных срабатываний | около 70 % | меньше 10 % |
| Обнаружение деградации | 15–40 минут | 2–5 минут |
| Разбор одного уведомления | 20–30 минут | 5–7 минут |
Поток уведомлений сократился без роста времени реакции: строгость теперь задаёт целевой уровень надёжности, а не субъективно выбранный порог.
Чем бюджет ошибок отличается от порогового алерта?
Пороговый алерт следит за мгновенным значением метрики: доля неудачных запросов перевалила за заданный процент в течение минуты — сработало. Бюджет ошибок считает иначе: он накапливает долю неудачных запросов за окно наблюдения и сравнивает её с допустимым остатком. Разница принципиальная — порог ловит любой всплеск, даже если пользователи его не заметили, а бюджет отражает реальную потерю надёжности за период.
Механика простая. При цели доступности 99,9% бюджет ошибок — это 0,1% от всех запросов за окно наблюдения, обычно скользящее окно в несколько недель. Пока доля неудачных запросов внутри этой квоты, сервис в норме и дежурного будить не за чем. Как только квота выбрана, алерт означает, что дальнейшая работа идёт за счёт надёжности, которую мы обещали.
Дальше включается сгорание бюджета — скорость, с которой расходуется остаток. Её считают в двух окнах одновременно: короткое показывает быстрый всплеск и поднимает дежурного, длинное показывает медленную деградацию, которую не видно на мгновенном графике. Так сбой, съевший заметную часть квоты за час, не проходит мимо, а плавное ухудшение за две недели фиксируется отдельно.
Практический эффект: алертов становится в разы меньше, а каждый оставшийся действительно требует вмешательства. Логика описана в Site Reliability Engineering и обкатана на сервисах с высокой нагрузкой — мы переносим её на инфраструктуру заказчика, подбирая окна наблюдения и пороги сгорания под его трафик и режим дежурств.
Технические сомнения: окна, агрегация, ложный шум
Окно агрегации, редкие сервисы и размытая ответственность ломают SLO-based alerting чаще, чем сама математика расчёта. Ниже — короткие ответы на вопросы, которые инженеры задают до старта внедрения.
Как выбирать окно агрегации?
Одним окном не обойтись: короткое ловит быструю деградацию, но шумит на всплесках, длинное устойчиво к случайным сбоям, но запаздывает. Поэтому берём пару окон разной длины и разного порога расхода бюджета ошибок — быстрый сигнал уходит дежурному, медленный заводит задачу на разбор. Пороги подбираем по историческим данным сервиса, а не «на глаз».
Что делать с редкими сервисами?
На низком трафике доля ошибок скачет от единичного сбоя, и оповещение по проценту даёт ложные срабатывания. Для таких сервисов считаем абсолютное число неуспешных операций или фиксируем полное отсутствие успешных событий — это устойчивый сигнал. Цель по надёжности для них формулируем отдельно, с более широким окном наблюдения.
Кто владеет целью по надёжности?
Владелец цели — команда сервиса, а не инфраструктурная группа: она меняет код и отвечает за поведение системы. Само описание цели и правила оповещений храним рядом с кодом в репозитории, изменения проходят ревью. Так порог не «уезжает» молча, а история правок объясняет, почему он именно такой.
Как отделить реальный сбой от шума?
Оповещение поднимаем на исчерпание бюджета ошибок, а не на каждый отдельный отказ: одиночные сбои и перезапуски не будят дежурного. Срабатывания группируем по сервису и клиентскому пути, дубли схлопываем. Если сигнал приходит чаще, чем команда успевает реагировать, — порог пересматриваем, иначе дежурный привыкает игнорировать оповещения.
Обсудим задачу: с чего начнём и что понадобится
Начать разговор стоит с обсуждения задачи в конкретных терминах: какие сервисы держат выручку, что для них считается нормой и где сейчас проходит граница между «работает» и «горит». Нам достаточно исходных данных по сервисам и текущего состояния мониторинга, чтобы вернуться с оценкой и планом работ, а не с общими обещаниями.
Что ждём от вас в первом сообщении:
- Перечень сервисов с ролью каждого в продукте и указанием владельца на стороне заказчика — по нему мы поймём, какие пути обработки запросов вообще имеет смысл покрывать целевыми уровнями.
- Текущие цели по доступности и времени отклика, если они уже сформулированы, либо жалобы на качество: «страница открывается медленно», «ночью пропадает канал» — этого хватит для первого контура.
- Где сейчас собираются метрики и логи, есть ли исторический ряд за несколько месяцев. Без истории нельзя посчитать, как часто цель нарушалась до внедрения, и потом не с чем будет сравнить.
- Существующие дашборды, правила алертов и каналы уведомлений: мессенджер, почта, дежурный телефон, система учёта инцидентов.
- Доступы для чтения к системам мониторинга и к описанию инфраструктуры — как правило, их выдают на время разбора и можно отозвать в любой момент.
- Порядок дежурств и эскалации: кто принимает алерт ночью и по какому признаку понимает, что пора будить второго инженера.
- Разбор последних инцидентов: что срабатывало ложно, что пропустили совсем и сколько времени уходило на подтверждение проблемы вручную.
После этого вернёмся со сроком внедрения по этапам, составом работ и тем, кого нужно привлечь с вашей стороны на каждом шаге. Опишите задачу — и мы дадим оценку и план.
