SLI-based Alerting

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

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

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

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

Записывает SLI как отношение good events / valid events и обосновывает выбор знаменателя (что считать «валидным» событием).
Настраивает простейший порог-алерт на бюджет ошибок и понимает его ограничения (high false-positive rate, поздняя детекция).

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

L6+

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

Материалы

Книги

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 для пяти стратегий алертинга — единственное место в публичной литературе, где конкретные числа precision указаны явно.
Alex Hidalgo — Implementing Service Level Objectives (O’Reilly, 2020). По моему ощущению, дополняет SRE Workbook, не заменяет: главное — глубина по composite SLO и user journey’ам, чего нет в Workbook.

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

Google SRE — Alerting on SLOs. То же, что в Workbook гл. 5, но онлайн и бесплатно.
Štěpán Davidovič, Betsy Beyer — Reliable Alerting in the Cloud (SREcon). Короткий обзор; хорошо для slides внутри команды.
Grafana — How to alert on SLOs. Практично, с конкретными PromQL.
Liz Fong-Jones — Why Are My Pages Going Off? SLO-Based Alerting Strategies (SREcon). Продвинуто; сильный доклад от практика, который этим занимается на работе.

Курсы

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

Инструменты

Prometheus + Alertmanager — каноничный стек для recording rule SLI и alerting rule burn-rate. Если у вас k8s — выбор по умолчанию.
VictoriaMetrics + vmalert — альтернатива Prometheus для высоконагруженных сценариев; совместимый язык правил.
Grafana Alerting — UI-ориентированная альтернатива Alertmanager; удобна для команд, живущих в Grafana, неудобна для GitOps-flow.
Sloth — генератор PromQL для SLO и burn-rate алертов из декларативного YAML. По моим наблюдениям, его чаще берут команды от 5+ сервисов: вручную написать корректные multi-window правила тяжелее, чем кажется, и Sloth убирает целую категорию ошибок (опечатки в формуле, забытые окна, неконсистентные шаги).
Pyrra — open-source альтернатива Nobl9, k8s-native, с встроенным dashboard error budget. Я вижу, что её берут как stepping-stone, когда Sloth уже маловат, а Nobl9 ещё рано.
Nobl9 — коммерческая платформа. Имеет смысл, когда SLO ведут несколько команд в разных регионах и нужен общий язык / портал. Для одной команды — overkill.

Best practices

Глава 5 SRE Workbook содержит сравнительную таблицу пяти стратегий алертинга по precision и recall на одном 30-дневном окне. Простой порог (target × threshold) даёт precision 5% — то есть 95% поднятых алертов false. Multi-window multi-burn-rate с двумя окнами (короткое + длинное) даёт precision 67%, recall 94%. Разница не «чуть лучше» — разница в порядок величины меньше шума. Это единственное место в публичной литературе, где precision указан явно с числами; если вы пишете алерт и не помните своё precision — это первое число, которое нужно посчитать.

Что работает (короткие правила):

Алертим на симптом, а не на причину. Антипаттерн: алерт CPU > 80%. Симптом — то, что заметил пользователь («сервис вернул ошибку», «запрос идёт 500 ms»). Причин может быть много, симптомов мало; алерт на симптом переживёт смену реализации, переезд в другой кластер, замену БД. Алерт на причину через полгода или ловит нормальную работу, или молчит в инциденте.
Разные burn rate — разные каналы доставки. Быстрый ожог (например, 14.4× за 1 час) → пейджер. Медленный (1× за 3 дня) → тикет, разбор в рабочее время. Один канал для срочного и несрочного убивает чувствительность к срочному: дежурный за неделю перестаёт верить пейджеру.
Каждый алерт ведёт к runbook. Алерт без runbook — это «разбуди человека и пусть сам думает в три ночи». Через 6 месяцев такой алерт игнорируется или удаляется молча. Если runbook нет, алерт либо удаляется немедленно, либо в backlog с явным дедлайном на написание.

Что я считаю не менее важным, но менее «правилом» и более выбором:

Multi-window multi-burn-rate — не догма, а решение проблемы false-positive vs late detection. Один порог в принципе не может одновременно быть и точным (низкий false-positive rate), и быстрым (поймать быстрый ожог). Двойное окно решает это арифметически — короткое окно с высоким burn rate ловит быстрые инциденты, длинное с низким burn rate ловит медленные деградации. Беда в том, что выбор конкретных окон и burn rate — нетривиальное упражнение, и почти каждая команда, которую я видел, копирует пример из главы 5 Workbook без понимания, почему там стоят именно эти числа (1h × 14.4 и 6h × 6). Эти числа были выведены для целевого SLO 99.9% и месячного окна; для других SLO они другие. Если вы переписываете под себя — пересчитайте, не копируйте.

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

Знаменатель SLI важнее числителя — и о нём забывают. «Good events» (числитель) команды обсуждают часами; «valid events» (знаменатель) — забывают. Я видел SLO 99.95% запросов вернули 2xx за 200ms, в котором в знаменатель попадали healthcheck-запросы, internal probes из мониторинга, scrap-запросы поисковых ботов и async-операции с известно-долгим p99. В таком SLO любые движения сервиса размываются техническим шумом — он не нарушается ничем и не сжигает ни одной минуты бюджета. Знаменатель решает, про что SLO; не отфильтровав чужой трафик, получаешь SLO, который никогда не нарушается или нарушается всегда. Лекарство — явно выписать, что считается valid event, и регулярно (раз в квартал) проверять, не дрейфует ли определение.

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

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

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

Я не знаю хорошего ответа на «как ставить алерты для batch-сервисов и pipelines, где user-facing SLI плохо определён». RED-метрики (rate / errors / duration) работают для онлайн-сервисов; для batch — freshness / throughput / correctness, но как ставить burn rate на freshness, когда нагрузка по запросам нерегулярная — я в публичной литературе консенсуса не видел. Если у вас есть опыт — расскажите через PR.