31.01.2023
Замена СУБД — одна из самых актуальных задач, стоящих перед банками. Большинство из них до сих пор используют СУБД зарубежных вендоров, а отказ от них — это очень дорогой и трудоемкий процесс. В качестве безопасной альтернативы выступают продукты российских разработчиков. Например, платформа Digital Q.DataBase от «Диасофт». На нее будут переведены в первую очередь продукты линейки Diasoft FA#*. Упростить миграцию поможет специальный конвертер кода, который позволит перейти на новый технологический стек в кратчайшие сроки — от 6 месяцев до 1 года.
За прошедшие с тех пор четыре года массовая миграция с иностранных СУБД на открытые или российские аналоги так и не началась. Причины очевидны — это очень дорогой и трудоемкий процесс, требующий в первую очередь адаптации решения, которое использует СУБД, и изменения давно устоявшихся процессов — таких, как разработка, обработка и анализ данных, формирование отчетности и т. д. Кроме того, организации не были уверены в том, что альтернативные решения смогут обеспечить необходимую производительность и будут столь же надежны, как давно известные продукты.
В 2022 г. ситуация резко изменилась. После ухода с рынка иностранных вендоров пользователи лишились технической поддержки продуктов. Во избежание неприятностей они изолировали их от внешней среды, однако очевидно, что в отсутствие обновлений срок жизни таких решений ограничен. Так, результаты опроса крупнейших российских банков, проведенного тем же TAdviser в начале 2022 г., показали, что одной из главных проблем для них стало использование иностранных СУБД: основные системы банков, такие как АБС и процессинг, работают либо на Oracle, либо на Microsoft SQL Server. То есть для того, чтобы перейти на использование отечественных СУБД, необходимо адаптировать к ним АБС и процессинг.
Альтернативой западным решениям должен стать продукт из Единого реестра российских программ для ЭВМ и БД. Таким образом, от популярной еще недавно идеи использования открытых продуктов, например, PostgreSQL, придется отказаться и выбирать из имеющихся в реестре СУБД от отечественных вендоров. В этом случае все вопросы, связанные с доработкой, установкой, обеспечением безопасности, поддержкой СУБД, ложатся на плечи разработчика.
Например, компания «Диасофт» предлагает отечественную СУБД Digital Q.DataBase. На нее будут переведены все продукты компании, в первую очередь продукты в составе платформ развития Digital Q.FinancialMarkets, Digital Q.Consumer, Digital Q.Corporate (до марта 2020 г. — Diasoft FA#*).
Продукты линейки Diasoft FA#* отвечают за комплексную автоматизацию банков и состоят из двух частей: серверной и клиентской.
Серверная часть продуктов будет переведена на импортонезависимую СУБД Digital Q.DataBase. Она основана на подконтрольном «Диасофт» форке PostgreSQL — PostgreDB — и адаптируется к особенностям каждого продукта. Это важно, поскольку продукты линейки Diasoft FA#* накопили в себе функциональность, которая создавалась годами. Такой код гораздо сложнее адаптировать.
Клиентская часть продуктов может работать под Wine на ALT Linux, а в качестве офисного приложения может использоваться отечественное ПО из реестра Минцифры.
Работа конвертера не меняет бизнес-логику приложения, данные в процессе конвертации не преобразуются, следовательно, не теряются. Бизнес-процессы организации остаются без изменений. Сотрудники продолжают писать код в прежней нотации, поэтому нет необходимости переобучать их для работы с PostgreSQL или нанимать новых.
Поскольку код в другой синтаксис переводится полностью, появляется возможность встроить конвертацию в pipeline сборки продукта и одновременно получить две его версии: одну — для клиентов, использующих MS SQL, другую — для клиентов, использующих PostgreSQL. При этом исходный код версий в разном синтаксисе единый, а значит, не требуются дополнительные расходы на разработку продукта в двух версиях.
Для минимизации количества ошибок, которые могут быть вызваны особенностями PostgreSQL, проводится дополнительная проверка с помощью инспектора кода.
Шаг 1. Обследование: выявляем недистрибутивный функционал и окружение. На этом этапе основная задача — выявить недистрибутивный функционал, понять его объем, что он собой представляет и как может быть обработан с помощью конвертера. Также специалисты «Диасофт» изучают окружение — другие программные продукты, которые взаимодействуют с СУБД. В результате определяется количество недистрибутива и возможность его автоматического преобразования с помощью конвертера или вручную. Это позволяет точно спрогнозировать объем необходимых работ. Вместе с этим согласовывается методика модели нагрузочного тестирования.
Шаг 2. Готовим инфраструктуру. Для СУБД на PostgreSQL требуется иная инфраструктура, чем для СУБД MS SQL: меняется операционная система и процесс взаимодействия клиент-серверного приложения с самой СУБД. На этом этапе на выделенном оборудовании развертываются серверы базы данных и операционная система, отдельно готовится инфраструктура для нагрузочного тестирования.
Шаг 3. Выполняем миграцию данных. Специалисты компании «Диасофт» переносят всю дистрибутивную и недистрибутивную структуру таблиц и данные в них (дефолтные значения, допустимые значения now, свойств типа identity и т. д.). Затем они экспортируют данные из базы MS SQL и импортируют их в базу PostgreSQL. Чтобы сократить время переноса данных, работы выполняются в максимально распараллеленном режиме. Далее строятся индексы и сверяются выгруженные и загруженные данные. Таблицы, содержащие исполняемый код, также будут конвертироваться в синтаксис PostgreSQL при переносе данных, чтобы их понимала новая СУБД. Такой подход позволяет избежать потери данных при переходе с одной СУБД на другую.
Шаг 4. Конвертируем недистрибутивный код. Недистрибутивный код банка может быть довольно объемным, и вручную его преобразовывать сложно. Эту задачу позволяет решить специальный конвертер, о котором шла речь ранее.
Шаг 5. Обновляем программные продукты линейки Diasoft FA#.* Устанавливаются обновления продуктов линейки Diasoft FA#* до самой последней версии с поддержкой PostgreSQL. Настраивается клиентская часть, и устанавливается недистрибутивный функционал банка. После проводится функциональное тестирование продуктов.
Шаг 6. Проводим приемо-сдаточные испытания. На этом этапе пользователь должен убедиться, что система работает так же, как и на СУБД MS SQL — в тех же интерфейсах и с теми же данными.
Шаг 7. Проводим нагрузочное тестирование. На этом этапе измеряется производительность по согласованной модели тестирования. В случае необходимости проводятся мероприятия по оптимизации производительности.
Шаг 8. Запускаем в эксплуатацию. Пользователь продолжает работу, только уже с обновленными продуктами и новой СУБД.
Таким образом, в прогнозируемые сроки банк получает обновленный продукт с накопленной функциональностью, переведенный на новую, импортонезависимую СУБД. Переход выполняется поэтапно и бесшовно — без влияния на бизнес-процессы организации, переобучения сотрудников или найма дополнительных дорогостоящих специалистов.
Задача перехода на новый технологический стек выполняется под ключ одним исполнителем, который гарантирует качество и имеет все необходимые компетенции. Используемые программные продукты безопасны и входят в Единый реестр российских программ для ЭВМ и БД.
В результате миграции на импортонезависимую СУБД банк защищает свой бизнес от рисков, возникающих из-за накопления критических ошибок в зарубежном решении. А также получает возможности для дальнейшего развития функционала ИТ-системы, что необходимо для сохранения высокой конкурентноспособности.
*В марте 2020 г. все продукты компании «Диасофт» объединены под брендом Digital Q и распределены по платформам развития в соответствии с предметной областью автоматизации.
Замена СУБД — одна из самых актуальных задач, стоящих перед банками. Большинство из них до сих пор используют СУБД зарубежных вендоров, а отказ от них — это очень дорогой и трудоемкий процесс. В качестве безопасной альтернативы выступают продукты российских разработчиков. Например, платформа Digital Q.DataBase от «Диасофт». На нее будут переведены в первую очередь продукты линейки Diasoft FA#*. Упростить миграцию поможет специальный конвертер кода, который позволит перейти на новый технологический стек в кратчайшие сроки — от 6 месяцев до 1 года.
Какие СУБД используют банки
Исследование TAdviser, проведенное в 2019 г., продемонстрировало практически тотальную зависимость российских пользователей, как в государственном, так и в бизнес-сегменте, от СУБД иностранных производителей — на долю Oracle и MS SQL приходилось 81% и 64% внедрений соответственно. На третьем месте по популярности — открытый продукт PostgreSQL (51%). На тот момент более 70% опрошенных организаций заявили, что изучают или уже планируют миграцию с используемых СУБД в ближайшие три года.За прошедшие с тех пор четыре года массовая миграция с иностранных СУБД на открытые или российские аналоги так и не началась. Причины очевидны — это очень дорогой и трудоемкий процесс, требующий в первую очередь адаптации решения, которое использует СУБД, и изменения давно устоявшихся процессов — таких, как разработка, обработка и анализ данных, формирование отчетности и т. д. Кроме того, организации не были уверены в том, что альтернативные решения смогут обеспечить необходимую производительность и будут столь же надежны, как давно известные продукты.
В 2022 г. ситуация резко изменилась. После ухода с рынка иностранных вендоров пользователи лишились технической поддержки продуктов. Во избежание неприятностей они изолировали их от внешней среды, однако очевидно, что в отсутствие обновлений срок жизни таких решений ограничен. Так, результаты опроса крупнейших российских банков, проведенного тем же TAdviser в начале 2022 г., показали, что одной из главных проблем для них стало использование иностранных СУБД: основные системы банков, такие как АБС и процессинг, работают либо на Oracle, либо на Microsoft SQL Server. То есть для того, чтобы перейти на использование отечественных СУБД, необходимо адаптировать к ним АБС и процессинг.
Что делать с иностранными СУБД
Какие варианты решения этой проблемы существуют? По мнению опрошенных CNews экспертов, поскольку большая часть крупных российских компаний предпочитала on-premise решения, ПО продолжает функционировать, даже лишившись обновлений. Его техническую поддержку способны осуществлять российские компании. Благодаря этому иностранное ПО можно использовать еще 2–3 года — до момента морального устаревания. Однако затягивать с миграцией все-таки не стоит. «В отсутствие обновлений в СУБД накапливаются ошибки, которые невозможно исправить, если ты не имеешь доступа к коду. Кроме того, нет возможности развивать решение, использовать новый функционал», — говорит Александр Бакулин, руководитель продуктового направления «Депозиты» компании «Диасофт».Альтернативой западным решениям должен стать продукт из Единого реестра российских программ для ЭВМ и БД. Таким образом, от популярной еще недавно идеи использования открытых продуктов, например, PostgreSQL, придется отказаться и выбирать из имеющихся в реестре СУБД от отечественных вендоров. В этом случае все вопросы, связанные с доработкой, установкой, обеспечением безопасности, поддержкой СУБД, ложатся на плечи разработчика.
Например, компания «Диасофт» предлагает отечественную СУБД Digital Q.DataBase. На нее будут переведены все продукты компании, в первую очередь продукты в составе платформ развития Digital Q.FinancialMarkets, Digital Q.Consumer, Digital Q.Corporate (до марта 2020 г. — Diasoft FA#*).
Продукты линейки Diasoft FA#* отвечают за комплексную автоматизацию банков и состоят из двух частей: серверной и клиентской.
Серверная часть продуктов будет переведена на импортонезависимую СУБД Digital Q.DataBase. Она основана на подконтрольном «Диасофт» форке PostgreSQL — PostgreDB — и адаптируется к особенностям каждого продукта. Это важно, поскольку продукты линейки Diasoft FA#* накопили в себе функциональность, которая создавалась годами. Такой код гораздо сложнее адаптировать.
Клиентская часть продуктов может работать под Wine на ALT Linux, а в качестве офисного приложения может использоваться отечественное ПО из реестра Минцифры.
Как будет организован процесс миграции
Вместе с этим, перевод продуктов линейки Diasoft FA#* на импортонезависимый стек складывается из двух составляющих: миграции данных и миграции кода. Миграция данных — давно отлаженный в компании «Диасофт» процесс. Переносится вся дистрибутивная и недистрибутивная структура таблиц и данных в них. При этом данные не видоизменяются. После переноса в базу PostgreSQL проводится контроль их целостности. Что касается миграции кода, рассматривалось несколько подходов. Первый — перевод продуктов на трехзвенную архитектуру с конвертацией кода на язык Java и параллельным выводом бизнес-логики из процедур, хранимых на сервере. Второй — написание кода на макроязыке, который, в зависимости от используемой СУБД, раскрывается в синтаксисе MS SQL, PostgreSQL и т. д. Третий — отказ от импортозамещения и установка новых продуктов схожего функционала, разработанных в микросервисной архитектуре. Однако все описанные подходы, помимо неоправданно больших трудозатрат и растягивания во времени процесса перехода на новый технологический стек, не учитывают, что некоторые банки хотят самостоятельно адаптировать код и поддерживать программные продукты силами собственных специалистов, без обучения и расширения штата.Что такое конвертер кода
Компания «Диасофт» выбрала принципиально другой путь. В «Диасофт» разработан специальный конвертер, который обеспечивает перевод кода с синтаксиса MS SQL на синтаксис PostgreSQL для работы на новой, импортонезависимой СУБД. Конвертер подходит для перевода дистрибутивного кода и, что важно, для адаптации процедур собственной разработки банка.Работа конвертера не меняет бизнес-логику приложения, данные в процессе конвертации не преобразуются, следовательно, не теряются. Бизнес-процессы организации остаются без изменений. Сотрудники продолжают писать код в прежней нотации, поэтому нет необходимости переобучать их для работы с PostgreSQL или нанимать новых.
Поскольку код в другой синтаксис переводится полностью, появляется возможность встроить конвертацию в pipeline сборки продукта и одновременно получить две его версии: одну — для клиентов, использующих MS SQL, другую — для клиентов, использующих PostgreSQL. При этом исходный код версий в разном синтаксисе единый, а значит, не требуются дополнительные расходы на разработку продукта в двух версиях.
Для минимизации количества ошибок, которые могут быть вызваны особенностями PostgreSQL, проводится дополнительная проверка с помощью инспектора кода.
|
Разработка конвертера позволила обеспечить переход на новый технологический стек в кратчайшие сроки — от 6 месяцев до 1 года. |
Этапы перехода на новую СУБД
В «Диасофт» накоплен опыт масштабных проектов перевода клиентов с одной СУБД на другую. Основываясь на этом опыте, специалисты компании предлагают следующий план действий.Шаг 1. Обследование: выявляем недистрибутивный функционал и окружение. На этом этапе основная задача — выявить недистрибутивный функционал, понять его объем, что он собой представляет и как может быть обработан с помощью конвертера. Также специалисты «Диасофт» изучают окружение — другие программные продукты, которые взаимодействуют с СУБД. В результате определяется количество недистрибутива и возможность его автоматического преобразования с помощью конвертера или вручную. Это позволяет точно спрогнозировать объем необходимых работ. Вместе с этим согласовывается методика модели нагрузочного тестирования.
Шаг 2. Готовим инфраструктуру. Для СУБД на PostgreSQL требуется иная инфраструктура, чем для СУБД MS SQL: меняется операционная система и процесс взаимодействия клиент-серверного приложения с самой СУБД. На этом этапе на выделенном оборудовании развертываются серверы базы данных и операционная система, отдельно готовится инфраструктура для нагрузочного тестирования.
Шаг 3. Выполняем миграцию данных. Специалисты компании «Диасофт» переносят всю дистрибутивную и недистрибутивную структуру таблиц и данные в них (дефолтные значения, допустимые значения now, свойств типа identity и т. д.). Затем они экспортируют данные из базы MS SQL и импортируют их в базу PostgreSQL. Чтобы сократить время переноса данных, работы выполняются в максимально распараллеленном режиме. Далее строятся индексы и сверяются выгруженные и загруженные данные. Таблицы, содержащие исполняемый код, также будут конвертироваться в синтаксис PostgreSQL при переносе данных, чтобы их понимала новая СУБД. Такой подход позволяет избежать потери данных при переходе с одной СУБД на другую.
Шаг 4. Конвертируем недистрибутивный код. Недистрибутивный код банка может быть довольно объемным, и вручную его преобразовывать сложно. Эту задачу позволяет решить специальный конвертер, о котором шла речь ранее.
Шаг 5. Обновляем программные продукты линейки Diasoft FA#.* Устанавливаются обновления продуктов линейки Diasoft FA#* до самой последней версии с поддержкой PostgreSQL. Настраивается клиентская часть, и устанавливается недистрибутивный функционал банка. После проводится функциональное тестирование продуктов.
Шаг 6. Проводим приемо-сдаточные испытания. На этом этапе пользователь должен убедиться, что система работает так же, как и на СУБД MS SQL — в тех же интерфейсах и с теми же данными.
Шаг 7. Проводим нагрузочное тестирование. На этом этапе измеряется производительность по согласованной модели тестирования. В случае необходимости проводятся мероприятия по оптимизации производительности.
Шаг 8. Запускаем в эксплуатацию. Пользователь продолжает работу, только уже с обновленными продуктами и новой СУБД.
Таким образом, в прогнозируемые сроки банк получает обновленный продукт с накопленной функциональностью, переведенный на новую, импортонезависимую СУБД. Переход выполняется поэтапно и бесшовно — без влияния на бизнес-процессы организации, переобучения сотрудников или найма дополнительных дорогостоящих специалистов.
Задача перехода на новый технологический стек выполняется под ключ одним исполнителем, который гарантирует качество и имеет все необходимые компетенции. Используемые программные продукты безопасны и входят в Единый реестр российских программ для ЭВМ и БД.
В результате миграции на импортонезависимую СУБД банк защищает свой бизнес от рисков, возникающих из-за накопления критических ошибок в зарубежном решении. А также получает возможности для дальнейшего развития функционала ИТ-системы, что необходимо для сохранения высокой конкурентноспособности.
*В марте 2020 г. все продукты компании «Диасофт» объединены под брендом Digital Q и распределены по платформам развития в соответствии с предметной областью автоматизации.