Проблема не в банках

Не так давно несколько крупных банков выступили с предложением перенести обязательный переход на отечественное ПО, включенное в реестр Минцифры, с 2025 на 2027 год. В качестве аргумента приводилось мнение, что отечественные поставщики не успеют адаптировать автоматизированные банковские системы (АБС) под работу с российскими системами управления базами данных (СУБД).

Дело в том, что системы АБС и СУБД тесно связаны в ИТ-инфраструктуре банка, и подавляющее большинство банков используют СУБД от американской компании Oracle, от которой надо отказаться до 2025 года включительно.

Сложность же заключается в том, что ключевые российские разработчики АБС не готовы разом перевести весь банковский рынок на российские СУБД. Большинство компаний-разработчиков осуществляет от трех до шести таких проектов в год. Но по 50 проектов за год никто не реализует, так как тестируемых решений и штатных ресурсов — инженерного и программистского — не хватает.

Зависимость от разработчика: уйти нельзя остаться

В Московском кредитном банке сейчас используется АБС разработчика Центра финансовых технологий. Если говорить о замене ключевых и сложных систем, мы значительно зависим от вендоров, как и другие участники рынка. Так, похожая ситуация с процессингом — системой управления картами, транзакциями и авторизацией. Это вторая по значимости система учета после АБС. Дело в том, что процессинговое ПО — отечественное, но внутри него — код Oracle.

При этом, по моему мнению, отказаться от вендоров и самостоятельно написать с нуля свою АБС на данный момент никто из банков технологически не готов. Даже если несколько банков создадут консорциум для разрешения данной ситуации, за несколько лет невозможно подготовить функциональность, которую разработчики АБС создавали десятилетиями.

Какой будет СУБД

Выбирая новую СУБД, большинство участников рынка склоняется к PostgreSQL. Изначально это продукт Open Source, отечественная сборка которого вошла в реестр Минцифры. Сейчас она максимально приближена к Oracle по функциональности и логике работы.

Мы считаем, что переход на нее будет наименее болезненным с точки зрения бизнес-логики, построения хранения данных и их индексации. Другие российские системы управления базами данных «идеологически» стоят от Oracle дальше, чем PostgreSQL, и наша команда не рассматривала их как альтернативу.

У PostgreSQL уже есть функции под которые необходимо переписать всю бизнес-логику АБС — она сейчас у всех написана под Oracle. Это очень большой объем кода, который нужно заменить в системе, не меняя при этом базовую функциональность: модули расчетов, депозитов и реквизитов.

Дружеское ПО

Отмечу, что у банков нет обязательств отказываться от всех видов иностранного ПО: замене подлежат лишь программные продукты из недружественных стран и системы, признанные объектами критической инфраструктуры, связанные с платежами, карточными транзакциями.

В этом году МКБ заменил BI-систему (Business Intelligence — набор инструментов и программ для бизнеса, которые обрабатывают и визуализируют данные) на ПО китайского вендора FineBI.

К слову, наши бизнес‑подразделения давно занимаются разработкой дашбордов и обладают экспертизой в области BI‑аналитики. Поэтому нам было важно получить именно self‑service решение, в рамках которого пользователь без техподдержки производителя мог бы самостоятельно, с помощью настроек, а не программирования, решать свои задачи в информационной системе.

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

Найти устойчивость ПАКа

ИТ-команда нашего банка также ведет работу по замене «железной» части программно-аппаратного комплекса (ПАК).

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

Например, хранилище данных у нас было от HP, сервера — IBM, операционные системы — Red Hat. И мы сохраняли устойчивую работу ПАКа, меняя отдельные компоненты: к примеру, могли отказаться от системы хранения HP и перейти на Hitachi, и все работало по-прежнему.

Сейчас мы не можем уверенно говорить о том, что все отечественные компоненты ПАКа имеют тот же уровень совместимости, надежности и стабильности.

На данный момент мы находимся в стадии пилотной эксплуатации — ищем сочетания компонентов, которые стабильно взаимодействуют, подбираем разные технологические решения, запускаем на них бизнес-системы, учимся их эксплуатировать, проверяем работоспособность ПАКа.

В следующем году мы планируем запустить проекты перехода на отечественную СУБД в рамках АБС и процессинга и создать стабильно работающий ПАК на отечественных компонентах, на котором можно безбоязненно эксплуатировать прикладное программное обеспечение.

Также в планах на 2024 год — заменить на российский весь стек, который отвечает за качество, загрузку и обработку данных, а также офисное ПО — операционную систему для пользователей, браузер и почтовый клиент.