29.12.2023
Новости компании
Как перенести данные и минимизировать риски их потери? В чем сложности миграции данных между облачными и локальными платформами?
Сегодня, когда технологии развиваются с невероятной скоростью, а бизнес требует все большей гибкости и адаптивности, вопросы интеграции и безопасного переноса данных становятся ключевыми для успешного функционирования предприятий.
О сложностях интеграции систем с открытым и закрытым исходным кодом, методах минимизации рисков потери данных при переносе между платформами и тонкостях миграции данных между облачной и локальной средой, рассказывает Сергей Прорубщиков, исполнительный директор «Интегро Текнолоджиз».
Какие технические препятствия чаще всего возникают при интеграции систем с открытым и закрытым исходным кодом?
Сергей Прорубщиков: Их несколько. Во-первых, для любых систем может возникнуть проблема отсутствия или недостаточности стандартных интерфейсов для взаимодействия, таких как публичные API на актуальных технологиях, например, Web-Services или REST. Это затрудняет доступ к данным. Во-вторых, часто отсутствует актуальная документация, что особенно критично для систем с закрытым исходным кодом. Для систем с открытым кодом хотя и можно потратить время на его изучение, это также становится определенным препятствием. Кроме того, для закрытых систем особенно ощутимо отсутствие знающих специалистов или разработчиков, которые могли бы консультировать по вопросам устройства системы. Эти препятствия могут быть преодолены за счет дополнительных усилий в исследованиях и разработке. Однако не в каждом проекте отведено достаточно времени и ресурсов для выполнения этих работ, что добавляет сложности в процесс интеграции.
Как правильно оценить и минимизировать риски потери данных при переносе между платформами?
С.П.: Оценка рисков базируется на требованиях к надежности информационного обмена между системами (платформами). Бывают разные бизнес-ситуации: в одних потери данных допустимы, в других приведут к остановке производственных процессов. Таким образом, отталкиваться следует от требований бизнеса и автоматизируемых процессов.
Для минимизации рисков при обмене данными между системами или между системами и промежуточным программным обеспечением, таким как интеграционный брокер, необходимо использовать стандартные подходы. Важно обеспечить наличие транзакций: в процессе обмена обе системы, передающая и принимающая, должны подтверждать успешность передачи и приема данных. Если используется промежуточное ПО, например интеграционный брокер или интеграционная шина, необходимо сохранять данные после их получения от передающей системы и удалять их только после успешной передачи получателю, что обеспечивает персистентность данных на промежуточном уровне. Кроме того, следует применять резервирование всех элементов тракта передачи данных, применяя методы кластеризации и другие подходы, гарантирующие отказоустойчивость на уровне, достаточном для соответствия требованиям бизнеса к гарантированной доставке данных. И конечно, нужно соблюдать баланс между сложностью и надежностью, так как при увеличении сложности надежность, как правило, уменьшается.
Как вы подходите к интеграции унаследованных систем, которые могут быть устаревшими, но критически важными для бизнес-операций?
С.П.: По опыту работы с унаследованными/устаревшими системами, в них чаще всего встречаются сложности с наличием современных API и документации/экспертов. И зачастую приходится заниматься реализацией дополнительных сервисов, которые обеспечивают систему требуемыми интерфейсами. Как правило, это исследование и разработка, то есть дополнительные время и ресурсы. Поскольку мы ведём речь про критически важные для бизнеса системы, альтернативные предложения и сценарии редко находят поддержку у заказчика.
К примеру, в нашей практике были случаи, когда мы реализовали сервисы с нетривиальной логикой извлечения и загрузки информации напрямую в базу данных системы. Ситуацию существенно усложняли уход поставщика с рынка РФ и отсутствие у заказчика информации в части структуры хранения данных и взаимодействия сервера приложений с базой данных. Решение задачи заняло довольно много времени, так как, отталкиваясь от знаний бизнес-процесса, применяемого в системе, мы анализировали изменения в данных и реакцию системы на их внешнее изменение. Реализация целевого решения в таких случаях занимает 20–30% от общего времени на разработку, а все остальное уходит на эксперименты и продумывание задач.
Был случай, когда система работала исключительно через файловый обмен, и для обеспечения гарантии доставки были реализованы сервисы доставки файлов с гарантией и проверка успешности на основе журнала (лога) этой системы.
Часто необходимо найти баланс между потребностью в быстрой интеграции и необходимостью тщательной проверки данных на соответствие. О чем говорит ваш опыт?
С.П.: Опыт подсказывает, что для баланса требуется использование промежуточного ПО — интеграционной шины или брокера. При наличии данного элемента существенно упрощается процесс подключения конечных систем стандартными API и появляется возможность проверки (валидации) данных в ходе передачи.
Что необходимо предпринять для обеспечения масштабируемости интегрированных систем в долгосрочной перспективе?
С.П.: Масштабирование интегрированных систем влечет за собой рост интенсивности и сложности обмена данными. Для такого сценария обязательно будем рекомендовать заказчику применение специализированного ПО для интеграции, то есть интеграционного брокера/шины. И в дальнейшем масштабировать интеграционные компоненты вместе с конечными системами.
Какие наиболее интересные инновации или технологии в области интеграции данных вам приходилось недавно внедрять?
С.П.: В последнее время в сфере интеграции данных появилось множество новых и интересных инноваций и технологий, которые включают как инструменты транспортного уровня, так и инструменты для реализации интеграционной логики. Одним из наиболее заметных направлений является широкое использование стриминговых сервисов, таких как Kafka, и процессов, основанных на этих сервисах, например Siddhi. Эти технологии позволяют более эффективно обрабатывать и передавать потоковые данные. Еще одна интересная тенденция — растущая популярность сервисов для управления жизненным циклом API, в частности WSO2 Api Management, которые обеспечивают более эффективное управление и контроль за API. Кроме того, наблюдается активное развитие сервисов для упрощения работы с гетерогенными средами хранения данных, примером чего служит Hasura. Эти инновации значительно улучшают процессы интеграции данных, делая их более гибкими и эффективными.
В чем сложности миграции данных между облачными и локальными платформами?
С.П.: Миграция между облачными и локальными платформами имеет свои особенности, несмотря на то что подходы мало зависят от среды выполнения. Одним из ключевых аспектов при работе с облачными платформами является необходимость наличия в команде специалистов по DevOps. Этот подход уже давно используется, поскольку он упрощает многие задачи, связанные с доставкой сервисов на среды заказчика. Также значительное внимание уделяется повышенным требованиям к защите данных в процессе их передачи, что предусматривает шифрование и контроль за их целостностью. Кроме того, важным фактором является обеспечение надежных доступов, в том числе аутентификация и авторизация сервисов как на общем, так и на административном уровне. Это может включать получение разрешений на открытие портов в файерволах заказчика или его партнеров, что добавляет определенную сложность в процесс миграции данных.
Какие меры необходимо предпринять для гарантии непрерывности бизнес-процессов во время интеграции систем?
С.П.: Гарантия непрерывности бизнес-процессов во время интеграции систем — сложная задача, требующая внимательного рассмотрения и применения проектных подходов, а не только инженерных решений. В первую очередь крайне важно разработать стратегию миграции или внедрения, учитывая требования к непрерывности бизнес-процессов, и это следует делать до начала работ или на ранних стадиях проекта. Далее, необходимо обеспечить наличие тестового контура интегрируемых систем, то есть создать специализированную среду для экспериментов и пилотных решений.
Кроме того, критически важно провести end-to-end-тестирование интеграции до ее внедрения, включая процедуры перехода и отката системы в исходное состояние. Помимо этого, следует осуществлять опытную эксплуатацию, а в некоторых случаях и так называемую параллельную эксплуатацию.
Важно подчеркнуть, что все эти мероприятия могут быть достаточно обременительными с точки зрения вовлечения бизнес-пользователей и затрат. Поэтому перед началом проекта необходимо тщательно оценить и согласовать с заказчиком вероятные риски и стоимость их устранения, с учетом требований к бизнес-процессам.
Есть ли подходы к интеграции данных, которые уже стали неэффективны или устарели и почему?
С.П.: На наш взгляд, это так называемая интеграция «точка-точка», когда речь идет о реализации выделенного сервиса или сервисов для конкретных двух систем. Данный подход повсеместно использовался, пока не появились надежные и доступные транспортные сервисы и интеграционные брокеры.
При этом вы оказываетесь в зависимости от разработчика такой интеграции, и любые изменения требуют модификации кода и полного цикла разработки. Применение подобного подхода решает локальную задачу, но совершенно игнорирует возможности масштабирования, замены систем, а это актуально для современного бизнеса. Он хочет быстро расти и иметь лучшие инструменты для автоматизации процессов, что предполагает необходимость гибкого подхода к интеграции систем, то есть использование специализированного промежуточного ПО.
Как оценить и выбрать инструменты или сервисы для интеграции данных?
С.П.: Наш подход основан на исследовании и практике использования. Начать можно с обзора рынка и коммуникации с поставщиками.
При этом, если выбор в конкретном сегменте широк (например, интеграционные брокеры), надо ограничиться в количестве рассматриваемых решений, то есть их не должно быть слишком мало (одно) или слишком много (больше трех).
В процессе принятия решения о выборе инструментов мы уделяем внимание ряду ключевых аспектов. Первый из них — способность инструмента обеспечивать требуемую функциональность. Также важно наличие успешных примеров внедрений, развитой базы знаний и активного сообщества разработчиков, что говорит о его надежности и популярности.
Кроме того, мы рассматриваем доступность квалифицированных специалистов на рынке труда, что влияет на возможности поддержки и развития решения. Немаловажен и аспект простоты обучения и внедрения инструмента в практику, включая наличие удобных средств разработки и интеграцию со средствами непрерывной интеграции и развертывания (CI/CD).
Также мы оцениваем эксплуатационные возможности инструмента — его способности к резервированию и мониторингу, что критично для поддержания надежности системы. И конечно, для платных продуктов мы учитываем экономические показатели, в частности, такой важный фактор при принятии решения о внедрении, как стоимость лицензий для конечного потребителя.
После выбора необходимо развернуть стенды и реализовать прототипы для проверки гипотез. Результаты прототипирования используются для принятия решения. Отдельно стоит отметить, что наш подход базируется на фактических данных и опыте применения. Мы считаем это чрезвычайно важным в современном информационно перегруженном мире, где есть искушение и возможности ограничиться теоретическими исследованиями и выводами, сделанными другими специалистами.
Какие проблемы связаны с управлением версиями данных и их согласованностью при интеграции различных систем?
С.П.: Обычно это проблема определения текущего состояния в разных системах. Когда данные в одной системе отстают от данных в другой. Часто все усугубляется тем, что одна система может получать агрегированные данные из нескольких. В сложных интеграционных картинах всегда есть некоторый период несогласованности здесь или там. Как пример можно привести ситуацию из авиации, когда командир воздушного судна получает разрешение на отстыковку, в то время как табло над гейтом все еще показывает, что идет посадка. Если возникают подобные вопросы, начинается поиск баланса между производительностью и оперативностью, с одной стороны, и точностью и согласованностью — с другой.
В основном подобная сложность возникает на этапе, когда в системах заказчика появляется два или более конкурирующих источника данных, претендующих на звание «мастер». Эти вопросы легко решать на фазе обследования, выявляя соответствующие риски и выставляя дополнительные требования к решению и бизнесу. К примеру, можно отказаться от асинхронного обмена в части потоков и перейти к синхронному режиму или искать какие-то еще варианты устранения неоднозначностей. Хорошим решением будет использовать выделенную систему для управления мастер-данными (НСИ), если, конечно, такая имеется у заказчика или он готов к её внедрению. На фазе реализации выявление таких вопросов обходится существенно дороже.
Источник: IT World.
О сложностях интеграции систем с открытым и закрытым исходным кодом, методах минимизации рисков потери данных при переносе между платформами и тонкостях миграции данных между облачной и локальной средой, рассказывает Сергей Прорубщиков, исполнительный директор «Интегро Текнолоджиз».
Какие технические препятствия чаще всего возникают при интеграции систем с открытым и закрытым исходным кодом?
Сергей Прорубщиков: Их несколько. Во-первых, для любых систем может возникнуть проблема отсутствия или недостаточности стандартных интерфейсов для взаимодействия, таких как публичные API на актуальных технологиях, например, Web-Services или REST. Это затрудняет доступ к данным. Во-вторых, часто отсутствует актуальная документация, что особенно критично для систем с закрытым исходным кодом. Для систем с открытым кодом хотя и можно потратить время на его изучение, это также становится определенным препятствием. Кроме того, для закрытых систем особенно ощутимо отсутствие знающих специалистов или разработчиков, которые могли бы консультировать по вопросам устройства системы. Эти препятствия могут быть преодолены за счет дополнительных усилий в исследованиях и разработке. Однако не в каждом проекте отведено достаточно времени и ресурсов для выполнения этих работ, что добавляет сложности в процесс интеграции.
Как правильно оценить и минимизировать риски потери данных при переносе между платформами?
С.П.: Оценка рисков базируется на требованиях к надежности информационного обмена между системами (платформами). Бывают разные бизнес-ситуации: в одних потери данных допустимы, в других приведут к остановке производственных процессов. Таким образом, отталкиваться следует от требований бизнеса и автоматизируемых процессов.
Для минимизации рисков при обмене данными между системами или между системами и промежуточным программным обеспечением, таким как интеграционный брокер, необходимо использовать стандартные подходы. Важно обеспечить наличие транзакций: в процессе обмена обе системы, передающая и принимающая, должны подтверждать успешность передачи и приема данных. Если используется промежуточное ПО, например интеграционный брокер или интеграционная шина, необходимо сохранять данные после их получения от передающей системы и удалять их только после успешной передачи получателю, что обеспечивает персистентность данных на промежуточном уровне. Кроме того, следует применять резервирование всех элементов тракта передачи данных, применяя методы кластеризации и другие подходы, гарантирующие отказоустойчивость на уровне, достаточном для соответствия требованиям бизнеса к гарантированной доставке данных. И конечно, нужно соблюдать баланс между сложностью и надежностью, так как при увеличении сложности надежность, как правило, уменьшается.
Как вы подходите к интеграции унаследованных систем, которые могут быть устаревшими, но критически важными для бизнес-операций?
С.П.: По опыту работы с унаследованными/устаревшими системами, в них чаще всего встречаются сложности с наличием современных API и документации/экспертов. И зачастую приходится заниматься реализацией дополнительных сервисов, которые обеспечивают систему требуемыми интерфейсами. Как правило, это исследование и разработка, то есть дополнительные время и ресурсы. Поскольку мы ведём речь про критически важные для бизнеса системы, альтернативные предложения и сценарии редко находят поддержку у заказчика.
К примеру, в нашей практике были случаи, когда мы реализовали сервисы с нетривиальной логикой извлечения и загрузки информации напрямую в базу данных системы. Ситуацию существенно усложняли уход поставщика с рынка РФ и отсутствие у заказчика информации в части структуры хранения данных и взаимодействия сервера приложений с базой данных. Решение задачи заняло довольно много времени, так как, отталкиваясь от знаний бизнес-процесса, применяемого в системе, мы анализировали изменения в данных и реакцию системы на их внешнее изменение. Реализация целевого решения в таких случаях занимает 20–30% от общего времени на разработку, а все остальное уходит на эксперименты и продумывание задач.
Был случай, когда система работала исключительно через файловый обмен, и для обеспечения гарантии доставки были реализованы сервисы доставки файлов с гарантией и проверка успешности на основе журнала (лога) этой системы.
Часто необходимо найти баланс между потребностью в быстрой интеграции и необходимостью тщательной проверки данных на соответствие. О чем говорит ваш опыт?
С.П.: Опыт подсказывает, что для баланса требуется использование промежуточного ПО — интеграционной шины или брокера. При наличии данного элемента существенно упрощается процесс подключения конечных систем стандартными API и появляется возможность проверки (валидации) данных в ходе передачи.
Что необходимо предпринять для обеспечения масштабируемости интегрированных систем в долгосрочной перспективе?
С.П.: Масштабирование интегрированных систем влечет за собой рост интенсивности и сложности обмена данными. Для такого сценария обязательно будем рекомендовать заказчику применение специализированного ПО для интеграции, то есть интеграционного брокера/шины. И в дальнейшем масштабировать интеграционные компоненты вместе с конечными системами.
Какие наиболее интересные инновации или технологии в области интеграции данных вам приходилось недавно внедрять?
С.П.: В последнее время в сфере интеграции данных появилось множество новых и интересных инноваций и технологий, которые включают как инструменты транспортного уровня, так и инструменты для реализации интеграционной логики. Одним из наиболее заметных направлений является широкое использование стриминговых сервисов, таких как Kafka, и процессов, основанных на этих сервисах, например Siddhi. Эти технологии позволяют более эффективно обрабатывать и передавать потоковые данные. Еще одна интересная тенденция — растущая популярность сервисов для управления жизненным циклом API, в частности WSO2 Api Management, которые обеспечивают более эффективное управление и контроль за API. Кроме того, наблюдается активное развитие сервисов для упрощения работы с гетерогенными средами хранения данных, примером чего служит Hasura. Эти инновации значительно улучшают процессы интеграции данных, делая их более гибкими и эффективными.
В чем сложности миграции данных между облачными и локальными платформами?
С.П.: Миграция между облачными и локальными платформами имеет свои особенности, несмотря на то что подходы мало зависят от среды выполнения. Одним из ключевых аспектов при работе с облачными платформами является необходимость наличия в команде специалистов по DevOps. Этот подход уже давно используется, поскольку он упрощает многие задачи, связанные с доставкой сервисов на среды заказчика. Также значительное внимание уделяется повышенным требованиям к защите данных в процессе их передачи, что предусматривает шифрование и контроль за их целостностью. Кроме того, важным фактором является обеспечение надежных доступов, в том числе аутентификация и авторизация сервисов как на общем, так и на административном уровне. Это может включать получение разрешений на открытие портов в файерволах заказчика или его партнеров, что добавляет определенную сложность в процесс миграции данных.
Какие меры необходимо предпринять для гарантии непрерывности бизнес-процессов во время интеграции систем?
С.П.: Гарантия непрерывности бизнес-процессов во время интеграции систем — сложная задача, требующая внимательного рассмотрения и применения проектных подходов, а не только инженерных решений. В первую очередь крайне важно разработать стратегию миграции или внедрения, учитывая требования к непрерывности бизнес-процессов, и это следует делать до начала работ или на ранних стадиях проекта. Далее, необходимо обеспечить наличие тестового контура интегрируемых систем, то есть создать специализированную среду для экспериментов и пилотных решений.
Кроме того, критически важно провести end-to-end-тестирование интеграции до ее внедрения, включая процедуры перехода и отката системы в исходное состояние. Помимо этого, следует осуществлять опытную эксплуатацию, а в некоторых случаях и так называемую параллельную эксплуатацию.
Важно подчеркнуть, что все эти мероприятия могут быть достаточно обременительными с точки зрения вовлечения бизнес-пользователей и затрат. Поэтому перед началом проекта необходимо тщательно оценить и согласовать с заказчиком вероятные риски и стоимость их устранения, с учетом требований к бизнес-процессам.
Есть ли подходы к интеграции данных, которые уже стали неэффективны или устарели и почему?
С.П.: На наш взгляд, это так называемая интеграция «точка-точка», когда речь идет о реализации выделенного сервиса или сервисов для конкретных двух систем. Данный подход повсеместно использовался, пока не появились надежные и доступные транспортные сервисы и интеграционные брокеры.
При этом вы оказываетесь в зависимости от разработчика такой интеграции, и любые изменения требуют модификации кода и полного цикла разработки. Применение подобного подхода решает локальную задачу, но совершенно игнорирует возможности масштабирования, замены систем, а это актуально для современного бизнеса. Он хочет быстро расти и иметь лучшие инструменты для автоматизации процессов, что предполагает необходимость гибкого подхода к интеграции систем, то есть использование специализированного промежуточного ПО.
Как оценить и выбрать инструменты или сервисы для интеграции данных?
С.П.: Наш подход основан на исследовании и практике использования. Начать можно с обзора рынка и коммуникации с поставщиками.
При этом, если выбор в конкретном сегменте широк (например, интеграционные брокеры), надо ограничиться в количестве рассматриваемых решений, то есть их не должно быть слишком мало (одно) или слишком много (больше трех).
В процессе принятия решения о выборе инструментов мы уделяем внимание ряду ключевых аспектов. Первый из них — способность инструмента обеспечивать требуемую функциональность. Также важно наличие успешных примеров внедрений, развитой базы знаний и активного сообщества разработчиков, что говорит о его надежности и популярности.
Кроме того, мы рассматриваем доступность квалифицированных специалистов на рынке труда, что влияет на возможности поддержки и развития решения. Немаловажен и аспект простоты обучения и внедрения инструмента в практику, включая наличие удобных средств разработки и интеграцию со средствами непрерывной интеграции и развертывания (CI/CD).
Также мы оцениваем эксплуатационные возможности инструмента — его способности к резервированию и мониторингу, что критично для поддержания надежности системы. И конечно, для платных продуктов мы учитываем экономические показатели, в частности, такой важный фактор при принятии решения о внедрении, как стоимость лицензий для конечного потребителя.
После выбора необходимо развернуть стенды и реализовать прототипы для проверки гипотез. Результаты прототипирования используются для принятия решения. Отдельно стоит отметить, что наш подход базируется на фактических данных и опыте применения. Мы считаем это чрезвычайно важным в современном информационно перегруженном мире, где есть искушение и возможности ограничиться теоретическими исследованиями и выводами, сделанными другими специалистами.
Какие проблемы связаны с управлением версиями данных и их согласованностью при интеграции различных систем?
С.П.: Обычно это проблема определения текущего состояния в разных системах. Когда данные в одной системе отстают от данных в другой. Часто все усугубляется тем, что одна система может получать агрегированные данные из нескольких. В сложных интеграционных картинах всегда есть некоторый период несогласованности здесь или там. Как пример можно привести ситуацию из авиации, когда командир воздушного судна получает разрешение на отстыковку, в то время как табло над гейтом все еще показывает, что идет посадка. Если возникают подобные вопросы, начинается поиск баланса между производительностью и оперативностью, с одной стороны, и точностью и согласованностью — с другой.
В основном подобная сложность возникает на этапе, когда в системах заказчика появляется два или более конкурирующих источника данных, претендующих на звание «мастер». Эти вопросы легко решать на фазе обследования, выявляя соответствующие риски и выставляя дополнительные требования к решению и бизнесу. К примеру, можно отказаться от асинхронного обмена в части потоков и перейти к синхронному режиму или искать какие-то еще варианты устранения неоднозначностей. Хорошим решением будет использовать выделенную систему для управления мастер-данными (НСИ), если, конечно, такая имеется у заказчика или он готов к её внедрению. На фазе реализации выявление таких вопросов обходится существенно дороже.
Источник: IT World.