Error budget: когда выпускать новые функции, а когда исправлять сбои

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

Допустим, разработчики подготовили новую корзину, а за последнюю неделю сайт несколько раз терял заявки. Обсуждение «выпускать или подождать» легко превращается в спор между сроками и осторожностью. Заранее согласованная политика позволяет опираться на измерения, понимать последствия решения и называть человека, который принимает исключение.

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

Что меняет политика бюджета ошибок

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

В примере политики Google SRE предусмотрены приостановка обычных изменений при нарушении SLO и исключения для наиболее срочных проблем и исправлений безопасности. Это пример организационного соглашения для конкретной ситуации, а не обязательный стандарт для каждого сайта. Заимствовать стоит понятную структуру решения; пороги, сроки и полномочия выбирает ваша команда.

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

Как рассчитать бюджет запросов и его остаток

Для показателя, основанного на запросах, сначала фиксируют общее число учитываемых операций и число плохих результатов за одно и то же окно. Критерий плохого события берут из выбранного SLO. Это может быть ошибка, превышение времени или невыполнение другого согласованного условия.

В руководстве Google SRE по внедрению SLO рассматривается подход через отношение хороших событий ко всем учитываемым. Для такой модели формулы просты:

• Допустимая доля плохих событий: q = 1 − SLO, где SLO записан долей, например 0,999.
• Бюджет окна: B = N × q, где N — число учитываемых событий.
• Остаток: R = B − E, где E — фактическое число плохих событий.
• Доля оставшегося бюджета: R / B × 100%, если B больше нуля.

Условный сервис за последние 28 дней обработал 500 000 учитываемых запросов. Его SLO — 99,9%, плохих событий — 180. Тогда допустимая доля составляет 0,1%, бюджет — 500 событий, расход — 180, остаток — 320. Из бюджета осталось 64%, израсходовано 36%. Фактическая успешность равна 99,964%.

Это снимок текущего окна, а не заранее выданные 320 разрешений на будущие ошибки. При поступлении запросов и смещении окна изменяются и N, и E. Не округляйте дробный бюджет вверх, чтобы получить лишнее допустимое событие: условие соответствия остаётся E ≤ N × q.

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

Если SLO определён через долю времени работоспособности, единицей расчёта становится время. Для 28 суток непрерывного наблюдения имеем 40 320 минут. При цели 99,9% допустимая доля составляет 0,1%, а бюджет — 40,32 минуты, то есть 40 минут 19,2 секунды. После подтверждённых 12 минут неработоспособности остаётся 28,32 минуты.

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

Есть и модель хороших временных окон: например, минута считается хорошей при выполнении заданного условия. Тогда считаются окна, а не непрерывные секунды простоя. Для 40 320 минутных окон и цели 99,9% математический бюджет равен 40,32 плохого окна; 41 полностью плохое окно уже нарушит цель.

Десять минут отказа ночью и десять минут в часы спроса одинаковы в простой временной модели, но могут дать разное число неуспешных запросов. Поэтому переводить бюджет запросов в минуты без модели нагрузки нельзя. Храните значения с единицами и не складывайте разные бюджеты в один общий остаток.

Как календарный и скользящий период меняют картину

В календарном периоде заранее известны границы: например, начало и конец месяца. В скользящем окне каждый расчёт охватывает последние 28 дней или другой установленный срок. Новые события входят в расчёт, старые выходят. Такие варианты описаны в документации Google Cloud по мониторингу SLO.

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

В календарном периоде заранее неизвестно окончательное количество запросов. Остаток, вычисленный по уже наблюдавшемуся трафику, отличается от прогноза на весь месяц. Если система использует прогноз, подпишите допущение и не выдавайте его за гарантированную будущую ёмкость бюджета.

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

Burn rate: с какой скоростью расходуется бюджет

Остаток показывает накопленное состояние, а burn rate помогает заметить быстрое ухудшение. Для модели запросов это отношение текущей доли плохих событий к допустимой доле: burn rate = error ratio / (1 − SLO). Формула предполагает цель ниже 100%: при нулевом допустимом бюджете такое отношение не определено. В главе Google SRE об оповещениях по SLO этот показатель используется для обнаружения существенного расходования бюджета до его полного исчерпания.

