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

Все ИТ-системы организации можно классифицировать по трем уровням (согласно модели Gartner Pace Layered Application Strategy – PLAS):

• Учётные системы (systems of record), которые поддерживают основные транзакции и критические данные. Такие системы обычно редко меняются и регулируются нормативными требованиями.
• Дифференцированные системы (systems of differentiation), которые поддерживают уникальные процессы компании или отрасли. Они нуждаются в достаточно частых изменениях для удовлетворения меняющихся потребностей бизнеса и клиентов.
• Инновационные системы (systems of innovation), которые оперативно создаются и изменяются с учетом новых требований и возможностей.

Один из подходов – ввести DevOps для инновационных систем, защищая изменения остальных систем более традиционным подходом. Это позволит получить некоторые преимущества от DevOps при сохранении безопасности критичных бизнес-систем, однако фактически предполагает  наличие двух внутренних ИТ-организаций с различными способами работы, инструментами, а главное с разным отношением, поведением и культурой (Attitude, Behaviour and Culture – ABC).

ИТ-подразделения постоянно жалуются на то, что команды разработчиков «перебрасывают  ПО через стену», создавая проблемы как для ИТ, так и для клиентов. По мнению Стюарта, в DevOps есть набор идей, которые позволяют раз и навсегда устранить эту стену, и могут применяться даже для критичных бизнес-систем:

1. Формирование кросс-функциональных команд, в которые входят разработчики, а также поддержка и эксплуатация. Поставьте перед этими командами цели, которые связаны с реальными бизнес-результатами, и мотивируйте на предоставление ценности для заказчика.
2. Вовлечение сотрудников эксплуатации на ранних этапах разработки. Они должны не просто выдать разработчикам несколько «нефункциональных требований» и ждать, пока дадут протестировать конечный продукт, но принять участие и предоставить необходимую экспертизу, чтобы убедиться, что системой можно управлять, что инциденты и проблемы диагностируются, что производительность измеряется.
3. Привлечение разработчиков на более поздних стадиях жизненного цикла. Сообщайте им, когда происходит сбой, чтобы они могли принять участие в сборе данных, необходимых для диагностики сложных проблем. Позвольте им испытать на себе, как трудно выполнять регулярные задачи эксплуатации, чтобы они могли улучшить дизайн в следующий раз.
4. Разработка сквозных процессов. Не создавайте процесс управления изменениями, предназначенный только для защиты эксплуатации, пусть он будет сквозным и объединяет сбор требований, разработку кода, построение релиза, разработку и проведение тестов, подачу запросов на изменение и их согласование, развертывание финального варианта. Если вся эта деятельность спроектирована как единый процесс, то вы сможете его оптимизировать, например, используя Теорию ограничений (Theory of Constraints – TOC), выявите участки, требующие улучшений, и сосредоточьте усилия на том, что имеет значение.   

Даже если для компании не применимы все идеи вместе, вероятно, есть одна или две, которые можно использовать, чтобы улучшить интеграцию между разработкой и эксплуатацией ИТ. А какие методы используются для этого у вас?