SLO и бюджет ошибок: считаем допустимые сбои сервиса на конкретном примере

В отчёте сервиса написано «доступность 99,9%», но после инцидента команда спорит, насколько серьёзно нарушена цель. Одни считают минуты простоя, другие — HTTP-ошибки, третьи исключают ночное время. Чтобы число помогало принимать решения, сначала нужно договориться о событии и границах измерения.

Возьмём API чтения заказов. За фиксированные 30 суток учитываются клиентские запросы выбранного production-маршрута. Успех означает корректный ответ по согласованному правилу; серверные ошибки и timeout считаются плохими событиями. Ошибки клиента, retries и исключения нужно определить отдельно, чтобы числитель и знаменатель описывали одну пользовательскую задачу.

От измерения перейдём к цели

SLI — измеренная доля хороших событий среди всех учитываемых. SLO — целевая граница этой доли за заданный период. Если цель равна 99,9%, допустимая доля плохих событий равна 0,1%. При миллионе учитываемых запросов это бюджет 1000 плохих запросов.

Пусть хороших ответов оказалось 998400 из миллиона. Плохих — 1600, доступность — 99,84%. Бюджет израсходован на 160%, остаток равен −600 запросов. Отрицательный остаток говорит о превышении цели, а не о том, что системе физически запрещено принимать следующий запрос.

from decimal import Decimal

total = 1_000_000
good = 998_400
target = Decimal('0.999')
bad = total - good
budget = Decimal(total) * (1 - target)
remaining = budget - bad
print('SLI percent:', Decimal(good) / total * 100)
print('bad:', bad)
print('budget:', budget)
print('remaining:', remaining)
print('budget consumed percent:', Decimal(bad) / budget * 100)

Числовые результаты: SLI 99,84%, bad 1600, budget 1000, remaining −600 и расход 160%. Decimal сохраняет десятичное определение цели. В реальном расчёте проверьте total > 0 и допустимый диапазон good: отсутствие трафика нельзя автоматически трактовать как доказанную доступность.

Почему нельзя сразу перевести бюджет в минуты

Пример основан на запросах. Минутный отказ в пиковое время может потратить больше бюджета, чем десятиминутный ночью. Пересчёт 0,1% от длительности месяца описывал бы другую модель — доступность по времени с собственным определением успешного интервала. Смешивать её результат с количеством ошибочных запросов нельзя.

Даже request-based SLI зависит от точки измерения. Счётчик внутри приложения не увидит запросы, которые не дошли до процесса. Если важен весь пользовательский путь, выбирайте измерение на подходящей границе или дополняйте его внешними проверками. Зафиксируйте источники и известные пробелы в определении SLI.

Свяжем число с решением

Бюджет полезен, когда команда заранее согласовала действия при его быстром расходе и исчерпании. Например, при превышении за период ограничиваются рискованные изменения, а работа по надёжности получает приоритет. Конкретные исключения, ответственные и способ разрешения разногласий оформляются в политике, а не придумываются во время спора о релизе.

Один остаток за 30 дней не показывает текущую скорость ухудшения. Поэтому рядом полезен расход за короткие окна относительно допустимой доли ошибок. Большой недавний всплеск требует реакции раньше, чем длинный период полностью исчерпается. При редком трафике короткие окна особенно чувствительны к единичным ошибкам; правило должно учитывать объём наблюдений.

Выберем период без скрытых изменений

Календарный месяц и скользящие 30 суток ведут себя по-разному. В календарной модели граница периода обнуляет накопленный расчёт, в скользящей старые события постепенно выходят из окна. Сравнивайте отчёты только с одинаковым определением времени и учётом часового пояса.

Изменение маршрутов, кодов успеха или исключений меняет смысл показателя. Если одновременно сузить denominator и поднять SLI, нельзя объявлять это техническим улучшением без объяснения нового состава событий. Храните определение рядом с запросом и примерами.

Начните с одной важной операции и проверьте счёт на известном учебном наборе. Когда участники одинаково отвечают, что считается плохим запросом, откуда он наблюдается и какое действие следует из расхода бюджета, SLO становится рабочим способом обсуждать надёжность и темп изменений.

Ещё по теме

• Как разобрать инцидент после восстановления: хронология, причины и проверяемые действия
• Высокий load average при свободном CPU: куда смотреть в Linux

Продолжить изучение

Хотите глубже разобраться в надёжности сервисов и работе с инцидентами? Посмотрите программу «DevOps Engineer PRO: от Junior до Middle».