Автоматизация рутины в финтехе: опыт Росбанка

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

Как и любой финтех, Росбанк уже не просто банк, а целая сеть связанных и не очень услуг, продуктов и сервисов. Большинство из них развёрнуты в сторону клиентов, но есть и те, что смотрят в светлые глаза сотрудников IT-департамента. Про них сегодня и пойдёт речь. А точнее, про команду автоматизации инфраструктурных задач и их основной продукт — внутренний портал MyGTSSpace.

Что такое MyGTSSpace

Разработка любого IT-продукта в Росбанке включает в себя заказ и настройку серверов, баз данных, а также регистрацию явок, паролей и сертификатов. Эти процессы находятся в ведении разных подразделений — хоть процедура и давно вошла в привычку, но растягивалась на 2–3 дня. Сейчас это время удалось сократить до нескольких минут.

И всё благодаря упомянутому порталу MyGTSSpace. Отдел маркетинга к неймингу не подключали, зато название верно отражает суть: у группы Societe Generale, частью которой является Росбанк, есть сервис-центр для IT-инфраструктуры, который называется Global Technology Services (GTS). Соответственно, MyGTSSpace — это некое пространство в GTS, которое позволяет заказать сервер, базу и другие штуки, нужные для создания и развития продукта.

Код сервисов и портала хранится, собирается и деплоится через GitLab. Каждый сервис упакован в размещённый на OpenShift контейнер и подключается к порталу через собственный API. Внутренние клиенты могут пользоваться сервисами как через веб-интерфейс, так и через API.

Когда сервис написан не Росбанком (то есть когда нужно подключить к порталу коробочное решение), используется уже доступный API или библиотека Python.

Команда автоматизации инфраструктурных задач была создана с одной целью — упростить рутину других IT-отделов. Заранее уточню, что команда работает только на внутренние структуры банка, так что «заказчики» — это сотрудники Росбанка.

В этой статье я расскажу про четыре сервиса, которые представлены на портале MyGTSSpace: PKIaaS, PgaaS, MessageFinder, LBaaS. По факту сервисов, конечно, больше, но эти самые популярные.

PKIaaS — Public Key Infrastructure as a Service

В банке SSL-сертификаты приходится использовать как во внешнем контуре, так и в локальной сети без выхода в интернет — это не паранойя, а стандарт безопасности. Поэтому получение и продление сертификатов для наших айтишников обычное дело.

Если сравнивать создание безопасной среды с другими процессами в IT-инфраструктуре банка, то получится, что требования безопасности там самые жёсткие (сюрприз!). И это, с одной стороны, затягивает сроки, а с другой — создаёт препятствия для автоматизации, исключая из арсенала недостаточно безопасные инструменты. Например, существующие автоматические службы выпуска сертификатов, такие как Let’s Encrypt.

Группа Societe Generale использует стандарт безопасности, при котором подписант сертификата ни при каких обстоятельствах не должен попасть в конфликт интересов. Проще говоря, подписант обязан быть своим. И такой у Societe Generale есть — это UNIPASS.

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

Сертификат можно генерировать как полностью на стороне UNIPASS, так и с использованием CSR-файла. Для внутренних сервисов используется упрощённый вариант, так как мы и так владеем и сертификатом, и ключом. Вариант с CSR используется только в особых случаях по просьбе клиента или партнёра.

Таким образом, если пару лет назад получение сертификата UNIPASS, подписанного Societe Generale, занимало примерно день, то теперь время ожидания сократилось до минуты.

PgaaS — PostgreSQL as a Service

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

Раньше получение БД под новые разработки было на совести DBA. Инженер по заявке заказывал виртуальную машину, разворачивал на ней СУБД, создавал таблицы и доступы для заказчика. Пока приходило 1–2 тикета в месяц, всё было хорошо. Но со временем поток заявок увеличился, а их выполнение по времени стало конкурировать с основными обязанностями инженеров. Дополнительно нанимать дорогих специалистов на такую шаблонную работу нерационально, поэтому решили автоматизировать.

Что получилось в результате: клиент заходит на портал, указывает требуемые параметры БД и на выходе получает отдельную виртуальную машину с настроенной PostgreSQL. Доступ выдаётся только к PostgreSQL и панели pgAdmin, так что вносить изменения в структуру БД разработчик может самостоятельно (добавлять пользователей, создавать таблицы, выдавать права).

DBA из процесса исключены полностью, а скорость отработки заявок при этом ещё и выросла: пользователь получает БД в течение 10 минут. Каждую неделю через портал создаётся пять-шесть баз данных.

MessageFinder

Сервис MessageFinder — это унифицированный поисковик сообщений в интеграционной шине. Мы используем IBM Integration Bus (IIB). Интеграционная шина, или ESB, это специальное ПО для организации взаимодействия совершенно разных информационных систем через унифицированный интерфейс.

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

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

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

В Росбанке все поступающие сообщения и этапы их жизни в шине дополнительно сохраняются в БД Oracle. Такая избыточность просто необходима для разбора причин и последствий сбоев, которые иногда (хоть и крайне редко) возникают. По идее, администратор шины SQL-запросом может найти любые сообщения для любого подразделения примерно за 5–10 минут. Но проектов много и ждать столько каждый раз — непозволительно долго.

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

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

Вот несколько примеров использования этого сервиса:

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

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

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

LBaaS — Load Balancer as a Service

Как и в случае с PgaaS, название говорит само за себя. Это служба для упрощения публикации внутренних сервисов с возможностью балансировки этого трафика. Будь то один сервер или группа серверов с каким-то приложением на них.

LBaaS в своей работе манипулирует несколькими службами:

• балансировщик на базе NetScaler;

• сервис для управления DNS-записями;

• сервис PKIaaS, о котором было упомянуто выше;

• различное сетевое оборудование, на котором нужно предусмотреть корректные ACL и маршруты.

LBaaS создаёт доменное имя, запрашивает сертификат у PKIaaS и прописывает его в настройках инстанса в NetScaler. Затем регистрирует группы сервисов для распределения между ними нагрузки, добавляет, если необходимо, ACL и маршруты на сетевое оборудование. Все настройки делаются в соответствии с политиками безопасности банка.

Каждая балансировка сразу после создания появляется в личном кабинете заказчика. По сервису генерируются отчёты о работе, которые доступны онлайн и заказчику, и владельцу балансируемого сервиса, если это разные люди.

И, конечно же, в настройки балансировщиков можно вносить изменения:

• добавлять/удалять узлы;

• добавлять/удалять сертификаты;

• менять стратегию балансировки;

• управлять так называемыми «мониторами» — правилами распределения нагрузки и правилами определения состояния конкретного узла.

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

LBaaS можно считать примером удачного переиспользования сервисов MyGTSSpace: он не выполняет действия напрямую, а обращается к другим, более узким сервисам. Например, к PKIaaS.

Что хотелось бы сказать в конце

Мы довольны проделанной работой. Чтобы знать, насколько востребован каждый сервис, мы собираем статистику.

Перед началом разработки мы провели замер времени, которое сотрудник тратит на рутинные действия. Например, в среднем на человека приходится по 9 заявок на выпуск сертификата в день, вручную каждая занимала бы около 10 минут. Получается, что один только PKlaaS экономит более 7 рабочих часов в неделю каждому специалисту.

Также мы проводим опросы по качеству сервисов и собираем фидбэк.

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