SLI-based Alerting

Алерт CPU > 80% говорит ровно одно: у какой-то машины есть какая-то задача. Алерт «99% запросов укладываются в 500 ms» говорит, что проблему заметит пользователь. Разница кажется косметической, пока не посчитаешь ночные побудки: первый будит зря, второй ловит реальные инциденты, и на то, чтобы индустрия это признала, ушло примерно десятилетие операционного опыта. Алертинг на SLI — про переход от первого ко второму.

Что должен уметь

Главный навык на уровне L5 — проектировать multi-window multi-burn-rate алерт по схеме SRE Workbook гл. 5. Это не «прочитать главу и применить» — это понять, почему длинное окно с низкой скоростью сжигания (burn rate) даёт тикет, а короткое с высокой — вызов дежурного. Я регулярно встречаю команды, которые читали главу и ввели «multi-window», но окна выбрали без понимания математики — в результате алерт либо шумит, либо молчит, как и пороговый, который заменяли.

Различает SLI, SLO и SLA; читает чужие SLO-based алерты и понимает, что именно они ловят.
Поднимает по runbook простой SLO-based алерт, написанный командой.

Записывает SLI как отношение good events / valid events и обосновывает выбор знаменателя (что считать «валидным» событием).
Настраивает простейший пороговый алерт на бюджет ошибок и понимает его ограничения: много ложных срабатываний, позднее обнаружение.
Выводит множитель burn rate из доли бюджета и длины окна SLO; объясняет, почему цель в него не входит.

Проектирует multi-window multi-burn-rate алерт по схеме из SRE Workbook гл. 5: подбирает окна и пороги под нужную чувствительность: что будит дежурного, а что уходит тикетом.
Разделяет потоки «срочно разбудить» и «разобраться в рабочее время» через разные burn rate.
Знает, где схема не работает: малый трафик и крайние цели; выбирает для таких сервисов другой способ и называет его цену.
Связывает каждый алерт с runbook и удаляет алерт без runbook как фоновый шум.

L6+

Проектирует стратегию алертинга для сервиса целиком: набор SLI, иерархия алертов, политика error budget, регламент эскалации.
Внедряет SLO-based алертинг в существующую команду с пороговой историей и переводит её на новую модель без снижения детектируемости инцидентов.
Ведёт короткий записанный список пороговых алертов, которым SLI не подходит: близкое исчерпание ресурса, молчание самого мониторинга, состояния без доли.
Задаёт правило приоритета, в котором канал определяют три входа вместе: множитель, контур и класс критичности сервиса.

Материалы

Книги

Betsy Beyer et al. — Site Reliability Engineering (O’Reilly, 2016), глава 6 «Monitoring Distributed Systems». Рекомендую как базу терминологии, глава короткая.
Betsy Beyer et al. — The Site Reliability Workbook (O’Reilly, 2018), глава 5 «Alerting on SLOs». Главная глава по теме, рекомендую читать её первой. Шесть стратегий алертинга разобраны последовательно, у каждой явно названы слабые места по precision, recall, времени обнаружения и времени сброса, и там же лежат готовые параметры окон для multi-burn-rate.
Alex Hidalgo — Implementing Service Level Objectives (O’Reilly, 2020). По моему ощущению, дополняет SRE Workbook, не заменяет: главное — глубина по составным SLO и пользовательским сценариям, чего в Workbook нет.

Статьи и доклады

