Портал №1 по управлению цифровыми
и информационными технологиями

Какое отношение ITIL имеет к DevOps? Гораздо большее, чем вы думаете

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

Многие приверженцы DevOps восприняли его как противоположность тому неизменному подходу, который они видели в традиционном управлении ИТ-услугами (ITSM — в лице ITIL как сборника лучших практик). Эта точка зрения может быстро привести к разделению на два лагеря: «мы» и «они», что иронично, поскольку оба подхода в конечном счёте сосредоточены на предоставлении ценности клиенту. ITIL существует с конца 1980-х годов. Сертификация является одной из самых распространённых в мире. ITIL v3 был опубликован в 2007 году и обновлен в 2011 году. Последняя версия, ITIL 4, дебютировала в прошлом году.

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

Приверженцы DevOps часто приводят в пример «водопадную модель» разработки программного обеспечения как сумму проблем традиционного ITSM, характеризуя релизы как чрезмерно осторожные и одновременно слишком рискованные, поставляющие слишком мало, слишком поздно и слишком редко. Гораздо лучше, по мнению адептов DevOps, иметь несколько небольших и более частых релизов, что значительно снижает риск и в то же время быстрее приносит клиентам и компании пользу.

А в итоге, удалось ли DevOps выиграть битву за сердца и умы, предложив генеральный план того, как именно все организации должны теперь разрабатывать и поставлять программное обеспечение и технологии в будущем? И если да, то куда же тогда денется обширный пласт опыта и знаний, накопленных в области ITSM, как пример — в форме ITIL? Ответ на первый вопрос — «да, частично», в то время на второй вопрос — «вероятно, останется на своём же месте». Реальность такова, что два подхода никогда не были настолько далеки друг от друга и противоположны, как могло бы показаться. ITIL 4 проделал долгий путь, чтобы закрыть подобный разрыв в восприятии.

Как объясняет Марк Смолли, главный редактор книги «ITIL4® 4High-velocity IT» в своём интервью корреспонденту портала Theregister.com, ощущается определённое несоответствие. В области разработки программного обеспечения «быстро» — это хорошо, «скорость» определяется вехами и тому подобным. В то время как в «традиционном» управлении ИТ-услугами, «стабильно» — это хорошо, потому что у бизнеса будут потери, если системы вдруг начнут сбоить и не смогут на должном уровне поддерживать его. И вот он, казалось бы, неразрешимый парадокс между «стабильностью», что «хорошо», и «скоростью» — что тоже «хорошо». Как с этим быть?

Один из способов — изменить нашу точку зрения и рассмотреть более широко контекст обоих подходов.

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

Стоит помнить, что развитие управления ИТ-услугами как дисциплины было реакцией на появление и распространение систем, которые быстро развивались и требовали как аккуратного управления, так и предоставления. Управление ИТ-услугами было склонно к стабилизации и «заморозке» состояния дел «из лучших побуждений». Конечно, это также замедлило процессы развития, в конечном итоге вызвав к жизни Agile-движение.

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

Например, традиционный подход «крупных релизов», объединяющий в себе множество изменений и происходящий один или два раза в год, действительно нёс в себе огромные риски, признаёт Марк. Из-за того, что изменения были редкими, не создавалась база в виде практики работы с ними. Если же использовать подход со множеством мелких и частых изменений, то не только риск небольших изменений будет меньше, но и из-за того, что вы вносите изменения намного чаще, вы постепенно создаете среду с намного лучшими возможностями для внесения изменений.

ITSM также даёт расширенное представление о том, что означает термин «выполненная работа». Agile сосредотачивается на «потенциально готовом к поставке образце» программного обеспечения, в то время как DevOps распространяет его до «поставленного». Расширение представления в том, что думать нужно о совместно создаваемой ценности, востребованной лишь тогда, когда кто-то действительно что-то делает с продуктом или услугой, используя их.

Нужно расширить сферу деятельности группы разработчиков продукта, не ограничиваясь лишь вопросами развертывания. Убедиться, что продукт востребован у пользователей. Оперативно получать обратную связь. Задумываться об опыте его предоставления, например, расширяя традиционные соглашения об уровне обслуживания, которые зачастую довольно формальны и неуклюжи с точки зрения получаемых результатов.

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

