Привет, Хабр! Меня зовут Дмитрий Бодин, в МТС Диджитал я руковожу командой интеграции DataOps Platform — платформы по работе с данными. Мы занимаемся внедрением и сопровождением инструментов DataOps внутри экосистемы МТС.

При запуске DataOps Platform мы увидели слабую заинтересованность в ее сервисах, так как все привыкли работать с инструментами от известных вендоров. В этот момент мы поняли, что очень важно продвигать платформу внутри компании и сопровождать пользователей на всех этапах внедрения.

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

На старте про внутренний продукт пришлось много рассказывать

DataOps Platform обеспечивает экосистему МТС инструментами для потребления, хранения, преобразования и визуализации данных в соответствии с практиками DataOps. Сначала это направление развивалось внутри МТС в виде отдельных компонентов: что-то мы брали из open-source, а что-то писали сами. Например, onETL — Python-библиотеку для ETL/ELT-процессов, основанную на Apache Spark и других open-source-утилитах. В 2023 году мы объединили инструменты в платформу и начали активно внедрять ее внутри МТС. И сразу же столкнулись с проблемой: новый продукт по умолчанию никому не нужен.

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

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

Затем мы провели серию митапов, где продакты детально рассказали о каждом продукте DataOps-платформы: 

• DataOps.BI: дашборды на основе корпоративных источников данных с использованием гибкой модели ролевого доступа;

• Data Catalog: точка входа для вопросов по данным. В нем можно узнать, какие данные есть в МТС как экосистеме, их характеристики и откуда их можно получить;

• Data Quality: self-service-инструмент для контроля качества данных;

• Data Virtualization: распределенный движок выполнения SQL-запросов, которые исполняются системой в различных источниках данных;

• ETL: инструменты и сервисы для реализации процессов выгрузки, загрузки и трансформации данных;

• DataOps.Streaming: инструмент самообслуживания для потоковой обработки данных, позволяющий даже начинающему разработчику в сжатые сроки реализовать streaming-процесс;

• Databases: кластеры Greenplum и ClickHouse в формате PaaS; 

• Hadoop: администрирование собственной сборки Hadoop (DataOps Hadoop) и поддержка уже существующих кластеров.

Также организовали OpenDay DataOps-платформы: сделали рассылку на всю компанию, провели демо каждого инструмента, собрали обратную связь и ответили на вопросы участников. На сессии Q&A мы вскрыли моменты, которые на самом деле волновали пользователей, получили запрос на процесс Feature Request и затем уже реализовали его в платформе. 

В результате за два дня нам прислали почти двести запросов. Но это было только начало. 

С ростом числа новых пользователей потребовался их онбординг и сопровождение

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

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

В нашем случае решением стало единое окно входа — моя команда Customer Happiness. Она нежно подхватывала пользователя и в рамках проектного подхода проводила его до успешного подключения. Также мы запустили три линии поддержки, чтобы сопровождать после интеграции весь период работы с нашим решением.

В 3 квартале 2024 года в команду технической поддержки у нас поступило 4 000 запросов: на консультации, изменение прав доступа или регистрацию инцидентов. Все обращения падают на первую линию поддержки, если они не решаются на первой линии, заявка переходит на вторую линию и так далее. Сейчас у нас четыре инженера, а в начале 2023 года не было ни одного, и весь поток обращений лился в команду разработки.

Многим пришлось помогать с нуля, поэтому нам потребовались ресурсы для MVP «под ключ» 

У нас в экосистеме много разных продуктов, и часто у них на старте нет серверов и нужных компетенций в командах. К тому же внедрение начинается с гипотез, на проверку которых тяжело найти ресурсы. 

Чтобы исправить это, на время MVP мы стали выделять мощности в нашем внутреннем облаке. Пользователи тестируют платформу и инструменты и параллельно стартуют процесс защиты бюджета. 

Дополнительно мы передаем в команды матрицы компетенций и требования к ролям — так проще определить, кого у них не хватает, и правильно составить текст вакансии для поиска. 

Начали вместе с пользователями прорабатывать оптимальную архитектуру

У многих команд нет своего архитектора, поэтому на каждом проекте интеграции мы подключаем solution-архитектора из Customer Happiness для детальной проработки решения. И предлагаем оптимальный вариант с учетом уже готовых паттернов и завершенных проектов. 

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

На схеме видно некоторое количество источников. В зависимости от бизнес-сценария, их число меняется от одного до десяти и более. Причем это могут быть источники разного типа. Например, базы данных MySQL, Postgres и прочее. По центру схемы у нас располагается ETL-сервер для транспортировки и преобразования данных, на котором мы используем наш собственный DataOps onETL, он развернут на этой же ноде. Задачи могут быть реализованы в режиме ad-hoc, а также поставлены на регламент. Затем мы агрегируем данные в базу: обычно это Clickhouse или Greenplum, в зависимости от объемов, профиля, нагрузки и сценариев использования.

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

Стали помогать пользователям с компетенциями и ролями внутри команд 

Мы разрабатывали инструменты DataOps-платформы с возможностью их использования в режиме self-service. Но в реальности столкнулись с тем, что в командах пользователей нет людей и не заложены нужные роли. 

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

Оказалось, что у многих команд нет своего delivery-менеджера и даже DevOps, без которых не обойтись в режиме self-service. На этапах интеграции пришлось подключать своих специалистов и консультировать по всем контрольным точкам. 

В задачи delivery-менеджера из Customer Happiness входит ведение проекта интеграции, поддержание в актуальном состоянии плана-графика, который мы введем в Jira:

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

Итог: с внутренними пользователями пришлось работать как со внешними и даже лучше

В декабре 2022 года показатель MAU для платформы составлял 750 пользователей, а после запуска Customer Happiness, через 7 месяцев, он поднялся до 2,5 тысяч. Сейчас у нас уже 5,5 тысяч активных пользователей в месяц и 225 успешно реализованных проектов интеграции. 

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

• определяем цели и ограничения проекта;

• проводим архитектурную сессию с потребителем;

• согласовываем HLD целевой архитектуры с учетом требований ИБ;

• разрабатываем ресурсную модель и план реализации проекта;

• сопровождаем реализацию проекта совместно с SME потребителей;

• осуществляем поддержку решений через портал техподдержки.

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