SLO, SLI и бюджеты ошибок

Updated Jul 2026

Почему QA-архитекторам нужны основы SRE

Современные QA-архитекторы находятся на пересечении инженерии качества и инженерии надёжности. Понимание SLO, бюджетов ошибок и их операционных последствий не является опциональным на уровне архитектора. Эти концепции предоставляют количественный фреймворк для принятия решений о качестве: когда выпускать, когда останавливаться и когда инвестировать в надёжность вместо функций.

Словарь SRE

Взаимосвязь между ними

SLI = The measurement (what you observe)
SLO = The target (what you commit to internally)
SLA = The contract (what you promise customers, with penalties)
Error Budget = SLO's tolerance (how much failure is acceptable)

Always: SLA <= SLO (your internal target should be stricter than your customer promise)

Выбор хороших SLI

Не все метрики подходят в качестве SLI. Лучшие SLI обладают следующими свойствами:

1. Ориентированы на пользователя. Измеряйте то, что испытывают пользователи, а не то, что показывают серверы.
2. Измеримы. Вы должны иметь возможность надёжно собирать данные.
3. Действуемы. Когда SLI деградирует, команда может что-то с этим сделать.

Категории SLI

Почему «аптайм сервера» — плохой SLI: Сервер может быть «работающим» (отвечать на health-check), возвращая ошибки на каждый пользовательский запрос. Аптайм измеряет инфраструктуру, а не пользовательский опыт.

Почему «среднее время ответа» — плохой SLI: Средние значения скрывают выбросы. Если 99% запросов занимают 100 мс, а 1% — 30 секунд, среднее составляет ~400 мс — что выглядит нормально, но маскирует ужасный опыт для 1% пользователей.

Определение SLO

SLO объединяет SLI с целевым значением и временным окном:

# slo-definitions.yaml
service: checkout-api

slos:
  - name: availability
    sli: successful_requests / total_requests
    # "successful" = status code < 500 (client errors are not server failures)
    target: 99.95%
    window: 30d
    error_budget: 0.05%    # ~21.6 minutes of downtime per month

  - name: latency
    sli: requests_completed_under_500ms / total_requests
    target: 99.0%
    window: 30d
    error_budget: 1.0%
    # 1% of requests can exceed 500ms without breaching the SLO

  - name: correctness
    sli: orders_with_correct_total / total_orders
    target: 99.99%
    window: 30d
    error_budget: 0.01%

Рекомендации по проектированию SLO

1. Начните с ожиданий пользователей. Если ваши пользователи ожидают, что оформление заказа займёт менее 2 секунд, ваш SLO по задержке должен быть строже.
2. Используйте перцентили, а не средние значения. SLO на p99 или p95 задержку защищают хвост распределения.
3. Используйте скользящие окна. 30-дневное скользящее окно — стандарт. Календарные месяцы создают панику в конце месяца.
4. Не стремитесь к 100%. SLO в 100% означает нулевую терпимость к любому отказу, что останавливает всю разработку. Даже Google нацеливается на 99,99%, а не на 100%.
5. Меньше — лучше. 3-5 SLO на сервис достаточно. Слишком много SLO создают путаницу в приоритетах.

Бюджеты ошибок: ключевая идея

Бюджет ошибок — самая мощная концепция в SRE. Он превращает надёжность в измеримый ресурс, который можно расходовать:

Политика бюджета ошибок

Политика бюджета ошибок определяет, что происходит по мере его расходования:

# error-budget-policy.yaml
service: checkout-api
slos:
  - name: availability
    sli: successful_requests / total_requests
    target: 99.95%
    window: 30d
    error_budget: 0.05%

  - name: latency
    sli: requests_under_500ms / total_requests
    target: 99.0%
    window: 30d
    error_budget: 1.0%

policy:
  budget_remaining_above_50pct:
    - Deploy normally
    - Run chaos experiments
    - Ship new features
    - Experiment with new architectures

  budget_remaining_25_to_50pct:
    - Reduce deployment frequency
    - Pause non-critical chaos experiments
    - Prioritize reliability work in sprint planning
    - Review recent deployments for regressions

  budget_remaining_below_25pct:
    - Feature freeze for this service
    - All engineering effort on reliability
    - Incident review for every budget-consuming event
    - Escalate to engineering leadership

  budget_exhausted:
    - Full deployment freeze except hotfixes
    - Executive escalation
    - Postmortem required for next deployment
    - Consider rollback of recent changes

Почему бюджеты ошибок меняют разговор

Без бюджетов ошибок обсуждение надёжности носит конфронтационный характер:

• Продуктовая команда: «Нам нужно выпустить эту функцию.»
• Команда QA/SRE: «Она не готова. Нужно больше тестирования.»
• Результат: Бесконечные переговоры, нет объективных критериев.

С бюджетами ошибок обсуждение основано на данных:

• Продуктовая команда: «Нам нужно выпустить эту функцию.»
• Команда QA/SRE: «У нас осталось 60% бюджета ошибок. Мы можем выпустить, но нужно внимательно мониторить.»
• Результат: Объективное решение на основе измеримого риска.

Мониторинг расходования бюджета ошибок

Настройка Prometheus/Grafana

# prometheus-error-budget-recording-rules.yaml
groups:
  - name: error-budget
    interval: 1m
    rules:
      # SLI: availability (successful requests / total requests)
      - record: sli:checkout:availability:5m
        expr: |
          sum(rate(http_requests_total{service="checkout",status!~"5.."}[5m]))
          /
          sum(rate(http_requests_total{service="checkout"}[5m]))

      # Error budget remaining (30-day window)
      - record: error_budget:checkout:availability:remaining
        expr: |
          1 - (
            (1 - sli:checkout:availability:30d) / (1 - 0.9995)
          )
        # Result: 1.0 = full budget, 0.0 = budget exhausted, <0 = over budget

      # Error budget burn rate
      - record: error_budget:checkout:availability:burn_rate:1h
        expr: |
          (1 - sli:checkout:availability:1h) / (1 - 0.9995)
        # Result: 1.0 = sustainable rate, >1.0 = burning faster than allowed

Практические шаги внедрения

Шаг 1: Измеряйте, прежде чем ставить цели

Перед определением SLO измеряйте текущую производительность в течение 30 дней. Ваш начальный SLO должен быть установлен на уровне или немного выше вашей текущей базовой линии — а не на уровне амбициозной цели.

Шаг 2: Начните с одного сервиса

Выберите ваш самый критичный сервис (обычно тот, который генерирует доход) и определите 2-3 SLO. Докажите, что процесс работает, прежде чем расширять.

Шаг 3: Автоматизируйте отслеживание бюджета

Ручное отслеживание бюджета ошибок не масштабируется. Используйте recording rules Prometheus или функцию SLO вашей платформы мониторинга (Datadog SLOs, Grafana SLO).

Шаг 4: Привяжите бюджет к действиям

Политика бюджета ошибок должна иметь силу. Если бюджет достигает 25% и политика говорит «заморозка функций», руководство должно обеспечить её выполнение. В противном случае вся система теряет доверие.

Шаг 5: Пересматривайте ежеквартально

SLO не являются постоянными. Пересматривайте их ежеквартально:

• Слишком жёсткие? (Постоянные заморозки функций = слишком амбициозные цели)
• Слишком мягкие? (Бюджет никогда не расходуется = цели не значимы)
• Отражают ли ожидания пользователей? (Жалобы пользователей при зелёных SLO = неверные метрики)

Распространённые ошибки