На текущий момент сертификации ITIL 4 явно ориентированы на внедрение методов работы Lean, Agile и DevOps, например, в ITIL 4 Create Deliver and Support и ITIL 4 High-velocity IT. В то же время акцент на потоках создания ценности и важности культурных принципов проходит красной нитью через все публикации обновлённой библиотеки. Несмотря на это, некоторые исследования показывают, что за последние пару лет персонал ITSM менее склонен к участию в инициативах организации в части DevOps. И это упущенные возможности для обеих сторон!

AXELOS (компания-владелец ITIL) даёт конкретные рекомендации, что именно должны делать ITSM-специалисты, чтобы исправить такую ситуацию. Не следует ждать приглашения, чтобы участвовать в инициативах по DevOps — ведь дело в устранении разрозненности и выстраивании совместной работы в интересах как организации, так и отдельных команд.

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

Таким образом, вставая на путь DevOps-преобразований, в общих интересах использовать накопленные знания ITIL-сообщества, зная, что оно включает DevOps и иные методы организации работ в основе своего подхода. В конечном итоге и ITSM, и DevOps команды создают и предоставляют ценность клиентам. Все остальное — вопрос перспективы.

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

Комментариев: 2

  • Лилия Арсентьева

    Действительно, часто сталкиваюсь с «разрывом» ITIL — Agile\DevOps. Часто первое воспринимают как что-то старое и закостенелое.

    • Поддержу. Гартнер хорошо рисует свои Hype Cycle, которые отражают настроение индустрии. Понятно, что мода на ITIL/ITSM давно в прошлом. Также можно примерно предсказать, когда начнёт угасать мода на DevOps.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Открыта регистрация на вебинар «Какой SLM нам нужен?»
      22 апреля в 11:00 по московскому времени приглашаем вас на бесплатный вебинар «Какой SLM нам нужен?» Управление уровнем услуг — тема далеко не новая, но и …
    • Путешествие заказчика. Примеры. Часть 2
      Новый видеоролик продолжает серию, посвящённую концепции путешествия заказчика (customer journey), рассматриваемой на учебном курсе ITIL® 4 Specialist: Drive Stakeholder Value …
    • Поток создания ценности — поток создания чего?
      Прочитав замечательную статью моего коллеги «Все говорят: «Поток!». А ты построй поток» и возникшую после неё дискуссию, я подумала, что довольно часто сталкиваюсь с вопросом, а …
    • Service science в основе ITIL 4
      В редакцию портала поступил вопрос: Здравствуйте!  Роман Журавлёв в статье «Главное про ITIL 4» "...отнес к важным преимуществам то, что ITIL 4 опирается на такую …
    • Все говорят: «Поток!». А ты построй поток
      «А это была совсем не шляпа. Это был удав, который проглотил слона. Тогда я нарисовал удава изнутри, чтобы взрослым было понятнее.»Антуан де Сент-Экзюпери, Маленький принц Переход …
    • Роль лидера в продуктовой команде
      Довольно много людей полагают, что ключ к развитию потенциала и расширению возможностей продуктовых команд — это вежливо дать понять их руководству, чтобы они перестали …
    • Канбан-метод будет принят в качестве национального стандарта РФ
      Федеральное агентство по техническому регулированию и метрологии Росстандарт совместно с инициативной группой признанных российских экспертов по Канбан-методу объявило о начале …
    • Коммуникации в гибридной команде
      Благодаря неумолимой поступи нашей новой нормальности всё явственнее проявляются контуры будущей организации труда. Всё очевиднее становится понимание, что работа будет …
    • DevDays Moscow пройдут 8-10 июня
      С 8 по 10 июня в Москве пройдёт конференция DevDays Moscow, посвященная разработке программного обеспечения. В программе конференции Актуальные доклады (40+ спикеров) 7 …
    • Мотивация разработчика В2В продукта
      Команда создания и развития продукта состоит из разных людей: разработчиков, аналитиков, QA, владельца продукта и, иногда, из иных участников. Основной костяк этой группы …
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT