Зачем Газпромбанку система управления взаимодействием и как ее улучшают

Зачем в Газпромбанке нужна СУВ

СУВ создает единое информационное пространство. Через нее события и связанные с ними данные передаются между системами.

Например, платежи клиентов банка через АС Клиент-Банк поставляются в сервис расчетно-кассового обслуживания (РКО), а затем исполняются в Расчетном Центре (РЦ). СУВ обеспечивает взаимодействие между ними. Другой пример: информация о клиенте банка распространяется из единого справочника клиентов (ЕСК) по более чем 30 системам-подписчикам.

СУВ выполняет свои задачи благодаря шаблонам интеграции и ролевой модели — правилам обмена, которые настроены для взаимодействия систем. В СУВ таких правил больше 130. Шаблоны системы открывают доступ к 50 типам объектов: все виды платежных документов, реестры, нотификации, клиенты, счета, специализированные вызовы удаленных процедур, выписки. Каждый день через СУВ проходит около 8 млн сообщений. При пиковой нагрузке — 11 млн.

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

СУВ разделена между двумя центрами обработки данных (ЦОД). Если один из них откажет, система продолжит работать. Но задержка обработки сообщений иногда случается. Суммарно за год набирается до 30 минут — это среднее время замедления или прерывания обработки за 12 лет работы системы. Последняя версия СУВ не останавливалась с мая 2021 года.

Снизить время простоя практически до нуля позволила техническая архитектура СУВ. Она построена на принципах отказоустойчивости (кластер) и катастрофоустойчивости (ЦОДы). Текущие ресурсы СУВ в среднем способны выдержать нагрузку до 20 миллионов сообщений, а на пике производительности — до 28 миллионов. И это не предел. Если добавить еще один ЦОД, пропускная мощность и устойчивость системы увеличатся.

Как работает СУВ

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

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

Читай также: Нервная система Газпромбанка: нюансы работы сервисно-интеграционной платформы

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

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

Ключи SSL и КриптоПро выдаются на каждую систему удостоверяющим центром Газпромбанка. Получить их может только назначенный распоряжением администратор системы.

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

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

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

Читай также: Со скоростью «Формулы-1»: как в Газпромбанке создали единую банковскую систему

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

Система-участник подключается к ресурсам СУВ через индивидуальный Адаптер. К очередной системе его можно написать с нуля, однако СУВ предлагает использовать готовый фреймворк — Универсальный Адаптер (УА). Его цель — стандартизировать процесс подключения, ускорить и облегчить разработчику задачу по созданию полноценной функциональности системы.

В типовом Универсальном Адаптере «из коробки» уже находятся модули подключения, мониторинга, безопасности, работы с файловым обменом и рабочее место администратора с GUI-интерфейсами.

Помимо этих модулей, архитектура УА обеспечивает простоту обновления шаблонов сообщений (так называемый канонический формат данных, XSD-схема), когда выходят новые версии схем обмена. Поэтому наличие Универсального Адаптера снижает порог вхождения новых участников до популярных и стандартных технологий, которые доступны большинству разработчиков.

Как разрабатывали СУВ

СУВ разрабатывалась на основе опыта команды, которая занималась задачами практической интеграции с 2005 года. В 2009 году в банке придумали и описали концепцию интеграции, оформили документы с требованиями к функциям СУВ и выбрали подрядчика для реализации. Так был создан рабочий прототип СУВ-1.

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

Новые перспективы позволили команде продолжить работу над улучшенной версией СУВ-2. В 2010 году ее протестировали, запустили и интегрировали с четырьмя самыми крупными банковскими системами, которые обслуживали корпоративных клиентов. СУВ-2 проработала до 2014 года. В нее постепенно добавляли всё больше шаблонов процессов и форматов сообщений, оптимизировали ее работу и пропускную способность.

На момент запуска системы основными клиентами Газпромбанка были другие банки, крупные корпорации и холдинги. Требования к качеству интеграционных процессов оставались высокими, но объем передаваемой информации через СУВ был относительно невелик. Со временем появилось больше клиентов — частных предпринимателей и физических лиц. Выросло количество документов, автоматизированных систем, типов сквозных процессов, которые поддерживались в СУВ. Объемы передаваемой информации увеличились. Изначальная архитектура СУВ-2 предусматривала непрерывный и надежный обмен сообщениями до 10 миллионов транзакций в сутки. Понимая, что банку нужны новые возможности, в 2018 году руководство IT приняло решение дальше развивать систему в виде отдельного проекта — СУВ-3.

Сейчас именно она работает в Газпромбанке и отличается от предыдущих частью новых технологий. И хотя в основе архитектуры остались серверы и ПО IBM WebSphere, тем не менее сотрудники переработали структуру хранения данных, обработчики сообщений, процессы балансировки и компенсации сбоев. Средства журналирования и мониторинга заменили на более современные компоненты (Kafka, ElasticSearch, Prometheus).

Работы по развертыванию, тестированию, миграции данных и переводу СУВ-3 в промышленную эксплуатацию поддерживали идеями Первый Вице-Президент Дмитрий Назипов и Исполнительный Вице-Президент Игорь Ашметков. Еще они облегчили задачу на уровне финансирования, согласования планов и управления ресурсами.

Как будет развиваться СУВ

Сейчас команда фокусируется на замене продуктов IBM. Сотрудники банка прорабатывают концепцию миграции. Главная задача — перенести все компоненты системы так, чтобы обеспечить полную совместимость и максимально облегчить переход для остальных участников.

Запас производительности СУВ позволяет ничего не менять в архитектуре 5–7 лет. Это время команда собирается использовать, чтобы проработать обновленную концепцию и создать очередную версию СУВ на базе open-source и отечественных продуктов.

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

Команда разработки и поддержки СУВ расширяется. Если вы хотите работать с системой, у которой нет аналогов по нагрузке и производительности, посмотрите вакансии.