Интеграция данных: баланс между «быстро» и «хорошо»

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

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

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

Мы попросили экспертов поделиться мнением, как грамотно спланировать, спроектировать и осуществить интеграцию данных.

Если осуществляется миграция с проприетарных решений на ПО с открытым исходным кодом, заказчики нередко опасаются столкнуться с теми или иными техническими препятствиями. По мнению Александра Чиченина, технического директора компании ITentika, для закрытых систем наиболее вероятными рисками становятся слабое качество документации и трудности с реализацией механизмов интеграции. Под этим эксперт подразумевает закрытые форматы передачи данных и недокументированное API, скрытые уязвимости, требующие дополнительного black box security-тестирования, невозможность расширения существующей функциональности силами внутренней команды, а также высокую зависимость от поставщика системы — так называемый Vendor Lock-In, ситуацию в которой будет трудно за приемлемое время и средства поменять одну интегрированную систему на другую, если компания расторгнет договор или прекратит свое существование. 

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

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

Один из наиболее распространенных рисков, которые могут возникнуть при интеграции систем, — потеря данных. Чтобы ее избежать, эксперты рекомендуют реализовать некую промежуточную среду, или песочницу. «Для снижения рисков рекомендуется использовать промежуточную среду для загрузки сырых данных, затем уже загружать их в целевую систему. В случае неполадок, неполноты или конфликтов данных они будут сохранены в промежуточной среде в сыром виде для последующих попыток загрузки. Для оценки рисков также следует учесть доступность источника и надежность сети», — советует Денис Куц, руководитель направления заказной разработки компании iiii Tech (Форайз).

Использование устаревших или унаследованных (legacy-систем) до сих пор остается серьезной проблемой. И сегодня можно встретить организации, у которых есть системы, работающие десятилетиями, еще со времен MS-DOS либо ведущие свою историю с 1990-х или начала 2000-х годов. Компания-разработчик давно канула в Лету, а приложение функционирует, поскольку по-прежнему соответствует задачам заказчика. Но далеко не все задумываются, что такие системы представляют собой бомбу замедленного действия. «Ключевыми моментами при использовании подобных систем являются безопасность, возможность поддержки и их модификаций для внедрения новых функциональных возможностей, — комментирует Антон Аплемах, генеральный директор российского объектного хранилища Platformcraft. — В разрезе безопасности известны прецеденты многолетнего существования уязвимостей в ПО, которое применялось огромным количеством компаний. Например, уязвимость в одной из библиотек SSH, позволяющая злоумышленнику получить доступ к серверу без ввода пароля. Именно поэтому безопасность унаследованных систем становится одним из важных моментов в их эксплуатации. Возможность поддержки подобных систем накладывает определенные ограничения на команду специалистов и предполагает уровень не ниже middle, а в случае сложных систем — senior. Похожая ситуация складывается и с модификациями подобных решений, которые порой требуют проведения серьезного R&D».

Часто необходимо найти баланс между потребностью в быстрой интеграции и необходимостью тщательной проверки данных на соответствие. Константин Тельной, старший бэкенд-разработчик компании Simple, рекомендует в подобных ситуациях внимательно проконсультироваться с бизнесом. «Необходимо выяснять, насколько допустимы потери данных и ошибки, на чем можно сэкономить, — объясняет он. — Зачастую среди данных есть 20%, которые нужны прямо сейчас, и 80%, которые можно привлечь позже. Неплохо также понимать, насколько в целом сложна задача и на что влияют те или иные задержки. Часто можно сделать решение, которое технически не будет идеальным, однако устроит бизнес».

Александр Хантеев, руководитель архитектурной практики компании RNT Group, предлагает разделить переносимые данные на домены, сделать акцент на наиболее значимых областях и ускорить процесс за счет поэтапного переноса — этот подход позволит поддерживать высокий темп миграции, не допуская проблем с качеством переносимых данных. Бизнесу, по его словам, не нужны некачественные данные.

«Все в большой степени зависит от критичности данных для бизнеса и конкретных требований проекта. Больше внимания необходимо уделять критически важным данным и бизнес-процессам. Если, например, речь идет о банковских операциях, где необходима максимальная точность, то пренебрегать проверкой качества информации нельзя. Скорее всего, в этом случае придется корректировать сроки проекта. А если мы работаем со статистикой, не особо влияющей на финансовый результат, то в отдельных случаях можно пренебречь проверками или перенести их на следующие этапы проекта, после внедрения», — отмечает Павел Ревин, старший архитектор департамента аналитических решений ГК «КОРУС Консалтинг».

Миграция из локальной ИТ-инфраструктуры в облачную — отдельная история, и здесь может возникнуть целый спектр сложностей, связанных с интеграцией данных, начиная с объема, безопасности и пропускной способности вплоть до вопросов юридических и управления изменениями. «Прежде всего, при переносе данных в облако может возникнуть угроза конфиденциальности и целостности данных. Также могут появиться трудности при синхронизации данных из-за несовпадения структур и типов. Чтобы избежать ошибок и сократить время на миграцию, для переноса большого количества данных лучше использовать автоматизированные инструменты», — считает Анна Чеснокова, руководитель QA-отдела компании SimbirSoft.

По словам Павла Ревина («КОРУС Консалтинг»), в случае миграции в облако часто происходят сложности, связанные в сетевой доступностью, безопасностью и согласованностью данных. Также нередко возникают организационные вопросы согласования с ИБ-подразделениями. «Компания может иметь внутренние требования относительно данных: например, одни данные можно перемещать в облако, а другие ни при каких обстоятельствах не должны туда попадать. Для такого контроля могут потребоваться дополнительные модули и компоненты в системах. Важно создать план миграции, который учитывает эти аспекты, и провести тестирование, чтобы убедиться в успешной миграции», — говорит он.

Станислав Дарчинов (НКК) в первую очередь говорит о трудностях организационного плана. Они связаны с передачей ответственности по вопросам сертификации по ряду федеральных законов — о персональных данных 152-ФЗ, о безопасности критической информационной инфраструктуры (КИИ) 187-ФЗ. «Некоторая внешняя инфраструктура становится частью защищаемого периметра, и корпоративные данные являются защищенными согласно законодательству. Требования по наличию соответствующих сертификатов и специалистов для работы с ГИСами, медицинскими информационными системами, персональными данными и т. д. предъявляются к провайдерам облачных услуг, — комментирует эксперт. — Если, наоборот, происходит миграция из облака в корпоративную ИТ-инфраструктуру, то у предприятия должны быть все перечисленные выше сертификации и компетенции».

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

«Сложности миграции данных между облачными и локальными платформами могут включать ограничения предоставляемых облаком сервисов и их недостаточную зрелость. Также важно учитывать пропускную способность сети и безопасность, требования регуляторов и внутренние регламенты информационной безопасности. Большую роль играет неготовность бизнеса доверять свои данные публичному облаку. Именно поэтому в нашей стране такое развитие получают приватные и гибридные облака», — уверен Александр Хантеев (RNT Group).

Если говорить о приоритетности решаемых задач при переходе в облако, то Александр Чиченин (ITentika) в первую очередь советует решить проблемы, связанные с доступностью, надежностью и стоимостью каналов передачи данных между локальными и облачными контурами. «Для минимизации рисков многие провайдеры предоставляют выделенные линии, позволяющие напрямую связать облачные дата-центры с оборудованием клиента, тем не менее, резервирование таких каналов может быть значительно более сложным, чем резервирование обычных интернет-каналов», — объясняет он.