Google SRE — Alerting on SLOs. То же, что в Workbook гл. 5, но онлайн и бесплатно; рекомендую эту ссылку, если книги под рукой нет.
Štěpán Davidovič — Measuring Reliability: What Got Us Here Won’t Get Us There (SREcon22 EMEA). Про пределы существующего подхода к измерению надёжности. Сам не смотрел; доклад в списке как единственный, который с остальными спорит, а не достраивает их.
Andrew Dedesko, Adriano Mariani — How to implement multi-window, multi-burn-rate alerts with Grafana Cloud (блог Grafana Labs, март 2025). Практическое дополнение к главе выше: выражения PromQL для пар окон собраны на работающем сервисе в Cloud Run, их можно взять и проверить у себя.
Александр Попов — Как приручить SLO’на в племени микросервисов (блог Dodo Engineering на Хабре, декабрь 2025). К этому листу относится раздел про настройку алертов: двухоконная схема на burn rate упёрлась в ночной трафик и в разницу объёмов между облаками.
Prometheus — Alerting (документация, раздел Best practices). Одна страница о том, на что алертить в онлайн-сервисах, офлайн-обработке и пакетных заданиях; отдельными строками идут ёмкость и мониторинг самого мониторинга.
Liz Fong-Jones и др. — Developing Effective Service Level Indicators and Service Level Objectives (SREcon18 Europe). Про то, как выбирать SLI, — половина проблем с алертами родом отсюда. Не читал и не смотрел, как и остальные её материалы; строка здесь указатель, а не рекомендация.
Мой разбор — Скорость сгорания бюджета ошибок — что тут не так? (jtprog.ru, апрель 2026). Откуда берётся каноническое 14.4 из пятой главы Workbook и почему burn rate — безразмерный коэффициент, а не скорость. Разбирал это потому, что, по моим наблюдениям, из-за слова «скорость» коэффициент путают с интенсивностью ошибок и подбирают окна наугад. В конце — про скользящее окно и про то, как коэффициент шумит на малом трафике.

Курсы

Google Cloud — Site Reliability Engineering: Measuring and Managing Reliability (Coursera). Уровень начальный. Сам курс не проходил и за содержание не ручаюсь; в списке он для команды, которая впервые слышит про SLI и SLO.

Инструменты

Prometheus + Alertmanager — каноничный стек: SLI собирается recording rules, алерты — правилами на скорость сжигания. Рекомендую как выбор по умолчанию, особенно если у вас k8s.
VictoriaMetrics + vmalert — альтернатива Prometheus для высоконагруженных сценариев; язык правил совместим, поэтому рекомендую как замену без переписывания алертов, когда Prometheus перестаёт держать нагрузку.
Grafana Alerting — альтернатива Alertmanager с настройкой через интерфейс. Рекомендую командам, живущим в Grafana; там, где всё едет через git, она неудобна.
Sloth — генератор PromQL для SLO и burn-rate алертов из декларативного YAML. По моим наблюдениям, его чаще берут команды от 5+ сервисов: вручную написать корректные multi-window правила тяжелее, чем кажется, и Sloth убирает целую категорию ошибок (опечатки в формуле, забытые окна, неконсистентные шаги).
Pyrra — open-source альтернатива Nobl9, родная для k8s, со встроенным дашбордом бюджета ошибок. Я вижу, что её берут как промежуточную ступень: Sloth уже маловат, Nobl9 ещё рано.
Nobl9 — коммерческая платформа. Сам не работал; коллеги рекомендуют её там, где SLO ведут несколько команд в разных регионах и нужен общий язык и общий портал. Для одной команды — перебор.

Best practices

Глава 5 SRE Workbook разбирает шесть стратегий алертинга подряд, от простейшей к рабочей, и оценивает каждую по четырём параметрам: precision, recall, время обнаружения, время сброса. Числовых оценок precision авторы не дают. Дают кое-что убедительнее: для простого порога «текущий error rate выше SLO» получается, что можно поймать до 144 алертов в сутки, не отреагировать ни на один и всё равно уложиться в SLO. Вот настоящая цена наивного порога — сигнал, который вообще ничего не говорит о том, страдает бюджет или нет, но исправно будит дежурного каждые десять минут.

Рабочий вариант — multi-window multi-burn-rate. Для SLO 99.9% рекомендованные параметры такие: сжигание 2% бюджета за час (burn rate 14.4) — пейджер; 5% за 6 часов (burn rate 6) — тоже пейджер, но менее срочный; 10% за 3 суток (burn rate 1) — тикет. Каждое длинное окно страхуется коротким в 1/12 его длины, чтобы алерт погас, когда сжигание прекратилось. Эти числа стоит помнить наизусть. Они закрывают большинство практических случаев без собственных выкладок.

Что работает:

