Бюджет ошибок и его влияние на качество внедрений

Разберем понятие суммарного уровня ошибок и попытаемся достичь максимальной скорости внедрения без изменений качества обслуживания.

Суммарный уровень или error budget

Противоречия между командами разработчиков и инженеров заключается в соотношении темпов внедрения изменений и стабильности продукта.
Мы должны приложить все усилия, чтобы вывести этот конфликт на первый план, а затем постепенно избавляться от него, вводя понятие суммарного уровня ошибок, или бюджета ошибок (error budget).
Это значит что достижение 100%-ной надежности будет необоснованным требованием в подавляющем большинстве случаев. Посудите сами: для любой* системы 100 % — избыточный показатель надежности, поскольку ни один пользователь не заметит разницу между 100% и 99,999%, так как она теряется на фоне случайных факторов, обусловленных недоступностью других систем (wi-fi, ноутбук и т.д.).
Прежде чем начать размышления на тему стремления к 100% уровню надежности, то задайте сами себе следующие вопросы:
• ‰Есть ли у недовольных доступностью пользователей какие-либо альтернативы?
• ‰‰Как на них отразится изменение уровня доступности продукта?
• ‰Какой показатель доступности удовлетворит пользователей, при условии, что мы знаем как и когда они используют продукт?

Нужно ли стремиться к «сотне» и переживать из-за багов?

Коротко: в подавляющем большинстве случаев — нет*.
Система должна иметь установленный целевой показатель доступности.
Как только этот показатель будет определен, также будет определен допустимый суммарный уровень ошибок, который будет равен единице минус запланированный показатель доступности.
Например: доступный в 99,99 % случаев сервис будет недоступен в 0,01 % случаев. 0.01% — ни что иное как бюджет ошибок.
Участники команд вольны тратить этот «бюджет» на все, что хотят, но лучше тратить на что-то полезное (спасибо, кэп🫡).
Однако если бюджет ошибок потрачен или понижен (т.е. сервис работает на уровне, определенном в SLA или ниже его), то запуск любых новых возможностей замораживается до тех пор, пока команда не уменьшит количество ошибок до уровня, позволяющего продолжить запуск.

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

*если речь идет о каком-то сервисе, который подвергает риску жизни людей или большому финансовому убытку, то, безусловно, доступность должна быть 100% (например, системы поддержания жизнедеятельности и иные медицинские сервисы, автоматическая система торможения в автомобиле, системы мониторинга на ГЭС/АЭС и т.д;)


#engineering #sre #management #sla