Риски разделяются: если IT-команда не поставила результат, значит вся IT-команда должна перестроиться так, чтобы добиваться желаемого результата. Если рассуждать, как в классическом мире, что баги в коде — это проблемы только разработчиков, то между подразделениями выстраивается стена и они относятся друг к другу враждебно. Но виноваты не люди — виноваты процессы. Поэтому риски разделены между всеми, и, например, в случае ошибок в коде разработчики должны договориться с тестировщиками о том, как им узнавать об ошибках в продакшене, а с эксплуатацией — о том, как можно автоматизировать процесс тестирования, чтобы допускать меньше ошибок. Так все три IT-звена начинают работать сообща и вместе разбираются в проблемах, а не ищут виноватых.
Частота аварий 0-15% при внесении изменений на прод несколько раз в день выглядит интересно)
В смысле кто-то слегка .. заврался? ;)
Вот это забавляет - "Частота внесения изменений по запросу несколько раз в день". Т.е. вы на лету, несколько раз в день будете на прод накатывать обновление. А если обновление вызывает простой сервиса, даже минутный. Какой бизнес согласует такой вариант развёртывания поставок?
На самом деле все эти изыскания очень зависят от двух факторов - платформы и наличия ресурсов, т.е.размер команды. Если у вас 10 человек работает над одним проектом, то ок, пробуем. А если 5 человек работает в режиме многозадачности по 10 проектам, о каких нескольких поставках в день на прод может идти речь?
А если обновление вызывает простой сервиса, даже минутный
Так в этом и есть вся суть подхода, чтобы обновление было без простоя.
Когда команда не может это сделать — тогда девопс и нужен :-) Это больше организационные мероприятия: как разработать и внедрить быстрые и безболезненные выкатки-откатывания + технологическая часть, автоматизировать (читай ускорить и упростить) все что можно — CI\CD, кубер, вот это всё.
Ну, и эта сложность прямо, а не обратно пропорциональна размеру команд (хотя вы тут немного смешиваете, говоря про перегруз людей в мелких командах): чем больше народу = тем сложнее скоординироваться = тем дольше процессы по времени идут.
Время выполнения таски от постановки бизнесом до завершения релиза меньше часа - вот это действительно смешно.
Меньше чем за час ПО описывает задачу ПМ, то заводит ее в трекер, дёргает лида, тот достает из загашника свободного прогера, который быстренько все делает, и прогнав регрессионные тесты (а на крупном проекте только этот этап может сожрать до часа) таска катится в прод - "не верю". По сути автор исследования утверждает что всякие спринты аджайлы и разные методологии разработки это треш, и действительно успешные компании херачат по вотерфолу без тестов...
Это не правило — это возможность. Понятно, что в таком, по сторазвдень выкладки в день, формате развитие продукта невозможно. Но! если нужен критический для бизнеса хотфикс или под случившееся событие какая-то небольшая кастомизация — должна быть возможность сделать это быстро.