itil-ist (itil_ist) wrote,
itil-ist
itil_ist

Category:

Двухскоростное ИТ от Гартнера: Agile, DevOps и ITIL на службе бизнеса

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

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

Двухскоростное ИТ
Интересный подход к тому, как можно удовлетворить эти противоречивые на первый взгляд требования предлагает Гартнер (Gartner), определяя Двухскоростное ИТ (Bimodal IT). ИТ больше нельзя рассматривать как единое целое, работающее по единым правилам. Предлагается разделить ИТ на традиционное, с приоритетами в безопасности и минимизации рисков (Traditional IT), и гибкое, которое должно быть отзывчиво на все новые требования (Agile IT). Ключевые отличия двух подходов показаны на следующей иллюстрации:

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

Идея оказалась настолько интересной, что вызвала активное обсуждение в среде профессионалов, которое продолжается до сих пор. Так, например, Роб Ингланд, автор блога The IT Skeptic, пошел дальше и задался вопросом: «Зачем ограничивать себя только двумя скоростями? Почему, продолжая аналогию, не говорить о «вариаторе IT»?»

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

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

Возникает логичный вопрос как же это сочетается с широко распространённым ITIL? На Linkedin можно найти огромное количество рассуждений на эту тему, но лучше всего обратиться первоисточникам, а именно статье "Integrating Agile and ITSM" и официальному документу от авторов ITIL AXELOS «Maximize the synergies between ITIL® and DevOps». Вывод – они прекрасно дополняют друг друга. В заключении разбора можно привести хорошую иллюстрация таких отношений.

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

  • поступает требование бизнеса на новый функционал

  • бизнес-аналитик анализирует требование и преобразовывает его в задания для разработчиков

  • разработчики создают или изменяют код и помещают его в хранилище кода (например, Git)

  • Дальше вступает в бой автоматизация: автоматически код компилируется (MS Build)

  • автоматически создается тестовая среда с необходимой конфигурацией (vCenter или CSA для собственно виртуальной машины и Chef, CODAR, OO для базового ПО)

  • автоматически проходит регрессионное тестирование (HP UFT)

  • в случае успеха ресурсы тестовой среды высвобождаются, автоматически создается препродуктивная среда для интеграционного и нагрузочного тестирования (те же средства), в ITSM средстве создается Изменение на внесение изменения в промышленную среду

  • автоматически проходит интеграционное и нагрузочное тестирования (HP SV, NV, LR)

  • в случае успешного тестирования и после согласования Изменения в ITSM средстве код автоматически разворачивается в продуктивной среде (HP OO).

Все ПО приведено для примера и должно быть заменено на ПО в конкретной организации. Количество сред тестирования так же может быть произвольным.

Таким образом цикл от постановки требований до перевода в промышленную эксплуатацию занимает не недели, а часы. При этом нужно понимать, что совершенно не обязательно автоматизировать весь жизненный цикл сразу. Можно ограничиться только частью разработки, тогда будет организована работа только в части Непрерывной интеграции (Continuous Integration) или тестирования (Continuous Testing). Кому-то пригодятся подходы по автоматизированному созданию тестовых сред.

Конечно, есть факторы, которые не зависят от ИТ. Например, согласование бюджета и функционала, обновление и публикация маркетинговых материалов и т.п. Возможна ситуация, когда разработчики будут готовы выпускать релизы ежедневно, но, маркетинг не будет готов публиковать пресс-релизы на сайте с такой частотой. Для таких случаев был придуман подход Гибкое предприятие (Enterprise Agile или Business-agile enterprise). Конкретные рекомендации по реализации такого подхода были сведены в виде методологии Scaled Agile Framework (SAFe). Эта же методология может помочь организовать взаимодействие гибкого ИТ, со всеми гибкими методиками разработки, и традиционного ИТ, в котором применяются классические водопадные методологии ведения проектов – Mixing agile and waterfall development in the Scaled agile framework.

Заключение
На первый взгляд может показаться, что это далекое будущее, мало применимое к нашим реалиям. Однако на практике некоторые организации уже живут так. Многие команды разработки используют Непрерывную интеграцию (Continuous Integration) в своей ежедневной работе. Посетите любую конференцию связанную с разработкой (DevCon, SQA days, HighLoad++) и вы увидите серии докладов по этой теме. Наши последние проекты показывают, что частые небольшие релизы в промышленную среду это нормальная практика крупнейших российских банков. Давайте получше присмотримся к этим возможностям и если не построим всеобщее счастье, то улучшим и оптимизируем некоторые аспекты нашей с вами работы.
Tags: agile, devops, links, опыт
Subscribe
  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 0 comments