Тестирование в финтехе: на гребне волны импортозамещения
Привет, коллеги и любопытствующие читатели! Меня зовут Андрей Ахметов, я главный инженер ЦК-тестирования в РСХБ-Интех.
В прошлый раз мы с вами говорили про то, какие экзотические баги можно встретить в тестировании и как с ними бороться. Сегодня я расскажу в целом про тестирование в финтехе в контексте волны импортозамещения.
Финтех — это компании, которые стремятся сделать жизнь клиентов комфортнее, улучшая и делая удобным повседневное обращение с деньгами. То есть финтех — это банки, деньги, клиенты и их взаимодействие. И у этой сферы есть две ипостаси.
Для обычных клиентов финтех неразрывно связан с банками. Современный банк для клиента — это возможность совершить платеж или перевод в любое время дня и ночи. Это круглосуточная поддержка, безопасность и удобство. Весь спектр услуг банка размещается буквально на ладони, в мобильном приложении или на экране компьютера. И для банка каждая минута промедления — это тысячи неуспешных операций и большие денежные потери. Поэтому важно, чтобы все работало без ошибок. И вот тут проявляется вторая ипостась финтеха.
Чтобы банк работал бесперебойно, нужен труд большого количества людей, как сотрудников самого банка, так и нас. А мы — это те, кто создает, обслуживает и тестирует ПО, то есть делает возможной ту самую магию круглосуточных переводов и платежей. Как же видим банк мы? Примерно так:
Финтех — это чрезвычайно динамично развивающаяся отрасль, и нам приходится работать с тем, что было заложено много лет назад, с тем, что было добавлено позже, и тем, что нужно срочно вводить прямо сейчас.
В РСХБ-ИНТЕХ есть много различных команд разработчиков и обслуживания систем. Есть команда ДБО (Дистанционное банковское обслуживание). Они занимаются фронтальной частью, с которой взаимодействуют клиенты. Есть команда по разработке и поддержке системы для ведения бухучета, они сводят дебет с кредитом. Есть команда процессингового центра. Цель их системы — обеспечить достоверность данных авторизации при работе с банковскими картами и точность перемещения средств. Есть команда интеграционной платформы, которая маршрутизирует сообщения и помогает системам найти общий язык, и многие другие.
Когда-то я попал в самую сердцевину этих хитросплетений, в команду проекта ЕСПП — Единой системы приема платежей. Сейчас это масштабный платежный хаб, нацеленный на обработку запросов от фронтальных систем банка — это точки обслуживания, кассовое ПО, банкоматы, терминалы, мобильные приложения, интернет-банки и в целом все доступные пользователю каналы.
История ЕСПП началась в 2017 году. Тогда это была маленькая система, по сути коробочное решение с платежами через кассу и банкоматы, которое мы купили у вендора и настроили под себя. Были стандартные взаимодействия, настроенные обработчики, логирование велось по старинке — файлы в папках на сервере.
Все было очень лампово. Было много времени, чтобы узнавать, как что работает, пробовать разные способы тестирования. Но время-то шло, и развивался интернет-банкинг, с ним развивался мобильный банкинг, а, соответственно, росла и расширялась наша система, добавлялись новые шлюзы. В процессе роста, с появлением новых вариантов платежей и ростом объемов транзакций появились и определенные вызовы для нас.
Возникли новые интеграции с разными системами, а все это новые цепочки взаимодействий. И все это нужно эффективно тестировать. Тут есть одна наша особенность. ЕСПП относится к middle-системам, а взаимодействие с middle-системой несколько отличается от стандартной схемы front-back.
Например, есть система ДБО, которая относится к фронтальной части, и когда коллеги тестируют новый интерфейс, они имеют основной целью убедиться, что нужный элемент интерфейса появляется в нужное время. В процессе оплаты их больше волнует дизайн или верстка, скроллинг.
Коллеги из АБС (автоматизированная банковская система) относятся к back-системе. И им важно, чтобы от нас пришли корректные счета, чтобы мы правильно сформировали бухгалтерские проводки. Мы их тоже формируем. Также им важна скорость, с которой их система отвечает на запросы, ведь они обрабатывают тысячи обращений в минуту.
Каждый из них живет в своем мире, но постоянно взаимодействует с соседними системами и между собой. Каким образом? Посредством нас. ЕСПП связывает front и back-end. И нам важно, чтобы ДБО корректно собрали и передали параметры, с которыми мы позже пойдем в АБС. В свою очередь, нам важно, чтобы АБС вовремя ответила, потому что нам нужно будет передавать эти параметры дальше по цепочке. Чтобы не было ошибок при взаимодействии.
В целом на схеме выглядит все не так уж и сложно, если не учитывать того, что у нас есть собственная база данных, собственная проверка, дополнительная проверка клиентов и то, что наросло на систему за годы. А также тот факт, что мы обращаемся к системам за пределами банка. Это платежные интеграторы, такие как ГИС ЖКХ, системы Город, НКО от Сбербанка.
В один момент в наш уютный мир вторгся СБП. У них жесткие тайм-ауты и требования к взаимодействию. При этом нам нужно помнить про безопасность и тот факт, что мы тестируем банковское ПО, а банки зависят от регуляторов. А это значит, что необходимо выполнять требования законодательства. Есть четкие, иногда сжатые сроки, и это принуждает нас успевать все сделать в режиме дедлайна.
С 2017 года мы сильно выросли, и с ростом системы стало очевидно, что стандартные модули от вендора не покрывают потребности банка. Началась кастомизация, и на каждую новую регуляцию или тип платежа нам требовалось создание новых кастомных модулей. Это новые шлюзы, новые обработчики, это костыли, новые костыли к старым шлюзам и обработчикам. И все это неизбежно привело к увеличению сложности системы.
Большой проблемой стало то, что логи разрознены. Часть логируется на серверах, часть в контейнерах, часть взаимодействия можно отслеживать через kibana. Все это усложняет диагностику проблемы, особенно в условиях высоконагруженной системы, которой ЕСПП стала после подключения к НСПК (Национальная Система Платежных Карт и бренд СБП под которым ее все знают). Вот в таком состоянии мы пришли к 2024 году, когда нам нужно завершить процесс импортозамещения.
Регулятор не дремлет, и импортозамещение надо завершать точно в срок и быстро. Мы сделали выбор перейти на новое решение, которое позволит унифицировать подход к логированию и мониторингу. У нас была на тот момент коробка, которую мы много лет допиливали и допиливаем все еще. И в ней множество кастомных модулей, которые мы не можем попросить у вендора переработать. Точнее, мы можем, но это слишком дорого.
Также у нас возникли сложности с количеством взаимодействий, так как логи и взаимодействия раскиданы по разным местам. Я уже говорил, что логи нашей системы на сервере, их можно посмотреть, открыв руками. Логи интеграции с соседними системами можно посмотреть в Kibana. Это еще один портал. Логи взаимодействия с НСПК при оплате через СБП можно смотреть в докере. И посмотреть их можно, открыв лог докер-контейнера. И в этом всем не так легко разобраться. Порой даже более опытные коллеги не сразу понимают, что произошло. Я уж молчу про новых сотрудников.
Погружение в нашу систему очень затянуто. И в процессе поиска дефекта нам многое приходится держать в голове. И это хоть и развивает, но утомительно. А процесс импортозамещения нужно было завершить к ноябрю этого года. И раз выбора все равно нет, можно ли сделать процесс работы удобным и эффективным?
Мы подумали, чего бы мы глобально хотели. В первую очередь — чтобы обновленную версию модулей можно было быстро установить и настроить без танцев с бубном или множества дополнительных настроек. Иногда бывает в процессе тестирования, что кто-нибудь откатил версию модуля, но не успел об этом сообщить. И вот начинаешь проверять и думаешь, что все работает прекрасно, смотришь в логи, а модуль работает неправильно. Начинаешь копать глубже, и тут оказывается, что это просто не та версия. Поэтому хотелось бы упростить процесс контроля версии и отслеживания изменений в системе.
Также было бы здорово, если бы настройка и раскатка проходила в автоматическом режиме, ну или хотя бы в полуавтоматическом, чтобы минимизировать количество ручных операций. И хотелось бы, чтобы интеграцию можно было более четко и уверенно прослеживать, причем так, чтобы было видно весь путь сообщения от одной системы к другой. И все это в одном приложении или на одном портале. Еще чтобы все это можно было удобно анализировать.
В процессе решения этих задач мы огляделись и поняли, что у нас в банке есть платформа, которая разрабатывается еще с 2020 года — App.Farm. Целью ее создания было стимулирование собственной разработки в РСХБ. Эта платформа направлена на минимизацию зависимости от вендоров и аутсорсинга, на развитие внутренних компетенций, на создание условий для разработчиков, а еще для того, чтобы сократить время на тестирование, разработку и развертку приложения. Что важнее для меня как для тестировщика, все это приводит к облегчению и ускорению процесса поиска дефектов.
В App.Farm есть все, что нам нужно: централизованное логирование, трассировка запросов, автоматизация тестирования и деплоя. И все это возможно благодаря микросервисной архитектуре и использованию докер-контейнеров.
У нас в ЕСПП часть системы уже была представлена в виде микросервисов. Но тут появилась возможность все это масштабировать. А за счет чего? App.Farm — это PaaS или платформа как услуга. Это коробочный продукт для стандартизации процессов разработки и эксплуатации продукта в банке. И да, это опять коробка, но тут своя родная. App.Farm представляет собой единую неделимую систему, которая состоит из различных инфраструктурных компонентов. Эти компоненты инкапсулированы в саму платформу и не представляются как отдельные сервисы. Они работают вместе и нужны для обеспечения работы самой платформы.
И тут, наверное, главный плюс для нас — что App.Farm не предоставляет Kubernetes, Nexus, Vault, Elasticsearch или другие подобные компоненты как сервис. Вместо этого есть API самой платформы, за которым реализация может меняться на любую другую без необходимости уведомлять, договариваться или мигрировать системы, которые стали от этого зависеть напрямую. App.Farm построен на следующем стеке открытых решений: Kubernetes, GitLab, Open Search, Jaeger, Grafana, Istio, VictoriaMetrics, Kibana и других Open Source продуктов. Также есть инструменты собственной разработки. И, как я уже говорил, доступ ко всем этим решениям предоставлен через API.
Для удобства работы пользователей с приложениями и сервисами, размещенными в App.Farm, разработан информационный портал для управления сущностями платформы. И он используется разработчиками, архитекторами, тестировщиками, IT-менеджерами, инженерами систем банка для получения актуальной информации о полном состоянии своих сервисов и приложений, размещенных на платформе, а также об их интеграционных связях. Из вышеописанного стека нам в части тестирования полезны Jaeger, Kibana и Grafana. Использование комплекса из этих трех инструментов позволит нам получить полное представление о производительности системы на разных уровнях, таких как трассировка запросов, анализ логов и мониторинг ресурсов. Расскажу о каждом из инструментов немного подробнее.
В Jaeger трассировка запросов позволяет визуализировать пути запросов через систему. Можно отслеживать время их выполнения на каждом этапе. Также можно проводить анализ зависимости и прослеживать, какие сервисы взаимодействуют между собой, таким образом определяя, где возможны задержки и проблемы. Jaeger предоставляет данные о времени, проведенном в каждом сервисе, что позволяет выявить проблемы, связанные с медленными компонентами. А трассировка позволяет сравнивать производительность до и после внесения изменений в код.
Kibana позволяет собирать и анализировать логи приложения намного быстрее, чем если использовать простые текстовые файлы, информацию в которых нужно искать с помощью Ctrl-F. А можно создавать дашборды и графики, чтобы визуально представлять данные из логов, и по логам уже осуществлять удобный поиск. Kibana позволяет находить конкретные сообщения об ошибках или событиях по заранее настроенным ID, меткам или тегам. И все это экономит время при отладке и тестировании. Также есть возможность проанализировать, как изменения, такие как развертывание новой версии, влияют на логи, что также может указывать на проблему с новой функциональностью.
Grafana позволяет собирать и визуализировать метрики производительности в реальном времени, такие как загрузка процессора, использование памяти, задержки запросов и подобное. С Grafana можно отслеживать, как распределяется нагрузка между разными компонентами системы, можно создавать дашборды, комбинируя данные из разных источников, включая Jaeger и Kibana. И все это для того, чтобы получить целостное представление о производительности и состоянии системы во время тестирования. В Grafana можно создавать предупреждения, настраивать оповещения на основе определенных пороговых значений, что позволит заранее узнать о проблемах производительности или о том, что ресурсов недостаточно, а после, соответственно, оперативно отреагировать на них.
В качестве примера разберу работу с сервисом Jagger. В процессе тестирования у меня падает операция, и я знаю, что она обрабатывается в потоке DBO2-флоу. И я хочу посмотреть, как проходят по нему запросы.
Я выбираю в Jaeger DBO2 Flow. Ну, а так как в Jager можно отследить прохождение сообщений системы, по заранее настроенным меткам и тегам (Span_ID, Trace_ID, XD_Request_ID), то можно выбирать запросы, которые обрабатывались долго. Помимо прочего, это годится для сквозного тестирования, и будет удобнее тестировать нагрузку. Но сейчас я отберу 30 запросов, которые проходили дольше 5 секунд, сделаю выборку за последний час. Также можно настраивать кастомное время.
И вот выборка сгенерирована, и я вижу, что на графике он в правом верхнем углу. Время прохождения сообщения через сервис изображено схематично. Вижу внизу, что есть ошибки при обработке. Кликаю на графике самый верхний из трейсов, который больше 5 секунд.
И что я здесь вижу? Время начала трейса, общую длительность 5,79 секунд, длительность обработки, количество спанов, что бирюзовый adapter-dbo2 забрал сообщение из очереди. Он обработал его за 8,69 миллисекунды и передал в dbo2-flow, он коричневый. Dbo2-flow затратил на обработку в сумме примерно 13 миллисекунд и передал сообщение в адаптер ESPP, он желтый. И дальше сообщение обрабатывалось ESPP. Видно запрос DBO2/ESPP/Request, после чего сообщение попало в поток с ESPP/SendPaymentHubCommand. И там он долго обрабатывался, целых 753 миллисекунды. Это как раз мы и наши взаимодействия со смежными системами, как в банке, так и вовне.
И вот мы вернули ответ, уже ниже. Он попал в dbo2-flow, в коричневый. dbo2-flow его принял, и там сообщение застряло. Вот длинная коричневая полоса. Есть какая-то ошибка, для наглядности там красный восклицательный знак.
И далее dbo2-flow кинул сообщение в adapter-dbo2, адаптер вернул ответ. И так все потоки можно отслеживать. Меня же интересует момент, когда появилась ошибка, поэтому я кликаю момент возникновения ошибки, выделенный красным восклицательным знаком. Открывается более подробная информация. Вижу ошибку код 504. Это ошибка тайм-аута. То есть сервис не дождался ответа от вышестоящего сервера. А дальше я уже иду в логи, которые попадают в Kibana. Под ним Elasticsearch в качестве БД, а туда, в Kibana, логи сует Vector, как коллектор журналов. И все это анализирую. Это как пример.
Итак, после перехода в App.Farm нам станут доступны метрики, где можно будет смотреть нагрузку на контейнер. Но к этому моменту метрики должны быть уже встроены в модули. А как же их встроить? И тут мы подошли к нюансам процесса. До конца года осталось не так много времени, поэтому сейчас мы мигригуем в App.Farm наши собственные модули. Они написаны на C#, и в них мы можем встроить сразу нужные нам метрики, в частности, чтобы можно было видеть нагрузку на контейнеры или как быстро обрабатываются запросы.
Метрики можно будет смотреть в Grafana, и можно будет видеть, что за запросы, как быстро они обрабатывались, какие были ошибки, и можно будет отслеживать как общую статистику, так и помодульно.
Логирование тоже можно будет настроить. Это самая больная тема для нас. Мы все равно перерабатываем модули, а это отличная возможность сразу встроить нужные ID и метки. После у нас появится наконец-то удобный инструмент для наблюдения за тестированием. То есть сейчас это редкая возможность собрать удобную систему для тестирования прямо под себя, благо к этому все располагает.
Какая мораль этой истории?
Если у вас модульный монолит, то импортозамещение — это хорошо. Если вы спросите, есть ли минусы, да, наверное, есть. Как-то я спросил у руководителя App.Farm, как менять настройки, если все будет в контейнере? Он сказал, проблем нет, просто берешь, меняешь настройку, а потом пересобираешь контейнер. Говорит, если pipeline будет свободен, то это каких-то 5 минут. Мы привыкли к тому, что настройка меняется в нашей коробке просто одним кликом. Даже модуль обычно перегружать не нужно. Так что это было небольшим удивлением.
Но, к счастью, сразу же в процессе диалога я понял, что при переделывании модулей можно встроить API и через API менять настройку. И, в принципе, вот они плюсы и одновременно минусы. Это переделка.
Напоследок скажу, что дорогу осилит идущий. В этом году мы успеем закончить переход на открытые библиотеки и перенести часть наших модулей собственной разработки в App.Farm. А в следующем году нас будет ждать самое интересное — распиливание монолита. Наш слон боится выйти на этот мост, потому что мост выглядит очень ненадежно.
Но не бойтесь вступать на дорогу импортозамещения. Это может выглядеть сложно, будет неудобно в процессе, но это рост и неизбежное повышение эффективности в будущем. И вот тот же самый слон с такой же опаской переходит на другую сторону обрыва.
Для себя мы решили, что оборачивать сервис костылями не наш путь. Наш путь — искать максимально удобные решения, замещать ими неудобные устаревшие и переходить от вендорских решений к собственным разработкам, чтобы можно было легко управлять процессом.
