Масштабирование процессов управления данными при переходе на микросервисную архитектуру

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

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

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

Управление данными в жизненном цикле микросервиса

Инициатива и концепция сервиса. На этапе появления бизнес-идеи определяется, какие бизнес-сущности будет обрабатывать будущий микросервис, и здесь важно понять, станет ли сервис источником для каких-то еще данных или предназначен только потребителям. Кроме этого, на этом этапе прорабатываются контрольные точки и этапность выполнения задач по управлению данными. Офис CDO (Chief Data Officer — «директор по данным») на этом шаге жизненного цикла предоставляет типовой план работ по управлению данными при реализации микросервиса и стандартный чек-лист ответственного владельца данных.

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

Реализация и встраивание процедур контроля. На этом этапе реализуются процедуры контроля на нескольких слоях для проактивного обеспечения качества данных: в API и UI, например, валидация форматов, обязательных полей и логики внутри одной записи; в бизнес-логике микросервиса — связанность данных, обеспечение уникальности по ключам, контроль логической структуры data-продукта; в событиях и очередях — контроль соблюдения схемы и семантики сообщений; на входе в хранилище и хабы данных — здесь запускаются ресурсоемкие аналитические проверки, которые не могут быть реализованы в самих микросервисах из-за ограничений по производительности (кросс-системные сопоставления по массиву данных, проверки агрегатов, аномалий и др.). Все эти проверки дополняют превентивные процедуры контроля и служат «страховочной сеткой» на уровне корпоративной аналитики. На этом этапе офис CDO выступает в роли центра экспертизы, консультирующего ИТ-команды по доступному инструментарию для реализации тех или иных процедур контроля.

Ввод в эксплуатацию. До момента вывода сервиса в промышленную эксплуатацию в цепочке поставки данных работает отдельный блок приемосдаточных испытаний (ПСИ) процедур контроля качества данных. Для типового сценария в микросервис целенаправленно подаются заведомо ошибочные записи и проверяется срабатывание всех превентивных точек контроля. Офис CDO на этом этапе отвечает за методику ПСИ по качеству данных, координацию и контроль реализации требований. Для наиболее критичных микросервисов целесообразно дополнительно проводить независимый замер уровня качества данных, передаваемых микросервисом, на слое «сырых» данных хранилища. Такая практика позволяет выявить возможные ошибки проектирования процедур контроля на уровне источников данных, например, когда контроль отрабатывает только часть методов API или форм ввода данных в UI.

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

Управление данными в жизненном цикле микросервиса

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

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

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

***

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

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

Светлана Бова (bova@vtb.ru) — директор по данным, управляющий директор департамента ИТ -архитектуры, вице-президент; Ростислав Даньков (rdankov@vtb.ru) — директор по управлению проектами в области управления качеством данных, департамент ИТ -архитектуры, «Банк ВТБ» (Москва).