То, что DevOps не является "серебряной пулей" наверное уже ни для кого не секрет. Применение гибких практик разработки и эксплуатации продуктов существенно отличается от общеизвестных практик управления услугами своей выраженной ориентацией на ценность здесь и сейчас. Многолетний мир ITSM, в первую очередь, ориентирован на рациональность с акцентом на минимизацию затрат, рисков и ущерба. Многие могут это оспаривать, опираясь на первоисточники, не без оснований говорить, что библиотеки говорят о необходимости баланса между гибкостью и защищенностью, рисков и выгод. Да, это так, но всё же управление услугами не о том, как быть бизнесом, а о том как бизнесу помогать, а это "две большие разницы".

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

"Fail Fast!", подумали ракетостроители и сноровисто, отточенными движениями приварили к конструкции ещё пару твердотопливных ускорителей.

Взглянем на настоящую организацию, в которой мы работаем. С высокой вероятностью мы увидим, что в нашей организации нам потребуется совмещать эти разные способы производства. Если это средний или крупный бизнес, то кроме наших ключевых бизнес-приложений, где мы пусть успешно удовлетворяем требования бизнеса наиболее быстрым способом, у нас есть и более "медленные" подразделения. Это управление кадрами, со системами которых мы интегрируемся, информационная безопасность, требования которой мы не можем игнорировать. Пусть у нас есть ещё защищенная real-time система управления техническими процессами производства, сбои в которой чреваты человеческими жертвами или физическим разрушением производства, релизы в ней редки, но они проходят колоссальную по свой тщательности проверку и тестирование.

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

Нельзя не учитывать существенный риск непрерывности бизнеса в лице колоссальной зависимости бизнеса от команды развивающей продукт и входящих в неё людей. Необходимо защищать себя от риска ухода команды, увольнения ключевых сотрудников, утечки данных или технологий, а это означает сохранение знаний, детальное документирование. То есть именно то, что тратит дорогие ресурсы и уменьшает возможности команды по "delivery" в рамках производственного цикла.

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

Мы здесь надолго, поэтому нам нужно уже сейчас учиться его решать, разделять ресурсы, управлять и продолжать доносить ценность.