Сообщить об ошибкеКороткий ответ
Единственного правильного решения тут нет: единый глобальный error budget проще администрировать, но скрывает, какая именно команда/сервис реально расходует бюджет, и может либо несправедливо наказывать стабильные команды за чужие инциденты, либо размывать ответственность; решение зависит от степени связанности сервисов, зрелости организации и готовности инвестировать в более детальный мониторинг по сервисам.
Как это работает подробнее
глобальный error budget агрегирует влияние на пользователя на уровне всей системы (например, "доля успешных пользовательских сессий"), что хорошо отражает реальный опыт пользователя в сильно связанных системах, где отказ любого компонента одинаково заметен; но в организации с множеством независимых команд это не даёт сигнала, какая конкретно команда должна менять своё поведение, когда бюджет сгорает из-за чужого сервиса.
Компромисс: можно начать с глобального SLO для видимости общей картины и добавить SLO критичных сервисов постепенно по мере роста зрелости мониторинга; либо сразу внедрить иерархическую модель, если бюджет на инструментирование есть — выбор зависит от размера организации, степени независимости команд и готовности инвестировать в детальную трассировку сквозных запросов.
Пример / кейс
Ожидаемое поведение: команда должна явно обсудить и зафиксировать, какой вариант выбран и почему, включая то, как часто такая ситуация (чужой сервис замораживает несвязанную команду) реально происходит и оправдывает ли это инвестиции в вариант B.
Пример кода
Вариант A (глобальный бюджет): SLO = 99.9% успешных пользовательских сессий.
Проблема: сгорание бюджета из-за бага в сервисе рекомендаций замораживает релизы
несвязанной команды платежей.
Вариант B (иерархия SLO): глобальный SLO 99.9% + отдельные SLO на checkout (99.95%)
и на recommendations (99.5%, некритичный сервис).
Инцидент в recommendations не замораживает релизы checkout.Что использовать на практике
- Практический подход. Альтернатива — иерархия SLO (глобальный SLO для пользовательского опыта плюс отдельные SLO для каждого критичного сервиса в цепочке), что требует больше инструментирования (трассировка, разбивка метрик по сервисам), но даёт точную ответственность. Расплывчатая ответственность в едином бюджете часто приводит к политическим спорам "кто виноват" вместо конструктивной работы над стабильностью, особенно когда freeze релизов из-за чужого инцидента блокирует несвязанную команду.
Подводные камни
- Частые ошибки. Вводить единый бюджет без возможности декомпозировать, кто его расходует, что лишает возможности принимать точечные решения; полностью игнорировать пользовательский end-to-end опыт, уходя в чисто пер-сервисные SLO, которые по отдельности выглядят хорошо, но вместе дают плохой общий опыт из-за накопления задержек/ошибок по цепочке вызовов.