SLI, SLO и error budget: практическое руководство для IT-сервисов

SLI показывает фактическое качество сервиса, SLO задаёт целевой уровень, а бюджет ошибок превращает разницу между 100% и целью в управляемый запас риска. Вместе они помогают обсуждать надёжность через пользовательский результат, а не через количество серверов и зелёных индикаторов.

Цель «сервис должен работать всегда» не задаёт приоритетов. Она не объясняет, сколько инвестировать в резервирование, когда остановить релизы и какое ухудшение действительно замечает клиент.

Термины без путаницы

SLI, Service Level Indicator — измеряемый показатель качества: успешность запросов, задержка, свежесть данных, полнота обработки.
SLO, Service Level Objective — целевое значение SLI за окно времени.
SLA, Service Level Agreement — внешнее или внутреннее соглашение с обязательствами и последствиями.
Error budget — допустимая доля плохих событий внутри окна SLO.

Пример: SLO 99,9% успешных операций за 30 дней допускает 0,1% неуспешных. Но считать минуты простоя корректно только для непрерывно доступного сервиса. Для API и очередей точнее считать хорошие и общие события.

Начните с пользовательского пути

Мониторинг инфраструктуры отвечает, жив ли компонент. SLI должен отвечать, получил ли пользователь нужный результат.

Для интернет-магазина путь «оформить заказ» может включать:

создание корзины;
расчёт доставки;
подтверждение оплаты;
сохранение заказа;
отправку уведомления.

Показатель CPU базы данных не заменяет успешность этого пути. Сервер может быть загружен, но справляться; либо выглядеть здоровым, когда внешняя интеграция уже ломает оформление.

Какие SLI выбрать

Доступность

Доля валидных запросов, завершившихся ожидаемым результатом:

availability = good requests / valid requests

Исключения из знаменателя должны быть определены заранее. Ошибка клиента из-за некорректного запроса может не нарушать SLO, но ответ 401 из-за сбоя identity-провайдера — нарушает.

Задержка

Доля операций быстрее порога:

latency SLI = requests faster than 500 ms / valid requests

Среднее значение скрывает хвост. Используйте долю событий в пределах порога и дополнительные P95/P99 для диагностики.

Свежесть

Для отчёта или реплики важно, насколько данные отстают от источника:

freshness = records updated within 10 min / expected records

Полнота

Для пакетной обработки:

completeness = processed valid records / received valid records

Успешный HTTP-ответ загрузчика не доказывает, что все записи дошли до потребителя.

Корректность

Для уведомлений важно не только принять сообщение, но и получить терминальный статус без дубля. Архитектура потока описана в статье об омниканальных транзакционных уведомлениях.

Хорошее событие должно быть определено явно

Описание SLI должно включать:

источник данных;
событие и единицу измерения;
критерий good;
знаменатель;
исключения;
окно;
допустимую задержку данных;
владельца;
способ проверки.

Если две команды вычисляют «доступность» по-разному, это два разных SLI.

Как выбрать первое SLO

Не копируйте 99,99% из рекламы провайдера. Начните с:

ожиданий пользователей и договоров;
исторического качества;
зависимости от нижележащих сервисов;
стоимости улучшения;
способности команды реагировать.

Первое SLO должно быть достижимым при нормальной работе и достаточно строгим, чтобы отражать реальную боль пользователя. Если текущая успешность 97,4%, цель 99,99% без плана создаст постоянное нарушение и перестанет влиять на решения.

Google SRE рекомендует согласовать SLO со стейкхолдерами и закрепить, как бюджет ошибок влияет на приоритеты. Без этого SLO остаётся ещё одним KPI на дашборде.

Расчёт бюджета ошибок

Для SLO 99,9%:

error budget = 1 - 0.999 = 0.001

При 10 миллионах валидных операций за 30 дней допустимо 10 000 плохих событий.

Если измерение действительно основано на времени, приблизительный бюджет для 30 дней:

SLO	Допустимая недоступность
99%	7 ч 12 мин
99,9%	43 мин 12 с
99,95%	21 мин 36 с
99,99%	4 мин 19 с

Эта таблица не учитывает распределение трафика. Пять минут в пик могут повредить большему числу операций, чем час ночью, поэтому событийная модель обычно полезнее.

Burn rate: насколько быстро расходуется бюджет

Burn rate 1 означает, что бюджет расходуется ровно с допустимой скоростью. Burn rate 10 — в десять раз быстрее; при сохранении такого темпа месячный запас закончится примерно за три дня.

