Error Budgets и SLO

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

В каждой софтверной компании идёт один и тот же спор: product-менеджер хочет катить фичи быстрее, а инженер, отвечающий за стабильность, хочет сначала починить техдолг и повысить надёжность. Обе стороны правы, и у обеих нет общего языка для принятия решений. Product-менеджер оперирует 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% запросов должны получать успешный ответ за менее чем 300ms» — это SLO. SLO — это внутреннее обещание, которое команда даёт себе и другим командам в организации. Ключевое слово — внутреннее: SLO не видны пользователям.

SLA (Service Level Agreement) — юридическое обязательство перед клиентами с финансовыми последствиями. «Если uptime за месяц ниже 99.95%, мы компенсируем 10% стоимости подписки». SLA — это контрактный документ, и он обычно мягче, чем 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 — это расходуемый ресурс, как бюджет компании. Вы можете потратить его на что угодно: на рискованные деплои, на миграцию базы данных, на эксперименты с новой инфраструктурой. Пока бюджет не исчерпан — катите фичи. Когда бюджет подходит к концу — остановитесь и инвестируйте в надёжность.

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

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

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

Google предлагает следующую модель: если сервис превысил свой error budget за предыдущие четыре недели (то есть SLO нарушен), команда замораживает все изменения, кроме P0/P1 багфиксов и патчей безопасности, до тех пор, пока сервис не вернётся в рамки SLO. Это звучит драматично, но на практике работает как саморегулирующийся механизм: когда разработчики знают, что нарушение 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% как цель. Это даёт error budget, который можно расходовать, и при этом мотивирует улучшать надёжность. 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%, это в рамках нормы, мы приняли этот риск осознанно».