Егор Сычев, Senior Software Engineer: Глубокая модернизация финансовых приложений — требование времени

С необходимостью глубокой модернизации процесса онлайн-кредитования столкнулся один из системообразующих банков Казахстана. Разработкой новой архитектуры этого ключевого сервиса занимался Senior Software Engineer банка Егор Сычев. В эксклюзивном интервью он рассказал, как провести переезд с легаси-систем на новые в одной из крупнейших финансовых организаций СНГ, кратно повысив эффективность инфраструктуры и снизив нагрузку на серверы более чем в два раза.

𝓲

Фото: Личный архив Егора Сычева

— Егор, чем была вызвана необходимость в модернизации процесса оформления кредитов?

— В старой архитектуре интерфейс был тесно связан с серверной частью (бэкендом). Это означало, что практически каждое действие пользователя, переход на новый экран или даже раскрытие выпадающего списка, требовало отдельного обращения к бэкенду.Гид по российским системам PAM (Privileged Access Management) 88.9 т

Для клиента это выглядело как постоянные микро-задержки и визуальные «прогрузки» страниц. Система работала стабильно, но сам механизм взаимодействия с сервером стал узким местом при росте нагрузки.

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

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

— Ранее вы работали над приложением для оформления страховых полисов одной из крупнейших, согласно рейтингу^[1] Forbes за 2022 г., страховой компании Казахстана Jusan Garant, а также вы имели опыт разработки интернет-магазина. Удалось ли адаптировать и применить ваши лучшие практики и архитектурные решения из этих проектов при работе над банковским приложением?

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

— Как вы поделились, первые отзывы о модернизированном приложении исключительно положительные. Какие внедренные под вашим руководством изменения для пользователей стали самыми заметными?

— Сократилось время отклика, то есть, приложение стало быстро реагировать на запросы. Это особенно заметно при работе с медленным интернетом. Произошло это из-за сокращения сетевых запросов к серверам в 2,5 раза. Кроме того, миграция на современную платформу .Net позволила кардинально снизить потребление ресурсов на серверах. Новая архитектура требует меньше вычислительных мощностей для обработки того же числа пользователей. Отдельно отмечу работу с данными: нам удалось сократить количество обращений к базе данных в 3,7 раза. Вместе с другими оптимизациями это позволило существенно снизить нагрузку на базу данных и сократить потребность в «железе», обеспечив прямую экономию на инфраструктурных расходах.

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

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

В техническом плане модернизация заключалась в переписывании устаревшего приложения со стека ASP.NET MVC (.NET Framework 4.7) на ASP.NET Web API (.Net 6) и SPA-фронтенд на Vue. Мы внедрили качественное логирование и мониторинг и полностью переосмыслили проблемные участки системы. Это позволило устранить так называемые «плавающие баги» — ошибки, которые то появляются, то исчезают, и их сложнее всего отловить.

— Под вашим руководством модернизация приложения прошла в кратчайшие сроки. За счет чего?

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

— В ИТ-среде вы известны своим перфекционистким подходом. Были ли доработки у банковского приложения?

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

— Будучи сторонником философии Zero Incidents в ИТ, как вы добиваетесь снижения сбоев в создаваемых вами архитектурах?

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

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

— Приоритет реальных задач над теоретическими стандартами. Я убежден, что слепое следование общепринятым «лучшим практикам» — это ловушка, которая часто приводит к избыточной сложности или низкой производительности. Любой стандарт — это лишь инструмент, а не закон. Мой подход заключается в том, чтобы глубоко понимать логику процесса и не бояться нарушать каноны, если они становятся барьером для системы. Если что-то не получается, не надо пытаться залакировать проблему. В банковской сфере, где цена ошибки высока, полумеры недопустимы. «Технический долг» всегда возвращается с процентами — в виде сбоев и недовольных клиентов. Поэтому мой принцип — не косметический ремонт, а полная переработка. Сейчас этот подход и заложенная мной архитектура уже масштабируются на другие продукты, становясь стандартом качества в банке.

Автор: Дмитрий Архипов

Примечания