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

Рис. 1. При переходе от монолитной к микросервисной архитектуре данные перестают «жить» в нескольких предсказуемых системах и расходятся по сотням независимых сервисов

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

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

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

Точечных улучшений недостаточно

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

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

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

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

Изменения

В микросервисной среде привычные методы управления данными теряют свою эффективность.

Стандартизация языка взаимодействия

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

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

Контрактная модель поставки данных

 

Рис. 2. Дата-контракт — соглашение о данных как о промышленном продукте. Пять блоков охватывают полный жизненный цикл: от семантики до управления инцидентами

Дата-контракт в ВТБ (рис. 2) — это не схема API и не внутренний регламент, а полноценное соглашение между поставщиком и потребителем данных, фиксирующее:

что передается — какие сущности, как они определены, в какой логике существуют;

  • как — структура, форматы, типы атрибутов;
  • когда и сколько — частота, объем, SLA, канал поставки, возможность перевыгрузки;
  • как меняется — правила версионирования, требования к обратной совместимости, процедура согласования изменений;
  • кто отвечает — за поставку, за потребление, за разбор инцидентов.

Контракт применяется не только между источником и платформой, но и между слоями самой платформы и на стыках с ключевыми потребителями. По всей цепочке поставки данных действует одна и та же дисциплина.

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

Контроль качества данных

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

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

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

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

Закрепленная ответственность

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

  • дата-офицеры со стороны бизнес-подразделений — отвечают за бизнес-смысл данных, требования к качеству, интерпретацию инцидентов и приоритеты улучшений;
  • менеджеры качества данных со стороны ИТ — отвечают за реализацию контролей, разбор технических причин дефектов, поддержку моделей.
Рис. 3. Ключевые показатели промышленной модели управления данными

Сегодня в банке имеется около 100 дата-офицеров и более 100 менеджеров качества, а всего в процессах управления данными участвуют более 2 тясяч сотрудников (рис. 3). Что особенно важно — KPI владельцев данных и проектов теперь учитывают качество данных не на декларативном уровне, а как измеримую метрику.

Сложности

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

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

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

Что получилось

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

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

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

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

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

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

Что дальше?

Следующий шаг — сделать архитектурную и организационную модель адаптивной и проактивной:

  • Интеллектуальное управление качеством. Переход от фиксированных правил к механизмам автоматического выявления аномалий и закономерностей. Контроль качества должен не только фиксировать отклонения, но и помогать находить их причины и предлагать варианты устранения.
  • ИИ в работе с платформой. Прежде всего планируется применять ИИ в задачах поиска и понимания данных (навигация, интерпретация структуры, объяснение бизнес-смысла) с целью снижения порога входа для пользователей и ускорения работы без потери управляемости.
  • Автоматизация управления поставкой. Глубокая диагностика отклонений в дата-контрактах, автоматическая реакция на инциденты, предсказательная аналитика по нарушениям SLA — все это для минимизации ручных операций при максимуме прозрачности.

***

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

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

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

Многие крупные компании сейчас проходят через переход на распределенные архитектуры, рост числа автономных команд, развитие платформ данных и применение ИИ. Опыт ВТБ показывает, что качеством и управляемостью данных в таких условиях нужно заниматься не на уровне хранилища или отчетного слоя, а встраивать эти процессы в архитектуру взаимодействия систем. Это сложнее, но именно такой подход дает устойчивый результат.

Владимир Громов (gromovv@vtb.ru) — заместитель руководителя департамента технологического развития общебанковских систем, Даниил Казаков (dmkazakov@vtb.ru) — начальник управления архитектуры данных, Ростислав Даньков (rdankov@vtb.ru) — директор по управлению проектами группы методологии управления данными, ВТБ (Москва). Авторы — лауреаты премии Data Award 2026.