SLO (Service Level Objective)

SLO (Service Level Objective) - это целевые показатели надежности сервиса, которые определяют, какой уровень качества считается приемлемым (например, "99,9% успешных запросов в месяц"). Они нужны, чтобы формализовать ожидания пользователей и команды, а также принимать решения: когда вкладываться в стабильность, а когда — в фичи.

Это соглашение, договоренность, обещание "Наш сервис будет работать не хуже, чем...". SLO — не догма, а инструмент для баланса между надежностью и бизнес-целями.

От SLA отличается тем, что применяется там, где между договорившимися не происходит взаиморасчетов, нет тарифов и штрафных санкций.

SLO служит для оценки качества сервиса с точки зрения пользователей этого сервиса. Смысл в том, что определив SLO для сервиса, мы должны пытаться удерживать наши реальные показатели немного выше, постоянно улучшая наш сервис.

SLO также используется для того, чтобы понимать, как приоретизировать задачи инженеров. Например, у нас есть две проблемы:

  1. раз в неделю наша главная страница начинает сыпать пятисотками
  2. раз в месяц у нас падает база данных

Пятисотки сжигают 7% нашего бюджета ошибок, а падение БД сразу 20%. Но первое случается чаще, и в итоге съедает больше, поэтому пятисотками следует заняться в первую очередь.

Пример SLO:

  • Доступность API - 99,9% uptime в месяц (API может быть недоступно не больше 43 минут в месяц). Метрика: (успешные HTTP-запросы / общее количество запросов) × 100%.
  • ВМ с 1 CPU и 1 HDD 10Gb должна создаваться не дольше 20 секунд. Метрика: Перцентиль p^95 времени создания.

Как определить SLO

Чем надёжнее система, тем дороже она стоит. Поэтому определите самый низкий уровень надёжности, который может сойти вам с рук, и укажите его в качестве SLO

сказано в рекомендациях Google. "Сойти с рук" - значит, что пользователи не заметят разницы или заметят, но это не повлияет на их удовлетворенность сервисом.

Кто определяет SLO

Определение SLO это совместный процесс, в котором участвуют SRE и менеджеры продукта (по хорошему - еще и разработка), но роли у них разные.

Роль Вклад в SLO Почему?
Product Manager / Бизнес Определяет, что важно для пользователей Знают, как это работает, знают бизнес-требования и UX
SRE Определяют, что технически возможно Понимают инфраструктуру и реалистичность

Почему это нужно делать вместе

  1. Продукт без SRE выберет нереалистичные SLO (например, "100% uptime"), что приведет к:
    • Постоянному нарушению SLO.
    • Невозможности релизить новые фичи (из-за Error Budget).
  2. SRE без продукта выберут слишком мягкие SLO (например, "95% uptime"), что приведет к:
    • Деградации пользовательского опыта.
    • Потере клиентов из-за частых сбоев.

Пример конфликта: - PM: "Нам нужен 99,999% uptime" - SRE: "Это потребует 100500x увеличение мощностей и найм 18 человек за 500000 рублей в секунду"
Компромисс: 99,9% uptime + автоматическое переключение при сбоях.

Как согласовать SLO

  1. Продукт говорит:

    • Какие функции продукта критичны
    • Какие метрики важны для пользователей (например, "скорость загрузки <2 сек").

  2. SRE предлагают:

    • Технически достижимые значения (например, "p^95 latency <1 сек").
    • Инструменты для измерения.
    • Последствия для Error Budget (например, "при 99,9% можно релизить 10 фич/мес").
    • Какие компоненты тормозят (например, "БД не вытянет 99,99% без шардинга").
  3. Итог: Подписанный документ с SLO, который устраивает всех.

Что будет, если SLO определяет только одна роль?

  • Только PM: Нереалистичные SLO → команды L3 и SRE всегда в тушении пожаров.
  • Только SRE: Слишком низкие SLO → сервис будет постоянно падать, но формально SLO соблюдается или SLO могут не учитывать бизнес-потребности (например, "нам всё равно на latency").