Команда задала SLO доступности 99,9% на 30 дней, но алерт проверяет только полное исчерпание бюджета ошибок. Какой принципиальный недостаток у такого правила?
slo:
target: 99.9%
window: 30d
alert:
condition: consumed_error_budget >= 100%
Такой алерт срабатывает слишком поздно: он замечает уже исчерпанный бюджет ошибок, но не скорость его расходования. Сервис может нарушить SLO задолго до срабатывания правила, а команда потеряет время на остановку релизов и устранение причины.
SLO и бюджет ошибок появились как практический способ связать надёжность с темпом изменений. Вместо требования абсолютной безошибочности команда заранее определяет допустимый объём отказов и использует его для принятия решений о релизах и работах по надёжности.
Самого факта расходования бюджета недостаточно: одинаковый объём ошибок может накапливаться постепенно или возникнуть за несколько минут. Поэтому для оперативного реагирования используют скорость выгорания бюджета и несколько временных окон наблюдения.
При SLO 99,9% за 30 дней допустимая доля неуспешных запросов равна 0,1%. Если серьёзный сбой вызвал 10% ошибок за короткий период, бюджет будет расходоваться примерно в 100 раз быстрее обычного допустимого темпа.
Правило из примера увидит проблему только после накопления всех допустимых ошибок. К этому моменту пользователи уже могли длительно получать ошибки, несколько релизов могли быть выпущены поверх неисправной системы, а остатка бюджета для безопасных изменений не останется.
Скорость выгорания — это отношение фактической доли ошибок к допустимой доле ошибок. Для SLO 99,9% допустимая доля равна 0,1%; фактические 1% ошибок означают скорость выгорания 10.
Высокая скорость выгорания позволяет обнаружить инцидент до полного исчерпания бюджета. На практике проверяют одновременно короткое и длинное окно: короткое быстро обнаруживает резкий сбой, а длинное подтверждает, что это не случайный всплеск измерений.
Одного короткого окна недостаточно: единичная ошибка или кратковременная проблема зависимости может вызвать ложный алерт. Одного длинного окна тоже недостаточно: оно сглаживает резкие ухудшения и задерживает реакцию. Комбинация окон снижает оба риска.
Порог должен учитывать критичность сервиса и требуемое время реакции. Слишком низкий порог создаёт шум и приучает игнорировать алерты, слишком высокий позволяет израсходовать значительную часть бюджета до вмешательства. Для разных SLO применяют разные пороги, а не универсальное число.
Платёжный сервис имел SLO 99,9% и алерт только по исчерпанию 30-дневного бюджета. Во время неудачного релиза доля ошибок выросла до 2%, но команда получила сигнал лишь после нескольких часов деградации.
Рассматривались три варианта. Полный отказ от алерта по бюджету уменьшил бы шум, но лишил бы команду контроля долгосрочного расходования. Алерт только по пятиминутному окну быстрее обнаруживал сбой, но часто срабатывал на кратких проблемах внешней зависимости. Сохранение старого правила не требовало изменений, но оставляло неприемлемо большую задержку реакции.
Выбрали комбинацию: короткое окно для быстрого обнаружения резкого выгорания, длинное окно для подтверждения устойчивой проблемы и отдельный контроль остатка бюджета для планирования релизов. Это разделило оперативное реагирование и долгосрочное управление надёжностью: кратковременные всплески стали реже тревожить команду, а быстрые серьёзные сбои начали обнаруживаться до исчерпания бюджета.
Нет. Само расходование части бюджета ещё не означает, что изменения нужно блокировать. Решение зависит от скорости выгорания, критичности SLO, качества диагностики и остатка бюджета; обычно ограничения усиливают по мере устойчивого превышения допустимого темпа.
Абсолютное число ошибок не учитывает нагрузку. Сто ошибок при ста запросах и при миллионе запросов имеют разный масштаб для пользователей и разный расход бюджета. Для SLO обычно важна доля плохих событий среди общего числа событий, а для малых выборок дополнительно нужны минимальный объём трафика или защитные условия от статистического шума.
В скользящем окне каждое новое измерение вытесняет самое старое, поэтому оценка отражает недавнее состояние и постепенно восстанавливается после инцидента. Это удобно для оперативного контроля, но может скрыть исторический ущерб, если старые ошибки начнут выходить из окна. Для планирования изменений важно явно определить, какое окно используется и как его результаты влияют на решения.