Из-за растущей конкуренции и развития новых технологий требования бизнеса к ИТ меняются настолько динамично, что зачастую видение проекта в его начале кардинальным образом преображается к завершению. Поэтому если раньше вендоров выбирали исходя из их репутации, технологической экспертизы и опыта, то теперь к критериям оценки добавилось умение быстро принимать решения и адаптироваться к изменениям. Если следовать классическим принципам ITIL (IT Infrastructure Library) без привязки к специфике конкретных проектов, то можно прийти к излишней формализации процессов. А это сильно замедляет принятие решений. Как показывает мой личный опыт, добиться гибкости и оперативности можно сочетая ITIL и DevOps.

ITIL раньше и сейчас

Первое издание ITIL, содержавшее узкопрофильные рекомендации по поддержке инфраструктуры, было опубликовано в конце 20-го века. В современной версии собрана коллекция лучших практик управления ИТ-услугами (ITSM) на каждой стадии жизненного цикла: анализ требований к сервису, его подготовка и встраивание в рабочую среду, эксплуатация и усовершенствование. Библиотека ITIL описывает все сферы деятельности ИТ-департамента, позволяя централизованно управлять процессами в соответствии с требованиями бизнеса.

Что такое DevOps

Понятие DevOps (аббревиатура из слов «development» и «operations») появилось относительно недавно. DevOps — это практика управления проектами, которая предполагает максимально плотное общение разработчиков и системных администраторов.

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

Противостояние разработчиков и администраторов

Методологии методологиями, но поговорим о людях. В данном случае о тех, кто непосредственно отвечает за разработку и эксплуатацию ИТ-систем. Взаимоотношениям «админов» и «разрабов» и их неспособности договориться посвящен немалый пласт современного фольклора, как правило, анекдотов. И это могло бы быть смешно, если бы не было так грустно. Ведь в результате конфликтов и недопонимания страдают ИТ-системы, а следовательно, и бизнес. Почему две стороны, имеющие одну цель («боеспособность системы»), не могут найти общий язык? Всё дело в разнице мышления, а также в том, что каждая из этих групп оценивает свою работу по разным показателям. Для разработчиков это в первую очередь скорость реализации изменений в программном коде. Для отдела эксплуатации — стабильность работы систем и минимум инцидентов. В результате возникает конфликт интересов: первые стараются как можно быстрее написать код и передать его в эксплуатацию, тогда как вторые, наоборот, не любят изменений, которые влекут за собой потенциальные риски.

Ситуация усложняется тем, что разработчики и администраторы работают в разных структурах и офисах компании, подчиняясь разным менеджерам, которые в свою очередь также конкурируют между собой. Есть и еще одна причина недопонимания: разработчики и администраторы пользуются самостоятельными, не интегрированными друг с другом инструментами. Но даже если системы связаны, они по-разному используют их.

При этом обе стороны считают, что выполняют свою работу хорошо, и по-своему те и другие правы: организации одинаково ценят шустрых программистов с большим КПД и внимательных администраторов, которые заботятся о бесперебойном функционировании систем.

Типичный производственный кошмар

Проблемы начинаются, когда программист передает свежие изменения в службу эксплуатации. Администратор вручную настраивает их под свое окружение, которое зачастую отличается от среды разработки. В лучшем случае он предварительно делает копию кода, а в худшем — редактирует рабочую версию, плодя в ней новые ошибки и уязвимости.

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

Однако развертывание приложения без должной проверки может обернуться большими потерями. Так было с Knight Capital Group, одним из крупнейших участников фондового рынка США. В 2012 году компания выпустила плохо отлаженную программу для высокочастотной торговли, которая начала автоматически открывать позиции по сотням бумаг, и в итоге меньше чем за час потеряла 500 млн долларов.

Чаще всего системные сбои происходят на стадии развертывания. Чтобы их избежать, разработчики и ИТ-подразделения должны действовать сообща еще задолго до этого.

Как подружить разработчиков и администраторов

Все организационные практики строятся вокруг трех целей: эффективность, доступность и прозрачность процессов. Например, формализованные инструкции ITIL по управлению инцидентами позволяют администраторам оперативно обрабатывать запросы. Agile обеспечивает прозрачность процессов разработки, стимулируя сотрудников больше общаться, обмениваться информацией и опытом. Lean-методологии помогают оптимизировать работу благодаря максимальной автоматизации и исключению из процесса действий, которые не добавляют ценности для пользователя.

DevOps же помогает стереть черту между разработчиками и администраторами, объединяя их в единую среду с общими инструментами для разработки и проектного управления.

Как мы комбинируем ITIL и DevOps

У DevOps и ITIL одинаковый взгляд на жизненный цикл ИТ-сервиса, но разный — на способы реализации каждой стадии. Почему бы не взять лучшее от обоих подходов?

Например, при управлении инцидентами и проблемами в Itransition мы берем за основу положения ITIL, но работу с инфраструктурой проекта для удобства переносим в общий чат. Эта методика называется ChatOps. Команды запускаем прямо из чата, при этом и разработчики, и администраторы видят, что происходит, в режиме реального времени. Рабочий процесс принадлежит команде, все могут посмотреть историю изменений, запускать свои команды, обмениваться информацией и оперативно помогать друг другу.

Аналогично с помощью DevOps мы оптимизируем процесс ITIL по управлению требованиями и изменениями. Согласно положениям ITIL, изменения рассматривает специальный Советом по изменениям (Change Advisory Board), который собирается с определенной регулярностью, скажем, раз в неделю, что влечет за собой задержки. Гибкая культура DevOps предполагает более широкое распределение ответственности за авторизацию изменений. Эти функции поручаются соответствующим функциональным менеджерам, которые принимают решения по мере необходимости.

На всех стадиях проекта мы в компании Itransition активно используем инструменты автоматизации и контроля, рекомендованные DevOps. Благодаря интеграции и автоматизации процессов и инструментов разработчики и администраторы могут оперативно менять компоненты продукта в соответствии с новыми требованиями.

Почему мы не ограничиваемся методологией DevOps? Потому, что у нее есть один серьёзный недостаток: гибкий подход порождает риски. При частых обновлениях и недостаточном количестве тестов вероятность поломок возрастает в разы. Поэтому важно регулировать соотношение DevOps и ITIL под каждый конкретный проект в зависимости от его особенностей.

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

Об авторе:

Максим Советкин окончил факультет прикладной математики и информатики Белорусского государственного университета. В Itransition работает уже более семи лет, отвечая за проектирование, развитие и поддержку корпоративной ИТ-инфраструктуры.