финансы и банки
Совкомбанк
Единое мобильное приложение для увеличения и упрощения автоматизированных бизнес-процессов.
Единое мобильное приложение – это приложение для автоматизации рабочих процессов сотрудников банка, которые территориально работают где угодно: в офисе банка, на территории клиентов юр. лиц (презентация и продажа продуктов), в торговых центрах и т.д.
Это также могут быть курьеры, которые доставляют карты клиентам. В ЕМП есть настройки, которые позволяют разделить доступную в приложении функциональность по различным департаментам в зависимости от того, где работает сотрудник.
Существует еще приложение «Мобильный кредит», которое предназначено не для сотрудников банка, а для подрядных организаций, агентов, владельцев карты Халва. Они также могут оформлять и приводить потенциальных клиентов на получение карты Халва.
У этих двух приложений есть единые модули. Например, модуль оформления карты Халва используется и в ЕМП и в Мобильном кредите.
У этих двух приложений есть единые модули. Например, модуль оформления карты Халва используется и в ЕМП и в Мобильном кредите.
Карта Халва
Универсальная карта, основным преимуществом которой является покупка товаров в рассрочку.
Задачи банка с точки зрения бизнеса
1. Увеличение числа автоматизированных бизнес-процессов.
2. Улучшение и упрощение этих процессов.
2. Улучшение и упрощение этих процессов.
Как появился ЕМП
Начиналось все с того, что приложения общались с внутренними системами банка (CRM, фронт юр. лиц и т.д.) напрямую. Это приводило к техническим проблемам, иногда не хватало места для хранения данных и в целом такая схема взаимодействия была неудобной. Было принято решение, что необходима серверная часть — Сервер ЕМП, который выступал бы своего рода API Gateway до других систем банка и базой данных для мобильных приложений.
Сервер ЕМП появился летом 2019 года, его запустили за несколько месяцев. Это был первый проект банка, который заехал в K8s. Первая версия была довольно простая, она осуществляла проксирование методов до др. систем. Потом в решение стали добавлять более сложную логику.
Сервер ЕМП появился летом 2019 года, его запустили за несколько месяцев. Это был первый проект банка, который заехал в K8s. Первая версия была довольно простая, она осуществляла проксирование методов до др. систем. Потом в решение стали добавлять более сложную логику.
Какие бизнес-функции реализованы на данный момент?
Сейчас основной клиентский сценарий выглядит так:
1
Клиент обращается к сотруднику банка.
2
Сотрудник банка на мобильном телефоне в ЕМП заводит анкету: заполняет ее данными клиента, делает фото паспортных данных и клиента.
3
По заполнению анкеты сотрудник банка нажимает кнопку и данные анкеты попадают на сервер ЕМП, который дальше проксирует эти данные в другие системы банка, в т.ч. на скоринг.
4
Скоринг в течение буквально нескольких минут анализирует данные и выдает решение по ним: предоставить или не предоставить кредитный лимит, какого размера. Эта информация попадает обратно в ЕМП через сервер.
5
В случае положительных ответов со стороны систем банка принимающих решения, сотрудник банка выдает клиенту карту Халва с кредитным лимитом или без него.
Таким образом для клиента и сотрудника банка процесс получения карты стал проще и быстрее.
Функциональность сервера ЕМП постоянно развивается. Сегодня он успешно используется в новых сценариях с постаматами и планшетами в офисах банка.
Недавно мы участвовали в создании пилотного проекта — единая карта жителя (ЕКЖ) для Мурманской области. Это универсальная карта с функциями банковской, транспортной, социальной, бонусной карты. При реализации была сложная интеграция с API регионального оператора. Проект был реализован в течение полугода, запустился в конце августа 2022 года и сейчас успешно работает.
Подходы к реализации
Чтобы предоставить новые версии решения и выкатить релиз раньше существовало техническое окно. Это происходило ночью с субботы на воскресенье в конце 2- или 3-недельного спринта. Мы выбрали ночное время субботы, чтобы нагрузка со стороны пользователей была наименьшей.
Поэтому новый релиз сначала обкатывался относительно небольшой группой пользователей и большинство потенциальных ошибок можно было отловить еще в воскресенье.
Но именно в понедельник при пиковой нагрузке на сервис со стороны пользователей была вероятность, что сервер не выдержит нагрузку и придется откатить весь релиз со всеми задачами обратно до старой версии системы. В таком случае важные задачи для бизнеса могли быть вовремя не поставлены в промышленную эксплуатацию, а возвращены со всем релизом на доработку.
Поэтому новый релиз сначала обкатывался относительно небольшой группой пользователей и большинство потенциальных ошибок можно было отловить еще в воскресенье.
Но именно в понедельник при пиковой нагрузке на сервис со стороны пользователей была вероятность, что сервер не выдержит нагрузку и придется откатить весь релиз со всеми задачами обратно до старой версии системы. В таком случае важные задачи для бизнеса могли быть вовремя не поставлены в промышленную эксплуатацию, а возвращены со всем релизом на доработку.
Канареечное развертывание
В поисках оптимизации процесса деплоймента новой функциональности пришли к решению использовать так называемое канареечное развертывание. Это такой процесс, когда релиз растягивается по времени, изменения становятся доступными лишь для небольшой доли пользователей, плавно увеличивая их количество и делая пользователей тестировщиками системы в боевой среде.
Проследив их поведение и метрики использования, сняв определенные параметры мониторинга, можно определить успешен ли релиз, не несет ли он новые ошибки и проблемы. После этого можно будет постепенно сделать доступным обновление для остальных пользователей.
Если по метрикам видны критичные ошибки, то новая версия откатывается и ранние пользователи новой версии переключаются обратно на основную (старую) версию.
Метрики определяет команда разработчиков и поддержки, например: процент ошибочных запросов (ошибки 4xx, 5xx), процент ошибок в логах, время обработки запросов и т.п. В случае срабатывания негативных метрик и отката нового релиза происходит поиск причины ошибок, исправление в коде, выпуск баг-фикса.
Цель канареечного развертывания — чтобы команда не была привязана по времени к релизам, к техническому окну. Это позволяет быстрее выкатывать задачи, отделять критичные задачи для бизнеса от других. За счет этого релизы становятся меньше по объему, а time to market ниже.
В планах автоматизировать такие процессы как: увеличение процента пользователей на новом релизе, откат пользователей с нового релиза на старый, фиксация нового релиза как основного, удаление старого релиза.
Проследив их поведение и метрики использования, сняв определенные параметры мониторинга, можно определить успешен ли релиз, не несет ли он новые ошибки и проблемы. После этого можно будет постепенно сделать доступным обновление для остальных пользователей.
Если по метрикам видны критичные ошибки, то новая версия откатывается и ранние пользователи новой версии переключаются обратно на основную (старую) версию.
Метрики определяет команда разработчиков и поддержки, например: процент ошибочных запросов (ошибки 4xx, 5xx), процент ошибок в логах, время обработки запросов и т.п. В случае срабатывания негативных метрик и отката нового релиза происходит поиск причины ошибок, исправление в коде, выпуск баг-фикса.
Цель канареечного развертывания — чтобы команда не была привязана по времени к релизам, к техническому окну. Это позволяет быстрее выкатывать задачи, отделять критичные задачи для бизнеса от других. За счет этого релизы становятся меньше по объему, а time to market ниже.
В планах автоматизировать такие процессы как: увеличение процента пользователей на новом релизе, откат пользователей с нового релиза на старый, фиксация нового релиза как основного, удаление старого релиза.
Команда
На проектах ЕМП работает около 30-35 человек:
8-9 Backend разработчики, 8-9 Frontend разработчики, аналитики и тестировщики.
Backend команда — 8 человек:
5 разработчиков Rocket Science и 3 разработчика из команды банка. Почти все на full remote. Есть тимлид и техлид.
8-9 Backend разработчики, 8-9 Frontend разработчики, аналитики и тестировщики.
Backend команда — 8 человек:
5 разработчиков Rocket Science и 3 разработчика из команды банка. Почти все на full remote. Есть тимлид и техлид.
В работе с данным заказчиком нам нравится, что владелец продукта отдает на откуп команде как должны решаться задачи, выбирать стек. Соответственно, проект позволяет участникам команды развиваться и знакомиться с разными частями системы.
Кейсы
Обсудим ваш проект?
Напишите нам!
Москва: Ленинский проспект 15А, 6 этаж
Новосибирск: Николаева 11, 12 этаж
Новосибирск: Николаева 11, 12 этаж
Нажимая на кнопку, вы даете согласие на обработку персональных данных и соглашаетесь c политикой конфиденциальности.