Привет, Хабр! Меня зовут Денис Антонов, я работаю SRE‑инженером и менеджером системы на платформе IPS (Investment Platform Solutions) в Блоке ИТ‑развития Инвестиционного бизнеса РСХБ‑Интех (дочерняя технологическая компания Россельхозбанка). Совместно с коллегами мы выстраиваем качественные процессы сопровождения и обновляем системы сервисов, чтобы они работали стабильно, исправно, и чтобы в случае поломки на исправление проблемы уходило минимальное количество времени и трудозатрат. Сегодня расскажу о технологическом стеке нашей IPS платформы: составных модулях и ключевых технологиях, а также об архитектуре и назначении одного из базовых модулей (аудит), о схеме работы и ключевых метриках технического и бизнес‑мониторинга, процессе подключения и траблшутинга и не только.

IPS (Investment Platform Solutions) — единая технологическая платформа для инвестиционного бизнеса, на которой разрабатываются и устанавливаются системы и сервисы, позволяющие бизнесу проще и конструктивнее подходить к решению различных задач.

Решение включает в себя сервисы, уже работающие в промышленном контуре: аудит, справочники, отчеты, уведомления, ФРМ (Фабрика рабочих мест, отдельное UI‑пространство) и различные интеграции. На изображении с составом решения (ниже) в левом верхнем углу можно увидеть UI‑модули, которые представляют собой страницы, куда заходят непосредственно сотрудники банка и работают с подключенными сервисами по различным ролевым моделям. Внешне это обычные web‑страницы, но внутри работа может проходить как с бэкэндом, так и с фронтендом.

Функциональная часть IPS — это продуктовая фабрика платформы, где расположены сами сервисы и системы. В техстек платформы входят Java, Kubernetes, Kafka и не только.

Аудит мониторинг: на данный момент сервис больше выглядит как бизнес‑оповещение, которое проходит через Elasticsearch и Opensearch в Kibana, и где можно в виде дашбордов мониторинга предложить коллегам по бизнесу отслеживать сообщения в самой системе и показатели в режиме реального времени.

Фабрика рабочих мест показана на схеме в виде UI‑пространства с различными сервисами, при помощи которых можно производить операции по инвестициям, банковским транзакциям и так далее. У нас единообразный UI для всех рабочих мест у сотрудников. Основа одна и та же, только в зависимости от выданных прав добавляются те или иные окошки с функционалом. Интеграционные сервисы — это как сервисы Kafka, доставляющие сообщения между всеми модулями.

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

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

Перейти с больших тяжелых легаси систем нас вынудило несколько причин:

• непосредственно тяжесть самих систем;

• долгие сроки выхода в релиз;

• отказоустойчивость, не позволяющая проводить доработки и нововведения в режиме реального времени;

• высокая стоимость;

• низкий уровень автоматизации CI/CD процессов, которые достаточно тяжело конфигурировать.

В наше время огромное количество систем уже переводят на микросервисную архитектуру, и здесь есть множество различных плюсов:

• возможность проведения изменений/дополнений отдельных подсистем, не затрагивая всю систему в целом, то есть отдельно от общей архитектуры и не затрагивая функциональные части основной системы;

• детализированный CI/CD‑процесс, в котором мы можем распределить, куда и как выпускать релизы;

• детализация информации по журналированию и аудиту;

• низкая стоимость, поскольку не нужно обслуживать всю коробку, только отдельные части;

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

Ниже приведен пример событийной архитектуры. Обмен сообщениями между сервисами проходит через Kafka — отличное интеграционное решение, которое сейчас повсеместно используется, в том числе у нас в РСХБ‑Интех. Kafka позволяет работать нелинейно. Мы одновременно используем это решение и для своих целей, и предоставляем как сервис коллегам. То есть коллеги через нас могут подключиться к Kafka. Также решение обладает масштабируемостью. Чтобы горизонтально масштабировать Kafka, не нужно каждый раз его куда‑то переносить. Решение достаточно легко масштабируется в рамках своих ресурсов. Нам нужно только добавлять ресурсы, и тогда Kafka можно будет использовать и для больших целей.

