Маркетплейс для автолизинга: о чем не стоит забывать тем, кто запускает свой проект
Понимая перспективность цифровых каналов для привлечения клиентов, финансовые компании начали смотреть в сторону e-commerce и создавать уникальные для индустрии продукты. Многие из них полностью построены на современных онлайн-решениях и не предполагают участия менеджера в процедуре оформления сделки, что делает финансовый продукт доступнее и быстрее. О том, какие ошибки могут допустить разработчики при создании подобных сервисов и как это исправить, рассказывает Константин Абакумов, директор дивизиона технологического развития клиентских организаций Группы «Иннотех» (Холдинг Т1).
Содержание |
Как всё начиналось
По уровню цифровизации финтех-компании догоняют банковский сегмент: новые технологии активно внедряются, но пока еще не стали стандартом работы. Одно из решений, набирающих популярность в индустрии, — это сервис, который позволяет оказывать финансовые услуги в цифровом формате на всех этапах сделки: от выбора автомобиля до окончания действия договора.
Маркетплейс для автолизинга имеет удобный и понятный интерфейс. Его ключевой раздел — это каталог, в котором представлены автомобили от нескольких дилеров. В каждой продуктовой карточке есть подробное описание транспортного средства, технические характеристики и фотографии. Клиент регистрируется в личном кабинете на маркетплейсе, выбирает в каталоге понравившийся автомобиль и условия, после чего сервис формирует для него индивидуальное коммерческое предложение. Подписание и обмен документацией тоже происходит дистанционно — через ЭДО и с любых устройств (на смартфоне или компьютере). Единственное, что осталось в офлайне, — визит в дилерский центр за автомобилем.
В этому году Группа «Иннотех» внедрила маркетплейс в одной из крупнейших российских компаний, «подхватив» идею, которую изначально реализовывал другой вендор. На тот момент проекту было уже более двух лет, и стало понятно, что с текущим поставщиком быстро вывести продукт на рынок не получится. Поэтому бизнес искал нового технологического партнёра для реализации этой задачи.
Прежде чем приступить к проекту, мы провели его аудит: тщательно проанализировали ИТ-архитектуру платформы, качество кода, документацию, подходы к CI/CD (DevOps), а также информационную безопасность. Дополнительно проинтервьюировали ключевых разработчиков и ИТ-архитектора со стороны вендора, провели с ними сессию Q&A. И нашли несколько «узких мест» в разработке, которые влияют на производительность маркетплейса и на то, сколько ресурсов бизнес будет тратить на его поддержку в будущем. Вот топ-5 ниш внутри первоначального проекта, с которыми работала наша команда.
Многообразие языков программирования и фреймворков
В основе продукта — микросервисный подход. Два сервиса реализованы на Java, остальные восемь — на Python и Django. Это критично с точки зрения горизонтального масштабирования продукта. Если бизнес хочет развивать маркетплейс, нужно, чтобы технологический стек был написан на одном языке программирования.
Каждый сервис создавался «в вакууме». Из-за этого в архитектуре были даже конкурирующие инструменты (например, jdk от Oracle, OpenJdk и Liberica, а в сборке – сразу Maven и Gradle). Поэтому мы рекомендовали стандартизировать стек и процессы сборки микросервисов.
Отсутствие механизмов отказоустойчивости
Мы внимательно изучили ожидаемые объемы бизнеса и сравнили доступность платформы, чтобы понять, получится ли в перспективе избежать сбоев с текущей ИТ-архитектурой. Так, например, компания планировала на конец 2023 года с помощью маркетплейса реализовать несколько сотен сделок. Количество пользователей сервиса должно было достигнуть более тысячи человек. Порядка 400 из них — «внутренние» клиенты. Это менеджеры по продажам, сотрудники службы поддержки, контакт-центра, отдела заключения договоров, службы безопасности и пр. Столь большие показатели не были учтены при внедрении в маркетплейсе механизмов высокой доступности (high availability).
Аудит также показал необходимость в кластеризации базы данных и более качественном управлении резервным копированием — это даст необходимую отказоустойчивость. А чтобы оценить вероятность возникновения проблем производительности при промышленной эксплуатации маркетплейса, Группа «Иннотех» запланировала нагрузочное тестирование.
Отсутствие плана масштабирования
 | Одной из интересных задач в рамках ИТ-аудита было исследование уже развернутого в контуре компании маркетплейса на предмет того, насколько микросервисы действительно поддаются горизонтальному масштабированию. |  |
Оказалось, что несколько фронтальных решений продукта для разных групп пользователей опираются на один и тот же бэкэнд. Сервисы настолько сильно связаны между собой, что задачи развития и масштабирования конкретного модуля могут потребовать доработку большинства или даже всех микросервисов маркетплейса. Это влияет на трудозатраты и бюджет — в какой-то момент они могут стать неприемлемо высокими для бизнеса.
Отсутствие стратегии информационной безопасности
Команда дополнительно провела статический анализ кода для выявления уязвимостей информационной безопасности. Проверка показала, что на момент аудита задачи аутентификации и авторизации межсервисного взаимодействия не были решены качественно. Не было целевого подхода центра аутентификации и авторизации для клиентского и межсервисного взаимодействия, внутренний трафик не шифровался. Всё это повышало потенциальную уязвимость и увеличивало риски внутреннего фрода.
Чтобы восполнить отсутствие документации по используемым в продукте средствам защиты от разного рода внешних и внутренних атак, команда дополнительно запланировала аудит информационной безопасности. На маркетплейсе нужно было провести как минимум пентесты каждого фронтального решения, анализ всех API на случай массовой выгрузки данных и несанкционированных изменений, изучить зависимости программных компонентов и проработать методы защиты доступа к данным в хранилищах. И в завершение — сделать аудит ролевой модели пользователя, технического и административного специалистов.
Наличие самописных решений в разных частях проекта
Как показал аудит, на стеке Java работало два микросервиса: сервис для разработчиков (API Gateway) и ядро сервисной бизнес-логики. Но был нюанс: они имели разные версии сборок виртуальных машин. Более того, API Gateway был переиспользован из другого проекта и имел самописные неподдерживаемые зависимости.
Сервис для разработчиков опирался на самописную и неподдерживаемую библиотеку маппинга данных (data mapping) от другого вендора. Она была сторонней, непубличной. Это существенный риск. На библиотеку опирается оркестрация маппинга и валидации данных в запросах между фронтэндом и бэкэндом.
Кроме того, большая и разветвленная структура сервиса, которая была у маркетплейса, итеративно усложнялась бы с развитием продукта. Это чревато ростом числа дефектов, долгим отладкам и тестированием каждой новой функции. Именно поэтому важно разделение бизнес-логики разных потребителей на отдельные сервисы по микросервисному подходу.
| | Как разработчику, нам, безусловно, потребовались все артефакты и код проекта после ИТ-аудита. Для этого мы взяли на себя роль «рефери» и вели переговоры между финансовой компанией и предыдущим вендором. | |
Это позволило нам решить проблему максимально экологично и получить всю необходимую для проекта информацию. Результат — за полгода команда «Иннотех» довела платформу до промышленной эксплуатации, доработав функциональность и устранив уязвимости информационной безопасности.
Как нам это удалось, и какие профиты для бизнеса получает заказчик — читайте в следующей серии нашего материала.
