Привет, друзья! Я Олег Васильев, владелец продукта Dream DE. В этой статье расскажу, как мы научились быстро и эффективно выводить витрины на Hadoop в эксплуатацию, или как мы за один квартал вывели 26 инициатив в рабочую среду силами четырёх инженеров по данным.

Ситуация: выводим ИИ-решения в эксплуатацию

Наша команда занимается выводом в эксплуатацию ИИ-решений для всего блока. Как мы это делаем? Мы выводим в приложение корпоративной аналитической платформы, которое у нас сделано на основе Hadoop, три сущности:

• витрину данных для модели;

• модель в пакетном исполнении;

• интеграцию.

Задачи у нас типовые, все витрины строим на внутренних источниках по подпискам в Супермаркете данных (СМД) или на внутренних данных ПКАП; модель исполняется в ПИМ, а интегрируем двумя стандартными путями: Kafka Synapse и транспортной файловой системой.

Что не так?

Проблема: теряем много времени

На вывод витрин в эксплуатацию уходило слишком много времени. Вот так у нас выглядел этот процесс раньше:

В нашей Лаборатории данных аналитик разрабатывал прототип,  формулировал бизнес-требования и передавал их нашей команде. Если нас что-то не устраивало, мы отправляли их обратно. После внесения необходимых изменений мы переходили к тестированию прототипа. Если обнаруживались ошибки, мы сообщали о них заказчику, который их исправлял и возвращал нам задачу.

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

Когда все проверки были пройдены, мы передавали всю информацию delivery-менеджеру. Он создавал задачу в Jira согласно стандартному релизному циклу, и мы запускали модель в эксплуатацию. Обычно весь процесс по выводу витрины занимал около 20-30 дней.

Последствия проблемы

Во-первых, возникают краткосрочные проблемы. Заказчику приходится несколько раз передавать свои требования, возникает эффект пинг-понга. Для нашей команды это приводит к высоким непрогнозируемым затратам времени на разработку (Time-to-Market), снижению качества сервиса и увеличению стоимости внедрения. А эти показатели являются основными метриками для нашей команды.

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

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

Как другие решают эту проблему

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

Мы выбрали другой путь.

Как мы решили эту проблему

Мы изменили подход к передаче требований заказчиком, перешли на новый формат взаимодействия с ним и автоматизировали работу инженеров по данным в своей команде.

Новый подход к работе с требованиями

Раньше заказчик вручную переносил много информации в Confluence или Jira. Теперь он проходит Data Mart Quality Gate (DMQG), запускает в Лаборатории данных 3.0 некий Jupyter notebook, внутрь которого встроены различные проверки и функциональность, позволяющая собрать всю необходимую нам информацию об источниках и целевых витринах. Если прототип рабочий, то заказчик может двигаться дальше. Другими словами, если заказчик успешно прошел через Jupyter notebook, то его требования считаются подтверждёнными и задача должна быть выполнена в прогнозируемые сроки.

После прохождения Data Mart Quality Gate, который проверяет прототип, выполняется коммит в наш репозиторий, и на его основе в Jira создаётся задача для нас. Таким образом, заказчику больше не нужно выполнять никаких действий, кроме прохождения quality gate.

Это значительно упрощает работу, так как ранее нам приходилось вручную агрегировать информацию из разных источников, в том числе для составления корректного S2T для загрузки в КАП МЕТА.

Изменился формат взаимодействия с заказчиком

Мы изменили способ общения с заказчиком. Раньше требования записывали в Confluence, теперь представляем их в виде задачи в Jira. Мы используем систему Kanban, которая позволяет увидеть, на каком этапе находится каждая инициатива. Прежде мы составляли планы на квартал со всеми нашими клиентами, но отказались от этой практики. Вместо этого мы предоставляем услуги на основе сервиса, и наша текущая пропускная способность позволяет удовлетворить все потребности клиента. Мы работаем по принципу «первым пришёл — первым обслужен» (FIFO), что делает весь процесс прозрачным и удобным для всех.

Автоматизация работы инженеров по данным

Мы создали инструмент под названием DreamDE, который автоматизирует все ручные задачи, выполняемые нашими инженерами по данным. После того, как информация в Data Mart Quality Gate заполнена, прототип заказчика и необходимая метаинформация загружаются в наш сервис. Его веб-интерфейс позволяет заказчику узнать подробности о предстоящей разработке, включая срок выполнения и тип изменений.

Затем одним нажатием кнопки начинается автоматическая подготовка репозитория для сборки в релизный Nexus. В результате получается проект в Bitbucket, содержащий готовый код для опромышливания. Он содержит стандартное ядро, соответствующее требованиям SberData, в которое интегрируется прототип, а также автоматически сгенерированные необходимые обвязки в виде CTL-потока, оркестратора Oozie и систем обработки журналов.

То есть одним нажатием кнопки запускается процесс непрерывной интеграции и доставки (CI/CD), которым централизованно управляют в SberData. Jenkins Job собирает дистрибутив, который затем отправляется в рабочую среду Nexus. После этого релизному менеджеру автоматически отправляется письмо с просьбой создать Release 2.0, который менеджер может сделать одним нажатием кнопки из полученного письма.

Таким образом, процесс вывода витрины в эксплуатацию сводится к 20-30 кликам мыши. Более того, сервис позволяет увидеть, кто и что делал и как это работает. Сервис позволяет просматривать информацию о каждой инициативе заказчика, её разработчике, названии в рабочей среде и способе работы. Благодаря синхронизации с Bitbucket, мы в Delta можем видеть, как наши CTL-потоки бегают в рабочей среде, что значительно облегчает поддержку.

Мы подключили к нашему сервису шесть внутренних команд нашего блока и две внешние команды. За первый квартал удалось силами четырёх инженеров по данным вывести в эксплуатацию 26 инициатив, каждая из которых включает в себя витрину, модель и, в некоторых случаях, интеграцию. Cредний t2m — 6 дней с момента передачи требований заказчиком. CSI по итогам 2024 года был 9,7 баллов.

Как пользоваться нашим сервисом

Процесс работы с нашим сервисом состоит из пяти частей: 

• митап для команды;

• регистрация команды;

• команда заполняет некий конфигурационный файл, в котором описываются все параметры работы команды, такие как пространство в Jira, DevOps, кластер автоматизации всех ручных операций и т. д. 

• мы выводим первый релиз вместе с командой;

• а дальше они двигаются самостоятельно.