Алертим на симптом, а не на причину. Симптом — то, что заметил пользователь: сервис вернул ошибку, запрос идёт полсекунды. Причин много, симптомов мало, и алерт на симптом спокойно переживёт смену реализации, переезд в другой кластер и замену базы. Алерт на причину через полгода либо ловит нормальную работу, либо молчит в инциденте.
Разные burn rate — разные каналы доставки. Быстрое сжигание (скажем, 14.4× за час) идёт в пейджер, медленное (1× за трое суток) — в тикет и в рабочее время. Смешаешь их в одном канале — потеряешь чувствительность к срочному: дежурный за неделю перестаёт верить пейджеру.

Третье правило я вынес из списка, потому что оно про дисциплину, а не про конфиг: каждый алерт ведёт к runbook. Алерт без runbook — это «разбуди человека и пусть думает в три ночи», и через полгода его начинают игнорировать или молча удаляют. Если runbook нет, у алерта два пути: удалить сразу или поставить в очередь с явным сроком, к которому runbook будет написан.

Дальше — то, что я считаю не менее важным, но это скорее выбор, чем правило.

Multi-window multi-burn-rate — не догма, а лекарство от выбора между ложными срабатываниями и поздним обнаружением. Один порог не может быть одновременно точным и быстрым. Это арифметика, а не вопрос настройки. Двойное окно разводит задачи: короткое с высоким burn rate ловит резкие инциденты, длинное с низким — медленную деградацию. Беда в другом. Подбор конкретных окон и порогов — нетривиальное упражнение, и почти каждая команда, которую я видел, копирует пример из главы 5 Workbook, не разбираясь, почему там стоят именно эти числа (1h × 14.4 и 6h × 6). Разобраться недолго. Множитель следует из двух вещей: какую долю бюджета согласны потерять до алерта и какой длины окно SLO. Два процента за час при тридцатидневном окне дают 0.02 × 720 = 14.4, при окне в 28 дней выйдет уже 13.44. Цель SLO в множитель не входит. Она появляется только в пороге доли ошибок: 14.4 × 0.001 для 99.9% и 14.4 × 0.01 для 99%. Таблица в Workbook подписана «для SLO 99.9%», и подпись сбивает с толку: от цели там зависит один этот сомножитель. Пересчитывать под себя стоит окно и доли бюджета. А таблицу множителей при том же окне авторы главы советуют применять ко всем сервисам сразу и не подбирать параметры для каждого.

На краях схема ломается, и Workbook говорит об этом прямо. При цели 90% полный отказ съедает за час 1.4% месячного бюджета, до двух процентов не дотягивает, и часовой алерт не сработает никогда. При цели 99.999% полный отказ сжигает месячный бюджет за 26 секунд, а это меньше интервала сбора метрик у многих систем мониторинга. Алертом такую цель не защитить. Её защищают конструкцией: изменение, раскатанное на один процент пользователей, оставляет до исчерпания бюджета 43 минуты.

Вторая граница — малый трафик, и на неё наступают чаще. Пример из той же главы: сервис получает десять запросов в час, и один из них упал. Часовая доля ошибок — 10%. При цели 99.9% одна эта ошибка съела 13.9% месячного бюджета, а на весь месяц их позволено семь. Пейджер звонит на каждый случайный таймаут. Workbook перечисляет четыре выхода: подмешать синтетический трафик, объединить мелкие сервисы в одну группу для мониторинга, изменить продукт так, чтобы единичный сбой стоил пользователю меньше, снизить цель или удлинить окно. У каждого своя цена. Синтетика, например, умеет прятать беду: сбой задел живых пользователей и не задел пробы, и успешные пробы разбавили сигнал. В Dodo на эту границу вышли на собственном трафике. Ночью его почти нет, между облаками объёмы различаются на порядки, и чувствительность алертов пришлось настраивать по времени суток. В своём разборе я назвал самый простой из выходов, агрегацию за большое окно. Цена у него понятная: алерт приходит позже.

SLI считается на стороне клиента, когда это возможно. Серверная метрика «процент 5xx» ничего не знает про балансировщик, DNS, деградацию сети между клиентом и сервером и сорванное рукопожатие TLS — то есть про изрядную часть того, что реально ломает пользовательский опыт. Я встречал ситуации, когда серверный SLI показывал 99.99%, а замеры из браузеров — честные 97%. Это разница между «всё нормально» и «инцидент». Идеал — синтетические проверки из сторонних регионов или телеметрия с самих клиентов. Серверные метрики их дополняют, но как единственный источник серверный SLI не годится. Если бюджета на клиентские измерения нет, серверный SLI всё же лучше, чем ничего; просто это компромисс, а не норма.

