senior

Что такое SLO, SLI и SLA?

SLA, SLO, SLI — три уровня определения и измерения надёжности сервиса, введённые Google в рамках практик Site Reliability Engineering (SRE).

SLA (Service Level Agreement) — юридическое соглашение с клиентом, определяющее минимальный уровень качества и компенсации при нарушении.
SLO (Service Level Objective) — внутренняя цель команды по надёжности, строже SLA, без юридических последствий.
SLI (Service Level Indicator) — конкретная метрика, показывающая текущий уровень качества.

Пример

SLI (что измеряем) → SLO (какую цель ставим) → SLA (что обещаем клиенту)

SLI: availability = 99.97%
SLO: availability >= 99.95%   -- SLO выполняется
SLA: availability >= 99.9%    -- SLA выполняется

Error Budget (бюджет ошибок)

Error budget = 100% - SLO. Это «допустимый» объём ошибок или простоя.

SLO	Error Budget/месяц	Допустимый downtime/месяц
99%	1%	7 часов 18 минут
99.9%	0.1%	43 минуты 50 секунд
99.95%	0.05%	21 минута 55 секунд
99.99%	0.01%	4 минуты 23 секунды
99.999%	0.001%	26 секунд

Как использовать error budget:

Пока error budget > 0: можно деплоить новые фичи, проводить эксперименты
Error budget исчерпан: замораживаем фичи, фокусируемся на надёжности
Error budget сгорает слишком быстро: алерт (burn rate alert)

Типичные SLI

SLI	Формула	Для чего
Availability	`success_requests / total_requests`	Доступность сервиса
Latency	`requests_within_threshold / total_requests`	Скорость ответа
Throughput	`successful_operations / time_period`	Пропускная способность
Error Rate	`error_requests / total_requests`	Частота ошибок
Freshness	`data_age < threshold`	Актуальность данных
Correctness	`correct_responses / total_responses`	Корректность ответов

Реализация SLI/SLO с Prometheus (recording + alert rules)

# recording_rules.yml — предвычисление SLI
groups:
  - name: sli_rules
    rules:
      # SLI: Availability (доля успешных запросов)
      - record: sli:availability:ratio_rate5m
        expr: |
          sum(rate(http_server_requests_seconds_count{status!~"5..", job="order-service"}[5m]))
          /
          sum(rate(http_server_requests_seconds_count{job="order-service"}[5m]))

      # SLI: Latency (доля запросов быстрее 500ms)
      - record: sli:latency:ratio_rate5m
        expr: |
          sum(rate(http_server_requests_seconds_bucket{le="0.5", job="order-service"}[5m]))
          /
          sum(rate(http_server_requests_seconds_count{job="order-service"}[5m]))

      # Error budget consumed (за последние 30 дней)
      - record: slo:error_budget:consumed_ratio_30d
        expr: |
          1 - (
            (1 - sli:availability:ratio_rate5m)
            /
            (1 - 0.999)
          )

# alert_rules.yml — алерты на burn rate
groups:
  - name: slo_alerts
    rules:
      # Быстрое сгорание error budget (бюджет закончится за ~2 дня)
      - alert: ErrorBudgetFastBurn
        expr: |
          (
            1 - (
              sum(rate(http_server_requests_seconds_count{status!~"5..", job="order-service"}[1h]))
              /
              sum(rate(http_server_requests_seconds_count{job="order-service"}[1h]))
            )
          )
          /
          (1 - 0.999) > 14.4
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Error budget burning fast — exhaustion in ~2 hours"

      # Медленное сгорание (бюджет закончится за ~5 дней)
      - alert: ErrorBudgetSlowBurn
        expr: |
          (
            1 - (
              sum(rate(http_server_requests_seconds_count{status!~"5..", job="order-service"}[6h]))
              /
              sum(rate(http_server_requests_seconds_count{job="order-service"}[6h]))
            )
          )
          /
          (1 - 0.999) > 6
        for: 30m
        labels:
          severity: warning
        annotations:
          summary: "Error budget burning slowly — exhaustion in ~5 days"

Grafana Dashboard для SLO

Пример

# Текущая availability (SLI)
sli:availability:ratio_rate5m{job="order-service"}

# Error budget оставшийся (%)
(1 - (1 - sli:availability:ratio_rate5m) / (1 - 0.999)) * 100

Пример SLO-документа для сервиса

Пример

Сервис: Order Service
Владелец: Team Orders

SLO 1: Availability
  SLI: доля HTTP-запросов с кодом != 5xx
  Target: 99.9% за 30-дневное окно
  Error budget: 0.1% (~43 мин downtime)

SLO 2: Latency
  SLI: доля HTTP-запросов с latency < 500ms
  Target: 99% за 30-дневное окно
  Error budget: 1% запросов могут быть медленнее

Действия при исчерпании error budget:
  1. Заморозка нестабильных деплоев
  2. Приоритет задачам надёжности
  3. Post-mortem для крупных инцидентов

Важное

SLO должен быть не 100%: 100% SLO невозможен и блокирует любые изменения. «Достаточно надёжный» — правильный подход.
SLO определяет SLA: SLO всегда строже SLA. Если SLO нарушен, команда реагирует до нарушения SLA.
Error budget — инструмент баланса: между скоростью разработки (новые фичи) и надёжностью.
SLI должен отражать пользовательский опыт: не «CPU < 80%», а «99% запросов отвечают за < 500ms».

Частые ошибки

SLO = SLA: если SLO равен SLA, нет запаса — любая деградация сразу нарушает соглашение.
Слишком высокий SLO: 99.999% означает 26 секунд downtime в месяц — стоимость поддержания огромна.
SLI не привязан к пользовательскому опыту: мониторить внутренние метрики вместо user-facing.
Нет error budget policy: error budget определён, но нет процесса, что делать при его исчерпании.
Один SLO на весь сервис: разные endpoint’ы имеют разную важность. /api/payments и /api/health — разные SLO.

Как используется в 2026

SLO-based alerting — стандартная практика в Google, рекомендуется в SRE Book. Prometheus + burn rate alerts.
Grafana SLO feature — встроенная поддержка SLO в Grafana Enterprise и Cloud.
OpenSLO — open-source стандарт для описания SLO в формате YAML.
Sloth — инструмент для генерации Prometheus recording/alerting rules из OpenSLO-описания.
Platform Engineering — SLO как контракт между Platform team и Product teams.

На собеседовании: чётко разграничьте SLA (юридическое), SLO (внутренняя цель), SLI (метрика). Обязательно объясните Error Budget и его роль как баланса между фичами и надёжностью. Сильный ответ включает конкретный пример: “SLI availability = 99.97%, SLO >= 99.95%, SLA >= 99.9%”. Частая ошибка — не упомянуть, что SLO не должен быть 100%.

#observability