Истоки DevOps

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

Рис. 1. Пример водопадной модели разработки программного обеспечения

При разработке крупных информационных систем, конечную функциональность которых можно определить и зафиксировать в самом начале работ, а также при отсутствии требований максимально быстрого завершения полного цикла разработки водопадная модель позволяет получать качественные результаты на выходе при достаточно детальном контроле расходов. Однако бурное развитие технологий выявило недостатки этой модели, негативно влияющие на взаимодействие внутренних или внешних заказчиков компании с исполнителями (собственными разработчиками компании либо сторонними программистами). В новых рыночных условиях от основного бизнеса часто требуется быстро выводить на рынок новые продукты, однако типичный цикл разработки — от начала проекта до получения первого работающего результата — по водопадной модели занимает от 6 до 18 месяцев, а в крупных организациях — 2–3 года. Кроме того, при появлении потенциально перспективных рыночных возможностей требования заказчиков могут меняться по ходу проекта разработки, что крайне сложно учесть при создании ИТ-системы без изменения сроков либо снижения качества выходных результатов (рис. 2).

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

Все это привело к накапливанию напряжения между заказчиками и исполнителями, между основным бизнесом и разработчиками ПО. Ответом стали инновационные подходы к программированию: Кен Швейбер предложил Scrum, а Кент Бек — экстремальное программирование (XP). Однако применение новых идей дало весьма скромные результаты, поскольку фокусировалось лишь на одном из этапов цикла разработки ПО — на программировании, тогда как изначально задача ставилась намного шире. Требовалось еще что-то, что позволило бы упростить и ускорить выполнение всей цепочки жизненного цикла ПО. В 2001 году Швейбер, Бек, Роберт Мартин и примкнувшие к ним коллеги по цеху обсудили возникшие проблемы и выпустили Agile Manifesto [2], призывающий разрушить стену непонимания между бизнесом и разработчиками ПО. Предполагалось, что, используя правильные дисциплины и правильный минимальный процесс, можно построить доверительные отношения между разработчиками и бизнесом. Последовавший за этим бум гибкой разработки значительно изменил ландшафт программной индустрии.

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

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

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

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

История виртуализации программных и аппаратных сред началась еще в 1964 году, с разработки операционной системы IBM CP-40, коммерчески доступные системы появились для мэйнфреймов в 1970–1980-е годы, а позже и для архитектуры x86. Виртуализация позволила не только эффективнее использовать дорогое аппаратное обеспечение, но и ввести дополнительный уровень абстракции между исполняемым кодом, предоставляющим полезные результаты заказчику, и системным ПО. Был сделан существенный шаг в сторону разделения компетенции и ответственности между «прикладниками» и «системщиками».

Технологии облаков развивались еще быстрее — до середины 90-х годов телекоммуникационные компании предлагали своим клиентам организацию частных глобальных сетей, прокладывая кабели для каждой точки, каждого заказчика. С появлением технологии частных виртуальных сетей (Virtual Private Network, VPN) возникла возможность по одним и тем же каналам отправлять пакеты разных клиентов без потери надежности и качества обслуживания. Именно тогда для наглядного отображения разграничения ответственности (где идет «кабель от клиента», а где трафик попадает в общую разделяемую сеть) провайдеры стали использовать символ облака.

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

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

Необходимая инфраструктура создается теперь с помощью программного кода. И не только создается, но и управляется как код — с хранением версий, отслеживанием изменений, отладкой, повторным использованием прошлых наработок и т. д. Кроме того, вторую жизнь получили давно придуманные технологии, не получившие в свое время широкого применения. К примеру, виртуализация на уровне ОС была доступна во многих Unix-системах еще в 1980-е годы, однако ее серьезный коммерческий успех под соусом контейнеров пришелся на вторую половину 2000-х. Если исходный механизм команды chroot, изменяющей видимый корневой каталог для текущего процесса и его дочерних элементов, был довольно ограничен по функциональности, то сейчас для контейнеров можно изолировать файловую систему, выделять дисковые квоты, ограничивать предоставляемые оперативную память, время процессора, ширину каналов ввода-вывода и т. д.

***

Появление новых способов взаимодействия бизнеса и клиентов на фоне роста популярности методов гибкой разработки вызвало потребность в новой организации управления ИТ. И наоборот, возникновение новых технологий управления инфраструктурой позволило иначе строить бизнес. В этой ситуации появление философии DevOps [3] было лишь вопросом времени.

Литература

1. Крейг Ларман, Виктор Базили. Итеративная и инкрементальная разработка: краткая история // Открытые системы.СУБД. — 2003. — № 9. — С. 71–80. URL: https://www.osp.ru/os/2003/09/183412 (дата обращения: 18.09.2017).
2. Наталья Дубова. Двигатель программной революции // Открытые системы.СУБД. — 2007. — № 2. — С. 64–69. URL: https://www.osp.ru/os/2007/02/4108290 (дата обращения: 18.09.2017).
3. Наталья Дубова. Программный круговорот // Открытые системы.СУБД. — 2011. — № 1. — С. 26–33. URL: https://www.osp.ru/os/2011/01/13006960 (дата обращения: 18.09.2017).

Олег Скрынник (o.skrynnik@cleverics.ru) — управляющий партнер, компания Cleverics (Москва).