Мосты между платформами

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

О сложностях интеграции систем с открытым и закрытым исходным кодом, методах минимизации рисков потери данных при переносе между платформами и тонкостях миграции данных между облачной и локальной средой, рассказывают Сергей Прорубщиков, исполнительный директор «Интегро Текнолоджиз», и Дмитрий Ларичев, руководитель Департамента управления данными ТПХ «Русклимат».

Какие технические препятствия чаще всего возникают при интеграции систем с открытым и закрытым исходным кодом?

Сергей Прорубщиков: Их несколько. Во-первых, для любых систем может возникнуть проблема отсутствия или недостаточности стандартных интерфейсов для взаимодействия, таких как публичные API на актуальных технологиях, например, Web-Services или REST. Это затрудняет доступ к данным. Во-вторых, часто отсутствует актуальная документация, что особенно критично для систем с закрытым исходным кодом. Для систем с открытым кодом хотя и можно потратить время на его изучение, это также становится определенным препятствием. Кроме того, для закрытых систем особенно ощутимо отсутствие знающих специалистов или разработчиков, которые могли бы консультировать по вопросам устройства системы. Эти препятствия могут быть преодолены за счет дополнительных усилий в исследованиях и разработке. Однако не в каждом проекте отведено достаточно времени и ресурсов для выполнения этих работ, что добавляет сложности в процесс интеграции.

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

Как правильно оценить и минимизировать риски потери данных при переносе между платформами?

С.П.: Оценка рисков базируется на требованиях к надежности информационного обмена между системами (платформами). Бывают разные бизнес-ситуации: в одних потери данных допустимы, в других приведут к остановке производственных процессов. Таким образом, отталкиваться следует от требований бизнеса и автоматизируемых процессов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Часто необходимо найти баланс между потребностью в быстрой интеграции и необходимостью тщательной проверки данных на соответствие. О чем говорит ваш опыт?

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

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

Что необходимо предпринять для обеспечения масштабируемости интегрированных систем в долгосрочной перспективе?

С.П.: Масштабирование интегрированных систем влечет за собой рост интенсивности и сложности обмена данными. Для такого сценария обязательно будем рекомендовать заказчику применение специализированного ПО для интеграции, то есть интеграционного брокера/шины. И в дальнейшем масштабировать интеграционные компоненты вместе с конечными системами.

Д.Л.: Если мы говорим о данных, то на обеспечение масштабируемости интегрированных систем в первую очередь влияет уровень организации процесса ведения НСИ в компании и реализация единой системы НСИ, качество ведения корпоративной модели данных и их каталога, минимизация количества интеграций, выполненных по принципу «точка-точка», качество организации перекрестного взаимодействия команд разработки взаимодействующих корпоративных информационных систем и релизной политики, организация обмена данными с использованием сервисов платформы управления данными или интеграционной шины данных.

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

С.П.: В последнее время в сфере интеграции данных появилось множество новых и интересных инноваций и технологий, которые включают как инструменты транспортного уровня, так и инструменты для реализации интеграционной логики. Одним из наиболее заметных направлений является широкое использование стриминговых сервисов, таких как Kafka, и процессов, основанных на этих сервисах, например Siddhi. Эти технологии позволяют более эффективно обрабатывать и передавать потоковые данные. Еще одна интересная тенденция — растущая популярность сервисов для управления жизненным циклом API, в частности WSO2 Api Management, которые обеспечивают более эффективное управление и контроль за API. Кроме того, наблюдается активное развитие сервисов для упрощения работы с гетерогенными средами хранения данных, примером чего служит Hasura. Эти инновации значительно улучшают процессы интеграции данных, делая их более гибкими и эффективными.

Д.Л.: У себя мы реализуем корпоративную платформу управления данными. Одна из основных задач, которые мы решаем в рамках реализации платформы, — задача консолидации данных, интересующих бизнес в рамках корпоративного хранилища данных, обеспечение качества этих данных, доступности их для бизнеса в режиме «24×7×365», а также обеспечение обмена данными между корпоративными информационными системами с использованием инструментов платформы.

В чем сложности миграции данных между облачными и локальными платформами?

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

Д.Л.: При планировании миграции данных между локальными и облачными платформами необходимо учитывать ряд сложных факторов.

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

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

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

Четвертый шаг заключается в обеспечении целостности переносимых данных и наличии технологических возможностей для их автоматизированной проверки после миграции. Это критически важно для обеспечения безопасности и достоверности данных.

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

Какие меры необходимо предпринять для гарантии непрерывности бизнес-процессов во время интеграции систем?

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

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

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

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

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

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

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

Есть ли подходы к интеграции данных, которые уже стали неэффективны или устарели и почему?

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

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

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

Как оценить и выбрать инструменты или сервисы для интеграции данных?

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

При этом, если выбор в конкретном сегменте широк (например, интеграционные брокеры), надо ограничиться в количестве рассматриваемых решений, то есть их не должно быть слишком мало (одно) или слишком много (больше трех).

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

Кроме того, мы рассматриваем доступность квалифицированных специалистов на рынке труда, что влияет на возможности поддержки и развития решения. Немаловажен и аспект простоты обучения и внедрения инструмента в практику, включая наличие удобных средств разработки и интеграцию со средствами непрерывной интеграции и развертывания (CI/CD).

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

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

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

Какие проблемы связаны с управлением версиями данных и их согласованностью при интеграции различных систем?

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

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

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

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

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

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