На полпути к импортозамещенной банковской системе
Большинство критически важных банковских систем работают на иностранных СУБД — это факт. Значит ли это, что, чтобы перейти на использование российских СУБД, нужно создавать новые автоматизированные банковские системы (АБС)? Вовсе нет! Наш коллега Михаил Мальцев, который руководит проектом перевода АБС RS-Bank V.6 R-Style Softlab на Postgres Pro, докажет, что для реализации стратегии импортозамещения можно не отказываться от привычного функционала. Также он даст ряд полезных советов банкам, планирующим проект обновления АБС, какую предварительную работу им нужно провести, чтобы процесс перехода на российский системный софт был проще и быстрее.
Почему банки не торопятся «импортозамещаться»?
Тема импортозамещения прочно обосновалась в топе задач, стоящих сегодня перед компаниями и организациями самых разных сфер деятельности. Но в большей степени она затронула финансовый сектор экономики. Хотя сейчас на нашем рынке функционируют автоматизированные банковские системы на нашем рынке преимущественно от российских ИТ-компаний, работают они на иностранных платформах (СУБД, ОС, офисный пакет).
Первые полностью отечественные разработки уже появились на рынке банковского ПО. Между тем банки в большинстве своем заняли выжидательную позицию и не выстраиваются в очередь к их создателям. Причин несколько, назову самые явные.
- Замена АБС — это дорогостоящий, сложный и довольно длительный процесс. Если текущая АБС устраивает всех, а новая не содержит важной сейчас бизнес-функциональности, то проект замены АБС превращается в расходный внутренний проект компании.
- Всем известная устойчивость Oracle дает возможность несколько лет стабильно работать без сбоев даже при отсутствии технической поддержки.
- Свою роль играет также приверженность имеющемуся функционалу и платформе — многие хотели бы получить его же в реализации на новом технологическом стеке, чтобы не пришлось переучивать персонал и привыкать к новому ПО, что всегда чревато определенным стрессом.
Мультиплатформенность как способ перевести АБС на новый стек технологий
Флагманский продукт нашей компании — АБС RS-Bank V.6 — функционирует на СУБД Oracle. Эта система нашла своего потребителя и хорошо себя зарекомендовала при работе в высоконагруженном режиме. Кроме российских банков в числе ее пользователей немало кредитных учреждений из стран СНГ, и их имеющийся стек вполне устраивает. А вот для отечественных пользователей нам необходимо было найти решение по импортозамещению. И тогда пришла идея сделать нашу АБС мультиплатформенной.
В чем суть проекта?
Итак, что мы имеем? У нас есть система, которая работает на СУБД Oracle, в операционной системе MS Windows, с использованием офисного пакета MS Office. Наша цель — все три компонента АБС (терминальную часть, сервер приложений и базу данных) научить работать еще и на импортонезависимом стеке технологий. В качестве платформы для этого мы выбрали СУБД Postgres Pro, операционную систему Astra Linux с установленным ПО WINE@Etersoft, а для выпуска отчетов — программу Р7-Офис — все эти решения зарегистрированы в реестре РосПО.
Тогда на выходе мы получим все ту же АБС RS-Bank V.6, но обладающую свойством мультиплатформенности — одинаково эффективно работающую и на СУБД Oracle, и на СУБД Postgres Pro. Достаточно при инсталляции выбрать нужный стек.
Проект реализации мультиплатформенности стартовал в конце ноября прошлого года. Выход первого прототипа АБС на Postgres Pro с самой востребованной функциональностью планируется к лету, тогда уже мы сможем продемонстрировать его клиентам. А весь проект планируем завершить в конце 2023 года, после создания коробочной версии системы.
Что предстоит сделать, и что уже сделано в рамках проекта?
Остановлюсь подробнее на том, что же собой представляет проект перевода АБС на новые технологические рельсы, и по каким направлениям ведутся работы.
Конвертация хранимых процедур. В СУБД Oracle есть хранимые процедуры, написанные на PL/SQL. С помощью созданного нами специального конвертора они в автоматическом режиме переводятся на Postgres Pro, то есть, по сути, мы делаем их аналоги на PG/SQL. Если какую-то часть хранимого кода перевести из одной базы данных в другую не удается, то для них мы либо дорабатываем конвертор, либо переписываем запросы вручную.
Чтобы наша АБС могла работать на Postgres Pro, необходимо доработать SQL-код, который используется непосредственно в коде на C++ и в макросах на RSL. Проще говоря, вся интерфейсная часть, задействованная при взаимодействии с базой данных, проверяется на корректность конвертации SQL-кода на Postgres Pro и при необходимости дорабатывается вручную. Однако это касается только сложных запросов, потому что простые запросы преобразуются конвертором запросов с Oracle на Postgres Pro корректно.
- Отдельно разрабатывается конвертор БД, выполняющий перенос данных из базы Oracle в базу Postgres Pro. Не секрет, что эти СУБД существенно различаются. Поэтому в конвертор БД заложен алгоритм, преобразующий различные сущности базы данных на Oracle в необходимые сущности БД на Postgres Pro. Этот конвертор клиенты будут использовать лишь однажды — непосредственно при переходе с одной СУБД на другую. Сделать это они могут либо самостоятельно, либо с привлечением нашей проектной команды.
Следующий шаг — замена операционной системы. Она потребовала небольшой доработки инструментального кода, потому что наша АБС на Astra Linux использует программное обеспечение WINE@Etersoft. С помощью этого ПО, которое является альтернативной реализацией Win32 API функций, Windows-приложения работают на Astra Linux.
- Инструментальная доработка понадобилась и для того, чтобы системные отчеты могли выпускаться и открываться в Р7-Офис.
- На текущий момент конвертор БД готов, сейчас выполняется полный цикл тестовых испытаний. Проверяем, корректно ли переносятся данные в таблицах, соответствуют ли типы данных нужным и т.д. Нам предстоит выполнить функциональное ручное тестирование, автоматизированное тестирование, нагрузочное тестирование, многопользовательское тестирование, тестирование обратной совместимости на Oracle, чтобы в конце проекта мы могли утверждать, что наша АБС одинаково хорошо работает как на Oracle, так и на Postgres Pro.
- Чтобы систему можно было устанавливать и обновлять на разных СУБД, мы внесем соответствующие изменения в инсталлятор и апгрейдер. И, конечно же, доработаем веб-интерфейс, чтобы он корректно функционировал не только на Windows, но и на Astra Linux.
Должен заметить, что работы по проекту идут весьма активно. Созданный конвертор для трансформации кода на PL/SQL в код на PG/SQL большинство языковых конструкций переводит в автоматическом режиме.
Как банку подготовиться к переходу на импортозамещенную АБС?
К любому новому проекту нужно готовиться. В нашем случае от четкости проведения предварительных работ будет зависеть, насколько легко и безболезненно для банков произойдет переход к использованию АБС на новом стеке.
Первое, чем нужно озаботиться, — это установкой на сервера банков необходимого ПО — Postgres Pro, Astra Linux, WINE@Etersoft, Р7-Офис. Следующая задача — подготовка квалифицированных кадров. Нужно, чтобы банковские специалисты умели работать на новом ПО.
И, пожалуй, самое главное — составить список всех доработок, выполненных банком самостоятельно в нашей АБС, проанализировать их и подготовиться к их переводу на новый стек. В первую очередь это касается хранимых процедур и таблиц.
А вот кому готовиться и адаптироваться к новому ПО не придется, так это непосредственным пользователям системы — для них ничего не изменится, так как вся известная им функциональность АБС останется прежней.
Перевод уже работающей АБС на новый стек банк сможет осуществить самостоятельно: для этого им достаточно будет запустить конвертор, который автоматически перенесет большую часть функционала из Oracle в Postgres Pro. Что же касается доработок самого банка, то для них наша команда либо адаптирует конвертор, либо окажет консультации в части необходимого изменения SQL-кода.
Вот и все, о чем я хотел рассказать в этой статье. Добавлю лишь, что если банк заранее подготовится к проекту и выполнит все перечисленные выше действия, то это существенно ускорит работу по переводу кредитного учреждения на новый стек. Ведь если предварительно все готово — есть база, есть серверы, то проект по переводу может занять от 2 недель до месяца.
Михаил Мальцев, руководитель проекта перевода RS-Bank V.6 на Postgres Pro, департамент банковского ПО RS-Bank, R-Style Softlab, входящая в группу Россельхозбанка
взяли опенсорс назвали его отечественным продуктомВся суть импортозамещения.
Комментарий недоступен
Ведь если предварительно все готово — есть база, есть серверы, то проект по переводу может занять от 2 недель до месяца.
Вы это серьезно?
Любое, самое минимальное изменение кода в банковской системе тянет за собой полный цикл ретеста. Просто потому что должна быть уверенность на 146% что новый код работает не хуже (по функционалу, нагрузке и т.д. и т.п.) старого.
Отретестить всю АБС - это не 2 недели и не месяц, а намного больше. И при этом банк не может закрыться на "технический перерыв" даже на 10 минут (есть нормативы регулятора на доступность систем разного уровня критичности - для mission critical систем это считаные минуты). Он должен продолжать работу в режиме 24/7.
Т.е. нужен некий "переходный период" когда в банке будут параллельно работать обе системы и результаты их работы будут постоянно мониториться на идентичность.
Не так все это просто с моей точки зрения (человека, который более 5-ти лет работает на уровне ядра АБС в банке из топ-10).
Не говоря уже о том, что не все банки на оракле работают :-)
V.P. Вы это серьезно?
Любое, самое минимальное изменение кода в банковской системе тянет за собой полный цикл ретеста. Просто потому что должна быть уверенность на 146% что новый код работает не хуже (по функционалу, нагрузке и т.д. и т.п.) старого.
Михаил Мальцев: Здесь речь идет о том, что если банк работает на коробочной версии АБС RS-Bank V6 с минимальными доработками со своей стороны, то перевод базы с Oracle на Postgres Pro и запуск работы на ней занимает от двух недель до месяца. Если же у банка большое количество собственных доработок, то конечно срок перевода увеличится, т.к. банку придется все свои доработки адаптировать и тестировать.
V.P. Отретестить всю АБС - это не 2 недели и не месяц, а намного больше. И при этом банк не может закрыться на "технический перерыв" даже на 10 минут (есть нормативы регулятора на доступность систем разного уровня критичности - для mission critical систем это считаные минуты). Он должен продолжать работу в режиме 24/7.
Михаил Мальцев: Речь не идет о тестировании банком дистрибутивного функционала АБС RS-Bank V6. Этот функционал итак будет оттестирован внутри компании до того, как новый дистрибутив, работающий и на Oracle и на Postgres Pro, будет передан в тираж.
V.P. Т.е. нужен некий "переходный период" когда в банке будут параллельно работать обе системы и результаты их работы будут постоянно мониториться на идентичность. Не так все это просто с моей точки зрения (человека, который более 5-ти лет работает на уровне ядра АБС в банке из топ-10). Не говоря уже о том, что не все банки на оракле работают :-)
Михаил Мальцев: В статье не рассматриваются все виды АБС и СУБД, на которых они работают. Речь идет о конкретной АБС RS-Bank V6, работающей в настоящий момент на СУБД Oracle, и о переводе ее работы на СУБД Postgres Pro.