SLI vs SLO vs SLA: различия и как их настроить

Кратко: SLI - это что вы измеряете, SLO - это какой цели хотите достичь, SLA - это контрактное обязательство. Эти термины из книги Google SRE - одни из самых используемых словосочетаний в эксплуатации веб-сервисов, и часто их путают.

Кратко: SLI - это что вы измеряете, SLO - это какой цели хотите достичь, SLA - это контрактное обязательство. Эти термины из книги Google SRE - одни из самых используемых словосочетаний в эксплуатации веб-сервисов, и часто их путают.

SLI - Service Level Indicator

Конкретная метрика, которой вы количественно оцениваете надёжность сервиса. Примеры:

% запросов, закончившихся HTTP 2xx или 3xx за последние 30 дней
% запросов с response time менее 500 мс
% правильно доставленных email (delivered, не bounced)
Соотношение успешных платёжных транзакций ко всем попыткам

Ключевые свойства хорошего SLI:

Измеримый - существует конкретный метод сбора данных
Релевантный пользователю - отражает реальный опыт клиента, не внутреннюю техническую метрику
Специфичный - «uptime» слишком расплывчат; «% успешных запросов на /api/v1/orders за 5-минутное окно» - это SLI

SLO - Service Level Objective

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

Примеры:

«99,9 % запросов на /api/orders должны заканчиваться HTTP 2xx за 30 дней»
«95 % запросов должны иметь response time меньше 200 мс за 7 дней»
«99,5 % платёжных транзакций пройдут успешно за календарный месяц»

SLO выше, чем SLA, чтобы у вас был буфер. Если SLA говорит 99,9 %, внутренний SLO должен быть, например, 99,95 % - чтобы был резерв на неожиданные инциденты.

SLA - Service Level Agreement

Контрактное обязательство перед клиентами. Определяет, что произойдёт, если вы не выполните SLO - типично:

Service credits - возвращаете часть месячной платы (10-50% в зависимости от размера нарушения)
Termination rights - клиент может расторгнуть контракт без санкций
Обязанность reporting - должны публиковать postmortem и отчёты uptime

SLA имеет юридические последствия. SLO - внутренняя цель.

Error budget

Ключевая концепция SRE: downtime, который вы можете позволить себе без нарушения SLO.

Пример: SLO = 99,9 % uptime за 30 дней. Это 0,1 % допустимого downtime. 0,1 % от 30 дней = 43 минуты в месяц. Это ваш error budget.

Практические последствия:

Если у вас уже 35 мин downtime в месяце, остаётся 8 мин до «нарушения SLO». Команда должна быть консервативной при следующих деплоях.
Если у вас 5 мин downtime, у вас 38 мин budget на риски - можете делать более агрессивные изменения, A/B тесты, эксперименты.
Error budget решает конфликт между скоростью инновации (dev team) и стабильностью (ops team). Оба следят за одним числом.

Практический пример: API e-commerce

SLI: % HTTP запросов на POST /api/checkout, закончившихся 2xx, измеренные в 1-минутных bucket'ах за последние 30 дней.

SLO: ≥ 99,9 % успешных запросов в rolling 30-day окне.

SLA (для Enterprise клиентов):

≥ 99,5 % uptime за календарный месяц
При 99,0-99,5 % = 10% credit от месячной платы
При 95,0-99,0 % = 25% credit
При < 95,0 % = 50% credit + право расторгнуть контракт

Error budget: 99,9 % SLO означает 43 мин downtime / месяц в budget. SLA даёт ещё больший буфер перед экономическим наказанием.

Сводка: таблица

Термин	Что это	Для кого
SLI	Конкретная метрика надёжности	Engineering команда
SLO	Внутренняя цель для SLI	Engineering + product
SLA	Контрактное обязательство	Клиент + legal
Error budget	Downtime, который можете позволить до нарушения SLO	Engineering risk management

Практические ошибки

Слишком амбициозный SLO. 99,99 % требует active-active redundancy в нескольких регионах. Для маленькой компании нереально.
Только uptime SLO. Web может быть «up» и всё равно непригоден к использованию. Добавьте latency SLO и error rate SLO.
SLA без автоматического измерения. Вручную рассчитанный SLA-отчёт ненадёжен. Инвестируйте в автоматизированный uptime tracking.
SLO без последствий. Если нарушение SLO никого не интересует, никто им не занимается. Свяжите с deploy freeze, on-call escalation и т.д.

Вывод

Framework SLI/SLO/SLA - не бумажная бюрократия, это язык, на котором engineering команда общается с business stakeholders о надёжности. Без этих терминов дискуссия о стабильности становится субъективной («наш веб нестабилен»). С ними - численной («за последние 30 дней мы достигли 99,87 % SLI, что ниже нашего 99,9 % SLO - вот план действий»).

Измеряйте SLI в реальном времени

ePulz.io предоставляет историческую запись uptime с rollup 30/90/365 дней. Основа для SLO reporting.

Запустить мониторинг →