Error Budget Gating

«Морозим или катим?» Когда этот вопрос задают в день инцидента, отвечает на него не бюджет ошибок, а тот, кто старше по должности. Я регулярно вижу команды, у которых бюджет посчитан, выведен на дашборд и даже записан в политику, а релизы едут как ехали. Между числом на графике и кнопкой выкатки у них нет ничего, кроме чьей-то памяти о договорённости.

Error Budget Gating закрывает именно этот разрыв: проверка остатка бюджета встроена в путь изменения и срабатывает по правилам, согласованным заранее. Вопрос у неё один — может ли сервис сейчас позволить себе ещё один риск. Ответов три: едем, едем медленнее, ждём.

Границы с соседями. SLO Engineering отвечает за то, откуда берётся бюджет и как он считается. SLO / Budget Review — ритуал, на котором правила пишут и пересматривают. Change Governance делит изменения на классы и объявляет заморозки по календарю. Ближе всех Progressive Delivery, и с ним путают чаще всего: гейт канарейки судит один релиз по его собственным метрикам за минуты, гейт по бюджету судит сервис по накопленному за окно и решает, пускать ли рискованное изменение вообще.

Что должен уметь

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

Перед выкаткой смотрит остаток бюджета сервиса и знает, в какой зоне политики сервис сейчас; рискованное изменение в закрытой зоне не выкатывает без записанного исключения.
Отличает изменение, которое тратит бюджет, от изменения, которое останавливает расход: исправление причины едет и при закрытом гейте.

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

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

L6+

Сводит правила гейтов зависимых сервисов, чтобы заморозка у одного не становилась сюрпризом для десяти.
Выделяет классы ущерба, к которым бюджет неприменим: потерю данных и утечку «в пределах бюджета» не допускают, для них ставятся другие рубежи.
Следит, чтобы гейт не стоял закрытым месяцами: хронически исчерпанный бюджет — вопрос к цели SLO, а не к дисциплине выкатки.

Материалы

Книги

Betsy Beyer et al. (eds) — Site Reliability Engineering (O’Reilly, 2016), глава 3 «Embracing Risk», автор Marc Alvidrez. Отсюда сама идея: пока SLO выполняется, релизы идут, бюджет израсходован — релизы встают. Советую дочитать до места, где такой выключатель назван простым приёмом и следом предложены подходы тоньше: замедлять релизы заранее, когда бюджет на исходе.
Betsy Beyer et al. (eds) — The Site Reliability Workbook (O’Reilly, 2018), приложение B «Example Error Budget Policy». Одна страница, с которой удобно начинать свою политику. Обязательно прочитать список случаев, когда команда продолжает работу над фичами при исчерпанном бюджете: по моим наблюдениям, при переносе к себе его теряют первым.
Betsy Beyer et al. (eds) — The Site Reliability Workbook (O’Reilly, 2018), глава 3 «SLO Engineering Case Studies». Истории Evernote и The Home Depot от первого лица. Читать целиком не обязательно: к гейту относится один эпизод Evernote 2017 года, он разобран ниже.

Статьи и доклады

Alex Bramley — Consequences of SLO violations — CRE life lessons (Google Cloud Blog, 2018). Лучшее из известных мне описаний ступеней: нарушения группируются по накопленному расходу бюджета, у каждой группы своё последствие. Отдельно ценна оговорка автора: организация, которая в момент нарушения SLO бросает все начатые фичи, встречается редко.
Tim Falzone, Ben Treynor Sloss — The Evolution of SRE at Google (;login:, USENIX, 2024). Граница применимости, названная самим Google: бюджеты ошибок хорошо служили сервисам без состояния, а для потерь, которые не должны случиться ни разу, бюджет равен нулю. Обязательно к прочтению перед тем, как вешать гейт на всё подряд.
Мой разбор — Надёжность строится в диалоге с бизнесом (jtprog.ru, май 2026). Про то, почему политика бюджета — документ продукта, а не инженерии: кто останавливает релизы, кто разрешает продолжить и чья подпись стоит под правилами. Писал его потому, что, по моим наблюдениям, спор о заморозке упирается в подпись гораздо чаще, чем в порог. Там же пример политики на одну страницу.
Мой разбор — Скорость сгорания бюджета ошибок — что тут не так? (jtprog.ru, апрель 2026). К гейту относятся два места в конце: бюджет на скользящем окне возвращается сам, когда старый инцидент выходит из окна, а на малом трафике одна случайная ошибка даёт коэффициент расхода в тысячи.

Инструменты

