Релиз готов, но сервис уже несколько раз задерживал клиентам выписки. Продуктовая команда хочет выпустить новую функцию. Дежурные просят сначала разобраться с обработкой документов. Чтобы принять решение, недостаточно спросить, зелёные ли сейчас серверы. Нужно понять, какое качество компания обещала, насколько далеко от него ушла и что может ухудшить следующий выпуск.
SLO задаёт измеримую цель качества за выбранный период. Error Budget, или бюджет ошибок, показывает допустимую долю неудачных результатов относительно этой цели. Польза возникает тогда, когда по этим данным действительно меняются приоритеты работы.
Сначала договориться, что считать хорошей выпиской
Допустим, клиент должен получить корректный документ в течение согласованного времени. Индикатор SLI может считать долю подходящих операций, которые завершились именно так. Ответ «запрос принят» недостаточен: выписка ещё не готова. Быстро вернуть неверные данные тоже не успех.
Требуется определить знаменатель: какие операции участвуют, как учитываются повторы, что происходит с зависшими заданиями. Неудачные попытки нельзя исключать только потому, что они не добрались до последнего сервиса. Иначе авария улучшит статистику: исчезнувших клиентов просто не посчитают.
Внутренние измерения, наблюдение со стороны клиента и синтетические проверки имеют разные слепые зоны. Это стоит записать рядом с показателем. Примеры выбора индикаторов и границ измерения есть в Google SRE Workbook. Цель выбирают для пользовательского результата, а не копируют из настроек системы мониторинга.
Как выглядит бюджет в числах
Условный пример, не рекомендация для любого сервиса: цель — 99,9% подходящих операций за 28 дней. Если за завершённый период их было 100 000, допустимая доля неудач составляет 0,1%, то есть 100 операций. При 60 неудачах использовано 60% бюджета. Больше 100 — цель за этот период не выполнена.
Это бюджет операций, не минут простоя. При неравномерном трафике одинаковый простой в разные часы затронет разное количество работы. Для расчёта по времени нужен другой индикатор; подменять им запросную модель нельзя.
Нужно также выбрать календарный или скользящий период. При скользящем окне старые события постепенно уходят из расчёта, а итоговый объём операций меняется. Начало месяца само по себе не обнуляет такой бюджет. Во время текущего периода нельзя обращаться с остатком как с фиксированной пачкой разрешённых сбоев.
Не ждать, пока запас закончится
Предположим, в недавнем интервале неудачно завершился 1% операций при допустимой доле 0,1%. Отношение равно десяти: это десятикратный burn rate. Он говорит о скорости расходования бюджета относительно цели, но не обещает точную дату исчерпания без предположений о будущем трафике.
Короткое окно помогает заметить резкую аварию, более длинное — устойчивое ухудшение. Их сочетание позволяет отличать продолжающуюся проблему от уже закончившегося всплеска. При малом трафике один отказ сильно меняет процент, поэтому правила уведомлений требуют проверки на реальном потоке. Подходы разобраны в главе об оповещениях по SLO.
Общий показатель может скрыть постоянно страдающую группу. Если небольшой филиал никогда не получает выписки вовремя, хороший результат остальных его не утешает. Полезны отдельные проверки значимых сценариев и групп, но не бесконтрольное размножение целей для каждого пользователя.
Что именно меняется в плане релизов
Заранее согласованная политика должна назвать действия, владельцев и условия возвращения к обычной работе. Например, команда приостанавливает расширение рискованного изменения, выделяет время на устранение причины и продолжает необходимые исправления. Это не означает запретить любые изменения: исправление уязвимости или аварии может требоваться немедленно.
Важно определить, кто разрешает исключение и на основании каких данных. А также что считается восстановлением: не просто прошедшее время, а прекращение ухудшения и достаточные основания продолжать выпуск. Иначе появляется стимул дождаться, пока плохие события выпадут из окна, ничего не исправляя.
В примере политики Google бюджет связывают с приоритетом надёжности, а не с наказанием разработчиков. Для нашей команды это означает реальное изменение обязательств по функциям. Требование «почините всё, но сроки оставьте прежними» не является политикой.
Какие ошибки нельзя списать на оставшийся бюджет
Утечка данных или повреждение финансовых записей требует отдельной реакции, даже если общий процент успешной работы высок. Бюджет качества не даёт разрешения на любой ущерб. Также внутренний SLO не заменяет условия SLA с клиентом: назначение и правила этих договорённостей могут различаться.
Отказ внешнего поставщика всё равно может испортить результат для клиента. Причина влияет на меры восстановления и выбор дальнейших вложений, но не должна автоматически исчезать из пользовательского показателя. Границы и исключения определяют до инцидента, а не под удобный отчёт.
Первый результат — решение по конкретному выпуску
Для начала достаточно одной важной операции и измерений, которым доверяют обе стороны. Перед релизом команда должна видеть выполнение цели, недавнюю динамику, затронутые группы и согласованный вариант действий. Если данных нет, полезнее признать неопределённость, чем объявить запас достаточным.
После нескольких циклов стоит проверить саму договорённость. Помогла ли она вовремя остановить неудачный выпуск? Получила ли команда время на исправление? Совпадают ли показатели с обращениями клиентов? Ответы определят следующие изменения точнее, чем желание добавить ещё одну девятку в цель.