Продолжим учебный пример. За последний час было 20 000 запросов, из них 60 плохих. Доля ошибок равна 0,3%. При допустимых 0,1% burn rate составляет 3: наблюдаемая доля плохих событий втрое выше согласованной. Эти 60 событий уже входят в 180 ошибок предыдущего расчёта; повторно прибавлять их не нужно.

Относительно бюджета текущего окна в 500 событий этот час содержит 12% расхода: 60 / 500 × 100%. При этом burn rate 3 не означает расход 3% бюджета в час. Одно число сравнивает доли ошибок, другое — фактическое количество событий с бюджетом окна.

Особенно осторожно относитесь к прогнозу «бюджет закончится через столько-то дней». При неравномерном трафике и скользящем окне результат зависит от будущей нагрузки, качества и выхода старых событий. Достовернее показать текущий burn rate, объём наблюдений и фактический расход за выбранный интервал, чем обещать точный момент исчерпания.

Для оперативной реакции полезно сравнивать короткий и более длинный интервал: продолжается ли ухудшение сейчас и сколько ущерба уже накопилось. Параметры выбирают под поток операций. У малопосещаемой формы одна ошибка резко меняет долю, поэтому рядом нужны количество попыток и отдельный контроль полного отказа.

Что делать, если данных недостаточно

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

Например, журнал приложения видит запросы, дошедшие до обработчика. Отказ DNS или сетевой доступности может произойти раньше и не попасть в этот журнал. Внешняя проверка помогает заметить такую ситуацию, но её собственные запросы не становятся измерением всего пользовательского трафика. Для каждой границы нужен ясный источник.

Если пропущенный интервал можно восстановить по достоверным журналам, пересчитайте показатель и зафиксируйте происхождение данных. Если нельзя, сохраните состояние «неизвестно» и описание пробела. Консервативно учитывать пропуск как плохой интервал допустимо только по заранее принятому правилу, с видимой отметкой такого решения.

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

Как определить исключения из расчёта

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

Заранее определите отношение к тестовому трафику, заведомо некорректным запросам, служебным адресам и согласованным работам. Исключение должно иметь объяснение с точки зрения выбранного показателя. Если пользовательское действие действительно не выполнено, удобная для отчёта причина сама по себе не делает событие хорошим.

Отказ внешней зависимости тоже не исчезает из пользовательского опыта. Можно отдельно назначить ответственность за устранение причины и разрешить некоторые работы вашей команды. Но удалять такой отказ из бюджета следует лишь тогда, когда это соответствует заранее определённой области SLO.

Ошибку классификации нужно исправлять: например, тестовый прогон действительно попал в производственный счётчик. Сохраните исходные и исправленные значения, основание и автора изменения. Снижение самой цели SLO ради текущего релиза требует отдельного продуктового решения и новой версии соглашения; его нельзя незаметно применять задним числом.

Пример политики для небольшой команды

Ниже — авторский учебный вариант для одного критичного процесса с уже выбранным SLO. Он показывает структуру правил; границы 50% и условия реакции не являются отраслевыми нормативами. Сначала действует ограничение при серьёзном инциденте. Если такого инцидента нет, существенный пробел измерений или отсутствие учитываемых событий переводит решение в состояние «Неизвестно». При достоверных данных и ненулевом числе учитываемых событий нулевой или отрицательный остаток означает ограничение изменений. Только при положительном остатке выбирают обычную работу или повышенное внимание; сигнал ускоренного расхода не отменяет более строгое ограничение.

Состояние	Условие примера	Решение
Обычная работа	Остаток больше 50%, данные полны и расчёт проверен, нет активного серьёзного инцидента и сигнала ускоренного расхода	Обычный процесс релиза с проверками и возможностью восстановления
Повышенное внимание	Данные полны и расчёт проверен, нет активного серьёзного инцидента, остаток положительный; при этом он не превышает 50% либо зарегистрирован ускоренный расход	Владелец оценивает риск изменения; команда уменьшает объём релиза и назначает работу по причине расхода
Ограничение изменений	Продолжается серьёзный инцидент либо при полных достоверных данных и ненулевом числе учитываемых событий остаток не больше нуля	Обычные функции откладываются; разрешаются согласованные аварийные, восстановительные и безопасностные исправления
Состояние неизвестно	Нет активного серьёзного инцидента, но есть существенный пробел измерений, неверный расчёт или нет учитываемых событий	Автоматического разрешения нет; сначала проверка данных и решение ответственного

