Такие компании, как Facebook и Google, ежедневно выпускают в промышленную среду по несколько версий продуктов. Как они достигают такой скорости при приемлемом качестве? Традицинные ИТ-службы не в состоянии обеспечить такую гибкость. С одной стороны, компании хотят расти и развиваться, а для этого должны предлагать новые продукты и услуги, отличающие их от конкурентов. С другой, клиенты хотят получать самые качественные, удобные продукты и услуги, способные адаптироваться к изменяющимся требованиям. Пользователи привыкли к тому, что на их персональных устройствах еженедельно обновляются любимые программы, и того же они ждут от продуктов других поставщиков: банков, магазинов, телекоммуникационных операторов и др. Понятно, что предприятия вынуждены реагировать на такие запросы своих клиентов, однако при этом они не готовы отказаться от классического подхода к разработке и предоставлению новых продуктов: стабильность, надежность, безопасность и управление рисками являются для них непременным условием существования их бизнеса. Для иллюстрации двойственности ситуации аналитики Gartner ввели термин «двухскоростные ИТ» (Bimodal IT) (рис. 1).

Двухскоростные ИТ

Рис. 1. Двухскоростные ИТ

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

Как организовать работу, чтобы при неизменном качестве можно было существенно ускорить внесение изменений? В этом могут помочь давно известные подходы Agile, DevOps и Lean [1–4], которые, благодаря современным средствам автоматизации, получили новый стимул к развитию. Итеративность, обратная связь и гибкость Agile-методов, основанные на взаимодействии команд разработчиков, дают возможность для постоянного и непрерывного выпуска ПО. Применение DevOps как подхода, позволяющего подразделениям разработки, тестирования и эксплуатации налаживать взаимодействие для реализации требований бизнеса по постоянному выпуску ПО и сервисов, позволяет распространить Agile и на этап эксплуатации продукта. Бережливая, или экономичная, разработка (Lean), в свою очередь, обеспечивает минимизацию издержек при выпуске новых версий ПО («давайте сократим все, что может помешать выпуску очередной версии»), например, с помощью автоматизации, устраняющей задержки. Кроме того, имеется еще и библиотека ITIL, применение которой в совокупности с DevOps и Agile позволяет создать методологическую платформу гибких ИТ.

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

Модель DevOps от HPE Software Services

Рис. 2. Модель DevOps от HPE Software Services

Рассмотрим пример модели DevOps, предложенной HPE Software Services (рис. 2). От бизнеса поступает запрос на новый функционал. Бизнес-аналитик его рассматривает и преобразует в задания для разработчиков, которые создают или изменяют код и помещают его в хранилище. В среде  непрерывной интеграции (CI tools) код автоматически компилируется и сохраняется в нужной версии в репозитории. Автоматически строится тестовая среда с необходимой конфигурацией для запуска последней версии кода. Автоматически осуществляется регрессионное тестирование. В случае успеха ресурсы тестовой среды высвобождаются и автоматически создается среда для интеграционного тестирования, а в системе ITSM формируется задание на внесение изменения в промышленную среду. Автоматически выполняется интеграционное тестирование. В случае успеха и после согласования изменения в системе ITSM код автоматически разворачивается в промышленной среде. Количество сред тестирования может быть произвольным и определяется конкретными потребностями предприятия, а средства автоматизации выбираются на основании корпоративных стандартов и с учетом уже используемых систем. Таким образом, от постановки требований до перевода новой версии в промышленную эксплуатацию проходят часы, а не месяцы, как в традиционных ИТ.

Конечно, имеются факторы, не зависящие от ИТ — например, согласование бюджета и функционала, обновление справочных материалов и т. п. Кроме того, возможна ситуация, когда разработчики готовы выпускать версии ежедневно, но служба маркетинга неспособна с такой частотой оповещать клиентов. В этом случае применяется еще более общий подход — Enterprise Agile ( гибкое предприятие ), рекомендации по реализации которого, например, представлены в методологии масштабируемой гибкости SAFe (Scaled Agile Framework). Эта методология помогает также при организации взаимодействия между различными гибкими и традиционными ИТ [5].

В России DevOps набирает популярность — на конференциях, связанных с разработкой, можно услышать доклады по этой теме. Естественно, гибкие подходы получили широкое распространение у компаний, бизнес которых непосредственно связан с Интернетом, однако и другие крупные организации проявляют интерес к гибким ИТ. Ряд компаний уже используют непрерывную интеграцию (Continuous Integration), а другие применяют методы непрерывной доставки (Continuous Deploy). Например, по результатам некоторых реализованных в HPE проектов можно сделать вывод, что частый выпуск в промышленную среду небольших релизов — уже обычная практика для крупнейших российских банков и операторов связи.

Как поставить Agile и DevOps на службу конкретной организации? Прежде всего авторы HPE SWS DevOps рекомендуют «думать масштабно, действовать последовательно» и сначала представить себе всю картину применения DevOps и определить уровень зрелости компании. Затем необходимо выявить ключевые болевые точки и понять, что может быть улучшено за короткие сроки с учетом текущих проектов организации. Далее необходимо запустить пилотный проект, нацеленный на устранение некоторых болевых точек, и постепенно его масштабировать.

***

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

Литература

  1. Наталья Дубова. В круге разработки // Открытые системы.СУБД. — 2003. — № 9. — С. 27–33. URL: http://www.osp.ru/os/2003/09/183379 (дата обращения: 18.05.2016).
  2. Святослав Верещак. Культура DevOps // Открытые системы.СУБД. — 2014. — № 7. — С. 36–39. URL: http://www.osp.ru/os/2014/07/13042919 (дата обращения: 18.05.2016).
  3. Александр Огнивцев. Союз Agile и ITSM // Открытые системы.СУБД. — 2015. — № 2. — С. 38–39. URL: http://www.osp.ru/os/2015/02/13046280 (дата обращения: 18.05.2016).
  4. Кристофер Эберт. Программное обеспечение: взгляд в будущее // Открытые системы.СУБД. — 2015. — № 4. — С. 23–25. URL: http://www.osp.ru/os/2015/04/13047966 (дата обращения: 17.05.2016).
  5. Ken France. Mixing agile and waterfall development in the Scaled agile framework. URL: http://www.scaledagileframework.com/mixing-agile-and-waterfall-development-in-the-scaled-agile-framework (дата обращения: 18.05.2016).

Андрей Косыгин (andrey.kosygin@hpe.com) — ведущий архитектор решений, Hewlett Packard Enterprise Россия (Москва).