SLO Engineering

«99.9% потому что круто» — типичная цель по SLO, которую я регулярно вижу. Каждая следующая девятка стоит на порядок дороже: переход 99% → 99.9% → 99.99% меняет и стоимость инфраструктуры, и требования к команде, и частоту, с которой люди просыпаются ночью. Без обоснования через боль пользователя это просто магическое число. Защищать его на ревью бюджета никто не станет. Этот лист про инженерную сторону: как из бизнес-сигнала вывести SLI, как сформулировать SLO, как всё это инструментировать. Не путать с SLO / Budget Review (ритуал ревью) и SLI-based Alerting (алерты поверх SLO).

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

Главный навык на уровне L4 — записывать SLI как отношение good events / valid events и обосновывать выбор знаменателя. Знаменатель решает, про что SLO; неаккуратный знаменатель, куда попали проверки живости, боты и внутренние пробы мониторинга, делает SLO бессмысленным. Я регулярно вижу команды, которые часами обсуждают числитель и решают судьбу знаменателя за пять минут. Порядок перевёрнут.

Различает SLI / SLO / SLA. Читает чужие SLO-описания и понимает, что они формализуют.
Читает существующие SLO своей команды; в инциденте может сказать, какие SLO под угрозой и сколько бюджета осталось.

Записывает SLI как отношение good events / valid events. Обосновывает выбор знаменателя в SLO-документе сервиса.
Определяет простой SLO для одного сервиса — по доступности, по задержке или по обоим сразу; выбирает окно — скользящие 28 дней или календарный месяц — и обосновывает выбор.

Проектирует набор SLI для сервиса: для онлайн-сервиса — RED (поток, ошибки, длительность); для пакетной обработки — свежесть данных, пропускная способность, корректность; для пользовательского сценария — составной индикатор по всему пути.
Инструментирует сервис: где возможно — со стороны клиента (синтетика, телеметрия из браузеров), на сервере — через клиент Prometheus или SDK OpenTelemetry; пишет правила агрегации (recording rules) по разным окнам.
Декомпозирует составной запрос на компонентные SLI и понимает, какой SLI ловит какую часть деградации.

L6+

Внедряет инфраструктуру SLO в команде: правила агрегации, дашборды скорости сжигания, расчёт бюджета ошибок как код (Sloth, Pyrra, Nobl9), записанная политика бюджета.
Согласует цель с ожиданиями бизнеса: 99.99% против 99.9% — это разница в деньгах; обосновывает выбор через боль пользователя и стоимость, а не «99.9%, потому что круто».

Разговор про цель идёт в процентах, а живёт команда в минутах. Перевод одного в другое стоит держать под рукой — допустимое время простоя для каждой девятки:

Доступность	Простой в год	Простой в месяц (30 суток)	Простой в неделю
90%	36.5 суток	72 часа	16.8 часа
99%	3.65 суток	7.2 часа	1.68 часа
99.9%	8.76 часа	43.2 минуты	10.1 минуты
99.99%	52.6 минуты	4.32 минуты	1.01 минуты
99.999%	5.26 минуты	25.9 секунды	6.05 секунды
99.9999%	31.5 секунды	2.59 секунды	0.6 секунды

Таблица посчитана для календарных окон: год — 365 суток, месяц — 30. Если SLO записан на скользящем окне в 28 дней, а так чаще и бывает,, бюджет примерно на 7% меньше месячного из таблицы: для 99.9% это 40.3 минуты вместо 43.2. Считать нужно в том окне, в котором записан SLO, иначе burn rate на дашборде и цифра в SLO-документе разойдутся.

Практический смысл этих чисел виден на границе 99.99%: месячный бюджет — 4.32 минуты, а типичный путь «алерт → дежурный проснулся → понял → откатил» занимает больше. То есть цель выше трёх девяток — это уже не про дисциплину дежурных, а про автоматический failover и rollback без человека в цикле. Я регулярно вижу, как команда соглашается на 99.99% в SLA с клиентом, не имея ни того, ни другого.

Материалы

Книги

Alex Hidalgo — Implementing Service Level Objectives (O’Reilly, 2020). Рекомендую как главный практический источник: главы с первой по шестую ведут от определения SLI до расчёта бюджета ошибок.
Betsy Beyer et al. — The Site Reliability Workbook (O’Reilly, 2018), глава 2 «Implementing SLOs». Тоже рекомендую: канонический подход Google, короче и суше Идальго.
Betsy Beyer et al. — Site Reliability Engineering (O’Reilly, 2016), глава 4 «Service Level Objectives». Рекомендую как фундамент: база терминологии и модели, на которых стоит всё остальное. За устройством практики идти не сюда.

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

Betsy Beyer et al. — Alerting on SLOs (SRE Workbook, гл. 5). Связь инженерной части SLO со стратегией алертинга. Рекомендую прочитать до того, как настраивать алерты, иначе они встают на метрики, а не на бюджет.
Betsy Beyer et al. — Appendix B. Example Error Budget Policy (SRE Workbook). Готовый шаблон Error Budget Policy. Рекомендую начинать с него, а не писать политику с нуля.
Štěpán Davidovič — Measuring Reliability: What Got Us Here Won’t Get Us There (SREcon22 EMEA). Про то, где привычный способ измерять надёжность перестаёт работать. Сам не смотрел; в списке доклад стоит как единственный источник, который с остальными спорит, а не достраивает их.
Мой разбор — SLO как чертёж архитектуры (jtprog.ru, май 2026). Прохожу цепочку целиком на одном кейсе поиска в маркетплейсе: функциональные требования → критичный пользовательский путь → шаги пути → SLI → SLO → бюджет ошибок. Источники выше начинают сразу с индикатора; здесь начало на шаг раньше, потому что, по моим наблюдениям, спорят в командах про сценарий, а не про формулу. Отдельным разделом — что в SLI брать нельзя.

