Что такое SLA, SLO и SLI?

SLA, SLO, SLI — что это и как между ними соотносится

SLI (Service Level Indicator) — это конкретная метрика, которая измеряет поведение сервиса. Проще — это то, что вы считаете. Примеры SLI:

  • Доступность (availability): доля успешных HTTP-ответов (2xx) от общего числа запросов.

  • Задержка (latency): процент запросов, уложившихся в порог (p95 < 200 ms или 99% запросов < 500 ms).

  • Ошибка (error rate): доля ошибок (5xx) от общего числа запросов.

  • Пропускная способность (throughput): запросы/сек, обработанные без таймаута.
    Формулы:
    SLI (availability, по времени) = (время, когда сервис в порядке) / (общее время наблюдения).
    SLI (по запросам) = (число успешных запросов) / (общее число запросов).

Пример (по запросам): всего 10 000 запросов, 9 995 успешных → SLI = 9 995 / 10 000 = 0.9995 = 99.95%.

SLO (Service Level Objective) — целевой уровень для одного или нескольких SLI. Это внутренний или публичный (но не юридический) KPI: команда говорит «наш SLO — 99.9% доступности за 30-дневный период». SLO задаёт целевой порог, по которому оценивается успех/неуспех операционной деятельности. Из SLO прямо вытекает error budget = 1 − SLO — «сколько ошибок нам разрешено». Error budget используют, чтобы балансировать скорость релизов и стабильность: если бюджет исчерпан — приоритет у стабилизации, если не исчерпан — можно рисковать ради фич.

Пример расчёта error budget в времени (30 дней = 30×24×60 = 43 200 минут):
SLO = 99.9% → error budget = 0.1% = 0.001 → допустимое время простоя = 0.001 × 43 200 = 43.2 минуты (43 мин 12 сек).

Небольшая таблица-памятка (30-дневный период):

  • 99% → 432 мин простоя (7 ч 12 мин).

  • 99.9% → 43.2 мин (43 мин 12 с).

  • 99.95% → 21.6 мин (21 мин 36 с).

  • 99.99% → 4.32 мин (4 мин 19 с).

SLA (Service Level Agreement) — это договор (обычно юридический) между поставщиком сервиса и клиентом, где прописаны минимальные обязательные уровни сервиса и последствия их нарушения (штрафы, кредиты, компенсации). SLA опирается на SLO/SLI (обычно SLA ссылается на конкретные SLO), но в SLA добавляют:

  • юридические условия (штрафные санкции, исключения — force majeure),

  • способ и окно измерения (как и кто считает SLI),

  • процедуры уведомления и требования по отчётности,

  • соглашения по возмещению при нарушении.

Ключевые отличия SLI / SLO / SLA

  • SLI — это метрика (что измеряем).

  • SLO — это цель/порог для этой метрики (внутреннее соглашение/цель команды).

  • SLA — это контракт с формальной ответственностью и штрафами.

Практика и подводные камни

  • Выбирайте правильные SLIs (те, что действительно важны для пользователей: доступность, задержка, корректность данных), а не «все метрики подряд».

  • Окно измерения: rolling window (скользящее, напр. последние 30 дней) vs calendar window (календарный месяц). Разные окна дают разные результаты.

  • Гранулярность: считать SLI по минутам/секундам/запросам — важно задать точную методику и учесть выбросы.

  • Сложные составные сервисы: при композиции нескольких сервисов нужно аккуратно агрегировать SLIs (взвешивание, формулы для зависимых сервисов), иначе итоговый SLI будет вводить в заблуждение.

  • Игры с метриками: нельзя «подгонять» измерение (например, исключать тестовые запросы без обоснования) — метрика должна быть воспроизводимой и документированной.

  • Слишком жесткие SLO могут дорого обходиться (в больших затратах на резервирование/избыточность). Слишком мягкие — ухудшают UX.

Лучшие практики

  • Формализуйте методику измерения SLI (источники данных, фильтры, агрегации).

  • Устанавливайте SLO совместно с продуктовой командой и бизнес-стейкхолдерами.

  • Внедряйте error budget и реагирование на его «сгорание».

  • Мониторьте и алертьте не только на нарушение SLO, но и на скорость «сжигания» error budget.

  • Документируйте SLA отдельно от SLO и уточняйте юридические исключения и процедуру расчёта компенсаций.