Портал №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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

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

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT