Главная› Уроки› SRE SLO

SRE: SLI, SLO, Error Budget

Как Google измеряет надёжность. Это переключение от «алертов на симптомы» к «алертам на пользовательский опыт» — фундаментальное для зрелой команды.

Терминология

ТерминЧтоПример
SLI Service Level IndicatorЧто измеряем% успешных запросов (HTTP 2xx,3xx,4xx из всех)
SLO Service Level ObjectiveЦель — внутренний контракт99.9% запросов успешны за 30 дней
SLA Service Level AgreementВнешний контракт с пользователем (юр.)99.5% uptime или вернём 10% оплаты
Error BudgetСколько можно «сломаться» = 1 − SLO0.1% от 30 дней = 43.2 минуты в месяц
Ключевая идея

SLA >> SLO >> реальность. SLO ставится строже чем SLA — даёт буфер. Реальность должна быть лучше SLO — даёт error budget на эксперименты.

Выбор SLI

Хорошие SLI — про пользователя. Не «CPU usage», а «latency запроса». Главные паттерны:

1. Request-based

Соотношение «good events» / «valid events»:

availability = успешные запросы / все запросы
latency = запросы < 500ms / все запросы
error_rate = 5xx ответы / все ответы

2. Time-based (windows)

Доля «хороших» окон времени:

uptime = минуты без ошибок / все минуты

3. Data freshness (для pipeline)

freshness = задачи завершены в SLA / все задачи

Выбор SLO — числа

SLOError budget (30 дней)Когда
99%7.2 часаВнутренние тулы
99.5%3.6 часаНе критичные сервисы
99.9%43.2 минуты★ Стандарт для B2B SaaS
99.95%21.6 минутКритичные продукты
99.99%4.32 минутыФинтех, банки
99.999%26 секундТелеком core
⚠️ Не ставь нереальные SLO

99.999% не достижимо без gigantic investment. Команда сгорит. Начни с 99.9%, расти если бизнес требует.

Error Budget — почему это game changer

Без error budget команды поляризуются:

С error budget — объективное правило:

Это инженерная этика, встроенная в процессы.

Burn rate alerts — современный подход

Старый способ: «алерт если error rate > 5% за 5 минут». Проблема — много шума или поздно реагируем.

Новый способ — burn rate: насколько быстро тратим бюджет.

Burn rateОкноSeverityAction
14.4×1 часPageБюджет на месяц истечёт за 2 часа — срочно
6×6 часовTicketБюджет истечёт за 5 дней — проблема
3×3 дняEmailБюджет истечёт за 10 дней — обсуждение
1×30 дней—Нормальный расход — без алерта

Multi-window multi-burn-rate (Google SRE)

# PrometheusRule
groups:
- name: slo
  rules:
  - alert: HighErrorBudgetBurn_Fast
    expr: |
      (
        sum(rate(http_requests_total{status=~"5.."}[1h]))
          /
        sum(rate(http_requests_total[1h]))
      ) > (1 - 0.999) * 14.4
      and
      (
        sum(rate(http_requests_total{status=~"5.."}[5m]))
          /
        sum(rate(http_requests_total[5m]))
      ) > (1 - 0.999) * 14.4
    for: 2m
    labels: {severity: page}
    annotations:
      summary: "Burn rate 14.4x — error budget gone in 2 hours"

  - alert: HighErrorBudgetBurn_Slow
    expr: |
      ... 6 hour window with 6x ...
    for: 15m
    labels: {severity: ticket}

Двойное окно (1h + 5m) исключает шум от коротких всплесков.

Implementing SLO — инструменты

Антипаттерны

SLO Document — что должно быть

  1. Service description
  2. Users / stakeholders
  3. SLI definitions (точные queries)
  4. SLO targets
  5. Error budget policy (что делаем при exhaust)
  6. Alerts (burn rate thresholds)
  7. Runbooks
  8. Review cadence (квартально)

Ресурсы