Сообщить об ошибкеКороткий ответ
SLI (Service Level Indicator) — измеримый показатель качества (например, доля успешных запросов); SLO (Service Level Objective) — внутренняя цель по этому показателю (например, "99.9% запросов успешны за 30 дней"); SLA (Service Level Agreement) — формальное соглашение с внешней стороной, обычно включающее последствия (компенсацию) за невыполнение.
Как это работает подробнее
сначала выбирают SLI — конкретную метрику, которая отражает опыт пользователя (latency, доля ошибок, доступность). Затем на основе SLI формулируют SLO — целевой порог, который команда обязуется поддерживать внутри себя. SLA обычно шире и формальнее: это договор с клиентом, часто с санкциями (возврат денег, кредиты) при невыполнении, и SLA-порог обычно мягче внутреннего SLO, чтобы оставался запас.
Пример кода
example.txt
SLI: доля HTTP-ответов со статусом < 500 от всех запросов за 5 минут
SLO: 99.9% успешных запросов за скользящие 30 дней (внутренняя цель команды)
SLA: 99.5% успешных запросов за месяц, иначе клиенту возвращается 10% оплаты (договор)Что использовать на практике
- Практика. команды используют SLO для принятия решений — например, если error budget (допустимый остаток "неудачи" по SLO) истрачен, замораживают рискованные релизы и фокусируются на надёжности. SLA — это то, что видит клиент или юридический отдел, и нарушение SLA обычно имеет финансовые последствия, поэтому внутренний SLO почти всегда строже, чем SLA.
- Практика. Видно, что SLO (99.9%) строже SLA (99.5%) — это специально оставленный запас ("буфер"), чтобы кратковременное ухудшение не сразу приводило к нарушению договора с клиентом.
Подводные камни
- Частые ошибки. использовать термины как синонимы, говоря "у нас SLA 99.9%" про внутреннюю цель команды без договора с клиентом; выбирать SLI, который не отражает реальный пользовательский опыт (например, мониторить только доступность backend, игнорируя latency или ошибки на фронтенде); ставить SLO=100%, что технически недостижимо и не оставляет пространства для безопасных релизов.