SLI, SLO и SLA

Три уровня договорённости

Термин	Что означает	Пример
SLI — Service Level Indicator	Измеряемый показатель поведения сервиса	Доля успешных оформлений заказа за пять минут
SLO — Service Level Objective	Целевое значение или диапазон SLI за выбранный период	Не менее 99,9% успешных оформлений за 30 дней
SLA — Service Level Agreement	Соглашение с пользователями, включающее последствия нарушения	При доступности ниже обещанной предусмотрена компенсация

SLI отвечает «что измеряем», SLO — «какого результата хотим», SLA — «что будет при невыполнении обязательства». Если у нарушения нет определённых последствий, перед нами обычно SLO, а не SLA.

Хороший SLI начинается с пользователя

Индикатор должен описывать значимый результат, а не просто доступность телеметрии. Ответ 200 на главной странице ещё не означает, что пользователь может войти в кабинет или оплатить заказ.

Типовые SLI:

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

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

Формула и окно

Availability SLI = успешные учитываемые запросы / все учитываемые запросы × 100%

Заранее определите, какие запросы входят в расчёт, как классифицируются ошибки клиента, таймауты, плановые работы и пропущенные замеры. Отсутствие данных нельзя автоматически считать успешным периодом.

Для задержки используют распределение: p95 = 420 мс означает, что 95% запросов завершились за 420 мс или быстрее. Среднее может скрывать медленный хвост.

Как задать SLO

Выберите один-два критичных пользовательских сценария.
Соберите текущие значения SLI за репрезентативный период.
Уточните ожидания пользователей и бизнес-последствия деградации.
Задайте достижимую цель и окно оценки, например 30 дней.
Определите действия при отклонении через бюджет ошибок.

При SLO доступности 99,9% за 30 дней допустимая недоступность во временной модели — 43,2 минуты. Если SLI считается по запросам, бюджет рассчитывают в запросах, а не переводят в минуты.

Цель 100% обычно не нужна: она резко повышает стоимость, а проблемы устройства, сети или браузера пользователя всё равно остаются вне контроля сервиса.

Когда нужен SLA

SLA связывает измерения с коммерческими или организационными последствиями. Для него необходимо дополнительно зафиксировать:

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

Не обещайте клиенту более строгий SLA, чем позволяют зависимости и фактическая архитектура.

Типовые ошибки

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

Связанные инструменты

Prometheus — расчёт SLI по метрикам и SLO-based alerting.
Grafana — дашборды целей и бюджетов.
Better Stack — внешние проверки, телеметрия и отслеживание SLO.

Связанные материалы

Бюджеты ошибок — допустимое отклонение от SLO.
Real User Monitoring — пользовательский срез задержки и ошибок.
Uptime monitoring — синтетические проверки доступности.
Метрики DevOps и инфраструктуры — процессное использование показателей.

Материалы и источники

Google SRE: Service Level Objectives — определения SLI/SLO/SLA и выбор индикаторов.
OpenTelemetry: Observability primer — SLI с точки зрения пользователя и связь с надёжностью.