Вслед за повсеместным принятием на предприятиях концепции DevOps, поддерживающей активное взаимодействие всех участников жизненного цикла приложений, сегодня заговорили и о DataOps — подходе, который обеспечивает «демократизацию» данных, позволяет работать с ними всем сотрудникам предприятия. Участники дискуссии постарались разобраться, что в DataOps от проходящей моды, а что от насущных потребностей.

Сам термин DataOps появился в 2015 году в блоге Энди Палмера, вместе с Майклом Стоунбрейкером основавшего компанию Tamr. В марте 2017 года термин прозвучал на конференции Strata+Hadoop World, организуемой O’Reilly, а вскоре прочно вошел в лексикон профильных периодических изданий, в частности в ИТ-глоссарии Gartner. Саму концепцию уже взяли на вооружение такие компании, как Facebook, Netflix, Uber, LinkedIn, Twitter и eBay, развернув под нее соответствующую инфраструктуру.

Термин был выбран достаточно удачно – все его понимают как применение практик быстрой интегрированной разработки и эксплуатации на больших объемах данных, однако в его трактовке возникают разногласия. Разрешить их и была призвана дискуссия «DataOps – agile-подходы к работе с данными», которую в рамках форума BIG DATA 2018 провел Андрей Николаенко из IBS.

В ходе дискуссии обсуждались, например, такие вопросы: agile-методологии в работе с большими данными: скрещивание модных терминов или насущная необходимость? «Бимодальные ИТ», большие данные и DataOps: можно ли развести процессы и данные — часть в «традиционный модус», часть в «гибкий цифровой»? Имеет ли смысл накопление данных при их неясной ценности для анализа в будущем? При обсуждении второго вопроса участники дискуссии рассмотрили ситуацию, когда все данные общие, но с ними одновременно надо работать двумя разными способами: традиционно, когда релизы приложений выходят раз в полгода, и в цифровом режиме, когда обновления происходят несколько раз в день. Анджей Аршавский, директор Центра анализа данных и математического моделирования НЛМК, вместе с Антоном Исаниным, руководителем центра качества «Альфа-Банка», подтвердили, что в их компаниях налицо бимодальность ИТ, но аккуратное выстраивание над платформой данных правильных переходников позволяет эффективно работать с единой платформой в двух режимах.

Наиболее оживленную полемику вызвал вопрос о выживании в условиях DataOps профессий аналитика, математика, программиста, тестировщика и администратора баз данных, поскольку этих специалистов потенциально могут заменить «универсальные солдаты» — исследователи данных (data scientist). Участники дискуссии опровергли тезис о том, что возможно слияние специализаций. Например, Вадим Индриков, начальник отдела системной архитектуры ГНИВЦ ФНС РФ, и Валерий Артемьев, консультант отдела разработки политик, стандартов и процедур Управления методологического и организационного обеспечения департамента статистики и управления данными Банка России, обратили внимание на то, что в командах скорой разработки очень важны взаимная страховка и понимание работы коллег. В этом смысле, как отметил Олег Егоркин, директор проектов «Ростелекома», важно владеть смежной квалификацией, но при этом само по себе понимание работы смежника и готовность его подстраховать вовсе не означает «универсализацию специализаций» – нельзя быть автомехаником, лишь обладая навыками замены колеса. Интересный момент по поводу слияния специализаций по работе с данными отметил Артем Данилов, архитектор хранилища данных в Avito.ru. Менеджеры по работе с посетителями портала Avito, сказал он, владеют SQL, составляют визуальные отчеты и с помощью запросов к базе постоянно решают возникающие нестандартные задачи, что, впрочем, не делает их разработчиками платформы данных, поскольку хранилище и витрины создают все-таки профильные специалисты.

Итак, по мнению участников дискуссии, чтобы «демократизировать» данные, нужно преобразовать как средства доступа к ним, так и способы управления данными, обеспечивающие коммуникации и интеграцию уже имеющихся данных, команд и систем. На решение этой задачи и направлена концепция DataOps — установление связи тех, кто собирает и готовит данные, с теми, кто их анализирует и применяет в бизнесе. Данные не принадлежат ИТ, специалистам по данным или аналитикам. Они принадлежит всему бизнесу, а инструменты самообслуживания должны позволять всем сотрудникам компании создавать собственные аналитические отчеты и визуализации, делясь своими открытиями с коллегами. В этой связи, как прогнозируют аналитики Gartner, уже в ближайшие годы 80% компаний из Global Fortune 1000 будут использовать в своей практике методологию DataOps.

DataOps (акроним от data и operations) — это новая методология, предполагающая совместную работу объединенных команд разработки и эксплуатации ИТ-систем (DevOps), инженеров по подготовке данных (data engineer) и исследователей данных (data scientist) для создания инструментов, процессов и организационных структур, необходимых предприятию, опирающемуся в работе на данные.

«Сегодня, помимо тенденции разработки с опорой на принципы DevOps, набирает силу новая, связанная с тем, что и в системы, и в сами процессы разработки внедряются элементы анализа данных. Поэтому в группе DevOps должен быть специалист соответствующего профиля», — объясняет Тед Даннинг, главный архитектор приложений компании mapR Technologies.

Принципы DataOps

Подобно DevOps, DataOps опирается на принципы скорой (agile) разработки. В рамках DataOps приоритетами являются непрерывная доставка аналитических знаний и ориентация на удовлетворенность клиента.

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

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

Для чего годится DataOps

DataOps — подход, направленный на поддержку процессов машинного обучения. «Например, исследователи данных, работая по схеме DataOps, могут более продуктивно взаимодействовать с инженерами ПО в процессе передачи отделу эксплуатации моделей для развертывания, — говорит Эллен Фридман, ведущий технолог mapR. — Но DataOps не ограничивается машинным обучением. Этот подход полезен для любых работ, связанных с анализом данных, так как он облегчает использование преимуществ, предоставляемых распределенными платформами управления данными».

Кроме того, DataOps хорошо сочетается с архитектурами на основе микросервисов.

DataOps на практике

Новые технологии требуют от предприятий перемен, способностей работать с большими объемами данных и оперативно реагировать на события.

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

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

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

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

При этом не требуется, чтобы специалисты в области Data Science работали в группе DataOps на постоянной основе: обычно исследователя данных включают в команду на определенное время, впоследствии он может перейти в другую команду, а его роль в группе берет на себя другой участник, например инженер по подготовке данных, иными словами, происходит постоянная ротация.

Как сформировать команду DataOps

Для создания команды DataOps не обязательно нанимать новых специалистов. Во многих организациях уже есть костях группы DataOps — участники имеющихся команд DevOps. Следующий этап — выбрать проекты, сопряженные с разработкой механизмов анализа больших объемов данных, и найти специалиста, имеющего опыт исследования данных. Это может быть инженер по подготовке данных, а не обязательно специалист в области Data Science.

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

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

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

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