DevOps: новый подход к интеграции

В профессиональный лексикон западных подразделений ИТ сегодня начинает входить странный на первый взгляд термин — DevOps. Это сокращенное слияние слов Development и Operations обозначает новый подход и технологии взаимодействия двух ключевых групп специалистов ИТ-департамента: разработчиков и операционного персонала — которые традиционно работали в обстановке антагонизма по отношению друг к другу. И наиболее часто употребляемая здесь метафора — стена, разделяющая эти две группы специалистов. Все взаимодействие между представителями службы оперативной поддержки ИТ-инфраструктуры и разработчиками обычно сводится к тому, что вторые «перебрасывают» первым через эту стену готовые релизы, нимало не заботясь о том, что с ними будет происходить в дальнейшем. Более драматическое сравнение предложили аналитики Forrester Стивен Манн и Гленн О’Доннелл, которые отметили, что и разработчики, и операционный персонал принадлежат к одной семье корпоративных ИТ, но при этом в своих отношениях друг с другом напоминают воинствующие кланы из трагедии Шекспира «Ромео и Джульетта». Последствия печальны — отсутствие согласия и слаженного взаимодействия отрицательно влияют на работу ИТ-службы, а значит, и на бизнес в целом.

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

Изменения правят миром ИТ

Слабая интегрированность групп разработки и операционной поддержки в ИТ объясняется существенным различием стоящих перед ними целей и задач. Команда разработки (Dev) отвечает за реализацию основных этапов создания новых приложений и модернизации существующих: сбор требований, написание и отладку кода, интеграцию, тестирование, выпуск очередных релизов. В компетенцию специалистов по операционной работе в ИТ (Ops) входят такие задачи, как выделение и конфигурирование системных ресурсов для прикладных задач, администрирование и мониторинг компонентов ИТ-инфраструктуры, управление изменениями и другие вопросы поддержки.

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

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

Реакцией на переменчивость «окружающей среды» стала активная адаптация принципов «скорой» (agile) разработки, среди которых — частые релизы создаваемого ПО и их запуск в продуктивную эксплуатацию. Этому противоречит характерное для работы операционной группы противодействие изменениям, которое находит свое выражение и в неповоротливых процедурах традиционного процесса управления изменениями. Методики Agile требуют перемен в стиле работы операционного персонала, его более согласованного взаимодействия с командой разработки. С точки зрения общего взгляда на ИТ-службу как поставщика сервисов для бизнеса идеология ITIL также стимулирует более тесное взаимодействие разных групп ИТ-специалистов для реализации сквозных процессов в рамках жизненного цикла сервиса и постоянного совершенствования сервисов.

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

DevOps сегодня и завтра

По мнению аналитиков Enterprise Management Association, ИТ-службы, берущие на вооружение концепцию DevOps, как правило, концентрируются на задаче развертывания приложений. DevOps понимается как усиление взаимодействия между разработчиками и операционным персоналом в ходе ввода готового решения в продуктивную эксплуатацию. Как показано на рис. 1, при таком подходе DevOps в жизненном цикле приложений, состоящем из шести этапов, относится к одной единственной стадии — развертывание/выпуск релиза. В этом случае сотрудничество между разработчиками и специалистами по операциям направлено на то, чтобы:

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

Рис. 1. Место DevOps в жизненном цикле приложений: традиционное представление

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

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

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

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

Оценка. Бизнес-заказчики анализируют работу приложений и выполнение соглашений об уровне обслуживания (Service Level Agreement, SLA) для определения приоритетных направлений новой разработки и модификации существующих решений. На этом этапе разработчики и операционный персонал могут получить первичную информацию о необходимости нового кодирования или внесения изменений в ИТ-инфраструктуру.
Проектирование. На этом этапе доминируют бизнес и разработчики, которые взаимодействуют между собой в ходе определения требований к приложению или сервису и реализации этих требований в проекте. Сотрудники, ответственные за операции, должны получить информацию о будущих модификациях, чтобы оценить их потенциальное влияние на продуктивную среду и проанализировать требования к ее совершенствованию.
Разработка. Здесь ключевую роль играет команда разработки. Если она действует с применением agile-методик, бизнес-заказчики, как правило, активно включаются в процессы функциональных инспекций кода. При необходимости операционный персонал участвует в развертывании и поддержке сред для разработки и тестирования.
Тестирование. Основные роли на этом этапе играют разработчики и специалисты по операциям. Первые (включая сотрудников отдела обеспечения качества) занимаются функциональным и интеграционным тестированием, вторые — интеграционным и нагрузочным тестированием для оцени готовности операционной среды к развертыванию приложений. Для участников со стороны бизнеса важной задачей на данном этапе становится приемочное тестирование.
Развертывание/выпуск релиза. Это основной этап в традиционной трактовке DevOps, соответствующий процессам управления изменениями и релизами по ITIL.
Управление. На этом этапе доминирует операционный персонал, ответственный за мониторинг и обеспечение работоспособности приложений. При этом в случае приложений внутренней разработки команда разработчиков, как правило, остается непосредственным участником процессов поддержки. В EMA отмечают, что качество эксплуатации приложения зависит не только от качества кода, но и от качества инфраструктуры, на базе которой оно работает, и от уровня подготовки пользователей. Поэтому и на данном этапе взаимодействие между всеми тремя группами играет важную роль.