Алерт только по факту полного исчерпания опаздывает. Используйте несколько окон:

короткое окно ловит резкое ухудшение;
длинное подтверждает устойчивость проблемы;
разные пороги отделяют аварии от медленного дрейфа.

Например, сочетание высокого burn rate за один час и подтверждения за пять минут выявляет крупный инцидент, а умеренный burn rate за шесть часов и тридцать минут — длительную деградацию.

Алерт должен вести к действию

Каждый SLO-алерт должен содержать:

затронутый пользовательский путь;
текущий SLI и burn rate;
начальное время;
ссылку на дашборд;
последние изменения;
runbook;
владельца эскалации.

Не создавайте алерт на каждую метрику. CPU, очередь и число соединений — полезные диагностические сигналы, но будить дежурного стоит при угрозе пользователю или быстром расходе бюджета.

Политика бюджета ошибок

Заранее договоритесь, что происходит при разных состояниях.

Состояние	Решение
Бюджет здоров	Обычный темп изменений
Расход ускорен	Усиленный review и ограничение рискованных релизов
Бюджет почти исчерпан	Приоритет надёжности и исправлений
Бюджет исчерпан	Остановка необязательных изменений до восстановления контроля

Исключения допустимы, но должны иметь владельца, обоснование и срок. Иначе политика не работает.

Составные сервисы

SLO компонента не нужно механически перемножать и выдавать за SLO пользовательского пути. Зависимости могут работать параллельно, иметь кеш, fallback или использоваться только частью запросов.

Измеряйте путь снаружи, а компонентные SLO используйте для договорённостей между командами. Для внешнего провайдера уточните:

что именно считается доступностью;
какие исключения есть;
где проходит граница ответственности;
как подтверждается инцидент;
покрывает ли SLA ваш пользовательский SLO.

Материал о IaaS и собственном дата-центре разбирает распределение ответственности подробнее.

SLO для очередей и фоновых процессов

Очередь может принимать сообщения, но обрабатывать их слишком поздно. Используйте:

долю событий, завершённых до deadline;
возраст старейшего допустимого сообщения;
полноту за окно;
число дублей;
долю permanent failures;
время до согласованного бизнес-результата.

После восстановления не отправляйте просроченное действие автоматически, если оно потеряло смысл. TTL и политика устаревших сообщений должны быть частью контракта.

Отчёт без самообмана

Еженедельный или месячный review отвечает:

Какой пользовательский путь нарушался?
Сколько бюджета потрачено и чем?
Какие изменения дали наибольший вклад?
Были ли периоды, когда SLI не измерялся?
Какие действия предотвращают повтор?
Нужно ли изменить SLO или измерение?

Не улучшайте отчёт исключением неудобных ошибок задним числом. Изменение определения применяется вперёд и документируется.

План внедрения

Неделя 1: один путь

Выберите критичный пользовательский сценарий и владельца. Опишите хорошие и общие события.

Неделя 2: качество данных

Сравните телеметрию с журналами и обращениями поддержки. Проверьте пропуски и задержку метрик.

Неделя 3: стартовое SLO

Возьмите исторический уровень, обсудите ожидания и установите цель на четыре недели.

Неделя 4: алерты и политика

Настройте burn-rate алерты, runbook и решения при расходе бюджета.

Через один-два окна пересмотрите порог на основании данных. SLO — управляемая гипотеза о нужной надёжности, а не вечное число.

Чек-лист

SLI описывает результат пользователя.
Good и total события определены однозначно.
Источник данных и его задержка известны.
SLO согласован продуктом, эксплуатацией и бизнесом.
Бюджет ошибок рассчитан на явное окно.
Алерты используют burn rate и несколько окон.
У каждого алерта есть действие и runbook.
Политика влияет на релизы и приоритеты.
Компонентные метрики не подменяют пользовательский путь.
Определение пересматривается только прозрачно.

Вывод

SLI, SLO и бюджет ошибок создают общий язык для бизнеса и инженеров. Начните с одного пользовательского пути, измеряйте хорошие события, согласуйте реалистичную цель и заранее определите решения при быстром расходе бюджета.

Практический первоисточник: глава Implementing SLOs в Google SRE Workbook. Для связи с восстановлением используйте Disaster Recovery Plan, а для построения данных — руководство по наблюдаемости.

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

SLI, SLO и бюджет ошибок: как измерять надёжность сервиса