Технологический суверенитет Газпромбанка: как переход на отечественный ПАК обеспечил беспрецедентную отказоустойчивость АБС

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

Цели и задачи проекта

Основная цель: обеспечивать устойчивое развитие, высокую надежность, масштабируемость и производительность критически важных АС (автоматизированных систем) банка на базе отечественных технологий.

Для реализации импортонезависимости инфраструктуры и долгосрочного развития АС, менеджментом банка были поставлены задачи:

• Организовать миграцию системы АБС на российский стек технологий Скала^р и Postgres Pro Enterprise с базы данных Oracle.
• Собрать тестовый контур и обеспечить работу всех подразделений банка и разработчиков АБС системы таким образом, чтобы можно было вводить тестирование и параллельно модернизировать систему под увеличение нагрузки.

Особенности проекта

● Высокие требования АС финансового сектора: проводилась миграция системы общенационального масштаба, находящейся в эксплуатации без возможности остановки сервисов. Целевое решение должно обеспечивать высокую скорость выполнения различных операций. Кроме скорости, как регулятором, так и бизнесом, предъявляются также жесткие требования к надежности и безопасности этих систем — любой сбой может значительно повлиять на показатели банка и способность осуществлять его основную деятельность.

● Техническая сложность: необходимо было обеспечить параллельную работу старой (Oracle) и новой (российский стек) систем с постоянной синхронизацией данных через каскадную репликацию.

● Экстремальные нагрузки: требовалось протестировать систему не только на стандартных пиках, но и на нагрузках, в 3 раза их превышающих, характерных для закрытия операционных дней и предпраздничных периодов.

● Человеческий фактор: в процессе тестирования было задействовано до пяти тысяч сотрудников банка, которые в реальном времени проверяли работу новых функций.

● Проблема обновлений: Сложившиеся ранее принципы работы ПО АБС на Oracle, и принципы доставки обновлений и модернизаций кода, включая модули для работы СУБД, не подходили под целевые условия частых запусков тестирования. Команды Газпромбанк и Скала^р организовали работу так, чтобы обновления ПО всех вендоров внедрялись в тестовый контур непрерывно и сопровождались методическими материалами для всех команд обеспечения целостности АБС-решения. Эти совместные действия помогли сократить срок ожидания обновлений (в части каскадной конфигурации) Машин МБД.П с пяти суток до нескольких часов.

Критерии выбора решения

● Возможность реализации каскадной репликации с базы данных Oracle.

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

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

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

Решение: комплексный подход на базе ПАК Скала^р

Уникальность проекта заключалась в необходимости провести миграцию в экстремально сжатые сроки в рабочие дни 24/7 и без остановки основных бизнес-процессов банка. Подготовка к непосредственному процессу миграции заняла около двух лет. С учетом логистики, обновления аппаратной части и модернизации программной части так, чтобы все команды — вендоров и Заказчика, — куда входит в общей сложности более чем 5000 ИТ-специалистов, были сосредоточены на общем результате запуска ядра АБС Газпромбанка в назначенный срок.

Новое ПО для тестирования отказоустойчивости ядра экосистемы ПАК АБС и машины баз данных МБД.П

Одной из сложностей проекта стало тестирование системы на способность выдерживать продолжительный горизонт транзакций — исключительно высокий и продолжительный объем операций, неравномерные, скачкообразные нагрузки, которые возникают в определенные операционные дни. Например, в предпраздничный период — резкие всплески количества платежей, когда множество предприятий одновременно начинают их закрывать. Отчетные периоды и пиковые часы нагрузки выгрузки информации из OLTP баз данных в OLAP-системы для формирования отчетов для регулятора, чтобы можно было принимать решения по ключевым параметрам макроэкономики с наибольшей эффективностью по сравнению с скоростью выгрузки предыдущих систем на Oracle.

Смоделировать подобный сценарий в тестовой лаборатории — крайне сложная задача. Поэтому команда ГПБ совместно с партнерами разработали специальное ПО, а также подобрали периоды максимальной финансовой активности, чтобы поэтапно запускать и наращивать нагрузку на систему в реальных условиях. В этапах тестирования участвовали несколько тысяч сотрудников банка. Это позволило проверить, способна ли система не только выдержать кратковременный всплеск, но и стабильно работать под длительной высокой нагрузкой в течение всего операционного дня, обрабатывая пиковые объемы транзакций клиентов банка без снижения показателей аппаратной инфраструктуры решений от Скала^р.

В результате система не только успешно справилась с нагрузкой, но и продемонстрировала запас производительности для непредсказуемых пиков даже при тестировании сценариев отказоустойчивости. Это стало убедительным подтверждением надежности программно-аппаратного комплекса в промышленной эксплуатации при максимальных нагрузках отчетных периодов и праздничных дней.

Возможность конфигурации каскадной репликации с Oracle и ускорение резервного копирования

Скорость резервного копирования удалось увеличить в 6 раз благодаря архитектурным решениям модуля резервного копирования в Машине Скала^р МБД.П. Применение технологии СУБД Postgres Pro CFS (компрессия блоков данных СУБД) позволило ускорить вычислительные операции для АБС и сократить объем хранимых данных на дисковой подсистеме, что в результате увеличило скорость как резервного копирования, так и восстановления базы данных.

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

Задача решалась совместными усилиями Группы Rubytech, всех команд банка, вендоров, чьи ИТ-решения присутствуют в качестве компонентов ПАК МБД.П, и специалистов ЦФТ. Такой подход позволил уверенно и без простоев запустить весь комплекс на импортозамещающих технологиях.

Новая система из актуальных комплектующих

Таким образом, основной сложностью стала не конфигурация отдельных машин, а организация работы между шестью Машинами Баз Данных Скала^р МБД.П, которые должны были работать бесперебойно в тестовом и предпродуктивном контурах со всеми функциями промышленного решения СУБД Postgres Pro.

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

Возможность обновления Машины по компонентам для тестирования для ускорения релизных процессов

Изначальный процесс сборки и обновления Машин вручную занимал от 8 до 16 часов на один узел, что делало задачу практически невыполнимой в требуемые сроки. Отсутствие стандартизированной документации на новые Российские продукты и зависимость от прошлого опыта Oracle усложняли процесс миграции, а принцип отсутствия доступа к интернету на площадках исключал возможность оперативного поиска решений. Для ускорения и стандартизации процессов была расширена документация и внедрено автоматизированное обновление через ПО «Геном быстрое развертывание».

Результат

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

Современная банковская ИТ-система, как правило, состоит из трех ключевых слоев — клиент (приложение, которое взаимодействует с пользователем), сервер приложений и сервер баз данных. Наиболее критичными для работы банка являются последние два. Как показывает практика, использование разных решений для слоя приложений и слоя БД не всегда является лучшим выбором с точки зрения как совместимости, так и гарантий долгосрочной совместной работы. ПАК Скала^р и постулаты инфраструктурного подхода замены рассыпных комплексов на Машины, позволяют заранее убедиться, что эти два слоя хорошо «склеены» и работают совместно надежно, поддержка осуществляется из одного окна и есть предсказуемый цикл развития решения. Таким образом, реализация проекта в Газпромбанк позволила подтвердить, что решение от одного производителя (Скала^р) закрывает потребность банка (даже такого крупного как ГПБ) в обеспечении технологической независимости критических систем силами Российских инженеров-разработчиков Машин.