Ускоренный расход также требует конкретного определения. Для учебной команды поводом к немедленному разбору может быть burn rate не ниже 3 за последний час при не менее 2 000 учитываемых запросов. Это сигнал расследования, а не универсальный запрет: для другого трафика порог и минимальную выборку нужно подобрать заново. Полный отказ критичного действия разбирают независимо от выполнения этого условия.

Заморозка относится к внесению определённых изменений в рабочий сервис. Она не запрещает проектирование, подготовку тестов или исправление кода на стенде. Однако при исчерпании бюджета план команды должен явно освобождать время на причины отказов, иначе правило превратится в ожидание удобной даты.

Что делать, когда бюджет исчерпан

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

1. Проверьте расчёт. Подтвердите период, знаменатель, классификацию событий и полноту данных.
2. Объясните основные расходы. Свяжите значимые эпизоды с инцидентами, а не только с линией графика.
3. Выберите конкретные действия. Например, исправить условие тайм-аута, сделать безопасный повтор или добавить проверку перед выпуском.
4. Назначьте владельцев и сроки. У каждой задачи должно быть проверяемое условие завершения.
5. Определите выход из ограничения. Нужны согласованное состояние бюджета, работоспособность процесса и подтверждение обязательных исправлений.

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

Кто разрешает исправления и исключения

Назначьте владельца сервиса, который может принимать продуктовый риск, и технического ответственного, который оценивает последствия изменения. В небольшой команде роли могут совмещаться, но полномочия всё равно стоит назвать явно. Отсутствие владельца не должно оставлять критичное исправление без решения на неопределённый срок.

Политика должна заранее разрешать согласованный путь для устранения действующей аварии, необходимого восстановления и срочного исправления безопасности. У такого изменения тоже есть риск: укажите цель, объём, проверки, способ наблюдения и план действий при ухудшении. Разрешение не означает публикацию без оценки.

Для обычной функции исключение оформляют отдельно: зачем выпуск нужен именно сейчас, какой процесс затрагивает, почему ожидание хуже, кто согласовал и до какого момента действует решение. Запись помогает позже оценить, оправдался ли риск. Формулировка «менеджер попросил» не объясняет ни последствия, ни критерий успеха.

Когда архитектура позволяет, ограниченное развёртывание помогает сначала оценить изменение на части трафика. Такой подход рассматривается в главе Google SRE о canary-релизах. Это дополнительный способ управления выпуском, а не основание игнорировать бюджет. Для изменений данных или несовместимых схем возможность безопасного возврата нужно разбирать отдельно.

Как выглядит решение о конкретном релизе

Вернёмся к условному сервису: в окне осталось 64% бюджета, но за последний час burn rate достиг 3 при 20 000 запросов. Одного хорошего остатка недостаточно, чтобы автоматически выпустить новую корзину. По нашей примерной политике сработал сигнал ускоренного расхода.

Ответственный сначала выясняет, продолжается ли проблема и связан ли расход с изменением, которое хотят выпустить. Если новая корзина добавляет работу в уже нестабильную интеграцию, выпуск откладывают до разбора. Если подготовлен узкий фикс установленной причины, его рассматривают по процедуре восстановления с собственными проверками.

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

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

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

Первые несколько циклов используйте для проверки самой политики. Если она постоянно блокирует необходимые исправления или пропускает явно рискованные изменения, уточните условия на будущие решения. Не переписывайте историю, чтобы старые действия выглядели согласованными с новыми правилами. Сохранение версий позволяет отличить ошибку решения от недостатка первоначального соглашения и улучшать процесс без поиска виноватого.

Вопросы о бюджете ошибок

Нужно ли обязательно израсходовать остаток?

Нет. Положительный остаток позволяет обсуждать допустимый риск и новые функции, но не требует создавать сбои. Решение должно учитывать пользу изменения, готовность проверки и последствия отказа.

Можно ли объединить несколько SLO в один бюджет?

Не складывайте независимые остатки: хороший поиск не компенсирует неработающее оформление заказа автоматически. Для релиза определите, какие процессы он затрагивает и какие условия по каждому из них обязательны.

Обязательно ли блокировать релизы автоматически?

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

Подключите SiteGuard для внешнего HTTP-контроля доступности сайта. Используйте результаты как часть наблюдений; бюджет ошибок и решения о релизах определяет команда.