Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях - страница 31

В идеальном случае при работе с DevOps разработчики постоянно быстро получают обратную связь, что дает им возможность быстро и независимо внедрять, интегрировать и валидировать код, а также обеспечивать развертывание кода в производственной среде (это могут делать как они сами, так и другой отдел).

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

Наиболее легко это достигается, когда архитектура модульная, хорошо инкапсулированная, в ней отсутствуют тесные связи между компонентами, так что небольшие группы имеют возможность работать с высокой степенью автономности, возникающие сбои оказываются небольшими и с ограниченными последствиями, не вызывающими глобальных нарушений работоспособности системы.

При таком сценарии время развертывания измеряется минутами или в худшем случае часами. Получившаяся карта потока ценности должна выглядеть примерно так, как показано на рис. 4.

Рис. 4. Технологический поток создания ценности с развертыванием за минуты

Помимо времени выполнения заказа и времени производства для оценки технологического потока создания ценности применяется и третий показатель – доля завершенной и правильной работы (percent complete and accurate – %C/A). Этот показатель отражает качество выполнения на каждом этапе потока создания ценности. Карен Мартин и Майк Остерлинг утверждают: «показатель %C/A можно получить, опросив клиентов, как часто в количественном выражении они получали продукт, пригодный к использованию сразу. Подразумевается, что они используют результат без необходимости его корректировать, добавлять пропущенную информацию или пояснения к имеющейся, если она недостаточно понятна».

В книге The Phoenix Project «три пути» представлены как основополагающие принципы. Из них выводится DevOps и его методы (рис. 5).