Применение практик DevOps - стр. 1
Применение практик DevOps
Методы управления ИТ-деятельностью не стоят на месте. Несколько десятков лет назад использовались одни подходы к разработке и эксплуатации информационных систем, сегодня – уже другие, а завтра придёт время следующих, переосмысленных способов и техник, опирающихся на новые знания, опыт и технологии. Бо́льшую часть времени методы управления развиваются эволюционно, путём систематизации и оттачивания созданных ранее моделей, основанных на неких базовых принципах и постулатах. Однако, время от времени происходят скачкообразные изменения, позволяющие отдельным организациям-лидерам сделать существенный шаг вперёд в вопросах эффективности и рациональности применения информационных технологий.
На передовой ИТ-менеджмента находится движение DevOps (сокр. от англ. Development &
Operations), названное так, в целом, довольно случайно. Новое имя собственное настолько же далеко от вкладываемого в него смысла, насколько аббревиатура ITIL далека от понятия «библиотека», а COBIT – от целей контроля (дополнительные сведения можно найти в главе Учебника 4CDTO «Модели и подходы к оценке цифровой зрелости»).
С публикацией COBIT 5 в 2012 году правообладатель подчеркнул, что, несмотря на то, что изначально аббревиатура COBIT являлась сокращением от «Control Objectives for Information and related Technology», теперь она является именем собственным.
Компания AXELOS, управляющая ITIL с 2013 года, также не рекомендует использовать первоначальное наименование «IT Infrastructure Library», ограничиваясь именем собственным ITIL.
Эксперты DevOps, стоявшие у истоков этого движения, признают ограниченность получившегося названия, призывая использовать более точные, на их взгляд, «BizDevOps», «DevSecOps» и подобные. Однако, вероятность изменения названия в настоящее время является незначительной.
Для дальнейшего изложения можно использовать следующее авторское определение, не претендующее на полноту, универсальность и уж тем более истину в последней инстанции: DevOps – продолжение идей гибкой разработки программного обеспечения и бережливого производства, применённое к полной цепочке создания ценности в ИТ, позволяющее добиваться большего от современных информационных технологий за счёт культурных, организационных и инструментальных изменений. Можно утверждать, что появлению DevOps в наибольшей степени способствовали два фактора: развитие гибких методов разработки программного обеспечения и управление ИТ-инфраструктурой, как программным кодом. Рассмотрим каждый из них.
Развитие гибких методов разработки программного обеспечения
В конце прошлого столетия доминирующей методологией разработки программного обеспечения была так называемая «водопадная модель» (или «каскадная модель»): последовательное выполнение заранее определённых этапов, каждый из которых занимает существенное время и завершается достижением заранее согласованных результатов, при этом переход на следующий этап во многих случаях происходит после полного и формального завершения предыдущего этапа (Рис. 1).
Рис. 1. Пример водопадной модели разработки ПО.
Дополнительным отличительным признаком такой модели является функциональная специализация исполнителей отдельных этапов: аналитиков, архитекторов, разработчиков, тестировщиков и т.д.
При разработке крупных информационных систем с конечной функциональностью, которую возможно определить и зафиксировать в самом начале работ, а также при отсутствии требования максимально быстрого завершения полного цикла разработки такая модель позволяет получать качественные выходные результаты при достаточно детальном контроле расходов. Однако в конце 90-х годов XX века, с бурным развитием Интернет-технологий и webпрограммирования, недостатки водопадной модели стали негативно влиять на взаимодействие и взаимопонимание заказчиков (бизнес-подразделений компании, либо внешних организаций) и исполнителей (программистов компании, либо внешних разработчиков программного обеспечения).
Действительно, появляющиеся рыночные возможности для основного бизнеса требовали быстрого – за считанные месяцы – вывода на рынок новых продуктов. В то же время типичный цикл разработки от начала проекта до получения первого работающего результата занимал от 6 до 18 месяцев, а в крупных организациях – до 2-3 лет. Кроме того, в условиях появления ранее неизвестных, но потенциально перспективных рыночных возможностей требования заказчиков могли меняться по ходу проекта разработки, что было крайне сложно учесть при создании ИТсистемы без увеличения сроков, либо снижения качества выходных результатов (Рис. 2).
Рис. 2. Классическая пирамида взаимосвязанных ограничений проектного управления.
Таким образом, накапливалось напряжение между заказчиками и исполнителями, между основным бизнесом и разработчиками ПО. Ответом на такой вызов стали инновационные подходы к программированию. К. Швабер выпустил несколько публикаций о Scrum (например, «Agile Software Development with Scrum», K. Schwaber, 2001, ISBN: 978-0130676344). К. Бек опубликовал книгу об экстремальном программировании – XP («Extreme Programming Explained: Embrace Change», K. Beck, 1999, ASIN: B01FKT01PY). Однако, применение новых идей давало весьма скромные результаты, в основном потому, что такое применение фокусировалось лишь на одном из этапов цикла разработки ПО – на, собственно, программировании, при том, что задача ставилась намного более широкая. Требовалось что-то, что позволит упростить и ускорить весь жизненный цикл ПО.