Управление корпоративными данными несколько лет назад выглядело как понятная задача.
Большинство критичных процессов жили внутри нескольких крупных систем с предсказуемым ритмом изменений, а контроль качества строился на проверках в хранилище, через которое все данные рано или поздно проходили.
Но переход бизнеса на микросервисную архитектуру изменил и саму природу данных, и подходы к работе с ними. Один из самых масштабных в России проектов такой перестройки реализован на платформе данных ВТБ, и в этой статье мы разбираем, как изменился сам процесс, какие принципы оказались рабочими и почему привычные методы контроля качества в распределённой среде уже не дают прежнего эффекта.
Что изменилось в природе данных
Главное изменение касается того, где и как данные возникают. Раньше значительная их часть жила в ограниченном количестве крупных систем с предсказуемым циклом изменений. В микросервисной архитектуре данные начинают формироваться и изменяться в сотнях независимых сервисов, и каждый из них развивается в собственном темпе и собственной командой, из-за чего структура данных и правила поставки могут меняться значительно быстрее.
К этому добавляется второй сдвиг. Если раньше большая часть процессов опиралась на регламентный захват изменений по расписанию, то в новой архитектуре приоритетной моделью становится стриминг, то есть непрерывный поток событий и данных. Это потребовало перестроить и архитектуру интеграции, и подходы к контролю качества.
У нас ситуация осложнялась тем, что многие новые системы были молодыми, и их логические модели данных активно менялись параллельно с промышленной эксплуатацией. К платформе подключались не зрелые и устоявшиеся источники, а системы, которые сами ещё развивались и уточняли свои модели. Одновременно банк выводил в эксплуатацию более 300 автономных систем продуктового и бухгалтерского учёта, развивал новые цифровые сервисы и запускал централизованную платформу данных.
Почему классические методы перестают работать
В монолитной среде акцент в управлении качеством данных делался на проверках уже внутри хранилища или аналитического контура. Логика была простая: данные пройдут через одну точку, где их можно проверить, очистить и при необходимости отправить обратно на исправление.
В распределённой архитектуре этого уже недостаточно. Данные рождаются в большом количестве независимых систем, ошибки расползаются по системе быстрее, чем их успевают ловить, и к моменту, когда некорректная запись доходит до аналитической витрины или модели машинного обучения, она уже могла повлиять на отчётность или принятие решения. Поэтому мы перешли к новой логике: от контроля последствий к управлению причинами. Качество должно обеспечиваться не на выходе, а в точке возникновения данных.
А зачем это вообще нужно банку
Тогда возникает логичный вопрос: зачем всё это нужно банку? Платформа данных в современной финансовой организации — это уже не вспомогательная функция и не один из технологических слоёв. На её данные опираются кредитные решения, антифрод, риск-менеджмент, регуляторная и управленческая отчётность, клиентская аналитика, модели искусственного интеллекта и новые цифровые сервисы. Если контроль над данными ослабевает, нестабильность сразу проявляется во всех этих процессах, поэтому управляемость данных, по сути, становится вопросом устойчивости значительной части бизнеса.
Наша архитектурная модель построена на трёх взаимосвязанных принципах, каждый из которых решает конкретную проблему распределённой среды:
Единая семантика данных. В сотнях сервисов, каждый из которых развивался своей командой, неизбежно возникал разнобой в том, как описываются одни и те же сущности. Мы стандартизировали «язык» взаимодействия источников и платформы: каждая сущность данных типизирована и описана в концептуальной модели, а конкретные реализации в информационных системах наследуются от этой модели. Это позволило унифицировать потоки данных независимо от внутреннего устройства конкретной системы.
Контроль качества — ближе к источнику. Владельцы мастер-систем, в которых создаются первичные данные, стали полноценными участниками процесса управления качеством. Каждый из них описывает порождаемые данные в бизнес-глоссарии, фиксирует требования к качеству и реализует соответствующие контроли непосредственно в самой системе-источнике. Принцип, который мы здесь закрепили, — превентивность. Задача не в том, чтобы обнаруживать ошибочные записи постфактум, а в том, чтобы не допускать их появления или дальнейшего движения по цепочке.
Дата-контракты. Это самый обсуждаемый сегодня элемент модели, и одновременно тот, в котором у индустрии нет единого понимания. Сам термин компании трактуют по-своему — от схемы данных в APIдо внутренних регламентов взаимодействия. У нас дата-контракт — это инструмент перевода поставки данных из «серой зоны» в полноценный управляемый контур с понятными правилами, обязанностями и метриками. Внутри контракта фиксируются:
- семантика — какие сущности передаются и как они определены;
- структура — какие именно атрибуты, форматы и правила типизации применяются;
- эксплуатационные параметры — когда и как данные должны поступать, с какой периодичностью, с каким SLA и по какому каналу;
- правила изменений — как инициируются изменения и какие требования предъявляются к обратной совместимости;
- управленческий блок — кто отвечает за поставку, кто за потребление и как разбираются инциденты.
Сам подход мы называем моделью договорённости о данных как о промышленном продукте. Данные перестают быть побочным результатом работы системы и становятся полноценным объектом поставки с понятными правилами.
Что это значит на практике
Проект реализован на централизованной платформе данных ВТБ, одной из крупнейших в России, и построен на полностью импортозамещённом технологическом стеке собственной разработки. В цифрах модель выглядит так:
- >300 систем-источников, охваченных проектом;
- >2000 сотрудников, вовлечённых в процессы управления данными;
- >2000 действующих дата-контрактов;
- >5000 автоматизированных проверок качества данных на ядре хранилища;
- >6000 контролей качества данных на стороне систем-источников;
- >100 менеджеров по работе с обращениями качества данных в ИТ и >100 офицеров данных со стороны бизнеса;
- специализированный стрим качества данных численностью >150 человек.
Почему без бизнеса это не работает
Одна из ключевых задач проекта состояла в том, чтобы вовлечь бизнес в управление данными как полноценного участника. Когда ответственность за данные сосредоточена внутри платформенной команды, организация быстро упирается в потолок зрелости. Данные имеют бизнес-смысл, и управлять ими должны не только технические специалисты, но и владельцы данных, их потребители и подразделения, в чьих процессах эти данные используются.
В нашей модели это решено через двойной контур ответственности. Со стороны IT работают менеджеры качества данных, а со стороны бизнес-подразделений — дата-офицеры, отвечающие за бизнес-контекст и интерпретацию качества в своей зоне. Бизнес вовлечён сразу в нескольких направлениях, включая определение требований к качеству, анализ инцидентов, приоритизацию улучшений и работу с KPI, которые закрепляют ответственность владельцев данных на измеримом уровне. В результате удалось не просто «подключить» бизнес к теме данных, а сделать управление данными частью общей модели управления банком.
Что было самым сложным
Модель пришлось строить в постоянно меняющемся ландшафте, без возможности сначала «заморозить» архитектуру и только потом запустить промышленный контур. Параллельно решались задачи архитектурной стандартизации, интеграции, управления качеством и сопровождения живых бизнес-процессов.
Дополнительная сложность была связана с тем, что у разных команд уже сложились собственные привычки и способы моделирования данных. Здесь важно было сделать новые правила не бюрократическим ограничением, а механизмом, который помогает быстрее и безопаснее работать в общей экосистеме.
Третий вызов касался баланса между централизацией и гибкостью. С одной стороны, нужен был единый язык данных и общая дисциплина, с другой — нельзя было замедлить развитие команд чрезмерно тяжёлым процессом. Поэтому проект строился как поиск этого баланса: сохранить скорость изменений, но сделать их управляемыми и совместимыми. Зрелая методология управления данными позволила осуществить масштабирование на сотни новых систем быстро и эффективно.
Что в итоге
Главный результат проекта в том, что управление данными перестало быть отдельной технической функцией и стало частью архитектуры самого банка. Изменения больше не происходят вне архитектурного контура, нестабильные или некачественные потоки не доходят до критичных процессов, а ответственность за поставку и качество закреплена через KPI и организационные роли.
Дальше мы движемся к тому, чтобы платформа управляла собой сама. Системы контроля качества учатся не только фиксировать отклонения по заданным правилам, но и находить аномалии и предлагать новые критерии проверки данных. ИИ-инструменты упрощают работу с данными для бизнес-пользователей и помогают разобраться в структуре, происхождении и бизнес-смысле без необходимости погружаться в техническую сторону. Автоматизируется и сама поставка данных, поскольку дата-контракты и мониторинг их исполнения переходят в режим, где роль ручных операций минимальна. Логика этого этапа принципиально иная, и платформа перестаёт быть инструментом, который нужно настраивать, превращаясь в среду, которая работает вместе с пользователем.
Комментарии