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 и обосновывает выбор знаменателя (что считать «валидным» событием).
Настраивает простейший пороговый алерт на бюджет ошибок и понимает его ограничения: много ложных срабатываний, позднее обнаружение.

Проектирует multi-window multi-burn-rate алерт по схеме из SRE Workbook гл. 5: подбирает окна и пороги под нужную чувствительность: что будит дежурного, а что уходит тикетом.
Разделяет потоки «срочно разбудить» и «разобраться в рабочее время» через разные 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, времени обнаружения и времени сброса, и там же лежат готовые параметры окон для 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). Про пределы существующего подхода к измерению надёжности. Сам не смотрел; доклад в списке как единственный, который с остальными спорит, а не достраивает их.
Grafana — How to alert on SLOs. Рекомендую как практическое дополнение к главе выше: конкретные PromQL, которые можно взять и проверить у себя.
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 99.9% и месячного окна; для других SLO они другие. Если вы переписываете под себя — пересчитайте, не копируйте.

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

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

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

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-метрики сделаны под онлайн-сервисы. Для пакетной обработки набор другой — свежесть данных, пропускная способность, корректность, — но как считать скорость сжигания по свежести, когда нагрузка нерегулярная, я в публичной литературе консенсуса не видел. Если у вас есть работающий опыт, расскажите через PR.