Прошло около десяти лет с тех пор, как 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 команды создают и предоставляют ценность клиентам. Все остальное – вопрос перспективы.
Действительно, часто сталкиваюсь с “разрывом” ITIL – Agile\DevOps. Часто первое воспринимают как что-то старое и закостенелое.