Sloth — вместе с алертами генерирует запись slo:period_error_budget_remaining:ratio, остаток бюджета за окно. Гейту хватает одного запроса к ней. По моим наблюдениям, если SLO уже описаны через Sloth, считать остаток отдельно не приходится.
Pyrra — тот же остаток бюджета и список SLO, отсортированный по нему. Удобна, пока гейт ручной и остаток перед выкаткой смотрит человек.
Argo Rollouts — анализ перед переключением трафика: запрос в Prometheus решает, продолжать выкатку или прервать. Имеет смысл, когда выкатка уже идёт через Rollouts; ставить его ради одного гейта избыточно.
Шаг в конвейере — скрипт, который спрашивает у Prometheus остаток бюджета и завершается с ошибкой ниже порога. По моим наблюдениям, чаще берут именно его: он работает с любым CI и читается за минуту.

Шаблоны

Error Budget Policy — заготовка политики из этого репозитория. Гейт исполняет её разделы «Пороги и действия», «Заморозка» и «Случаи вне контроля команды»; пока политика не заполнена, проверять в конвейере нечего.

Best practices

Короткий публичный пример того, как выглядит решение по бюджету вместо решения по должности, есть у Evernote. В 2017 году команда ловила сложный баг, и разработка попросила разбить обычный еженедельный релиз на несколько отдельных окон, каждое из которых могло задеть пользователей. Спор «можно или нельзя» заменили расчётом по SLO: оценили, во что эти окна обойдутся пользователям, и вместо пяти оставили два. Историю рассказывает сам Evernote в третьей главе SRE Workbook. Мне в ней нравится исход. Гейт не сказал «нет», он изменил форму релиза.

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

Ступени вместо выключателя. Схема «бюджет есть — катим, бюджета нет — стоим» описана ещё в SRE Book, и там же названа простым приёмом, после которого идут подходы тоньше. Команда CRE пишет откровеннее: организация, которая в момент нарушения SLO бросает все начатые фичи, встречается редко. Я считаю это главным доводом за ступени. Выключатель, который никто не готов дёрнуть, не работает. Ступень «новых экспериментов не начинаем» дёргают без спора, а следующая за ней, «едут только исправления», к тому моменту уже никого не удивляет. Сколько ступеней и на каких процентах, зависит от критичности сервиса; отправная таблица есть в шаблоне политики.

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

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

Мне попадались команды, уверенные в своём бюджете ровно до вопроса, как считается SLI. Оказывалось, что это доля успешных HTTP-ответов. Запрос, который вернул 200 за пятнадцать секунд, в такой бюджет не попадает, и гейт остаётся открытым посреди деградации, на которую уже жалуются в поддержку. Гейт не умнее своего индикатора. Прежде чем вешать на бюджет остановку релизов, я проверяю простую вещь: тратится ли бюджет тогда, когда пользователю плохо.

У гейта по бюджету есть три места, где он не работает. Первое назвал сам Google в 2024 году: бюджеты ошибок хорошо служили сервисам без состояния, а для потерь, которые не должны случиться ни разу, — утечки, потери данных, нарушения требований регулятора — бюджет равен нулю, и торговать им нельзя. Второе — малый трафик. При одном запросе в час единственная ошибка выглядит как расход на порядки выше нормы, и гейт хлопает от случайности. Третье — хронически исчерпанный бюджет. Гейт, закрытый третий месяц подряд, перестаёт быть гейтом: все изменения едут исключениями, и запись об исключении превращается в формальность. Я не уверен, что из этого состояния есть выход на уровне гейта; по моим наблюдениям, он лежит в пересмотре цели.

Связанные листья

SLO Engineering — откуда берётся число, на которое смотрит гейт. Без принятого SLO проверять нечего.
SLO / Budget Review — там правила гейта пишут и пересматривают; здесь — как они исполняются между ревью.
Progressive Delivery — гейт внутри одной выкатки. Оба гейта нужны вместе: один решает, пускать ли изменение, второй — как далеко оно уедет.
Change Governance — классы изменений, по которым гейт различает, что останавливать, и заморозки по календарю рядом с заморозкой по бюджету.
SLI-based Alerting — алерты на burn rate дают гейту второй вход, быстрый расход.
Problem Tracking — класс отказов, который раз за разом съедает бюджет, — это проблема со своей записью, а не повод для очередной заморозки.
Stakeholder Management — подпись владельца продукта под правилами гейта добывается там.
Production Readiness Review — проверка готовности до первого релиза; гейт по бюджету работает после него.

Открытые вопросы

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

Рядом лежат зависимости. Пример из SRE Workbook разрешает продолжать фичи, если бюджет съел сервис соседней команды, которая сама остановила релизы. Как проверять это автоматически, когда зависимостей десятки, я не знаю. Расчёт составных целей разобран в Composite SLO Methodology, но как переложить его на гейты, мне пока неясно.

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