SLI, SLO и error budget

Надёжность — число, а не ощущение

«Сервис работает хорошо» — не инженерное утверждение, его нельзя проверить. Чтобы говорить о надёжности предметно, её измеряют. Три понятия дают язык для этого: SLI, SLO и error budget. Они переводят расплывчатое «надёжно» в конкретные числа, по которым принимают решения.

SLI: что измеряем

SLI (Service Level Indicator) — конкретная метрика качества сервиса с точки зрения пользователя. Не «CPU загружен на 60%», а то, что чувствует пользователь:

• доля успешных запросов (не 5xx);
• доля запросов быстрее порога (например, быстрее 300 мс);
• доступность за период.

SLI считают из тех же метрик, что собирает Prometheus. «Доля успешных запросов за месяц» — это SLI.

SLO: какую цель ставим

SLO (Service Level Objective) — цель по SLI: какое значение мы считаем достаточным. Не 100%, а реалистичная планка.

SLI: доля успешных запросов
SLO: 99.9% успешных запросов за 30 дней

99.9% за месяц звучит почти как идеал, но это около 43 минут недоступности в месяц. Важно, что SLO ставят меньше 100% сознательно: стремиться к абсолютной надёжности бесконечно дорого, а пользователь не заметит разницы между 99.9% и 100%.

Не путать с SLA: SLA это договор с клиентом со штрафами, SLO это внутренняя инженерная цель, обычно строже SLA.

Error budget: право на риск

Здесь самое интересное. Если SLO это 99.9%, то 0.1% это допустимая доля ошибок, и она называется error budget (бюджет ошибок). Это право на сбои, которое можно тратить.

SLO 99.9% → error budget 0.1% (~43 минуты в месяц)

Error budget превращает надёжность в инструмент принятия решений:

• бюджет есть (сбоев меньше нормы) → можно рисковать: катить чаще, пробовать новое, экспериментировать.
• бюджет исчерпан (сбоев уже под лимит) → притормозить с рискованными изменениями, заняться стабильностью.

Так error budget разрешает спор «разработка хочет катить быстрее, а эксплуатация хочет стабильности»: пока бюджет есть, катим; кончился, стабилизируемся. Решение принимается по числу, а не по ощущениям.

Связь с алертами

SLO задаёт, на что алертить. Алерт из прошлого урока полезнее всего, когда он привязан к расходу error budget: «бюджет ошибок выгорает слишком быстро» важнее, чем сырой порог на метрике. Это и есть алерт на симптом, а не на причину.

Что важно запомнить

SLI измеряет качество сервиса глазами пользователя (доля успешных запросов, скорость, доступность). SLO это цель по SLI, которую ставят меньше 100% сознательно, потому что абсолютная надёжность бесконечно дорога.

Error budget — допустимая доля сбоев (100% минус SLO). Он превращает надёжность в решение: есть бюджет, можно рисковать и катить чаще; кончился, надо стабилизироваться. Лучшие алерты привязаны к расходу бюджета.

Этим закрывается трек про наблюдаемость: сигналы, логи, метрики, дашборды, алерты и SLO.