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

SLI - Service Level Indicator

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

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

У хорошего SLI есть три ключевых свойства:

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

SLO - Service Level Objective

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

Примеры:

• «99,9 % запросов на /api/orders должны заканчиваться HTTP 2xx за 30 дней»
• «95 % запросов должны иметь время отклика меньше 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: SLO 99,9 % означает 43 мин downtime в месяц. SLA даёт ещё больший запас перед экономическим наказанием.

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

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

• Слишком амбициозный 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.

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