Сообщить об ошибкеКороткий ответ
Однозначного рецепта нет — распространённый подход: при исчерпании error budget за текущий период автоматически или по процессу ужесточать политику релизов (например, требовать дополнительное одобрение, снижать скорость раскатки canary, временно замораживать неприоритетные релизы), а при здоровом запасе budget — разрешать более быстрые и смелые релизы; конкретные пороги и то, что именно замораживается, нужно обсуждать и калибровать с владельцами продукта, а не выводить как универсальное правило.
Как это работает подробнее
SLO определяет допустимый уровень ошибок/недоступности за период (например, 99.9% успешных запросов за 30 дней), а error budget — оставшийся «запас» на этот период. Если budget почти исчерпан, системы релизов могут автоматически требовать более строгих gate (дольше bake time в canary, обязательное ручное одобрение, временная заморозка некритичных деплоев), пока budget не восстановится или не начнётся новый период.
Пример кода
SLO: 99.9% успешных запросов за скользящие 30 дней (error budget = 0.1%)
Текущее потребление budget: 85% за 18 дней периода
Политика (для обсуждения, не универсальное правило):
- budget > 50% оставшегося -> обычный процесс релизов
- budget 10-50% -> обязательное canary с увеличенным bake time
- budget < 10% -> заморозка некритичных релизов, кроме security-патчейСравнение
- Компромисс. более строгая связка error budget с release gate повышает надёжность, но замедляет разработку и может демотивировать команду при частых заморозках, особенно если SLO выбраны слишком строго для реальных возможностей системы; более мягкая связка быстрее по разработке, но не создаёт реального стимула для инвестиций в надёжность. Выбор зависит от зрелости организации, критичности сервиса и готовности продуктовой стороны учитывать технический риск в приоритизации.
Что использовать на практике
- На практике. такая связка мотивирует команды самостоятельно балансировать скорость и надёжность без постоянного ручного вмешательства менеджмента, но требует зрелой системы мониторинга, которая действительно измеряет то, что важно для пользователей (а не просто технические метрики), и прозрачного процесса, что именно замораживается при исчерпании budget — часто замораживают именно рискованные изменения, а не вообще все релизы (например, security-патчи обычно исключение).
- Пример. Задача для обсуждения: кандидату — оценить эту политику, предложить, как избежать ситуации, когда команда намеренно скрывает ошибки, чтобы не триггерить заморозку, и как объяснить такую политику продуктовым стейкхолдерам.
Подводные камни
- Частые ошибки. вводят жёсткую полную заморозку всех релизов при исчерпании budget без исключений, что создаёт стимул занижать реальные инциденты, лишь бы не остановить работу; устанавливают SLO произвольно, без согласования с реальными ожиданиями пользователей/бизнеса, из-за чего error budget перестаёт быть осмысленным сигналом.