Иван Варжавин, исполнительный вице-президент Газпромбанка, поделился с «Б.О» опытом импортозамещения ключевых банковских систем и практикой взаимоотношений с отечественными вендорами
—Иван, когда и с чего началось импортозамещение IT-инфраструктуры ГПБ?
— Ключевым фактором интенсификации работы по импортозамещению стало изменение законодательства в конце 2022-го — начале 2023 года. В частности, был введен перечень значимых объектов критической информационной инфраструктуры (ЗОКИИ), в который вошли основные банковские системы.
Это поставило перед банком задачу масштабного импортозамещения. Работы были декомпозированы: проведен аудит текущего состояния систем, определен весь технологический стек — от аппаратного обеспечения до прикладного ПО. На основе анализа были выделены участки, где достаточно провести миграцию на альтернативное оборудование, и направления, требующие глубокой переработки прикладного кода или замены ключевых компонентов инфраструктуры. В частности, потребовалась замена систем управления базами данных: например, переход с СУБД Oracle на отечественную СУБД Postgres Pro.
Исторически основу серверного парка составляли решения IBM (RISC-сервера) и HP (архитектура x86). Ключевые базы данных функционировали на платформах Oracle, Sybase и MSSQL, что являлось стандартной практикой для крупных финансовых организаций.
—Хватало ли тогда производительности IT-инфраструктуры?
— На момент начала работ по импортозамещению явных проблем с производительностью и отказоустойчивостью систем не наблюдалось. Однако эпизодически появлялись «первые звоночки» по производительности при обработке пиковых объемов операций.
—Как на практике выглядел старт импортозамещения лично для вас?
— В зону моей ответственности вошел первый блок ЗОКИИ — корпоративные системы. Он включает в себя: АБС, Расчетный центр банка, а также ДБО со всеми каналами дистанционного взаимодействия с клиентами. Второй блок — это розничные системы, а третий — общекорпоративные.
—Получается, что импортозамещение всего IT не было предусмотрено?
— Верно, комплексное решение, предусматривающее стопроцентное покрытие всех систем «вплоть до электрических розеток», на начальном этапе не планировалось. Слона нужно есть по частям! Поэтому мы придерживались поэтапного подхода, отдавая себе отчет в масштабности текущей задачи. В первую очередь были определены и приоритизированы наиболее критичные компоненты, которые мы могли перевести на отечественные решения в установленные сроки. Замечу, что работа велась строго в рамках обязательных требований Банка России.
—Ставка была сделана на вендоров или на собственные силы?
— Мы выбрали гибридную стратегию, где решение зависело от конкретного программного продукта. Например, при импортозамещении систем ДБО не только проводились работы по замене зарубежных компонентов, но и выполнялась миграция клиентов на целевую систему «Газпромбанк Бизнес Онлайн» из старой системы ДБО от компании BSS. А в части АБС мы проводили все работы в тесном взаимодействии с вендором — компанией ЦФТ.
Параллельно велась работа по замене иностранных компонентов в рамках импортозамещения. Инфраструктура, на которой работала система, претерпела изменения: мы перешли с серверов IBM на отечественную платформу «Скала^р» и заменили СУБД Oracle на Postgres Pro.
—Какие сложности с ДБО возникли?
— Существенных технологических сложностей не припомню. Это, вероятно, объясняется тем, что при создании нашей ДБО изначально закладывались базовые принципы технологической независимости. Архитектура системы строилась на базе open-source и иных стандартных, не проприетарных компонентов.
Мы осознанно избегали глубокой привязки к конкретным вендорским решениям. Например, для высоконагруженных сервисов выбрали промышленный стандарт — СУБД Oracle, а для обеспечения масштабируемости и производительности использовали серверные мощности IBM. Такой подход позволил нам заранее пройти путь построения гибкой системы.
В результате, когда началась активная фаза импортозамещения, основные задачи свелись, во-первых, к замене отдельных компонентов и интеграции отечественных аналогов для тех немногих проприетарных элементов, которые все же использовались, во-вторых, к миграции и переносу системы на новую аппаратную инфраструктуру. После этого осуществили перевод клиентов на целевое решение.
Иван Варжавин (ГПБ). Фото: Ирина Анисина / «Б.О»
—Как повлияли эти процессы на сохранение привычных пользовательских интерфейсов ДБО?
— Банк России в то время на всех рабочих сессиях подчеркивал, что непрерывность и надежность сервисов должны оставаться безусловным приоритетом даже в условиях масштабного импортозамещения. Поэтому при проведении работ мы руководствовались двумя основными принципами: обеспечение непрерывной работоспособности систем и сохранение преемственности и удобства для пользователей.
Изменение интерфейса, с которым ежедневно работают тысячи сотрудников и который позволяет им обрабатывать большой объем операций, недопустимо, если это приводит к снижению производительности.
Например, увеличение времени на выполнение стандартных процедур с 6 до 12 часов сделало бы работу с банком неэффективной. Такой сценарий был неприемлем.
Сюда же наверняка необходимо добавить, что представители службы кибербезопасности банка с самого начала проекта выступали как неотъемлемые участники всех решений и всех разработок. Поэтому новое ДБО, безусловно, соответствует концепции Security-by-Design.
— СПО для ДБО понятно. А как было с «железом»?
— Задача по переходу на отечественное аппаратное обеспечение была одной из самых сложных. На старте мы использовали высокопроизводительные RISC-серверы IBM, прямых аналогов которым на российском рынке не существовало.
Поэтому наша работа строилась в несколько этапов. Сначала проанализировали доступные на рынке серверные конфигурации и начали моделировать, можно ли развернуть наши системы на новом оборудовании. Этот процесс сопровождался интенсивным нагрузочным тестированием целевых систем, в первую очередь АБС от ЦФТ.
По итогам тестов выявлялись узкие места, которые требовали совместных усилий всех участников проекта.
Проблемы решались комплексно: от оптимизации на уровне системного софта и обновления прошивок до поставки процессоров с увеличенной производительностью. Решать такие задачи локально или поодиночке было бы невозможно. Для координации была выстроена система регулярных встреч, а при возникновении критических проблем мы переходили на режим ежедневных оперативных совещаний и мозговых штурмов.
В качестве целевой платформы был выбран ПАК «Скала^р». Это решение было максимально готовым к промышленному использованию и уже внедрено в ряде организаций. Ключевое преимущество ПАК «Скала^р» — то, что это комплексное и уже преднастроенное решение. Вендор устранил основные проблемы совместимости драйверов, системного ПО и аппаратных компонентов, что значительно упростило и ускорило нашу миграцию.
Иван Варжавин (ГПБ), Вадим Ференец («Б.О»). Фото: Ирина Анисина / «Б.О»
—На рынке считается, что помимо всего прочего одним из преимуществ ПАК «Скала^р» является его динамическая IT-начинка. Как она проявила себя при миграции?
— Да, это один из ключевых аргументов в пользу выбора ПАК «Скала^р». Мы стремились избежать необходимости самостоятельно проходить путь интеграции компонентов, сопряженный с рисками и потерей времени. Использование готового, валидированного решения позволяло нам опереться на экспертизу производителя и не «набивать собственные шишки».
Подход к миграции различных систем, конечно, имел свои особенности. Например, ключевыми факторами производительности для АБС являются показатели базы данных. В случае с системами ДБО основная нагрузка ложится на вычислительные мощности, однако эта задача решается проще благодаря микросервисной архитектуре. Она позволяет масштабировать сервисы, размещая их на отдельных виртуальных машинах и динамически наращивая ресурсы по мере необходимости.
Поэтому основной вызов для нас был связан именно с миграцией АБС, где производительность всей системы напрямую зависит от производительности базы данных.
Что касается выбора системы управления базами данных (СУБД), мы сознательно отказались от использования версии с открытым исходным кодом (open source) в пользу коммерческого решения Postgres Pro. Это было стратегическое решение.
Глубокое понимание вендором внутренней архитектуры СУБД необходимо для решения сложных инцидентов и оптимизации производительности. Развивать подобные компетенции внутри банка было бы неэффективно как с точки зрения сроков проекта, так и с точки зрения затрат.
Поэтому мы выбрали команду Postgres Pro в качестве ключевого технологического партнера, способного предоставить всю необходимую экспертную поддержку.
—Как проходили тесты? Что они показали?
— Тестирование проводилось в несколько этапов с участием всех сторон: представителей банка, разработчика АБС и производителя оборудования.
Первые испытания были организованы на базе технологического центра компании «Рубитех». Это позволило провести тесты в контролируемой среде после полной адаптации АБС для работы на программно-аппаратном комплексе под управлением российской операционной системы.
Последующие, более масштабные тесты проводились уже на инфраструктурной площадке самого банка.
В ходе испытаний мы прошли путь от конфигурации с недостаточным запасом производительности до финального варианта, который не только обеспечивает стабильную работу, но и обладает достаточным ресурсом для обработки пиковых нагрузок.
Уверенность в выбранной конфигурации подтверждается результатами промышленной эксплуатации. Ярким примером служит случай, произошедший на третий день после перехода на новое решение: система успешно обработала максимальный за всю историю Газпромбанка объем операций по зарплатным зачислениям. Я не уверен, что старая инфраструктура на базе Oracle и IBM справилась бы с такой нагрузкой.
—На ваш взгляд, полученный результат можно назвать «импортоопережением»?
— Да, полученный результат можно охарактеризовать как важный этап на пути к «импортоопережению». В ходе реализации проекта мы не просто заменили иностранные аналоги, а предложили и внедрили улучшения, положенные в основу новой высокопроизводительной и отказоустойчивой конфигурации ПАК «Скала^р», аналогов которой ранее не было на рынке.
Например, в процессе нагрузочного тестирования мы выявили, что мощности штатных блоков питания недостаточно для корректной работы системы под пиковыми нагрузками. По нашей инициативе совместно с производителем была произведена их замена на более мощные, что обеспечило необходимый уровень надежности всего комплекса.
Эта работа стала результатом тесного партнерства с компанией «Рубитех», которая выступает ключевым интегратором ПАК «Скала^р». Коллеги из «Рубитеха» и «Скалы» обеспечили необходимое обучение наших специалистов, а также осуществляют сопровождение и техническую поддержку оборудования, помогая оперативно решать все возникающие вопросы.
Что касается показателей непрерывности бизнеса, то после завершения миграции на импортозамещенную платформу ключевая система банка — АБС — работает без единой остановки.
Мы полностью перешли на новую инфраструктуру в начале июня 2025 года, и за прошедшие месяцы сбоев в ее работе зафиксировано не было. Общий результат импортозамещения в банке был высоко оценен Центральным банком и всем банковским сообществом и обеспечил возможность проведения импортозамещения ЗОКИИ в банках второй волны.
—Что интересного происходило в это время в Расчетном центре банка?
— Действительно, мы пока не затронули тему импортозамещения Расчетного центра, а это на самом деле важный аспект, поскольку для его реализации мы построили решение на базе СУБД крупнейшего российского разработчика. Это отдельная архитектура и технология, которая не является прямой заменой Oracle или Postgres, а представляет собой самостоятельный продукт.
Именно благодаря этой российской технологии нам удалось добиться кардинального увеличения производительности и бесперебойности работы Расчетного центра. Скорость обработки документов в Расчетном центре выросла минимум в 10 раз.
Ключевым преимуществом отечественной СУБД, которую мы выбрали, является не только производительность, но и отказоустойчивость. Система построена по кластерному принципу. Наш кластер состоит из девяти серверов. Архитектура спроектирована таким образом, что система продолжает стабильно работать даже при одновременном выходе из строя трех или четырех серверов. Пользователи при этом не замечают никаких сбоев или снижения скорости.
На данный момент прямых аналогов этой российской СУБД на рынке нет. Именно поэтому для достижения такого значительного прироста производительности и надежности мы выбрали эту технологию. Путь к этому результату был непростым: мы прошли длительный этап выбора, тестирования и настройки решения.
Система развернута on-premise, то есть на нашей собственной инфраструктуре, а не в облаке «Яндекса». На данный момент мы не используем облачные сервисы для данных задач.
—C ядром системы понятно. А что с виртуализацией и периферией?
— На рабочих местах сотрудников в пилотном режиме используются тонкие клиенты с подключением по технологии VDI (Virtual Desktop Infrastructure) на импортозамещенном стеке. Задача по импортозамещению всей периферии, включая конечные рабочие станции, относится к последующим этапам проекта. Планирование этой работы ведется в настоящее время.
Ключевым этапом для нас стал переход на отечественные решения в области серверной виртуализации. Ранее наша инфраструктура была построена на платформе VMware. Мы полностью перевели все виртуальные серверы ЗОКИИ на решение отечественной компании «Базис». Этот процесс был поэтапным и потребовал нескольких итераций тестирования. В ходе испытаний выявлялись ошибки, которые оперативно исправляли разработчики. Финальный переход был завершен в конце прошлого года.
Этот переход позволил нам создать современную, динамическую IT-инфраструктуру, которая обеспечивает гибкое управление ресурсами и повышает общую эффективность системы.
Возвращаясь к вопросу о тонких клиентах на рабочих местах сотрудников, отмечу, что такая инфраструктура была внедрена в банке задолго до старта программы импортозамещения. У нас практически не используются традиционные стационарные компьютеры. Это архитектурное решение обеспечило банку ключевое преимущество — возможность быстрого и массового перевода сотрудников на удаленный режим работы, что было особенно актуально в условиях пандемии. К тому же с точки зрения ИБ такая модель также является предпочтительной.