SLO, SLI и error budget: как договариваться о надёжности с цифрами

«Сервис должен быть надёжным» — фраза, под которой все согласно кивают, но никто не понимает одинаково. Для разработчика «надёжный» = «не падает при моём релизе». Для product owner — «работает, когда я открываю». Для бизнеса — «деньги идут». Эти три определения не совпадают, и без чисел спор бесконечен.

SLO/SLI/error budget — это инструмент перевода «надёжности» в цифры, которые все понимают одинаково. Не про техническую красоту, а про умение договариваться: сколько надёжности мы покупаем за какую цену, и что значит «достаточно».

За двенадцать лет я внедрял SRE-практики дважды. Первый раз — формально, по книжке Google SRE. Получилось плохо: цифры были, договорённости — нет. Второй раз — с прицелом на то, чтобы это работало в команде, не как ритуал. Разберу, как это делается, и где обычно ломается.

Базовые термины

Чтобы дальше говорить осмысленно.

• SLI (Service Level Indicator) — измеримый показатель: «доля успешных HTTP-запросов», «p99 латентности».
• SLO (Service Level Objective) — целевое значение SLI: «99.9% запросов успешны за 30 дней», «p99 < 200ms».
• SLA (Service Level Agreement) — формальное обязательство, обычно с финансовыми последствиями. SLA = SLO + штрафы.
• Error budget — допустимое количество «нарушений» SLO. При SLO 99.9% за 30 дней error budget = 0.1% × 30 дней = 43.2 минуты простоя в месяц.

SLA — для внешних обещаний клиентам. SLO — для внутренней дисциплины команды. На большинстве проектов работает SLO, SLA — отдельная тема для контракта.

Что такое error budget на практике

Главная идея — у вас есть «бюджет» на отказы, который тратится со временем. Сервис уронил 5 минут — потратили 5 минут бюджета. Деплой повысил error rate на час — потратили час.

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

Это превращает «надёжность» из политического вопроса в счёт. Не «product owner хочет фичи, SRE хочет стабильности», а «у нас на этой неделе осталось 5 минут бюджета, рискуем или ждём?».

Как выбирать SLI

Главное правило — SLI должен отражать пользовательский опыт, не технический.

Плохие SLI

«CPU usage < 80%». Это оперативная метрика, не показатель пользы для пользователя. Сервис может быть нагружен и при этом работать прекрасно с точки зрения юзера.

«Сервис UP/DOWN». Бинарное состояние не отражает реальную проблему. Сервис «UP», но 5% запросов ловят 500 — пользователь страдает.

«Memory leak detected». Это инцидент, не показатель. SLI — это вероятностная мера успешного user experience.

Хорошие SLI

Для request-driven сервиса (HTTP API):

• Availability = доля успешных запросов = (успешные / всего). Что считать успешным — определяете отдельно (обычно HTTP 2xx и 3xx, не 5xx).
• Latency = доля запросов быстрее порога = (запросы < 500ms / всего). Часто формулируется как p99 ≤ 500ms.
• Quality = доля корректных ответов (для retrieval-сервисов).

Для pipeline (обработка событий):

• Throughput = доля обработанных событий за допустимое время.
• Freshness = доля событий, обработанных не позже N минут от появления.

Для систем, которые работают по расписанию (cron-jobs):

• Job completion rate = доля успешно завершённых запусков.

Главный вопрос: «что увидит пользователь, если SLI падает?». Если ответ «ничего» — это не SLI, это техническая метрика.

Как выбирать SLO

Цифра должна быть достижимой и осмысленной. Несколько правил.

Меньше «девяток», чем кажется

Раз 99.9% (43 минуты в месяц) выглядит мало. 99.99% (4 минуты в месяц) — практически невозможно поддерживать без значительных вложений.

Большинство интернет-сервисов реально работают на 99.5–99.9%. Кричат про «пять девяток», но реально это удел Google/Netflix-уровня.

Не равняйтесь на максимум

Если за последние 6 месяцев ваш сервис давал 99.97% — не ставьте SLO 99.99%. Будете тратить 50% времени команды на догон 0.02%.

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