Расскажу еще про пару полезных решений, используемых в нашей IPS.

Мы используем debezium чтобы узнавать об изменениях в базе данных (БД) в режиме реального времени. Debezium считывает изменения в БД и отгружает данные в топики кафки. Этот небольшой сервис, к примеру, показывает изменения в БД по котировкам, и коллеги в режиме реального времени все эти изменения увидят.

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

Приведу еще один пример — архитектура сервиса аудита, который сейчас у нас работает с использованием двух наших самописных сервисов. В правой части схемы можно увидеть непосредственно сервисы, различные модули, которые передают информацию в виде сообщений. В середине блок с Partition — это Kafka. Audit elastic и Audit postgre — два самописных сервиса на Java, написанных нашими коллегами в РСХБ‑Интех. Они занимаются перекладкой информации в ElasticSearch и OpenSearch, на которые мы сейчас переходим. В дальнейшем мы можем наблюдать это в Kibana. Одновременно эти же сообщения перекладываются в PostgeSQL.

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

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

Во фронте мы используем различные языки программирования: Java, C# и не только. Основным языком для фронтенда является TypeScript 5 . На бэкэнде основной язык у нас это Java 17. Также используется обширно Kubernetes, на котором у нас все крутится, что позволяет выстроить отказоустойчивый кластер, в котором нет необходимости тушить сервисы и системы и который достаточно легко управляется.
При перезагрузке какого‑либо сервиса мы не будем сталкиваться с постоянными отказами.

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

У нас очень большие планы на использование микросервисной архитектуры по целому ряду причин:

• Отказоустойчивость

• Безопасность и быстрые файловые интеграции

• Общие виджеты и ролевая модель

• Аудит всех систем в одном месте

• Адаптация легаси систем в новый ландшафт

• Интеграция новых сервисов в один запрос в джире

РСХБ начал уходить от легаси систем на микросервисную архитектуру и писать свои легаси системы. Мне удалось попасть на такую платформу, где с нуля полностью пишется вся архитектура.

В промышленном контуре IPS находится все необходимое по CI/CD процессам, по раскатке через технологию Ansible. Мы используем как Kubernetes, так и отдельно стоящие хосты, на которых крутятся интеграционные сервисы типа Kafka, MINIO и так далее. Мы их тоже обновляем и предоставляем как сервисы, соответственно, нам необходима технология Ansible, чтобы грамотно проводить релизы и CI/CD процессы. Kibana используется для отслеживания процессов журналирования. Все это, как полагается, протекает по контурам: тестовые, предпрод, продакшен с готовой системой.

Мониторинг осуществляется на системе ZABBIX. Отличное решение для текущих реалий, помогающее отражать информацию от всех систем и сервисов в режиме реального времени. Оповещения приходят на почту, в Telegram, а вскоре будут приходить и в ЦОС (Цифровой офис сотрудника) — наше собственное приложение для сотрудников, представляющее собой единое рабочее место с набором сервисов: календарь, почта, мессенджер, голосовой канал и всевозможные сервисы, в том числе для общения с техподдержкой. Оповещения о проблемах приходят за считанные секунды. И, например, если мне не пришло оповещение, что все в порядке, я начинаю работы по отладке системы. Если оповещение пришло, все отлично, работаем дальше.

Кроме ZABBIX для мониторинга мы используем Grafana. Она нужна для отслеживания работы Kubernetes и работает непосредственно с Prometheus.

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

Напоследок скажу, что я долгое время уже работаю с журналированием и сопровождением. Я заметил, что огромное количество времени тратиться на определение причин неполадки системы при возникновении инцидента или проблемы. Сейчас мы с коллегами внедряем оповещения для инженеров — уникальные коды на каждую обработку, проверку внутри самого кода. Есть какой‑то блок проверки, дальше идет информативность в info, error или warm, и внутри события есть уникальный код, который будет показывать при предоставлении информации о разработке в какой части кода произошла проблема. На предыдущих местах работы я столкнулся с тем, что этих кодов не было, и когда приходят 3–4 миллиона оповещений по 401, и все это в разных частях кода, абсолютно непонятно, что именно сбоит.

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