Инструменты

Prometheus — recording rules для SLI, правила алертинга для скорости сжигания. Канонический стек, рекомендую начинать с него: остальное в этом ряду так или иначе описывает то же самое.
Sloth — генератор PromQL для SLO и burn-rate алертов из декларативного YAML. По моим наблюдениям, чаще выбирают в командах от 5+ сервисов.
Pyrra — открытая платформа управления SLO поверх Prometheus: дашборд бюджета ошибок, многооконные алерты, оператор для Kubernetes.
OpenSLO — независимая от вендоров спецификация SLO в YAML; утилита oslo проверяет их прямо в конвейере. Рекомендую как формат описания, даже если платформа потом сменится.
Nobl9 — коммерческая платформа поверх любого мониторинга. Сам не работал; коллеги рекомендуют её там, где SLO надо держать в едином виде сразу по многим командам.

Best practices

Начну с того, что чаще всего ломает SLO ещё до первого дашборда: знаменатель важнее числителя. Good events обсуждают часами, valid events не обсуждает никто. Не отфильтруешь ботов, проверки живости, заведомо кривых клиентов и операции в окне обслуживания — получишь SLO, который либо не нарушается никогда, потому что технический шум разбавляет любую деградацию, либо нарушается постоянно, потому что в знаменатель попал трафик, за который ваш сервис вообще не отвечает. Ревью по такому индикатору бессмысленно в обоих случаях.

Второе — начинать с одного SLI на один сервис. Заход «покроем всё сразу, пятьдесят индикаторов на пятьдесят ручек» заканчивается тем, что в них никто не разбирается, а ревью превращается в чтение портянок. Запустите один корректный SLI, проведите его через первый SLO Review, отшлифуйте процесс. Потом расширяйте.

Третье касается самого числа. Цель выводится из боли пользователя, а не из красоты цифры: при каком уровне SLI человек начинает жаловаться, уходить или терять деньги — это и есть ваше число. Каждая девятка сверху стоит на порядок дороже, и платить эту цену без ответа на вопрос «кому и когда стало плохо» — чистое расточительство.

SLI считается на стороне клиента, когда это возможно. Одни только серверные метрики ничего не знают про DNS, балансировщик, деградацию сети и сорванное рукопожатие TLS. Синтетические проверки из сторонних регионов и телеметрия с реальных клиентов стоят ближе к пользовательскому опыту, а серверные метрики их дополняют, но не заменяют. Я регулярно вижу команды, у которых серверный SLI зелёный, а NPS едет вниз. Это ровно та слепота, о которой речь.

SLI на пользовательский сценарий, а не на отдельную ручку. Индикатор на каждый HTTP-маршрут нечитаем и о пользовательском опыте говорит мало. Пользователь не знает про ручки, он знает про действие: оплата прошла, поиск работает. Значит, и SLI собирается составным, по всему сценарию — из метрик всех компонентов, через которые проходит запрос от нажатия кнопки до ответа, включая те, что живут в чужих командах и про ваш SLO ничего не знают. Делать это сложнее. Зато это единственный способ разговаривать про SLO с продуктовой командой на одном языке.

С составным SLO осторожнее: формула не очевидна. Записать «SLO — это произведение компонентных SLO» в лоб — антипаттерн. Настоящая формула зависит от того, последовательно или параллельно используются компоненты, насколько они коррелированы и есть ли между ними повторы. Считается такое либо симуляцией, либо явным разбором зависимостей. Услышали в команде «давай просто перемножим» — копайте глубже.

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

SLI-based Alerting — алертинг строится поверх SLO Engineering; качество алертов прямо зависит от качества SLI.
SLO / Budget Review — ритуал, потребляющий данные SLO Engineering; без работающего ритуала SLO остаются техническим артефактом.
Networking — большинство SLI строятся на сетевых метриках (latency, error rate, DNS); знание сетевого стека определяет, что вообще можно измерить корректно.
Programming Languages — инструментирование SLI требует кода в сервисе (Prometheus client, OpenTelemetry SDK).
Capacity Planning — capacity planning опирается на SLO как на целевой уровень надёжности.
Vendor Reliability — SLA поставщиков задают нижнюю границу: без явного резервирования собственный SLO не выше произведения их обязательств на вашу собственную надёжность.
Symptom vs Cause Alerting — SLI на симптом — то, по чему будят дежурного; метрики причин остаются диагностическим контекстом.
Composite SLO Methodology — здесь про то, как формулировать SLO одного компонента, там — как складывать их для системы из многих. Читать вместе.

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

Измерения на живом трафике против синтетических проверок — когда какое, в какой комбинации и как не оставить дыр между ними. Разложить это по полочкам я пока не могу.

Второе наблюдение из практики: после первой настройки формулировки SLI в командах остаются неряшливыми, вроде «≥ 99% requests success». Без ответа на «что такое request», «что такое success» и «в каком окне» это не SLI, а слоган. Хороший SLI читается как count(http_requests{status!~"5.."} | window_5m) / count(http_requests{is_synthetic="false"} | window_5m) > 0.999. Если в команде нет такой строгости — стоит обсудить, как её внедрить.