Разные SLO для разных поверхностей

Главная пользовательская страница — 99.95%. Админка — 99.5%. Job, который раз в неделю шлёт отчёт — 99%. Не надо одинаково сильно защищать всё.

Расчёт error budget

Бюджет в единицах времени или в долях:

SLO 99.9% за 30 дней
= 0.1% от 30 дней
= 43.2 минуты simply downtime
или
= 0.1% от запросов могут упасть

На request-driven SLI бюджет считается в долях запросов. На 1M запросов в день — 1000 запросов могут упасть, оставаясь в SLO.

Burn rate — скорость потребления бюджета. Если за час сервис уронил столько же запросов, сколько бюджет на 30 дней — это burn rate ×720 (30×24). Это значение → алерт «срочно».

Алертинг по SLO

Старая школа алертинга — на конкретные ошибки: «5 ошибок в минуту → алерт». Это шумно: ошибки бывают всегда, и большая часть несущественны.

SLO-driven alerting — алерт, когда burn rate превышает порог:

# Многоуровневый burn-rate алерт
- alert: SLOBudgetBurnFast
  expr: error_rate > 14.4 * 0.001  # потратим бюджет за 2 часа
  for: 5m
  severity: critical

- alert: SLOBudgetBurnSlow
  expr: error_rate > 6 * 0.001     # потратим бюджет за 5 дней
  for: 30m
  severity: warning

Это убирает шум: алерт срабатывает только если темп ошибок реально угрожает SLO. Мелкие всплески, которые компенсируются спокойными периодами, не будят дежурного.

Что делать при исчерпании бюджета

Это политическая часть, и она не работает без поддержки руководства.

Базовая логика:

1. Бюджет исчерпан — фриз новых фич. Команда работает только на стабилизацию.
2. Деплои с риском (большие изменения, эксперименты) откладываются.
3. Только bug fixes и безопасность.
4. Когда бюджет восстанавливается (через окно SLO) — возврат к нормальной работе.

Если product owner отказывается это соблюдать — SLO не работает. Это политический договор между разработкой, SRE и продуктом. Без него цифры — это просто графики, а не инструмент.

Подводные камни

Несколько вещей, на которые я наступал.

SLI измеряется не там, где надо. Меряете availability на стороне backend'а, но между ним и юзером есть CDN, gateway, инфраструктура клиента. Реальный пользователь страдает чаще, чем ваш SLI показывает. Лучшая практика — измерять с точки максимально близкой к юзеру (real user monitoring).

SLO без error budget policy. Цифры есть, но никто не следит за ними и не реагирует. Это карго-культ. Должен быть документ «что мы делаем при исчерпании», и его соблюдают.

Слишком много SLO. 50 SLO на сервис — никто не помнит ни одного. 3-5 ключевых на сервис, всё остальное — внутренние метрики, не SLO.

SLO привязан к compute, не к user. «Pod CPU < 80%» — это не SLO. Это alarm на инфраструктуру. SLO — про пользовательский эффект.

Нечестное чтение бюджета. Команда «ну, у нас же был запланированный maintenance, не считаем». Все исключения должны быть документированы заранее, а не после факта. Иначе бюджет постепенно превращается в фикцию.

SLO для всего. Внутренние сервисы, у которых нет внешних потребителей, не нуждаются в SLO. У них есть SLI (метрики) для оперативной работы, но без обязательств.

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

Что запомнить

SLO — это инструмент договорённости через цифры. SLI меряет user-перспективу, SLO ставит цель, error budget даёт ресурс для риска.

Хорошая практика — 3-5 SLO на сервис, измеряемых близко к пользователю, с явной error budget policy и алертами по burn rate. Без policy цифры бесполезны: будет «графики красивые, фичи всё равно деплоим в любом состоянии».

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

SLO работает, когда вся команда — разработка, SRE, продукт — играет по одним правилам. Это не техническая практика, это организационная. Без поддержки руководства это просто красивые цифры, которые никто не уважает.