Марк Смолли: «DevOps переносит внимание с инструментария на взаимодействие между людьми»
Марк Смолли: «DevOps переносит внимание с инструментария на взаимодействие между людьми»

Марк Смолли: «DevOps мотивирует людей переосмыслить свою деятельность, в результате ИТ-команды приходят в движение»


11:48 12.06.2018   |  Михаил Зырянов |  Computerworld Россия

Рубрика Предприятие |   1158 прочтений



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

 

Цифровая экономика усилила один из ключевых принципов экономики традиционной: необходимо как можно быстрее выводить на рынок новые продукты и услуги, причем их качество должно быть достаточно высоким. Методика DevOps помогает разработчикам за меньшее время создавать и передавать в эксплуатацию цифровые продукты и сервисы, добиваясь при этом необходимого уровня качества. Какова нынешняя ситуация с DevOps, в каком ракурсе ее следует рассматривать и чего можно ждать от этой методики, рассказывает Марк Смолли, консультант компании Smalley.IT в области управления ИТ, всемирный посол фонда ASL BiSL Foundation. Смолли выступил с ключевым докладом на юбилейном, пятнадцатом форуме ITMF 2018 для профессионалов в области управления ИТ, организованном издательством «Открытые системы».

- С чем связана нынешняя шумиха вокруг DevOps?

Эта методика зародилась в 2008-2009 годах в Бельгии: эксперты попытались применить гибкие (agile) методики разработки для управления операционной деятельностью по оказанию ИТ-услуг. DevOps можно рассматривать как продолжение гибкой разработки: она считается завершенной, когда код наконец написан и готов к развертыванию, но еще не развернут. Методика DevOps идет дальше: в ней много внимания уделяется тому, каким образом код может быть развернут, причем быстро и надежно, после чего передан в продуктивную эксплуатацию.

Большое значение в DevOps имеет автоматизация, но также очень существенную роль играет созидательная (generative) культура взаимодействия между заинтересованными сторонами. Нередко в организациях приходится сталкиваться с сильной бюрократией: подразделения представляют собой закрытые структуры, которым трудно взаимодействовать между собой, в них не развита культура передачи полномочий и пр. Встречаются и «патологические» организации с «токсичной» культурой, где увольнения сотрудников становятся обыденным делом.

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

- Так ли нова парадигма DevOps?

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

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

DevOps – это достаточно новая парадигма, и ее пока сложно определить однозначно. Вспомним Джеффри Мура: в жизненном цикле инновационного продукта есть стадия инициализации, есть ранние последователи, и есть мейнстрим. DevOps сегодня находится в стадии преодоления разрыва, и только начинается переход в стадию мейнстрима. Сейчас люди, которые приступают к работе по DevOps, говорят, что пока рано проводить стандартизацию. Но, с другой стороны, организациям необходимо сотрудничать, чтобы определить эту методику в деталях, ввести стандартизацию, сертификацию и пр. Найти баланс между этими подходами достаточно трудно. Впрочем, все согласны с тем, что есть обширное поле деятельности, которое сейчас стремительно развивается.

- Каковы на сегодня наиболее сильные стороны DevOps?

Самая сильная сторона – это возможность использовать ИТ в интересах ИТ-специалистов. Я имею в виду автоматизацию процессов разработки. Еще одна сильная сторона в том, что DevOps смещает внимание ИТ-специалистов с инструментария на взаимодействие между людьми. Аббревиатура CALMS, которую ввел Джон Уиллис, включает основные принципы DevOps: культура (Culture), автоматизация (Automation), бережливое производство (Lean), измерение (Measurement) и обмен знаниями (Sharing). Как видим, автоматизация – лишь один из элементов DevOps. Эта методика мотивирует людей переосмыслить свою деятельность, в результате ИТ-команды приходят в движение, и это замечательно! DevOps оказывает очень мощное влияние на ИТ-индустрию.

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

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

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

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

- Каких изменений и наработок можно ожидать в DevOps в обозримом будущем?

Я считаю, говорить об этом несколько преждевременно. В современном цифровом предприятии, активно внедряющем технологии Интернета вещей, можно выделить не только подразделения ИТ и бизнеса, но и подразделения, отвечающие за операционные технологии (в первую очередь технологии автоматизации производственных процессов). Возникает вопрос: кто отвечает за системы Интернета вещей – ИТ, бизнес или ОТ? Прежде ИТ-команда отвечала за все, что связано с автоматизацией. Сегодня наблюдается конвергенция ИТ и бизнеса. Но куда отнести ОТ – к бизнесу или к ИТ? Другими словами, кто должен отвечать за ОТ – ИТ-подразделение или бизнес? Или же блок ОТ должен быть отдельной структурой? И в какой точке, в какой структуре должны находиться рычаги централизованного управления организацией в целом (а оно, уверен, должно быть)? Кто и как должен координировать, оркестрировать деятельность различных блоков – бизнеса, ИТ и ОТ? У меня пока нет ясного ответа.


Теги: Управление ИТ DevOps Agile Цифровая экономика ITMF 2018 AgileDevOpsITSM2018
На ту же тему: