Нужно внедрить подход "SRE: часть времени команды на надёжность, часть на фичи" — как на практике балансировать между релизами и работой над стабильностью с помощью error budget?

Короткий ответ

Error budget даёт объективный, заранее согласованный триггер: пока бюджет не израсходован, команда продолжает релизить фичи в обычном темпе; когда бюджет исчерпан (или сгорает слишком быстро), релизы фич приостанавливаются, и фокус смещается на устранение причин нестабильности, пока бюджет не восстановится.

Как это работает подробнее

error budget policy — это заранее согласованный с продуктовыми и инженерными лидами документ, который однозначно описывает, что происходит при разных уровнях расхода бюджета (например: 50% — предупреждение, 80% — усиленный review рискованных изменений, 100% — заморозка нерисковых релизов фич до восстановления бюджета).

Пример / кейс

Ожидаемое поведение: если за 20 дней из 30-дневного окна израсходовано 85% бюджета из-за серии мелких инцидентов, команда переходит в режим заморозки согласно политике — это обсуждаемое, но заранее согласованное решение, а не спонтанный спор в моменте.

Пример кода

example.txtКопировать

Error Budget Policy (фрагмент):
- Остаток бюджета > 50%: релизы по обычному графику.
- Остаток бюджета 20-50%: обязательный canary-деплой для всех изменений.
- Остаток бюджета < 20%: заморозка нерисковых фич, приоритет — устранение причин нестабильности.

Что использовать на практике

• Практический подход. Политику нужно согласовать до того, как бюджет закончится, а не придумывать реактивно во время спора "почему мы не можем релизить". Полезно считать burn rate (скорость сгорания бюджета), а не только текущий остаток — быстрое сгорание за час требует немедленной реакции, а медленное за месяц даёт время спланировать работу над стабильностью без паники.

Подводные камни

• Частые ошибки. Вводить error budget policy без реального полномочия её соблюдать (менеджмент всё равно продавливает рискованные релизы при исчерпанном бюджете, что обесценивает весь механизм); считать error budget только как инструмент наказания команды разработки, а не совместную договорённость о приемлемом риске; не различать "сгорание из-за внешнего сбоя зависимости" и "сгорание из-за собственных релизов" при анализе причин.