Developer

SLI, SLO, SLA, error budget

↑ Этап 7 · Observability и эксплуатация

Желательно~6 мин чтенияУровень: middle+

Зачем это на собесе

SRE-основы: как формализовать «надёжность достаточно хороша» и управлять релизами через error budget.

Определения

  • SLI (Service Level Indicator) — измеряемый показатель качества сервиса с точки зрения пользователя: доля успешных запросов, доля запросов быстрее порога, свежесть данных.
  • SLO (Service Level Objective) — целевое значение SLI за период: «99.9% запросов успешны за 30 дней».
  • SLA (Service Level Agreement) — договорное обязательство перед клиентом (с последствиями: штрафы, компенсации), обычно мягче внутреннего SLO.
  • Error budget — допустимая «доля отказов»: 1 − SLO. При SLO 99.9% за 30 дней бюджет = 0.1% ≈ 43.2 минуты недоступности.

Порядок: SLI → SLO (цель) → SLA (контракт, SLA ≤ SLO по строгости: внутренняя цель жёстче).

Доступность в «девятках»

SLOДопустимый простой за 30 днейза год
99%7 ч 12 мин3.65 дня
99.5%3 ч 36 мин1.83 дня
99.9%43 мин 12 с8 ч 46 мин
99.95%21 мин 36 с4 ч 23 мин
99.99%4 мин 19 с52 мин
99.999%26 с5 мин

Каждая лишняя «девятка» дороже на порядок (избыточность, автоматизация, регионы). Цель выбирается по ожиданиям пользователей и стоимости, а не «максимальной».

Выбор SLI

Хороший SLI отражает пользовательский опыт и измерим.

Тип сервисаSLI
Запрос-ответ (API)Доступность: успешные / все запросы; Латентность: запросы быстрее X мс / все; Качество: ответы без деградации
Конвейер данныхСвежесть (время от события до результата), Корректность, Покрытие, Пропускная способность
ХранилищеДоступность, задержка, долговечность (доля не потерянных данных)
ФронтендWeb Vitals (LCP, INP, CLS), доля сессий без JS-ошибок (crash-free)

Формула (события): SLI = хорошие события / валидные события × 100%.

# Доступность API (успешные не 5xx) за 30 дней
sum(rate(http_requests_total{job="api", status!~"5.."}[30d])) / sum(rate(http_requests_total{job="api"}[30d]))
# Латентность: доля запросов быстрее 300 мс (из histogram)
sum(rate(http_request_duration_seconds_bucket{job="api", le="0.3"}[30d])) / sum(rate(http_request_duration_seconds_count{job="api"}[30d]))

Правила: измерять как можно ближе к пользователю (на балансировщике/клиенте, а не внутри процесса); исключать шум (health checks, боты, ошибки 4xx клиента); несколько SLI на сервис (обычно 2–4); критические пользовательские пути (вход, оплата, запись на приём).

Формирование SLO

  1. Определить критические пользовательские сценарии (CUJ — Critical User Journeys).
  2. Выбрать SLI для каждого.
  3. Собрать историю, оценить текущий уровень; согласовать цель с продуктом/бизнесом (реалистичная, не 100%).
  4. Окно: скользящее 28/30 дней или календарное месяц/квартал.
  5. Документировать: SLI, SLO, окно, источник данных, владелец, реакция при нарушении.
  6. Пересматривать регулярно.

100% — неверная цель: стоимость растёт экспоненциально, зависимости (провайдеры, сети) ненадёжны, скорость изменений снижается.

Error budget и политика

Бюджет — «разрешённая порция ненадёжности», которую можно «потратить» на релизы, эксперименты, миграции.

Error budget policy (согласована командой и бизнесом):

Состояние бюджетаДействие
Остаётся > 50%релизы в обычном режиме, эксперименты допустимы
Остаётся < 25%осторожность, усиленное ревью, канареечные релизы
Исчерпанзаморозка фич, фокус на надёжность (исправления, тесты, отказоустойчивость), постмортемы
Внешняя причина (провайдер)фиксируется отдельно, обсуждаются риски и резервирование

Так надёжность и скорость разработки балансируются данными, а не спорами.

# Остаток бюджета ошибок (SLO 99.9% за 30 дней)
1 - ((1 - sli_availability_30d) / (1 - 0.999))

Burn rate и алертинг по SLO

Burn rate — скорость расходования бюджета: burn_rate = (доля ошибок за окно) / (1 − SLO). Burn rate 1 — бюджет закончится ровно к концу окна; 14.4 — исчерпается за 2 дня/(при 30-дн окне 1 час израсходует 2% бюджета).

Multi-window, multi-burn-rate алерты (Google SRE Workbook): быстрые и медленные сгорания с двумя окнами (короткое подтверждает, что проблема продолжается).

СерьёзностьBurn rateДлинное окноКороткое окноБюджет за окно
Page (срочно)14.41 ч5 мин2%
Page66 ч30 мин5%
Ticket31 сут2 ч10%
Ticket13 сут6 ч10%
- alert: ApiErrorBudgetBurnFast
  expr: |
    (sum(rate(http_requests_total{job="api",status=~"5.."}[1h])) / sum(rate(http_requests_total{job="api"}[1h])) > (14.4 * 0.001))
    and
    (sum(rate(http_requests_total{job="api",status=~"5.."}[5m])) / sum(rate(http_requests_total{job="api"}[5m])) > (14.4 * 0.001))
  labels: { severity: page }
  annotations: { summary: "Быстрое сгорание бюджета SLO API (99.9%)" }

Инструменты: Sloth, Pyrra (генерация правил и дашбордов SLO), OpenSLO (спецификация), Grafana SLO, Nobl9, Datadog SLO.

Преимущества: алерт срабатывает, когда пользователи реально страдают и бюджет тратится, а не на каждый всплеск; меньше шума.

SLA и внешние обязательства

  • SLA включает метрику, окно, исключения (плановые работы, форс-мажор, зона клиента), процедуру расчёта, компенсации (service credits);
  • SLA мягче SLO (например, SLO 99.95%, SLA 99.9%);
  • композитная доступность: последовательные зависимости умножаются: 0.999 × 0.999 = 0.998; параллельные (резервы) повышают: 1 − (1−a)(1−b); SLA провайдеров облака — основа расчёта максимально достижимой доступности;
  • SLO зависимостей (внутренние сервисы) — контракты между командами.

Внедрение в организацию

  • начать с 1–2 ключевых сервисов; простые SLI по доступности и латентности из существующих метрик;
  • дашборд SLO (текущее значение, остаток бюджета, burn rate) виден всем;
  • регулярные ревью SLO (ежемесячно/квартально): нарушения, причины, корректировка целей;
  • связь с инцидентами и постмортемами: какие потратили бюджет, что улучшить;
  • культура: SLO принадлежит продуктовой команде, а не только SRE; бизнес согласует цели;
  • ограничения и антипаттерны: слишком много SLO, цели «как можно выше», SLI, не отражающие пользователя (CPU), игнорирование бюджета, SLO только на бумаге, алерты не связаны с SLO.

Вопросы с ответами

Вид графа

Обратные ссылки