Сегодня в новостном потоке мы публикуем статью Олега Скрынника “Истоки DevOps”. Она признана лучшей по итогам конкурса «ITSM в России – практические ценности – 2017». Подведение итогов которого и награждение победителя прошло в рамках VIII Всероссийской Конференции “Digital ITSM”.
Статья также опубликована в ежегодном Альманахе itSMF России, который уже можно скачать на сайте сообщества.
Истоки DevOps
Можно утверждать, что появлению DevOps в наибольшей степени способствовали два фактора: развитие гибких методов разработки программного обеспечения и управление ИТ-инфраструктурой как программным кодом. Рассмотрим каждый из них.
Развитие гибких методов разработки программного обеспечения
В конце прошлого столетия доминирующей методологией разработки программного обеспечения была так называемая «водопадная модель»: последовательное выполнение заранее определённых этапов, каждый из которых занимает существенное время и завершается достижением заранее согласованных результатов, при этом переход на следующий этап во многих случаях происходит после полного и формального завершения предыдущего этапа. Дополнительным отличительным признаком такой модели является функциональная специализация исполнителей отдельных этапов: аналитиков, архитекторов, разработчиков, тестировщиков и так далее.
При разработке крупных информационных систем с конечной функциональностью, которую возможно определить и зафиксировать в самом начале работ, при условии отсутствия требований к максимально быстрому завершению полного цикла разработки такая модель позволяет получать качественные выходные результаты при достаточно детальном контроле расходов.
Однако в конце 90-х годов XX века, с бурным развитием Интернет-технологий и web-программирования, недостатки водопадной модели стали достаточно негативно влиять на взаимодействие и взаимопонимание заказчиков (бизнес-подразделений компании, либо внешних организаций) и исполнителей (программистов компании, либо внешних разработчиков программного обеспечения). Действительно, появляющиеся рыночные возможности для основного бизнеса требовали быстрого, за считанные месяцы, вывода на рынок новых продуктов. В то время как типичный цикл разработки от начала проекта до получения первого работающего результата занимал от 6 до 18 месяцев, в крупных организациях – до 2-3 лет. Кроме того, в условиях появления ранее неизвестных, но потенциально перспективных рыночных возможностей требования заказчиков могли меняться по ходу проекта разработки, что было крайне сложно учесть при создании ИТ-системы без увеличения сроков, либо снижения качества выходных результатов.
Таким образом, накапливалось напряжение между заказчиками и исполнителями, между основным бизнесом и разработчиками ПО. Ответом на такой вызов стали инновационные подходы к программированию. Кен Швейбер (Ken Schwaber) выпустил несколько публикаций о Scrum. Кент Бек (Kent Beck) опубликовал книгу об экстремальном программировании, XP. Однако применение новых идей давало весьма скромные результаты, в основном потому, что такое применение фокусировалось лишь на одном из этапов цикла разработки ПО – на собственно программировании, при том что задача ставилась намного более широкая. Требовалось что-то, что позволит упростить и ускорить всю цепочку разработку программного обеспечения.
В 2001 году Кен, Кент, а также ещё пятнадцать товарищей отправили друг другу приглашения, а затем собрались обсудить имевшиеся проблемы и выработать решение. Итогом стал так называемый манифест Agile, призванный устранить разрыв понимания между бизнесом и разработчиками ПО. Один из авторов манифеста, Роберт Мартин (Robert C. Martin), поясняет:
«Используя правильные дисциплины и правильный минимальный процесс, может возникнуть и развиться доверие между разработчиками и бизнесом. Бизнес начнёт доверять разработчикам, вместо того, чтобы думать, что они ленивые, продажные, противные существа, а разработчики начнут обращать внимание на бизнес и осознают, что те являются разумными, рациональными существами, а не с какой-то другой планеты.»
Последовавшее развитие и принятие идей гибкой разработки сообществом программистов и менеджеров проектов сильно ускорили и перестроили разработку ПО.
Ключевыми элементами гибкой разработки являются более плотное взаимодействие между заказчиком и исполнителем, уменьшение размера задач, ритмичность выдачи результатов через короткие промежутки времени (циклы) и ограничение размера команд.
Группа разработки ПО, применяющая гибкие подходы, выдаёт готовый к эксплуатации новый код каждые две-четыре недели. Конечные потребители плотнее вовлечены в создание продукта, а значит быстрая обратная связь значительно влияет на дальнейшее развитие продукта, что дополнительно добавляет вкуса к быстрым изменениям.
Однако во многих компаниях отказ от водопадной модели в пользу гибкой разработки даёт куда меньший эффект, чем ожидается. Такие наблюдаемые в работе многих компаний результаты связаны не столько с какими-то преимуществами водопадной модели или недостатками Agile. Зачастую полезный эффект нивелируется тем, что разработка кода – лишь одно из звеньев в цепочке создания ценности.
Действительно, до начала собственно разработки есть значительный блок работ, направленный на выявление бизнес-потребностей, их проработку, анализ, приоритизацию и так далее.
Далее, по окончании разработки готовый программный код необходимо быстро развернуть в продуктивной среде и начать эксплуатировать, чтобы заказчики получили всю ту пользу, которую им обещали, а также могли предоставить обратную связь разработчикам относительно качества получившегося продукта. При этом почти во всех организациях ИТ-инфраструктура является жёсткой, основанной на дорогом аппаратном обеспечении, которое было приобретено достаточно давно, бюджеты на закупку и настройку выделялись непросто, да и собственно бюджетный процесс для новых закупок долгий.
Более того, в подавляющем числе организаций ИТ-инфраструктура находится в довольно хрупком состоянии. Одним из факторов, усиливающих такую хрупкость, является комплексность, сложность применяемых ИТ-решений. Используется множество, десятки тысяч взаимосвязанных компонент. Другим фактором служит слабое документирование, равно как и быстрое устаревание документации относительно применяемых ИТ-решений и ИТ-систем, в том числе устаревание знаний ИТ-персонала, а также потеря знаний в следствие текучки кадров.
Трогать ИТ-инфраструктуру во многих компаниях страшно. Изменение – самое большое зло для отдела эксплуатации ИТ-систем, а постоянный большой поток изменений может привести к катастрофическим последствиям.
Таким образом, передовые методы разработки ПО упираются в замедление со стороны подразделений, ответственных за эксплуатацию информационных технологий, что нивелирует возможный положительный эффект применения гибких подходов.
Управление ИТ-инфраструктурой как программным кодом
Возникновению управления ИТ-инфраструктурой как программным кодом предшествовало появление и развитие двух технологий: виртуализации и облачных вычислений.
История виртуализации программных и аппаратных сред началась довольно давно, в 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 был довольно ограничен в функциональности и возможностях, то сейчас для контейнеров можно изолировать файловую систему, выделять дисковые квоты, ограничивать предоставляемые оперативную память, время процессора, ширину каналов ввода-вывода и так далее.
Неизбежность появления
Таким образом, рассмотренные истоки возникновения DevOps позволяют сделать следующие выводы.
Во-первых, ввиду появления новых способов взаимодействия с основным бизнесом, клиентами, и грамотного применения методов гибкой разработки назрела потребность строить работу и управление информационными технологиями иначе.
Во-вторых, с возникновением новых технологий управления инфраструктурой появилась возможность строить работу ИТ иначе. Можно сказать, что появление чего-то, аналогичного DevOps, было лишь вопросом времени.
