Бюджет ошибок и SLO: как считать без ловушек

При SLO 99,9% за 30 дней сервису доступно примерно 43 минуты и 12 секунд недоступности — если считать по времени. Но при подсчёте запросов тот же SLO означает другое число: на миллион подходящих запросов допустимы 1000 неуспешных. Бюджет ошибок помогает превратить цель по надёжности в измеримое ограничение на релизы и аварии; ошибка в выборе метрики делает это ограничение бессмысленным.

Сначала зафиксируйте, что именно обещает SLO

SLO — целевой уровень качества сервиса, выраженный через измеримую метрику и период. Например: «99,9% подходящих запросов завершаются успешно за скользящие 30 дней». Бюджет ошибок — доля или количество неудач, которые укладываются в эту цель. Для SLO 99,9% он равен 0,1% за тот же период.

Важно определить три вещи до расчётов: что считается успехом, какие события попадают в выборку и как долго действует окно. Успехом может быть ответ без ошибки, ответ быстрее заданного порога или выполнение обеих проверок. Если считать только HTTP 5xx, медленные ответы и ошибки бизнес-логики могут не попасть в бюджет, хотя пользователь уже получил неисправный продукт.

SLI* — сама измеряемая характеристика, например доля успешных запросов. SLO задаёт её цель. SLA — внешнее обязательство перед клиентом, которое может предусматривать компенсации. Эти понятия связаны, но не взаимозаменяемы.

Бюджет ошибок — не разрешение ломать сервис. Это способ заранее договориться, какой риск команда принимает ради скорости изменений.

Две формулы: по времени и по запросам

Для сервиса с SLO 99,9% допустимая доля ошибок равна 1 − 0,999 = 0,001, то есть 0,1%. Дальше расчёт зависит от того, какой SLI лучше отражает опыт пользователя.

Если важна доступность во времени

При окне в 30 дней есть 30 × 24 × 60 = 43 200 минут. Бюджет недоступности: 43 200 × 0,001 = 43,2 минуты. Это упрощённый расчёт для непрерывного сервиса, где каждая минута имеет одинаковый вес. Плановые работы тоже нужно учитывать последовательно: если пользователь не может пользоваться сервисом, исключать этот интервал из SLI можно только по заранее определённому правилу.

Если важен результат каждого запроса

Предположим, за период сервис получил 1 000 000 запросов, входящих в SLI. При бюджете 0,1% допустимы 1000 плохих запросов. Если запросы приходят неравномерно, такой способ не равен подсчёту минут: час пик может иметь большее значение для клиентов, но при слабой нагрузке простой может почти не отразиться на числе запросов.

Не выбирайте метод только потому, что его проще достать из мониторинга. Если клиентский сбой не создаёт запрос — например, сломан вход в систему до обращения к основному API, — запросный SLI может его не заметить. Иногда нужны отдельные SLO на разные пользовательские операции. Не сводите их в одну среднюю цифру: она способна скрыть отказ критичного сценария.

Как считать расход и скорость выгорания

Пусть цель — 99,9%, а доля неуспешных подходящих запросов за выбранное окно составила 0,2%. Отношение фактической доли ошибок к допустимой: 0,2% ÷ 0,1% = 2. Сервис расходует бюджет с темпом в два раза быстрее, чем допускает SLO. Это burn rate, или скорость выгорания бюджета.

Израсходованный бюджет лучше показывать и как долю, и как остаток. Если допустимы 1000 ошибок, а зарегистрировано 600, израсходовано 60%, остаток — 400 ошибок. Для времени формула аналогична: при лимите 43,2 минуты и 30 минутах недоступности потрачено около 69,4% бюджета.

Одна цифра не объясняет, срочно ли нужно реагировать. Расход 60% за весь месяц и 60% за первые два часа — разные ситуации. Поэтому отслеживайте скорость выгорания на нескольких окнах: коротком, чтобы поймать резкий инцидент, и длинном, чтобы увидеть устойчивое ухудшение. Конкретные окна и пороги выбирайте по характеру трафика и времени реакции команды, а не переносите из чужой конфигурации.

Правила, без которых цифра вводит в заблуждение

• Задайте исключения до инцидента. Опишите, какие запросы и клиенты входят в SLI, как обрабатываются отмены, тайм-ауты и внутренние проверки. Не меняйте состав выборки задним числом, чтобы улучшить отчёт.
• Считайте клиентский результат. Успешный ответ от балансировщика не гарантирует, что операция завершилась для пользователя. Проверьте, где именно снимается метрика и не теряются ли ошибки дальше по цепочке.
• Разделяйте SLO по критичным сценариям. Если оплата и загрузка справки имеют разную важность, общая доступность может скрыть проблемы с оплатой. Считайте отдельные показатели там, где различается цена отказа.
• Согласуйте политику бюджета. Заранее решите, что делает команда, когда остаток быстро убывает: например, приостанавливает рискованные изменения и направляет время на надёжность. Это внутреннее правило команды, а не автоматический запрет на любые релизы.
• Проверяйте полноту данных. Пропуски телеметрии нельзя автоматически считать успешными запросами. Отдельно сигнализируйте, когда источник метрик перестал передавать данные.

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

Как применять остаток, а не просто смотреть на график

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

Не трактуйте бюджет как гарантированное число аварий «на будущее». Он относится к заданному окну и меняется по мере поступления событий. При скользящем окне старые ошибки со временем выходят из расчёта; это не отменяет необходимости устранить причину повторяющегося сбоя.

Что делать дальше

Выберите один критичный пользовательский сценарий, сформулируйте для него SLI и SLO, а затем вручную проверьте расчёт на небольшом известном отрезке логов или метрик. Сверьте числитель и знаменатель с реальными событиями, добавьте на дашборд остаток бюджета и скорость выгорания. После этого договоритесь, какое действие команда предпринимает при быстром расходе. Инвалидация кеша и выбор метрик для отдельного компонента — самостоятельные задачи; здесь важен сквозной пользовательский результат.

* SLI (service level indicator) — индикатор уровня сервиса: метрика, по которой проверяют качество услуги для пользователя.