Знаменатель SLI важнее числителя — и о нём забывают. Числитель, те самые good events, команды обсуждают часами. Знаменатель не обсуждает никто. Я видел SLO 99.95% запросов вернули 2xx за 200ms, в знаменатель которого попадали проверки живости, внутренние пробы мониторинга, обращения поисковых ботов и асинхронные операции с заведомо долгим p99. Любое движение сервиса в таком SLO размывается техническим шумом: он не нарушается никогда и не сжигает ни минуты бюджета. Знаменатель решает, про что вообще этот SLO, и без фильтрации чужого трафика получается индикатор, который либо не нарушается вовсе, либо горит постоянно. Лекарство — явно выписать, что считается валидным событием, и раз в квартал проверять, не уехало ли это определение.

Алерты на SLO не отменяют короткий список пороговых. Burn rate считается из потока событий. Там, где потока нет, он бессилен, и таких мест три. Первое — то, что скоро закончится: диск, квота, срок сертификата. В шестой главе SRE Book про причины сказано, что беспокоиться стоит только об очень определённых и очень близких, и там же в сноске к близким отнесены «почти заполненные» части сервиса и работа без резерва. Второе — сам мониторинг. Если алертинг упал, алерт на SLO промолчит вместе с ним. Поэтому в kube-prometheus есть алерт Watchdog, который горит всегда, а тревогу поднимает внешняя система, когда он гаснет. Третье — состояния без доли: кворум либо есть, либо потерян. Рекомендации Prometheus первые два случая называют отдельными строками, capacity и metamonitoring. Список полезно держать записанным и коротким, а каждое новое пороговое правило встречать вопросом, почему его нельзя выразить через SLI.

И последнее: burn rate отвечает на один вопрос из трёх. Он говорит, как быстро горит бюджет. Будить ли человека, решают ещё два входа: контур и класс критичности сервиса. С контуром просто. Тестовые окружения не будят никогда, и в шестой главе SRE Book к каждому новому правилу положен вопрос, не отфильтровать ли из него тестовые развёртывания и узлы, с которых снят трафик. С критичностью тоньше. В Workbook типы запросов разложены по пяти классам, от CRITICAL до NO_SLO, чтобы не вести отдельную цель на каждый тип. В Dodo к тому же пришли с другой стороны: одинаковые алерты для создания заказов и для внутренних отчётов оказались плохой идеей, и сервисы сгруппировали по критичности. Для маршрутизации вывод один. Множитель 14.4 на приёме заказов и тот же множитель на внутреннем отчёте ведут в разные каналы, и держится это в метках алерта, по которым собирается маршрут, а не в памяти дежурного.

Связанные листья

SLO Engineering — предусловие: алертинг на SLI невозможен, пока сами SLI и SLO не определены.
Error Budget Burn Rate (TBD) — техническая база расчёта скорости сжигания, из неё и собираются правила алертинга.
Alert Fatigue Management — соседняя тема: алерты на SLI — основной инструмент борьбы с усталостью от алертов, но не единственный.
Runbooks — обязательная привязка: алерт без runbook не проходит ревью.
SLO / Budget Review — потребитель: ритуал ревью опирается на данные, накопленные SLO-based алертами.
Symptom vs Cause Alerting — как алерт устроен — здесь; на что именно алертить (симптом, не причина) — там. Читать вместе.

Открытые вопросы

Хорошего ответа на вопрос «как алертить пакетную обработку и конвейеры данных, где пользовательский SLI толком не определён», у меня нет. RED-метрики сделаны под онлайн-сервисы. Для пакетной обработки набор другой — свежесть данных, пропускная способность, корректность, — но как считать скорость сжигания по свежести, когда нагрузка нерегулярная, я в публичной литературе консенсуса не видел. Нижняя планка в публичных источниках есть, и она пороговая. Рекомендации Prometheus советуют будить, когда пакетное задание давно не завершалось успешно, и закладывать в порог не меньше двух полных прогонов. Это ответ на вопрос «когда будить», а про бюджет там ни слова. Если у вас есть работающий опыт, расскажите через PR.