Читать книгу: «Применение практик DevOps»

Применение практик 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). Однако, применение новых идей давало весьма скромные результаты, в основном потому, что такое применение фокусировалось лишь на одном из этапов цикла разработки ПО – на, собственно, программировании, при том, что задача ставилась намного более широкая. Требовалось что-то, что позволит упростить и ускорить весь жизненный цикл ПО.

В 2001 году К. Швабер, К. Бек и ещё пятнадцать экспертов встретились, чтобы обсудить имевшиеся проблемы и выработать решение. Итогом стал так называемый манифест Agile (http://agilemanifesto.org/), призванный устранить разрыв понимания между бизнесом и разработчиками ПО (дополнительные сведения можно найти в главе «Управление разработкой ПО»).

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

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

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

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

Действительно, до начала самой разработки имеется ещё значительный блок работ, направленный на выявление бизнес-потребностей, их проработку, анализ, приоритизацию и т.д.

Далее, по окончании разработки, готовый программный код необходимо быстро развернуть в среде эксплуатации, чтобы заказчики получили всю ту пользу, которую им обещали, а также могли предоставить обратную связь разработчикам относительно качества получившегося продукта. При этом почти во всех организациях, возникших до 2010-х годов, ИТ-инфраструктура является жёсткой, основанной на дорогом аппаратном обеспечении, которое было приобретено достаточно давно, бюджеты на закупку и настройку выделялись непросто, да и бюджетный процесс для новых закупок – долгий.

Более того, в подавляющем числе организаций ИТ-инфраструктура находится в довольно хрупком состоянии. Одним из факторов, усиливающих такую хрупкость, является комплексность, сложность применяемых ИТ-решений. Используется множество, десятки тысяч взаимосвязанных компонентов. Другим фактором служит слабое документирование, равно как и быстрое устаревание документации относительно применяемых ИТ-решений и ИТ-систем, в том числе устаревание знаний ИТперсонала, а также потеря знаний вследствие текучки кадров.

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

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

Управление ИТ-инфраструктурой как программным кодом

Возникновению управления ИТ-инфраструктурой как программным кодом предшествовало появление и развитие двух технологий: виртуализации и облачных вычислений.

История виртуализации программных и аппаратных сред началась довольно давно – в 1964 году, с началом разработки операционной системы IBM CP-40. За годы последовательного развития этого направления был достигнут весьма значительный прогресс. Коммерчески доступные системы появились для мейнфреймов (70-80-е годы прошлого века) и для более распространённых в последующем машин на архитектуре Intel x86 (80-90-е годы).

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

Технология облачных вычислений (см. главу «Облачные вычисления») развивалась ещё быстрее. До середины 90-х годов прошлого века телекоммуникационные компании предлагали своим клиентам организацию частных глобальных вычислительных сетей (WAN – Wide Area Network) путём прокладывания соответствующих соедини-тельных кабелей для каждой точки, каждого заказчика, от пункта А до пункта Б. Но с появлением технологии частных виртуальных сетей (VPN – Virtual Private Network) возникла возможность отправлять пакеты разных клиентов по одним и тем же каналам передачи данных, обеспечивая должный уровень безопасности, приватности и качества сервиса. Именно тогда для наглядного отображения разграничения ответственности – где идёт «кабель от клиента», а где трафик попадает в общую разделяемую сеть, – провайдеры стали использовать символ облака.

Клиенты, получившие возможность передачи данных на большие расстояния, стали использовать данные технологии не только для собственно обмена информацией между своими территориально удалёнными друг от друга системами, но и для распределения вычислительной нагрузки между разными узлами своих сетей. Напрашивалось появление технологии, упрощающей и удешевляющей такое взаимодействие. Небольшие провайдеры сделали первые шаги, а действительно масштабные изменения случились в 2006 году, когда компания Amazon представила своё решение ECC (Elastic Compute Cloud). Вскоре, в 2008 году, компания Microsoft запустила свой сервис Azure, а компания Google – сервис Google App Engine, впоследствии развившийся в Google Cloud Platform. Это, разумеется, не единственные, но самые крупные примеры предоставления вычислительных мощностей в аренду.

Виртуализация и облачные технологии сильно изменили вычислительный ландшафт. Предлагаемые коммерческими провайдерами ресурсы стали доступными по стоимости, надёжными, и обеспечивают необходимый уровень безопасности. Отношение клиентов к облакам и их использованию изменилось от «кто-то другой где-то управляет моим железом» на «у меня есть инфраструктура, которой я управляю на расстоянии» (дополнительные сведения можно найти в главе «Управление ИТ-инфраструктурой»).

Что же это означает – управлять инфраструктурой на расстоянии? Вспомним одну из ключевых парадигм Unix-систем: все необходимые действия с системой можно произвести из командной строки (а значит – и с помощью скрипта). Графические оболочки являются красивым, но опциональным инструментом.

Объединим теперь виртуальные облачные технологии и интерфейс командной строки для всех задач. В результате, ИТ-специалисты получили возможность с помощью текстовых команд создавать необходимые части ИТ-инфраструктуры, включая серверы, системы хранения данных, сетевые компоненты, все интерфейсы между ними, все настройки и конфигурации… Степень автоматизации существенно возросла, равно как и скорость выполнения необходимых изменений. Раньше для разворачивания ИТ-инфраструктуры, основанной на собственном аппаратном обеспечении, требовалось:

• 

обосновать и согласовать бюджет (недели и месяцы);

• 

дождаться очередного цикла закупки (месяцы);

• 

заказать оборудование у поставщика и оплатить его (дни);

• 

дождаться поставки (недели и месяцы);

• 

получить, установить, настроить, подготовить к использованию (дни и недели).

Теперь аналогичную по характеристикам ИТ-инфраструктуру можно создать так:

• 

запустить скрипт, дождаться окончания его выполнения (минуты, редко – часы);

• 

оплатить счёт облачного провайдера в конце месяца.

То есть необходимая инфраструктура создаётся с помощью программного кода. И не только создаётся, но и может управляться как программный код – с хранением версий, отслеживанием изменений, отладкой, повторным использованием прошлых наработок и т.д.

В завершение отметим также вторую жизнь, которую получили давно придуманные технологии. К примеру, виртуализация на уровне операционной системы была доступна во многих UNIX-системах ещё в 80-е годы прошлого столетия. Однако, серьёзный коммерческий успех этой технологии, которую чаще стали называть контейнеризацией, пришёл только во второй половине 2000-х, что совпадает по времени с событиями, описанными ранее. И если изначальный механизм chroot был довольно ограничен по функциональности и возможностям, то сейчас для контейнеров можно изолировать файловую систему, выделять дисковые квоты, ограничивать предоставляемые оперативную память, время процессора, ширину каналов ввода-вывода и т.д.