Рис. 2. Место DevOps в жизненном цикле приложений: новый подход

Инструментальная поддержка

Ускорение процессов выпуска новых решений, стимулирующее адаптацию принципов DevOps, поддерживается эволюцией инструментальных средств, которые используют специалисты каждой из групп. Разработчики, переходящие на agile-методики, имеют широкий спектр инструментария для «скорой» разработки. Для обеспечения динамики операционной поддержки, соответствующей agile-разработке, нужны инструменты, автоматизирующие выделение системных ресурсов и управление ими. На это работают развитые средства управления конфигурациями, виртуализации на разных уровнях, автоматизации операционных процессов (run book automation), облачные инструменты выделения ресурсов по требованию. Однако ключевую роль в реализации DevOps играет интероперабельность и интегрируемость инструментария для разных групп. Обеспечивая необходимый каждой группе профессиональный взгляд на задачи жизненного цикла приложения, именно инструментарий способен при этом предоставить общий язык для их эффективного сотрудничества и поддержать реализацию общих процессов.

Аналитики EMA отмечают, что с эволюцией DevOps в сторону охвата всего жизненного цикла приложений роль средств автоматизации будет возрастать. На них лежит основная нагрузка по организации потоков данных и обмена информацией между разными этапами цикла и группами специалистов — участников этих этапов. И от их эффективности будет во многом зависеть возможность объединения отдельных этапов и ролей, а также правильная поддержка различных лидерских позиций на определенных этапах.

В EMA выделяют несколько ключевых возможностей, которые должны обеспечиваться комплексными наборами средств автоматизации для поддержки DevOps нового поколения. Наиболее очевидной является интеграция. Для каждого из этапов жизненного цикла существует свой класс инструментария. Например, средства управления жизненным циклом приложений (Application Lifecycle Management, ALM) предоставляют инструменты для управления требованиями, модификациями кода, тестированием и др. Средства управления релизами (которые также иногда относят к классу ALM) поддерживают реализацию потоков работ в рамках этого процесса, одобрение изменений, планирование релизов, развертывание и автоматизированное валидационное тестирование. Средства управления инфраструктурой отвечают за выделение ресурсов приложениям, автоматизированный мониторинг работающих приложений и др. Для эффективной поддержки DevOps все эти решения должны иметь возможность обмениваться информацией между собой.

Для реализации DevOps важно автоматизировать сквозные потоки работ (workflow), объединяющие разные группы специалистов. Сложные приложения, с которыми теперь, как правило, имеет дело бизнес, связаны с изощренными процедурами создания, развертывания и управления. Эти процедуры объединяются в многошаговые процессы со сложной структурой, которые включают в себя как автоматизированные задачи, так и этапы, связанные с ручными действиями специалистов. Для объединения разных групп в рамках DevOps потребуется автоматизированный движок управления такими процессами.

Из программной инженерии хорошо известно, что поддержка приложения обойдется тем дешевле, чем раньше в ходе жизненного цикла в нем будут обнаружены ошибки. Удовлетворить этому условию призваны методы раннего и итеративного тестирования, поддерживаемые agile-разработкой. В контексте поиска оптимального инструментария для DevOps это означает выбор средств тестирования производительности и доступности приложений, охватывающих как этап разработки, так и уровень продуктивной эксплуатации.

Аналитики EMA перечисляют более десяти поставщиков программных систем класса DevOps. Пять из них обеспечивают поддержку всех этапов жизненного цикла в модели DevOps — это компании CollabNet, ExtraHop, IBM, OpTier и Serena. О реализации принципов DevOps заявляют также Microsoft и CA Technologies.

DevOps на практике

Сегодня отмечается рост интереса компаний к концепции DevOps — до 2012 года этот термин почти не фигурировал в ИТ-сообществе, но начиная с прошлого года он стал одной из наиболее активно обсуждаемых. Аналитики наблюдают тенденцию к формированию кросс-функциональных ИТ-команд, которые за последние пять лет хотя и не связывали себя с понятием DevOps, но по сути двигались в направлении реализации именно этих идей. По данным EMA, около 30% компаний уже реализовали или планируют реализовать DevOps в ближайшее время. При этом подавляющее большинство опрошенных подтвердили существование у себя кросс-функциональных команд, решающих задачи, связанные с жизненным циклом приложений. Большинство из тех, кто уже всерьез занимается DevOps (84%), считает, что их ИТ-системы смогут поддержать эту трансформацию. Те же, кто сомневается, среди основных причин скепсиса называют плохую интеграцию инструментария, который используют разработчики и операционный персонал, и низкий уровень автоматизации развертывания приложений.

***

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