Hyundai Mobility — разработка первого в России онлайн-сервиса подписки на автомобиль
1. О чем кейс
Hyundai Mobility Lab - дочерний цифровой бизнес Hyundai, который делает в России сервис подписки на автомобиль. Это живой продукт, который стоит в центре большой IT‑экосистемы (учет автомобилей в ERP, клиенты и коммуникации в CRM, биллинг, платёжные шлюзы, мобильное приложение и веб‑приложение). Сервис уже работал в Москве, Санкт‑Петербурге, Екатеринбурге, Воронеже, Волгограде и других городах, когда команда уперлась в потолок по производительности и стабильности. БизнесМатика вошли в проект именно для устранения этой проблемы.
За первый год совместной работы команда и клиент перевели систему на микросервисную архитектуру, заметно ускорили ключевые операции и уменьшили количество аварийных ночных релизов. Время реакции критичных операций сократилось в разы, а количество серьезных инцидентов на продакшене - до приемлемого уровня.
2. Когда подписка на машину "тормозит"
Сервис подписки Hyundai Mobility включал такие пользовательские сценарии: выбрать модель, срок, пробег, страховку - и ездить, не вникая в остаточную стоимость. Поскольку идея понравилась рынку, с ростом трафика и числа активных подписок стали проявляться проблемы.
Например, в пиковые моменты рекламных кампаний пользователи сталкивались с долгими загрузками (в частности, расчета стоимости подписки). Иногда бронирование подвисало.
Цели к старту проекта сформулировали следующим образом:
- сервис должен выдерживать рост нагрузки без красной зоны на мониторинге;
- новые тарифы и опции должны выходить по расписанию;
- архитектура должна стать масштабируемой.
На старте проекта замеры показали нестабильное время отклика по ключевым сценариям (расчет стоимости, бронирование, оплата), рост числа инцидентов в пиковые недели, а также длинный цикл вывода изменений.
3. Данные и интеграции
Сервис подписки стоял не сам по себе, а как некий "дирижер" оркестра корпоративных систем.
С одной стороны, ему нужно было знать все про автомобили (что есть на складе, что уже в подписке, что в пути, а что стоит на сервисе). Эти данные находились в учетных системах и ERP‑контуре, где у каждого автомобиля был свой жизненный цикл. С другой стороны, сервис работал с людьми - CRM хранила данные клиентов, истории обращений, согласия, предпочтения, статусы лидов.
- платёжная инфраструктура и биллинг (первый платеж, рекуррент, статусы оплат, возвраты);
- телематика части моделей (пробег, базовые данные о состоянии, геопозиция - там, где это было предусмотрено сервисной моделью);
- маркетинговые системы, которые приносили трафик и сегментировали аудиторию.
Часть информации по автомобилям приходила с задержкой, из‑за чего в витрине иногда появлялись машины‑призраки: в интерфейсе машина уже есть, а по факту она еще не дошла или уже уехала. Данные по клиентам лежали в нескольких системах, и их приходилось аккуратно сводить, чтобы не устроить сюрпризы с дубликатами и правами доступа.
Поверх этого накладывались требования по безопасности и персональным данным - шифрование, разграничение доступа, логирование. Интеграции с внешними партнерами (например, платежными) также требовали дисциплины на уровне API и аудит‑логов.
4. Как устроен сервис подписки изнутри
Совместно с командой клиента мы решили двигаться в сторону микросервисной архитектуры:
- каталог и витрина (модели, комплектации, доступность по городам);
- ценообразование и тарифы (базовые ставки, пакеты, акции);
- оформление контракта (юридические данные клиента, проверка, документы);
- биллинг и платежи;
- управление жизненным циклом подписки (подбор даты старта, продление, смена машины, паузы).
Сервис подписки стали рассматривать как центральную платформу, которая стоит между фронтом (мобильное приложение и веб‑интерфейс) и тяжёлыми backend‑системами автопроизводителя. В идеале мобильное приложение видит простой API: «посчитай подписку», «забронируй автомобиль», «продли подписку». Вся сложность общения с ERP, CRM и биллингом скрывается в глубине бэкенда.
5. Как шла работа
Проект начали с "инвентаризации". Первые недели ушли на то, чтобы разобрать код, схемы интеграций и реальные потоки данных (где узкие места, что ломается, что нельзя трогать, пока идет активный сезон).
Параллельно запустили режим быстрой стабилизации. Взяли несколько самых болезненных сценариев (расчет стоимости подписки, бронирование на выходных, платежи в пике) и сфокусировались именно на них. Часть запросов оптимизировали, часть вынесли в отдельные сервисы, часть просто перестали делать синхронно, переключив на очереди и фоновую обработку.
Следующий слой работ - собственно миграция на микросервисы. Команда постепенно выделяла бизнес‑домены, выносила их в отдельные сервисы и разрезала монолит на части.
Параллельно шло развитие продуктовой части. Бизнес хотел не только стабильности, но и гибкости (новые тарифы, специальные программы для отдельных категорий клиентов, запуск в новых городах). В этот момент стало особенно видно, зачем была нужна новая архитектура: изменения можно вставлять в конкретный домен, не разваливая всю конструкцию целиком.
По времени картина сложилась довольно реалистичная для такого типа проектов - первые ощутимые улучшения увидели уже через пару месяцев, основная часть миграции заняла около года, а затем работа перешла в режим последовательного развития.
6. Команда
Со стороны БизнесМатики в проект зашла смешанная команда. Архитектор, который говорил и с разработчиками, и с владельцами продукта. Несколько backend‑разработчиков, инженер по интеграциям, DevOps‑инженеры и QA.
Со стороны Hyundai Mobility ключевыми фигурами стали product owner сервиса подписки, владелец бизнес‑процесса и IT‑архитектор.
7. Технологии: без магии, но по‑взрослому
В основе технологического стек проекта была микросервисная архитектура. Сервисы разворачивались в контейнерах, там, где нужна была синхронность - REST API, там, где важна устойчивость и асинхронность - очереди и message broker.
Для данных использовали комбинацию реляционных баз данных для транзакционных сценариев и кешей для горячих операций. Критичные запросы к каталогу и ценообразованию старались обслуживать из быстрых хранилищ, чтобы пользователь не ждал, пока ERP вспомнит, где стоит конкретная машина.
Отдельного внимания заслуживает вопрос наблюдаемости. Логи собрали в единое место, метрики - на дашборды, оповещения настроили так, чтобы команда видела проблемы как можно раньше. Настроили CI/CD, перешли к более аккуратным стратегиям выката.
С точки зрения безопасности проект опирался на привычные практики - шифрование, разграничение доступа, периодические проверки кода и архитектуры с учетом требований к персональным данным и интеграциям с внешними сервисами.
8. Результаты в цифрах
Главный эффект проекта команда почувствовала по тому, как изменилась жизнь в пиковые недели - система стала вести себя предсказуемо.
- среднее время отклика ключевых операций заметно сократилось, особенно в период нагрузки;
- количество критичных инцидентов на продакшене снизилось кратно, а время восстановления при проблемах стало короче;
- вывод новых функций и тарифов превратился в работу в рамках спринтов.
Бизнес‑эффекты тоже проявились. Более стабильная и быстрая работа сервиса улучшила конверсию - меньше людей бросали оформление на середине, клиенты активнее пользовались возможностями самообслуживания (продлевали подписки, меняли условия и управляли услугами внутри приложения, не перегружая колл‑центр).
9. Риски и вызовы: что могло пойти не так
Любая миграция живого сервиса на новую архитектуру - это всегда сопряжено с рисковами. В Hyundai Mobility это понимали с самого начала.
Первый риск - трогать работающую систему, которой пользуются живые клиенты. Здесь спасла стратегия поэтапного выноса функциональности - часть пользователей шла через новый сервис, часть оставалась на старом. Возможность быстро откатиться с нового пути на старый помогала увереннее двигаться вперед.
Второй риск - человеческий. Часть команды опасалась, что система станет слишком сложной, часть - что новые инструменты оторвут их от привычного режима работы. С этим работали через совместные воркшопы, разбор инцидентов и примеры, как новые подходы сокращают ручной труд.
Третий риск - безопасность и регуляторика. Любая работа с персональными данными и платежами требует аккуратности. Команда безопасности подключалась с ранних этапов - архитектура и код обсуждались с учетом необходимых требований.
10. Как изменились люди - взгляд клиента
Если упростить отзыв клиента до одной мысли, то вместо ощущения, что цифровой продукт живет отдельной жизнью, появилось чувство управляемости.
Второй заметный сдвиг - в работе поддержки и эксплуатации. В пиковые периоды сотрудники стали смотреть на дашборды, знали пороговые значения и понимали, какие триггеры что означают. Система забрала часть рутины и отсавила возможность принимать решения, согласовывать изменения, планировать развитие.
11. Подписка как платформа
Для Hyundai Mobility этот проект стал не финалом, а переходом на следующий уровень. Когда фундамент стабилизирован, к нему можно надстраивать новые уровни.
В планах - масштабирование сервиса на новые регионы, работа с новыми сегментами клиентов и продуктовыми моделями. Более продвинутая аналитика позволит точнее прогнозировать спрос, планировать нагрузку на автопарк и формировать индивидуальные предложения. Появляется пространство для партнерств: подключение страховых, сервисных и других компаний через API.
Сервис подписки превращается в полноценную платформу, которая умеет жить в большом ИТ‑ландшафте и выдерживать рост - а это главный результат проекта.