Что такое 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 и уточняйте юридические исключения и процедуру расчёта компенсаций.