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

Неизбежность появления

Рассмотренные истоки возникновения DevOps позволяют сделать следующие выводы.

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

Во-вторых, с возникновением новых технологий управления инфраструктурой появилась возможность иначе строить работу ИТ.

Можно предполагать, что появление чего-то, аналогичного DevOps, было лишь вопросом времени.

Методология DevOps призвана решить три вполне конкретные задачи современной ИТ-организации.

Ускорение вывода на рынок

Компании, применяющие DevOps, наиболее часто сообщают о необходимости существенно сокращать время вывода на рынок (англ. Time to market). Под этим термином разные люди подразумевают разное. Часто встречающееся понимание – время от зарождения какой-либо бизнесидеи до предоставления клиенту возможности приобрести новый продукт или получить новую услугу, являющуюся результатом воплощения бизнес-идеи в жизнь. Таким образом, в расчёт (а точнее – в оценку) времени вывода на рынок включается довольно большой промежуток, содержащий в случае необходимости привлечения ИТ-департамента следующие шаги:

• 

структурирование и первое формальное описание бизнес-идеи, а скорее – нескольких бизнес-идей, их обоснование;

• 

оценка и выбор бизнес-идеи для реализации;

• 

планирование необходимых действий для реализации, выделение финансирования;

• 

подготовка бизнес-процессов и персонала;

• 

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

• 

одновременно с этим: маркетинговые активности, подготовка рынка, подготовка механизма и каналов продаж;

• 

запуск нового продукта или новой услуги.

Описанному процессу присущи некоторые сложности.

Во-первых, его общая длительность может измеряться годами, при том что бизнесу хотелось бы сократить её до месяцев. Бизнес-обоснование здесь прозрачно: за время разработки нового продукта рынок может измениться настолько, что продукт будет уже неактуален, либо конкуренты выпустят аналогичный продукт раньше, соберут сливки и закрепятся как лидеры. Ранний выход на рынок с привлекательным конкурентным предложением помогает занять доминирующее положение в новых нишах, которое, в свою очередь, даёт лидеру возможности в дальнейшем изменять рынок, подстраивая его под себя. Это существенное преимущество, которым обладают немногие, хотя стремятся к нему все. Кроме того, не следует забывать про всё возрастающую скорость изменений. Одна из наиболее наглядных иллюстраций данного тезиса – закон ускоряющихся возвратов (Law of Accelerating Returns), сформулированный в 1999 году Р. Курцвайлом. Согласно ему, скорость изменений в широком спектре эволюционирующих систем, включая новые технологии, но не ограничиваясь ими, стремится расти экспоненциально. На практике это означает, что прорывы в технологиях, в том числе информационных, случаются всё чаще. Компании, которые увеличивают темп изменений, становятся лидерами, а те, кто может лишь сохранять свой быстрый темп, получают возможность не остаться на обочине. Что уж говорить про тех, кто не способен меняться быстро…

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

Отметим, что роль традиционного ИТ-подразделения в увеличении срока вывода на рынок трудно переоценить. Действительно, в некоторых организациях на ИТ-работы приходится более 50-70% от общего календарного времени в 1,5-2 года.

Другое понимание термина «время вывода на рынок» менее глобально, но не менее значимо.

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

• 

рождение гипотезы, разработка методов оценки её справедливости;

• 

реализация гипотезы на практике;

• 

измерение результата, A/B тестирование, сравнение с целевыми значениями;

• 

корректировка по итогам анализа, переход на первый или второй шаг.

Несложно заметить возникновение цикла, ожидаемая скорость которого – недели. Такой быстрый темп необходим потому, что сама суть движения – в постоянном поиске. На старте, в самом начале, совершенно неизвестно конечное состояние, и, тем более, неизвестна дорога к нему. Долгосрочное планирование не имеет никакого смысла, компания видит лишь следующий, ближайший шаг – точнее, пытается его угадать. Проиллюстрировать данный тезис поможет широко известная метафора, сравнивающая выживание и развитие бизнеса с поиском реки с деньгами (Рис. 3).

Рис. 3. Река с деньгами.

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

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

Консалтинговая и образовательная практики компании Cleverics позволяют дать следующие оценки реально достигаемого ускорения: релизные циклы длительностью в 2-3 месяца сменяются непрерывной поставкой «по требованию», выполняемой несколько раз в день. Время выполнения одной задачи сокращается с 12-30 календарных дней до 2-4 дней; в слаженных и устойчивых командах – до 1-2 дней. При этом приведённые целевые числа не являются оценочными, а доступны всем заинтересованным сторонам в виде объективно собираемых метрик потока создания ценности, позволяющих анализировать и оптимизировать поток и работу команды. Таким образом, речь не идёт о повышении эффективности на 10-30%; применение принципов и практик DevOps даёт кратное ускорение, которого невозможно добиться иными средствами и методами.

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

Рис. 4. Функциональная структура традиционного ИТ-подразделения.

В отличие от такой схемы, в DevOps деление специалистов производится по командам, и каждая команда работает над своим продуктом. Будучи самодостаточной, команда включает в себя и владельца продукта, и архитекторов, и разработчиков, и тестировщиков, и ответственных за эксплуатацию, и за информационную безопасность (Рис. 5).

Рис. 5. Пример состава DevOps-команды.

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

Таким образом, можно утверждать, что традиционная организация ИТ-подразделения больше направлена на оптимизацию затрат (англ. Optimize for cost), в то время как организация по DevOps направлена на оптимизацию скорости (англ. Optimize for speed), и эти цели в общем случае являются разнонаправленными. Отметим также, что DevOps предлагает инструменты и способы ограничения роста затрат, такие как максимальная автоматизация всех рутинных операций, а также взаимозаменяемость в пределах одной команды. Кроме того, адепты DevOps справедливо указывают, что оптимизация скорости во многих случаях направлена на предоставление возможности бизнесу зарабатывать больше, что компенсирует возрастающие расходы на ИТ. В таком случае можно рассуждать об ИТ-отделе, как истинном бизнес-партнёре, а не центре затрат.