awesome-everything EN
↑ Обратно к восхождению

Наблюдаемость

SLI, SLO и error budget: надёжность в числах

Суть SLO — это обещание о надёжности в форме процента, error budget — оставшийся допуск на отказы до нарушения обещания. Вместе они заменяют споры «насколько надёжно — достаточно?» арифметикой.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на junior-высоте — поверхность
◷ 12 min

Product manager спрашивает: «можем выкатить новый checkout-flow на этой неделе?» Без SLO ответ — ощущение. С ним — арифметика: у error budget либо есть запас, либо нет.

Что значат три термина

SLI (Service Level Indicator) — отношение: доля «хороших» запросов (или событий) из всего, что было выполнено. Для request-driven сервиса «хорошее» обычно означает: вернул успешный статус, в допустимой задержке. Формула всегда одинаковая — good events / total events — результат между 0% и 100%.

SLO (Service Level Objective) — цель для этого SLI. 99.9% SLO означает: минимум 99.9% запросов должны быть «хорошими». Всё выше цели — запас; всё ниже — нарушение.

Error budget — то, что остаётся под целью: 1 − SLO. 99.9% SLO оставляет 0.1% бюджет на отказы, которые разрешено произвести до нарушения SLO.

ТерминФормулаПример (99.9% SLO, 30 дней)
SLIgood_events / total_events999,000 / 1,000,000 = 99.9%
SLOцелевое значение SLI>= 99.9% запросов должны быть успешными
Error budget1 − SLO0.1% = 1,000 отказов на миллион, ~43 минуты downtime
Burn rateactual_error_rate / (1 − SLO)1.0% error rate = 10x burn (бюджет за 3 дня)

Метафора: мобильный интернет

Думай об error budget как о месячном тарифе мобильного интернета. 99.9% SLO за 30 дней — та же форма, что «10 GB в месяц»: на старте периода фиксированный лимит, он тратится с каждым событием, и если закончился раньше — замедляешься (никаких feature-деплоев) до следующего расчётного периода.

Маленький инцидент — как 30-секундное видео, едва заметная вмятина. Двухчасовой outage — как HD-стриминг весь выходной: большая часть месячного лимита ушла. Тяжёлые расходники нормируют; лёгкие — выкатывают свободно.

Burn rate: производная величина, которая важнее всего

Burn rate нормирует частоту ошибок относительно SLO-цели:

burn_rate = actual_error_rate / (1 − SLO)

При 99.9% SLO (бюджет = 0.1% = 0.001):

  • 0.1% error rate → burn rate 1.0: бюджет иссякнет ровно к концу месяца
  • 1.44% error rate → burn rate 14.4: 30-дневный бюджет сгорит примерно за 2 дня

Burn rate 1 означает «устойчиво». Выше 1 — ты в темпе, чтобы пропустить SLO. Burn rate показывают на алертах и дашбордах, потому что это одно число для любого сервиса — 14.4x означает одно и то же везде.

Конкретный сценарий

SaaS-команда ставит 99.5% SLO. За месяц обслуживает 10M запросов; 0.5% = 50,000 ошибок допустимо. Конфиг-баг в первую неделю сжигает 30,000 ошибок за 20 минут — 60% месячного бюджета в одном инциденте. Burn-rate-алерт сработал; postmortem использовал сожжённый бюджет как метрику severity. Оставшихся 40% едва хватает на следующие 20 дней при базовой частоте — рискованный деплой пришлось поставить за feature flag.

Почему это работает

Без SLO «катить или не катить?» — политический спор: побеждает тот, у кого больше веса. С SLO и error budget ответ — арифметика: запас либо есть, либо нет. Это главный культурный сдвиг, который даёт фреймворк. Он превращает надёжность в язык, который читают и product manager’ы, и SRE, и директора.

Викторина

У сервиса 99.9% availability SLO за 30 дней. Чему равен error budget?

Викторина

Сервис с 99.9% SLO работает на 1.44% error rate. Каков burn rate?

Расставь шаги по порядку

Расставь шаги построения SLO с нуля:

  1. 1 Определи важный user journey (checkout, поиск, логин)
  2. 2 Выбери SLI: измеримое отношение good/total (например successful_requests / total_requests)
  3. 3 Поставь SLO: целевой процент для этого отношения (например 99.9%)
  4. 4 Посчитай error budget: 1 − SLO за rolling window (обычно 28 дней)
  5. 5 Поставь multi-window multi-burn-rate-алерты поверх SLO
  6. 6 Напиши error budget policy: что происходит при исчерпании бюджета
  7. 7 Пересматривай SLO ежеквартально на основе реального пользовательского опыта
Закончи аналогию

Заполни пропуск: error _______ — это допуск на отказы, который можно тратить до срабатывания заморозки деплоев.

Вспомните перед уходом
  1. 01
    По одному предложению: что такое SLI, SLO и error budget?
  2. 02
    Почему burn rate полезнее сырой частоты ошибок для алертинга?
  3. 03
    Что происходит при исчерпании error budget?
Итог

SLI — измеримое отношение good events к total events, описывающее, как сервис работает с точки зрения пользователя. SLO задаёт цель для этого отношения: 99.9% SLO означает, что 99.9% событий должны быть хорошими. Error budget — это 0.1% отказов, которые разрешены до нарушения SLO: при 1M запросов в месяц — 1,000 отказов, или примерно 43 минуты downtime. Burn rate нормирует текущую частоту ошибок относительно бюджетного темпа — burn rate 14.4x означает, что 30-дневный бюджет закончится за 2 дня, — что делает алерты и дашборды сравнимыми между сервисами. При исчерпании бюджета error budget policy останавливает деплои фич до восстановления.

Связанные уроки
опирается на
открывает
углубляется в
встречается в175
Продолжить восхождение ↑Выбор SLI и SLO-целей: отношения, не ощущения
хоткеи развернуть
поиск
⌘K
пред. пьеса
k
след. пьеса
j
тиры
t
это меню
?
sources3
expand
  1. 01
    sre.google/workbook/implementing-slos/
  2. 02
    sre.google/sre-book/embracing-risk/
  3. 03
    sre.google/workbook/error-budget-policy/

Trademarks belong to their respective owners. Editorial reference only.