Уралсиб-Онлайн

Заказчик: ПАО Банк Уралсиб
Руководитель проекта со стороны заказчика: Дмитрий Наранович

Руководитель департамента
ИТ-поставщик: Банк Уралсиб
Год завершения проекта: 2021
Сроки выполнения проекта: Март, 2020 - Март, 2021
Масштаб проекта: 1000000 абонентов
Цели: Основной целью проекта было быстрый переход на микросервисную архитектуру, а также модульную разработку, для чего потребовалось создание абсолютно новой платформы онлайн-банка, в новых фреймворках и принципах, с исключением всех устаревших решений, которые тормозили развитие текущих сервисов и возможностей.

Уникальность проекта

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

Первой из них являлось начало трансформации процессов разработки, переход на гибкие методологии и набор команды для этого.

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

В дальнейшем совмещение этих двух процессов дало возможность создать сервисы, которые можно развивать независимо друг от друга в рамках всей системы онлайн-банка, работать с продвинутыми средствами мониторинга и внедрить реально работающий процесс CI/CD за счет глубокой проработки методов автоматизированного тестирования и внедрения релизов. Ни один релиз, содержащий бизнес-нп не вышел позже намеченного срок 1 раз в 3 недели.

Проект решает задачи импортозамещения: Нет
Использованное ПО: Стандартное ПО для разработки и работы с серверной частью: Gitlab, IDEA, WebStorm, XCode, Android Studio, Kuber и т.д. Не применялись вспомогательные системы.
Сложность реализации: Мы банально не успевали за рынком по причине большого time-to-market — это время от начала разработки идеи до вывода готового продукта на рынок. У нас было всего 3-4 полноценных релиза в год, и мы практически не отвечали клиентским запросам. Поэтому, в первую очередь, мы решили сократить time-to-market до трёх недель — фактически это в 5 раз быстрее. На тот момент в банке была достаточно бюрократичная структура, а из-за жёсткого waterfall многие актуальные на тот момент задачи сильно менялись к моменту их реализации. В свою очередь, клиентам не нравилось пользоваться приложением банка и заходить на его сайт: команда не уделяла достаточно внимания пользовательскому опыту.

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

Всё это мешало, поэтому команда начала переделывать процессы и находить альтернативные способы взаимодействия. Однако те, кто работал в банке до прихода нашей команды, тяжело воспринимали изменения: к примеру, очень сложно давался процесс ухода от нарядов к работе в Jira.

Мы выбрали стратегию пересборки, начиная с фундамента: то есть буквально с нуля. Сразу заняться архитектурой — это очень важный момент при перезапуске. Если сразу соглашаться на уговоры руководства или кого-то ещё сделать всё быстро, но криво — через год придётся потратить уйму времени на переписывание кода.

Таким образом, мы построили несколько контуров для онлайн-банка, которые сейчас позволяют «бесшовно» накатывать обновления в любое время дня и ночи. При этом раньше релиз проходил только в воскресенье, только утром и только в техническое окно.

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

Ещё одна особенность: у нас всё покрыто автотестами. Именно они позволяют, регулярно проверять весь функционал и находить основные проблемы еще до попадания в master. Тесты гоняются круглосуточно — за счёт этого мы сократили время регресса нашего онлайн-банка и сайта с классических 5-7 дней, как у многих, до нескольких часов. За это время мы можем проверить функциональность всего онлайн-банка как минимум на верхнем уровне и во всех точках взаимодействия.

Эффективность такой работы мониторинга хорошо заметна, когда происходит, к примеру, какая-нибудь DDоS-атака. Наши средства мониторинга настроены таким образом, что мы прогнозируем подобные события и можем заранее подготовиться к тому, что, к примеру, через 10 мин пропускная способность снизится до предельных значений и клиенту станет некомфортно. Оповещения об этом рассылаются заранее: клиент видит сообщение о том, что есть временные трудности с использованием.

Сейчас после каждого изменения кода мы можем провести полное тестирование, не останавливаясь в дальнейшей разработке. Что это нам дало? Принцип CI/CD, или процесс бесконечной разработки, помог достичь желаемого результата по time-to-market: мы реально выпускаем релиз с настоящим бизнес-функционалом каждые три недели. К примеру, недавно у нас вышла цифровая карта, новая версия чата в iOS, мы внедрили новые принципы работы с QR-кодом и на 30% повысили его распознавание. Внедрили гибкую дизайн-систему для различных сервисов, но с централизованным управлением, что также сильно влияет на скорость разработки.
География проекта: Москва, Уфа, Санкт-Петербург
Дополнительные презентации:: Рисунок3.png