Ещё до 2022 года некоторые компании пробовали переходить на зарубежный софт. Чаще всего — ради экономии. Но сегодня для многих это уже вопрос выживания:
-
госкорпорации к переходу на российское ПО обязывает нацпрограмма «Цифровая экономика РФ»;
-
исполнители госзаказов также заинтересованы в миграции;
-
для банков, телекоммуникационных и транспортных компаний толчком служит риск санкций;
-
даже для малого бизнеса вопрос актуален: Microsoft Office может потерять поддержку в РФ.
Кроме того, Минцифры не раз обсуждали введение крупного штрафа (до 1 млн р.) за использование в работе зарубежного ПО. Как же быстро найти подходящие инструменты миграции?
Основные проблемы миграции на российское ПО и как их решить
Невозможно просто взять и перенести данные на отечественные системы управления базами данных (СУБД). Этот вопрос затрагивает множество важных аспектов. Прежде всего при переносе данных на новую платформу необходимо обеспечить сохранность информации и продолжение бизнес-процессов в прежнем режиме. А после перехода на российское ПО требуется выйти на прежнюю скорость работы, несмотря на различия в архитектурах. Рассмотрим основные проблемы миграции:
Различия между отечественными и зарубежными СУБД
Проблема: зарубежные СУБД (Oracle, MS SQL, MySQL) используют свои стандарты хранения данных, которые не могут поддерживаться российскими аналогами (Postgres Pro, ЛИНТЕР, Tarantool). Несмотря на совместимость систем, зарубежные обладают некоторыми надстройками, которые отсутствуют у отечественных.
Решение:
-
конвертеры БД (ora2pg, AWS Schema Conversion Tool, Pj Looder, SQL Server) переводят SQL-запросы и схемы между разными СУБД;
-
встроенные утилиты (миграционные скрипты Postgres Pro) упрощают переход с Oracle и MS SQL.
Зависимость от зарубежных программных продуктов
Проблема: каждая российская СУБД обладает своими уникальными особенностями. И нужно учитывать, что у некоторых приложений есть специфические возможности зарубежных систем управления. Поэтому доработка ПО потребуется в любом случае.
Решение:
-
прокси-слои и адаптеры API эмулируют отсутствующие функции;
-
кастомизация СУБД: вендоры (Postgres Pro, ЛИНТЕР) дорабатывают свои продукты под требования заказчика;
Необходимость переноса большого массива
Проблема: импорт накопленного объёма данных требует специальной организации. Механизм переноса данных нужно подбирать индивидуально. Допустим, организовать поэтапный процесс — по годам или тематическим блокам. Может потребоваться снятие ограничений, вызванных особенностями прежней архитектуры. Например, с помощью конвертации. Также может быть организована параллельная работа двух систем: пока новая система тестируется, старая продолжает работать; при этом Данные синхронизируются в реальном времени.
Мы рассмотрели ключевые проблемы, которые существенно усложняют процесс перехода с зарубежного софта на российское ПО. На самом деле их намного больше. И набор инструментов миграции будет зависеть от множества факторов.
Классификация инструментов миграции
Миграция данных — сложный многоуровневый процесс. Каждый этап подразумевает использование определённых инструментов, а окончательный их список для любого бизнеса будет своим. Исходить нужно из следующих параметров:
-
насколько сложный проект;
-
какова уникальность базы данных;
-
как много данных накоплено у компании;
-
какой сценарий миграции будет наиболее подходящим;
-
на какой стадии миграция (возможно, многое уже сделано).
Рассмотрим основные инструменты, в зависимости от этапа:
-
Анализ и аудит
Прежде всего необходимо выявить, где скрыты зависимости программного обеспечения. С этим отлично справляется DepChecker. Инструмент в автоматическом режиме анализирует используемые сторонние библиотеки и сервисы на предмет их совместимости с отечественным ПО.
Пример: компания хочет перейти на Astra Linux, запускает DepChecker и обнаруживает, что 30% ПО зависит от .NET Framework (он не поддерживается).
Перед переносом нелишним будет проверить качество кода. Эту задачу решает SonarQube, который выявляет баги, уязвимости и случаи дублирования кода. Также инструмент позволит решить обнаруженные проблемы и упростить работу над проектом.
-
Перенос данных
Перенос данных на российскую СУБД — ответственный этап. Осуществить его позволят конвертеры. Например, Ora2Pgpro, расширенная платная версия бесплатного продукта Ora2Pg. В отличие от Ora2Pg, Ora2Pgpro переносит данные из Oracle не в PostgreSQL, а в PostgrePro (российскую СУБД).
Пример: компания хочет перенести базу данных с Oracle на PostgrePro. В общей сложности это 500 Гб, куда входят разные таблицы (клиенты, заказы, транзакции), процедуры на PL/SQL, триггеры и представления (views). Ora2Pgpro автоматически конвертирует 70% кода, оставшиеся 30% дорабатываются вручную. В итоге миграция займёт меньше времени, чем в том случае, если использовать только ручной труд.
-
Тестирование
После миграции на российскую СУБД (например, PostgrePro или ЛИНТЕР) критически важно провести комплексное тестирование. Оно позволит выявить скрытые ошибки, влияющие на производительность и функциональность.
Выделяют три вида тестирования:
-
функциональное
для проверки, корректно ли работают все запросы, хранимые процедуры и бизнес-логика.
Тут подойдёт Selenium, который автоматически протестирует веб-приложения. У него открытый исходный код, что позволяет тестировщику корректировать инструмент под свой запрос.
-
нагрузочное
для проверки, выдержит ли российская СУБД рабочую нагрузку.
Инструмент JMeter, моделируя поведение реальных пользователей, имитирует нагрузку и тестирует устойчивость системы. Ещё один инструмент нагрузочного тестирования — «Яндекс.Танка», в основе которого генератор phantom, способный воспроизвести сотни тысяч HTTP-запросов в секунду.
-
интеграционное
для проверки взаимосвязей между компонентами.
Интеграционное тестирование помогает понять, как новая СУБД работает с другими системами — 1С, СRM, веб-приложениями. Можно применить популярный инструмент SoapUI, который обладает открытым исходным кодом и удобным графическим интерфейсом.
В результате тестирования может выясниться, что нужна доработка, которую тоже важно учесть при составлении плана миграции. Стоит исходить из того, что весь этап займёт 20-30% времени от всего процесса.
Пример: после перехода с VMware на «Ред Виртуализацию» ИТ-отдел запускает JMeter, чтобы проверить, выдержит ли новая система пиковые нагрузки.
Заключение
Выбор инструментов зависит от специфики IT-инфраструктуры компании, объёма данных и сложности бизнес-процессов. Для начала следует определить сценарий миграции. Чем он проще, тем меньше меньше инструментов понадобится:
-
если нужен просто перенос офисных пакетов, достаточно конвертеров;
-
перенос ERP/CRM предполагает запуск полного цикла: аудит, перенос, тестирование, виртуализация.
Использование правильно подобранных инструментов миграции экономит время, средства и снижает риски. Поэтому решение этой задачи лучше доверить экспертам.
Хотите снять с себя ответственность и риски за миграцию инфраструктуры, доверьте этот процесс техническим специалистам Cloud4Y. Мы предлагаем услугу «Бесплатная миграция в облако».
