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

При большой продолжительности развертывания сверхусилия требуются практически на каждой стадии потока создания ценности. Может оказаться, что при завершении проекта, когда все результаты труда инженеров собраны воедино, все перестанет работать, код не будет собираться правильно или перестанет проходить тесты. Исправление любой проблемы, определение, кто именно «сломал» код и как это исправить, потребует нескольких дней или даже недель, а в результате отдача для клиентов окажется невысокой.

Идеал DevOps — развертывание за минуты

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

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

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

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

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

Наблюдать за %C/A в качестве оценки необходимости доработок

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

«Три пути»: принципы, лежащие в основе DevOps

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

Рис. 5. «Три пути» (пример взят из текста Джина Кима The Three Ways: The Principles Underpinning DevOps, размещенного в блоге Revolution Press blog по адресу: http://itrevolution.com/the-three-ways-principles-underpinning-devops/

, доступ осуществлен 9 августа 2016 г.)

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

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

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

«Второй путь» обеспечивает быстрый и постоянный поток обратной связи справа налево на всех этапах потока создания ценности. Это требует от нас усиления обратной связи с целью предотвратить повторное появление проблем и получить более быстрое обнаружение и восстановление. При этом мы обеспечиваем качество уже на исходном этапе и создаем или встраиваем знание в те этапы, где оно необходимо, — это позволяет нам создавать все более безопасные системы: проблемы обнаруживаются и исправляются задолго до того, как может произойти катастрофический сбой.