«Кембрийский взрыв» в мире инструментов DevOps

Сегодня DevOps находится на интересной стадии своей эволюции — учитывая огромное количество доступных средств, поддерживающих эту методологию, можно говорить о «кембрийском взрыве» разнообразия инструментов и областей их применения. («Кембрийский взрыв» (Cambrian explosion) — условное название явления, вызвавшего резкое увеличение количества ископаемых останков доисторических животных в отложениях, соответствующих началу кембрийского периода. — Прим. ред.) Но действительно ли это многообразие необходимо? Произойдет ли масштабная консолидация, следствием которой станет исчезновение большинства нынешних инструментов? Какие именно области специализации средств способствуют росту многообразия и что следует учитывать при планировании архитектуры потоков формирования ценности ПО?

На протяжении двух десятилетий, начиная с 1980-х годов, основной компанией, которая поставляла средства разработки ПО большинству корпоративных ИТ-отделов, была Rational — во многих организациях весь жизненный цикл ПО отслеживался с помощью инструментальной цепочки продуктов этой компании. Сегодня есть соблазн отзываться о подобных инструментах-«тяжеловесах» с иронией, однако Rational создала цепочку, которая была невероятно сложной, но и эффективной для своего времени. Помимо средств разработки, в компании предложили Rational Unified Process (RUP) — связную систему процессов и инструментов для программной инженерии, обеспечивающую отделам ИТ и организациям разработки ПО сквозной обзор, контроль и предсказуемость масштабных программных проектов. Фактически RUP стала стандартом разработки по водопадной модели (waterfall). В 1990-х годах происходило стремительное расширение использования как инструментальной цепочки, поставляемой Rational, так и соответствующих процессов и методологий. Затем, в 2000-х годах появились скорые (Agile) методы, прежде всего как реакция на проблемы, которые породил командно-административный стиль управления выпуском ПО, присущий каскадной модели и RUP. После Agile появилось течение DevOps, и сегодня благодаря тому и другому эпоха водопадной модели ушла в прошлое: среди почти 26 тыс. участников опроса, проведенного Stack Overflow в 2017 году, 76,9% пользовались методами Agile и только 26,9% — водопадной моделью [1]. Хотя последняя по-прежнему применяется во многих крупных организациях, сегодня преимущества, обеспечиваемые Agile и DevOps, общепризнаны: это более короткие сроки поставки и меньший объем работ на каждой стадии конвейера.

Причины «взрыва»

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

Взрывной рост многообразия инструментов DevOps

Можно также упомянуть проведенное компанией Tasktop исследование, в рамках которого были проанализированы инструментальные цепочки 300 отделов ИТ крупных корпораций: в 70% этих организаций уже интегрировали три инструмента или больше, а в 40% — не меньше четырех.

Кроме того, стремительно расширилось использование средств с открытым кодом. Например, распределенную систему управления версиями Git, согласно данным Stack Overflow, используют 69,2% из 30,7 тыс. участников опроса, тогда как Rational ClearCase — только 0,4% [2]. Очень быстрый переход на Git и вытеснение традиционных тяжеловесных инструментов указывают на важную тенденцию. У Agile, DevOps и открытого кода есть нечто общее: развитие всех трех происходит по инициативе «снизу», и все они ориентированы на то, чтобы предоставить новые возможности исполнителю. Эта тройка разрушает модель контроля «сверху вниз», обеспечивая «демократизацию» инструментальной цепочки. Из рисунка хорошо видно, что эта демократизация отменяет свойственный прежней эпохе принцип, по которому один и тот же продукт предлагался для всех нужд. Большое количество категорий инструментов свидетельствует о появлении различных специализаций, чего раньше не было. Потребность в таком разделении обязанностей обусловлена различиями в типах работ, выполняемых в рамках процесса выпуска ПО.

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

Анализ многообразия

Предстоит ли нынешним инструментам массовое вымирание? Анализ инструментальных цепочек позволяет выявить два типа многообразия инструментов.

• Фундаментальное многообразие приносит пользу за счет повышения продуктивности выпуска ПО. Например, группы, разрабатывающие Java-приложения, действуют продуктивнее при использовании Kira, а разработчикам, применяющим Azure и .NET, тот же результат обеспечивает Visual Studio Team Services.
• Случайное многообразие не помогает организации в достижении ее целей. В эту категорию входят инструменты, унаследованные в результате слияний и приобретений, или средства с похожей функциональностью, которые были взяты на вооружение независимо друг от друга ввиду отсутствия централизованного руководства. Например, у организации может быть сразу три системы отслеживания ошибок: унаследованный инструмент двадцатилетней давности, разработанный собственными силами; современный трекер проблем, которому отдают предпочтение разработчики; аналогичный трекер с открытым кодом, перешедший в организацию после поглощения другой компании.

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

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

• Специализация по заинтересованным лицам. Различным участникам процесса выпуска ПО нужны разные инструменты для повышения эффективности в своем конкретном направлении деятельности. Например, сотрудникам службы поддержки нужны инструменты, ориентированные на соглашения об уровне обслуживания или ITIL, а разработчикам требуются средства, оптимизированные для процессов ревизии и обновления кода.
• Специализация по масштабу. Некоторые инструменты специализированы в зависимости от размера организации. Так, упрощенный инструмент Kanban может подходить для оптимизации рабочих процессов десятка команд, а для отслеживания требований в системе, критичной к безопасности, необходим иерархический инструмент соответствующего назначения.
• Специализация по платформе. Поставщики платформ разработки нередко предлагают построенное на соответствующих инструментах решение для освоения своей платформы. Например, Microsoft поставляет универсальные решения DevOps и Agile, оптимизированные для платформы разработки Azure, но в меньшей степени подходящие для более гетерогенной экосистемы Java.
• Специализация по зоне. В книге «Zone to Win» Джеффри Мур перечисляет «зоны», соответствующие различным стадиям зрелости предприятия [3]. Для продукта, ориентированного на экспериментальную «зону трансформации», могут понадобиться только самые простые и экспериментальные инструменты — например, средства отслеживания проблем, доступные на GitHub. Более зрелые продукты, находящиеся в «зоне производительности», потребуют более тесной интеграции с запросами бизнеса и планированием.
• Многообразие поставщиков. С ростом аутсорсинга и использования ПО с открытым кодом становится непрактичным рассчитывать на то, что поставщики ПО будут применять те же инструменты, что и организация-потребитель. Например, в рамках проектов с открытым кодом обычно используются инструменты с открытым кодом, а мелкие поставщики чаще применяют упрощенные инструменты отслеживания, а не средства уровня предприятия, рассчитанные на выпуск крупных программных проектов.
• Унаследованные системы. Затраты и нарушения работоспособности, сопряженные с отходом от унаследованной системы (от устаревшего инструмента или разработанного самостоятельно трекера дефектов), могут быть чрезмерными. Особенно это справедливо для давно выпускающихся продуктов, находящихся в режиме сопровождения или в «зоне производительности». Эти инструменты могут быть еще одним источником многообразия, если их модернизация чревата остановкой рабочего процесса.

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

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

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

***

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

Литература

1. Developer Survey Results: 2017. Stack Overflow, 2017. URL: insights.stackoverflow.com/survey/2017 (дата обращения: 23.04.2018).
2. G. Kim et al. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations, IT Revolution, 2016.
3. G.A. Moore. Zone to Win: Organizing to Compete in an Age of Disruption, Diversion, 2015.

Мик Керстен (mik@tasktop.com) — основатель, генеральный директор Tasktop.