---
title: SLI, SLO и SLA
description: Как измерить уровень сервиса с точки зрения пользователя, задать цель надёжности и отличить её от договорных обязательств.
---

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

| Термин | Что означает | Пример |
|---|---|---|
| **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 и память полезны для диагностики, но сами по себе не показывают, получает ли пользователь нужный результат.

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

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

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

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

## Как задать SLO

1. Выберите один-два критичных пользовательских сценария.
2. Соберите текущие значения SLI за репрезентативный период.
3. Уточните ожидания пользователей и бизнес-последствия деградации.
4. Задайте достижимую цель и окно оценки, например 30 дней.
5. Определите действия при отклонении через [бюджет ошибок](https://wpcraft.ru/kb/infrastructure/sre/error-budgets.md).

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

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

## Когда нужен SLA

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

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

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

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

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

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

- [Prometheus](https://wpcraft.ru/kb/infrastructure/tools/prometheus.md) — расчёт SLI по метрикам и SLO-based alerting.
- [Grafana](https://wpcraft.ru/kb/infrastructure/tools/grafana.md) — дашборды целей и бюджетов.
- [Better Stack](https://wpcraft.ru/kb/infrastructure/tools/better-stack.md) — внешние проверки, телеметрия и отслеживание SLO.

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

- [Бюджеты ошибок](https://wpcraft.ru/kb/infrastructure/sre/error-budgets.md) — допустимое отклонение от SLO.
- [Real User Monitoring](https://wpcraft.ru/kb/infrastructure/observability/real-user-monitoring.md) — пользовательский срез задержки и ошибок.
- [Uptime monitoring](https://wpcraft.ru/kb/infrastructure/observability/uptime-monitoring.md) — синтетические проверки доступности.
- [Метрики DevOps и инфраструктуры](https://wpcraft.ru/kb/processes/kpi/devops-infra.md) — процессное использование показателей.

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

- [Google SRE: Service Level Objectives](https://sre.google/sre-book/service-level-objectives/) — определения SLI/SLO/SLA и выбор индикаторов.
- [OpenTelemetry: Observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) — SLI с точки зрения пользователя и связь с надёжностью.