Error Budgets и SLO

Вечный конфликт

В каждой софтверной компании идёт один и тот же спор: продакт хочет катить фичи быстрее, а инженер, отвечающий за стабильность, требует сначала закрыть техдолг и поднять надёжность. Обе стороны правы, и у обеих нет общего языка. Продакт оперирует revenue и сроками, инженер — uptime и числом инцидентов; метрики живут в разных системах координат.

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

Google SRE-книга 2016 года предложила механизм, превращающий политический конфликт в инженерное решение: error budgets.

SLI, SLO, SLA — три уровня

Перед разговором об error budgets стоит разобраться с тремя аббревиатурами, которые часто путают.

SLI (Service Level Indicator) — конкретная измеряемая метрика. Доля успешных HTTP-ответов (статус 2xx/3xx), латентность 95-го перцентиля, время от события до доставки уведомления. SLI берётся из мониторинга. Хороший SLI отражает то, что пользователь воспринимает как «работает»: если API отвечает за 10 секунд с кодом 200, технически он «работает», но пользователь считает иначе.

SLO (Service Level Objective) — целевое значение SLI, которое команда устанавливает внутри себя. «99.9% запросов должны получать успешный ответ за менее чем 300 ms» — это SLO. Внутреннее обещание команды себе и другим командам в организации. Ключевое слово — внутреннее: SLO не видны пользователям.

SLA (Service Level Agreement) — юридическое обязательство перед клиентами с финансовыми последствиями. «Если uptime за месяц ниже 99.95%, мы компенсируем 10% стоимости подписки». Контрактный документ, обычно мягче SLO: при SLO 99.9% SLA ставят на уровне 99.5%, чтобы оставить запас.

Error budget: математика надёжности

Error budget — это количество ошибок, допустимое в рамках SLO. Формула тривиальна: при SLO 99.9% успешных запросов за 30 дней error budget равен 0.1%. При миллионе запросов в день это 1000 запросов, которые могут завершиться ошибкой за день, или 30000 за месяц.

В модели Google SRE error budget — расходуемый ресурс, аналог бюджета компании. Его тратят на рискованные деплои, миграцию базы, эксперименты с новой инфраструктурой. Пока бюджет не исчерпан — фичи катятся. Когда бюджет подходит к концу — остановка и инвестиции в надёжность.

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

Error budget policy: правила игры

Error budget без политики — красивый дашборд, на который все смотрят и ничего не делают. Error budget policy — документ, описывающий, что происходит, когда бюджет заканчивается.

Модель Google: если сервис превысил error budget за предыдущие четыре недели (SLO нарушен), команда замораживает все изменения, кроме P0/P1 багфиксов и патчей безопасности, пока сервис не вернётся в рамки SLO. Звучит драматично, но работает как саморегулирующийся механизм: разработчики, зная о заморозке как последствии, сами начинают вкладываться в тестирование, canary-деплои и мониторинг — предотвратить заморозку дешевле, чем пережить.

Пример policy, адаптированной под реальную команду:

Бюджет > 50%: зелёная зона. Катим фичи, экспериментируем, допускаем рискованные изменения.
Бюджет 20–50%: жёлтая зона. Все изменения через canary-деплой, post-deploy мониторинг обязателен, рискованные миграции откладываются.
Бюджет < 20%: красная зона. Приоритет — надёжность. Новые фичи замораживаются, команда фокусируется на устранении причин потери бюджета.
Бюджет исчерпан: полная заморозка. Релизы — только багфиксы и security-патчи.

Как выбрать правильный SLO

Типичная ошибка — ставить SLO «повыше», потому что 99.99% выглядит лучше, чем 99.9%. Каждая девятка стоит экспоненциально дороже: разница между 99.9% и 99.99% — error budget в десять раз меньше, инвестиций в отказоустойчивость, мониторинг и тестирование в десять раз больше.

Правильный SLO определяется тем, что замечают пользователи. API внутреннего backoffice на 50 человек в рабочее время — 99.5% может быть достаточно. Платежи в реальном времени — 99.99% оправдан, каждая ошибка стоит денег и доверия.

Стартовать стоит с SLO чуть выше текущего реального показателя. Сервис исторически держит 99.7% — цель ставится 99.9%. Бюджет есть что расходовать, мотивация улучшать надёжность сохраняется. SLO 99.99% при реальных 99.5% — фикция, которая будет постоянно нарушена и перестанет восприниматься как ориентир.

SLO и Developer Experience

Связь SLO с DX — в предсказуемости. Когда у команды есть чёткий SLO и error budget policy, разработчики понимают правила игры: знают, сколько риска можно принять, когда вкладываться в надёжность, а когда катить агрессивнее. Это снижает тревожность — вместо размытого «а вдруг сломается» появляется конкретное «осталось 62% бюджета, можно катить».

Error budgets защищают разработчиков от бесконечной гонки за надёжностью и от выгорания на on-call. Без SLO каждый инцидент воспринимается как катастрофа, менеджмент требует «чтобы такое больше не повторялось», и это ведёт к over-engineering и параличу деплоев. С error budget ответ другой: «потеряли 0.02% бюджета, осталось 0.08%, в рамках нормы, риск принят осознанно».