Всем привет! С вами на связи Евгений Певцов, эксперт по качеству данных группы развития методологии из МТС. Около года назад мои коллеги уже рассказывали, зачем нам потребовались формализованные соглашения об обмене данными и какую проблему они должны были решить.

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

Сейчас дата-контракты — это полноценный сервис, встроенный в существующие ETL-процессы на всем жизненной пути данных. Им ежедневно пользуются продуктовые команды, архитекторы, аналитики и Владельцы данных. 

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

Что мы поменяли после внедрения 

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

Проработали два сценария создания контрактов

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

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

Первая половина — это команды, которые отвечают за мастер-данные клиентов или каталог товаров. Такие данные используют во многих системах, а количество потребителей со временем только растет. В этом случае логично, чтобы инициатором выступал именно Поставщик. Команда анализирует свои данные, выбирает, какие наборы являются самостоятельными дата-продуктами, и публикует для них дата-контракты в сервисе. Фактически это становится публичным предложением использовать конкретный набор данных на заранее определенных условиях. А дальше, если новая команда захочет использовать этот дата-продукт, ей не придется заново обсуждать базовые правила взаимодействия. Можно выбрать уже существующий, ознакомиться с его условиями и подать заявку, которую со своей стороны должен будет согласовать Поставщик. Конечно, если у нового потребителя появляются дополнительные требования, контракт можно доработать или создать отдельную версию, но в большинстве случаев достаточно переиспользовать уже опубликованный. Такой подход особенно хорошо работает для популярных дата-продуктов на коммунальных источниках, когда вместо множества похожих договоренностей появляется единая точка входа для всех потребителей. 

Но бывают и совершенно другие ситуации. Например, когда продуктовая команда запускает новую функцию и понимает, что ей необходимы данные из системы, которая раньше не использовалась. Ждать Поставщика в этом случае неэффективно. Поэтому Потребитель может самостоятельно начать процесс по подготовке дата-контракта: убедиться, что на интересующий объект (или объекты) еще не создали дата-контракт, создать черновик, заполнить свою часть соглашения — цели использования данных, требования к качеству данных, ожидания по SLA и так далее — и направить на согласование Владельцу данных. Так Поставщик подключается уже на этапе обсуждения условий взаимодействия.

Поэтому в итоге мы добавили возможность выбрать подходящий вариант.

Интегрировали контракты в процесс разработки

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

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

Автоматизировали рассылку уведомлений об изменениях

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

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

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

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

• какие именно объекты будут затронуты;

• что поменяется в схеме;

• когда изменения вступят в силу;

• к кому можно обратиться за дополнительной информацией.

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

Внедрили многоступенчатый контроль 

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

Если Владелец данных длительное время не отвечает или нарушает условия дата-контракта, вопрос сначала эскалируется на трехсторонний бриф к нам в команду Data Governance. Если наши пояснения и сопровождение контракта не помогли и продукт повторно нарушает условия соглашения, подключаются администраторы данных кластеров и выносят вопрос о причинах нарушения на совет по данным. А если подобное поведение привело к критическому влиянию на бизнес, финальная ступенька в этой лестнице — эскалация на CTO вертикали, где уже выносится обязывающее решение на уровне приоритетов, бюджета и стратегии.

Основная наша цель тут — обеспечить предсказуемость взаимодействия между командами.

А как насчет API?

• за сколько рабочих дней нужно уведомлять Потребителей о несовместимых изменениях;

• какие показатели качества данных обязательны;

• какие SLA нужно соблюдать;

• какая команда поддержки отвечает за сопровождение дата-продукта;

• существуют ли определенные ограничения на источнике (регулярная плановая недоступность или другие особенности работы).

Теперь же при согласовании подписки на REST API создание черновика дата-контракта в интеграционной платформе инициируется самостоятельно. Из спецификации автоматически подгружаются технические сведения о сервисе: описание интерфейсов, структура объектов, используемые схемы и другая информация, которую до этого приходилось переносить вручную. Остальные разделы, которые помогают ответить на вопросы, командам предлагается заполнить самостоятельно, ведь именно они определяют, насколько безопасной будет интеграция в долгосрочной перспективе.

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

Стратегический эффект: дата-контракты стали частью Data Governance

Дата-контракт постепенно становится одним из элементов корпоративной системы управления данными. Это особенно заметно по трем направлениям:

1. Переиспользуем данные вместо создания новых витрин. Разные команды независимо друг от друга строят похожие витрины данных, создают собственные интеграции и разрабатывают практически одинаковые преобразования. Чаще это происходит потому, что инженеры просто не знают, что аналогичное решение уже существует. У нас реестр дата-контрактов постепенно становится каталогом уже существующих корпоративных дата-продуктов — наборов датасетов Поставщика, объединенных общим бизнес-смыслом и включенных в один дата-контракт. Теперь, когда аналитик получает задачу подготовить новую витрину для продукта, его первым шагом становится поиск. В результате количество дублирующих витрин постепенно сокращается, стоимость хранения и сопровождения объектов хранилищ уменьшается, а сами данные становятся более консистентными.

2. Плавно переходим к модели Data as a Product. В крупных экосистемах обмен информацией между различными направлениями бизнеса давно перестал быть исключительно технической задачей. Все чаще возникает необходимость фиксировать эти договоренности не только на уровне разработки, но и на уровне организационных процессов. Так что дата-контракты становятся официальным приложением к договорам об информационном взаимодействии между вертикалями компании. В перспективе подобный подход открывает возможность для формирования внутренних сервисных отношений между командами, где дата-продукты имеют понятного Владельца, измеримые показатели качества и понятные всем правила использования.

3. Ответственность становится прозрачнее. Иногда продукт официально считается ответственным за определенный набор данных, но при возникновении вопросов выясняется, что никто из продуктовой команды не может объяснить происхождение отдельных атрибутов, сроки обновления или причины изменения схемы. Подобные ситуации обычно говорят не о плохой работе конкретной команды, а о том, что ответственность за данные никогда была сформулирована недостаточно явно. Дата-контракт делает эти ожидания однозначными. В нем фиксируются Владелец дата-продукта, контактные лица и команда по разбору инцидентов из ITSM-системы. Со временем именно такая прозрачность становится одним из ключевых элементов зрелой системы Data Governance.

Наши планы

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

Автоматическое отслеживание изменений схем

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

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

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

Интеграция с процессами разработки

Еще одно направление развития связано с тем, чтобы дата-контракты стали полноценной частью конвейера разработки.

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

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

Такой подход позволяет обнаруживать проблемы тогда, когда их исправление требует минимальных затрат. А дата-контракт становится еще одним артефактом разработки наряду с исходным кодом, спецификацией API и автотестами.

Переход от документа к исполняемому контракту

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

В перспективе мы хотим максимально сократить этот разрыв:

• внедрить проверку качества данных в системы мониторинга;

• ввести договоренность, что цели использования данных, которые Потребители указывают в условиях дата-контракта, будут аргументом для сотрудника ИБ при согласовании доступов к данным;

• интегрировать описание структуры данных в этап валидации изменений схем;

• подключить SLA к контролю соблюдения обязательств Поставщика;

• добавить автоматическое подтягивание информации о Владельцах на этап маршрутизации инцидентов и согласования изменений.

Вместо заключения

За последние несколько лет термин Data Contract стал достаточно популярным. Во многих публикациях его рассматривают как одну из составляющих современных подходов к построению платформ данных, архитектуры Data Mesh или концепции Data as a Product. Однако на практике ценность дата-контрактов определяется не набором полей в документе.

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

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