Могут ли ITIL и DevOps сосуществовать? Этим вопросом недавно задался некий Гарет Дэйн, попросивший около 25 профильных экспертов и наблюдателей поделиться мнением относительно того, являются ли эти две методики конфликтующими или совместимыми. Модель ITIL, изначально расшифровывавшаяся как «библиотека инфраструктуры информационных технологий», представляет собой набор оптимальных практик, официально признающих и утверждающих документально, что ИТ-решения поставляются организациям в виде материально осязаемых сервисов. А модель DevOps старается согласовывать результаты работы команд программистов со специалистами, ответственными за выпуск программ, поддерживая таким образом непрерывный поток релизов по мере возникновения соответствующих бизнес-нужд.

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

Тем не менее, судя по различным точкам зрения, собранным Дэйном в его посте, в целом все сходятся на мнении, что несмотря на разногласия между двумя подходами, в худшем случае они друг другу не мешают, причем многие считают, что в долгосрочной перспективе они друг друга дополняют. (Я, среди прочих, и сам поучаствовал в обсуждении этого вопроса.)

«Я точно уверена в том, что ITIL и DevOps совместимы, — говорит в унисон множеству других специалистов Карен Феррис, директор и эксперт по управлению ИТ-сервисами фирмы Macanta Consulting. — С первого дня существования модели ITIL в ней утверждалось, что ее необходимо „принимать и адаптировать“, что, собственно, до сих пор справедливо и для модели DevOps. Возможно, формулировка этой мысли отличается, но результат один и тот же — повышение эффективности бизнеса там, где это необходимо».

Другие замечают, что несмотря на то, что менталитеты ITIL и DevOps отличаются, обе концепции служат для сближения ИТ-услуг и бизнеса — а больше от них ничего и не требуется. «Модель ITIL для управления качеством сервисов — это совсем не то же самое, что модель гибкой разработки ПО (Agile), — утверждает Рой Эткинсон, аналитик в области техподдержки и ИТ-услуг, а также автор текстов и докладчик профессиональной ассоциации HDI. — Если сравнить с Манифестом гибкой методологии разработки ПО, то некоторые его положения полностью противоречат догматам ITIL, к примеру, положение о необходимости «реагировать на изменения, а не жестко следовать плану». Все же он добавляет: «Гибкие методики не поощряют скоропалительных реакций и непродуманной деятельности; их целью всегда является получение высокого качества путем итераций и определения приоритетов. Следуя по пути внимательного отношения к управлению услугами и не забывая при этом о практике реагирования на изменения, можно быстрее добиться целей, которые ставит перед собой гибкая методика разработки».

Стив Велан, эксперт по ITIL и инструктор консалтинговой фирмы Purple Griffon, считает, что DevOps является фактическим продолжением учения, основанного на идеях ITIL. «В плане организации процессов DevOps является всего лишь подмножеством ITIL, ведь под описание ITIL подходят все процессы, упомянутые в DevOps. Получается, что в DevOps нет ничего такого, чего не было бы в ITIL. По сути ITIL описывает, что делать, а DevOps — как это делать».

Джулиан Симпсон, разработчик ПО в компании Neo Technology, считает, что взаимодействие между ITIL и DevOps зависит от типа организации, в которой вы работаете. «Стартап из двух человек, пишущих мобильные приложения, может совсем игнорировать принципы ITIL без каких бы то ни было негативных последствий. Однако если так же попытается поступить страховая компания из 1000 человек, в ее случае последствия будут ужасными», — замечает он. В конечном счете, для организаций любого размера и типа «важнее всего наладить процесс таким образом, чтобы цели всех отделов и коллективов были созвучны друг другу, а между людьми установилось доверие».

Дэниел Брестон, глава отдела реорганизации процессов DevOps компании Ranger4 Limited, предлагает объединить ITIL и DevOps в некую гибридную модель «гибкого управления ИТ-услугами» (AgileITSM), активно продвигающую культуру сотрудничества, обмена информацией, контроля за ходом и качеством работ и — как же без него — удовольствия от процесса.

По большому счету в центре внимания должен оставаться клиент — как внутренний, так и сторонний, — так что и ITIL, и DevOps помогают командам ИТ-специалистов сосредоточиться на этом объекте внимания, говорит Каймар Кару, глава отдела ITSM фирмы Axelos. «Секрет получения максимальной пользы от ITIL заключается в том, чтобы внедрить сам менталитет управления услугами, но адаптировать отдельные правила под конкретные нужды организации. DevOps как раз помогает это сделать и подсказывает дополнительные способы реализации ключевых концепций управления услугами, создавая новые преимущества благодаря сотрудничеству и оставляя при этом в приоритете клиента».

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

Разумеется, обе философии чаще внедряются на словах, чем на деле, говорит Эткинсон. «DevOps и ITIL могут уживаться под одной крышей, но сосредоточиться нужно именно на достижении эффективного результата, а не на совершенствовании выбранной философии. Весьма часто можно наблюдать, как организации слишком много значения придают громким названиям, но при этом не следуют ни духу, ни букве соответствующей философии».