Все началось с объединения разработки и операций в DevOps, а теперь организации переходят на другие Ops-методологии в рамках ИТ и вне их. Опрошенные порталом InformationWeek эксперты рассказывают об особенностях методологий XOps.

BizOps, MarketingOps, DevOps, AIOps, MLOps, DataOps... Как следует из названий, все это межфункциональные методологии, но нужны ли они компании? Если нужны, то какие именно? Все зависит от точки зрения. Очевидно, что организации находятся на разных стадиях зрелости. На это влияет отрасль, размер, возраст, культура, уровень внедрения технологий и бюджет компании. Однако в последнее время они все чаще нуждаются в преимуществах, которые предоставляют различные виды XOps. Как и DevOps, они нацелены на ускорение процессов и повышение качества, будь то программное обеспечение (DevOps), данные (DataOps), модели машинного обучения (MLOps) или аналитика (AIOps).

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

XOps начались с DevOps

Практика гибкой разработки ПО пользуется популярностью в бизнесе. Бизнес-лидеров еще с начала 2000-х убеждали, что их компаниям нужно быть более гибкими, чтобы оставаться конкурентоспособными. В ответ на это многие команды agile- разработки ПО приняли на вооружение методы DevOps и все чаще делают шаги навстречу непрерывной интеграции/непрерывной доставке (CI/CD). Последние автоматизируют дополнительные задачи, обеспечивая видимость, сквозную работу всех операций конвейера и более плавные потоки процессов, чем предлагает традиционная каскадная модель доставки ПО. DataOps, MLOps и AIOps — это также межфункциональные проекты, ориентированные на постоянное улучшение, эффективность и улучшение процессов.

Ландшафт XOps

Ops-ландшафт продолжает расширяться, но особый интерес представляют DataOps, MLOps и AIOps.

DataOps — это процессно-ориентированная методология, которая для повышения скорости выполнения связанных с данными задач задействует автоматизацию, что в конечном счете влияет на качество анализа. По словам Арвинда Прабхакара, CTO поставщика DataOps-платформы StreamSets, DataOps предоставляет для компаний со сложной инфраструктурой данных гибкость управления изменениями. «Количество людей в цепочке поставок данных зашкаливает, и современному предприятию приходиться с справляться. Но сделать это на уровне современной инфраструктуры данных на порядок сложнее, чем было 10 лет назад», — сказал он.

Как и DevOps, DataOps включает в себя быструю итерацию цикла, оценку и мониторинг для того, чтобы упростить сквозное понимание данных. Ключевую роль здесь играет инженер по данным. А директор по данным (CDO) — в компаниях, где он есть — управляет оптимизацией процессов, чтобы обеспечить надежность данных и управление ими.

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

Консалтинговая фирма Booz Allen Hamilton начала свое знакомство с MLOps с изучения концепций DevOps и того, как их можно связать с MLOps. «Вы должны объединить вместе технологов, архитекторов данных и ИБ-экспертов», — рассказал старший вице-президент и руководитель аналитического направления компании Джон Ларсон. Это позволяет привносить в среду разработки моделей МО новые идеи, такие как контейнеризация, упрощающая масштабирование и развертывание.

Сейчас компания применяет MLOps для оценки производительности, дрифта (ухудшение прогнозируемой производительности), а также правильности развертывания моделей МО в режиме реального времени.

«Важно контролировать версии данных, версии моделей и их развертывание. В этом помогает интеграция MLOps с DataOps и DevSecOps в инфраструктуру DevOps, — говорит Ларсон. — Я думаю, что важно масштабировать и адаптировать то, что мы делаем, потому что это даст нам механизмы, инструменты, средства отслеживания, чтобы понять, что происходит в процессе развертывания модели, как она дрейфует и обновляется».

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

XOps: так хайп ли это или нет?

Главный аналитик Forrester Чарльз Бетц советует не обращать внимания на хайп, поднятый вокруг XOps: «В известной мере это обычная возня и люди просто генерируют сырые идеи, чтобы посмотреть, какие из них приживутся. На самом деле меня действительно не трогают все эти BizOps, DevOps, DevSecOps, BizDevSecOps, MarketingOps. В основном все они делают одно и то же, и это движение к более межфункциональному способу работы».

Одна из причин не гоняться за различными формами XOps заключается в том, что это противоречит современным тенденциям найма ИТ-персонала. Традиционно предпочтение отдавалось специализации, но сегодня диапазон ИТ-функций становится шире (например, разработчик полного стека или Site Reliability Engineer). HR-специалисты говорят, что для отдела или команды важнее иметь правильное сочетание навыков, а не правильное сочетание званий или ролей.

«Крупные компании рассказывают, что у них проблемы с координацией работы. На прошлой неделе сразу два старших вице-президента сказали мне: „Не могу найти администраторов (DBA) для каждой продуктовой команды, поэтому мы сталкиваемся с проблемой предоставления общих услуг“, — поделился Бетц. — Экспертизы не хватает, и непонятно как решить эту проблему, не возвращаясь к плохим старым временам, когда требовалось шесть месяцев, чтобы заполучить в команду того, кто нужен. Вот почему людям нужен межфункциональный мир».

Он считает, что методы Scrum и Agile нужно вложить в правильные руки, и в первую очередь это продуктовые команды. «В идеале у продуктовой команды должны быть ресурсы и разрешения, необходимые для выполнения работы. И операционная модель, основанная не на обмене и транзакциях, а на сотрудничестве, — говорит Бетц. — Фундаментальным смыслом всего этого является то, что операционная модель переключается с транзакций с высокими издержками на чистое сотрудничество между сфокусированными командами, при этом процессные и транзакционные трения являются скорее исключением, а не правилом».

Хотя аргумент о том, что разные виды XOps требуют различной экспертизы, имеет смысл, нужно остерегаться излишней сложности и бюрократии. «Существуют неопровержимые доказательства, что чрезмерная специализация заводит процесс в тупик, — утверждает Бетц. — Вы обзаводитесь группой менеджеров среднего звена, потому что ваша зарплата привязана к количеству людей, которые вам подчиняются, и все они пытаются расширить свои владения».

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

Сегодня на предприятиях формируется все больше DevOps-подобных структур, на что поставщики отвечают такими решениями, как DataOps. Однако с точки зрения конкурентоспособности наличие нужных возможностей является более важным, чем то, как они называются. Учитывая организационную уникальность компаний, классификация XOps для них будет столь же индивидуальной, как и в случае с DevOps.