Привет, Хабр!
Меня зовут Никита Шехов, я руковожу командой разработки «Единой цифровой платформы» (ЕЦП) в РСХБ.Цифра. В этой статье хочу рассказать, как мы создавали платформу для автоматизации бизнес-процессов банка, с какими вызовами столкнулись и какие решения оказались ключевыми. В будущем планирую рассказать про историю проекта, выбор архитектуры, сбор команды и борьбу с импортозамещением.
Что такое ЕЦП?
Единая цифровая платформа — это микросервисная экосистема, объединяющая технические компоненты и бизнес-сервисы для автоматизации процессов в Россельхозбанке. Её ядро включает следующие сервисы:
Управление доступом (RBAC)
Логирование и аудит
UI-кит для фронтенда
Работу с файлами и документами
Интеграция с внешними системами (гибкий адаптер)
Уведомления
Шаблонизатор для печатных форм
BPM-движок, для работы с процессами
На базе ЕЦП можно развернуть любой бизнес-процесс — от кредитования до управления проблемной задолженностью. При этом весь базовый функционал уже готов «из коробки». Мы используем PaaS-платформу AppFarm (рассказываем о нём в статьях на Хабре) для размещения наших сервисов, поэтому у нас не болит голова о процессах публикации от среды разработки до продакшена.
С чего всё начиналось
В конце 2022 года перед нами стояла амбициозная задача — импортозаместить зоопарк из 5+ legacy-систем (CRM, управление залогами, скоринг и др.), работавших на зарубежном стеке. Условия были жёсткими: было всего два года на переход, в интеграциях нужно было переключить 400+ потоков данных на импортозамещенные решения. Кроме того, в плане безопасности решения должны были соответствовать требованиям регуляторов. И, конечно же, переход должен был быть непрерывным для бизнеса: параллельно мы поддерживали старые и новые системы.
На старте внутренняя команда с опытом в микросервисы состояла всего из 5 человек, 40 зибилистов, 3 Jboss специалистов. Нас ожидал найм 60 человек на новое решение и 40 «плавающих» сотрудников от вендора, которые приходили на два месяца, а потом увольнялись.
Системы, которые требовалось заменить, дублировали функционал, имели устаревшие интерфейсы (например, IE с ActiveX) и слабо взаимодействовали друг с другом. Решение было очевидным — построить единую платформу.
Вайб того времени: у нас было два часа на сон, семьдесят пять созвонов в день, пять бизнес-линий или стримов, план, наполовину наполненный здравым смыслом, целое море разношерстных систем, продуктов и групп разработки, а также ящик прогхантерского энергетика, литры чистого адреналина, ящик зеленого мерча и 12 пузырьков жидкого магния.
Не то что бы всё это было категорически необходимо, чтобы обеспечить непрерывность бизнеса при импортозамещении, но если уж начали строить Единую цифровую платформу, то к делу надо подходить серьёзно.
Кастомизация vs. Собственная разработка
Мы рассматривали коробочные решения (FIS, ELMA и т.д), но отказались от них по трём причинам:
1. Зоопарк технологий: каждая legacy-система использовала свой стек (Java, .NET, проприетарные СУБД), добавлять еще одно универсальное решение — всё равно, что принять тот факт, что «в мире было 12 стандартов, давайте сделаем один общий для всех, так в мире стало 13 стандартов».
2. Отсутствие команд: большинство систем поддерживали вендоры, а внутренние отделы занимались только сопровождением и чуть-чуть развитием.
3. Гибкость: готовые решения не позволяли быстро адаптироваться под меняющиеся требования регуляторов.
Выбор пал на собственную разработку и микросервисную архитектуру — это дало возможность переиспользовать общий функционал для всех 5 систем.
Сбор команды: ад или приключение?
Сформировать команду из 60 человек за полгода — задача не для слабонервных. Собирать ИТ-команду — это не просто дело техники, это настоящее искусство. Возможно, именно поэтому этап набора сотрудников становится одним из самых сложных этапов проекта. Когда перед тобой стоят шестьдесят вакансий, а каждая позиция требует идеального кандидата, начинается настоящая гонка за таланты.
Именно тогда, в разгар глобальной борьбы за квалифицированных спецов, я столкнулся с первой серьёзной проблемой — собеседования. Их было столько, что по вечерам хватало сил только сверлить взглядом стену в тишине, а мозг просился не открывать глаза на следующее утро. После нескольких дней по 4-6 собеседований в день, было принято решение остановиться на 2-3 собеседованиях в день. Были изучены тысячи резюме, и каждый звонок приходилось выбирать между талантливым новичком, мечтающим о зарплате стариком и матерым специалистом, готовым принять предложение только с условиями космического полёта.
Например, как забыть разговор с юнцом, заявившим твёрдым голосом: «Меня устроит зарплата не меньше трёхсот»? Или диалог с мидлом, недавно перешедшим границу среднего звена: «Ну что вы! Меньше пятисот даже не предлагайте!» На таком фоне встреча с действительно хорошим кандидатом воспринимается как чудо, сравнимое с обнаружением биткоинов на старой флешке.
К счастью, к нашей команде присоединился отличный HR, он оказался настоящим спасителем, который избавил нас от потока неподходящих резюме, отбирая и показывая самых интересных кандидатов утром за чашечкой кофе.
В поисках золотой середины. Одной не совсем неожиданностью оказалась любовь наших ребят к удалёнке. Как только появилась возможность вернуться в офис на гибрид, было очевидно, что большинство предпочтёт остаться дома. Вся эта шумиха вокруг гибрида звучала примерно так: «Нет, спасибо, я лучше буду сидеть дома, а не вот эти вот офисы и общение вживую».
Тем не менее решение было найдено: наши ребята работают из разных уголков России, начиная от центральной части и заканчивая Сибирью. Правда, временные зоны порой создают ощущение телепортаций во времени, но это небольшая цена за возможность сотрудничать с лучшими специалистами.
Ограничения и реальность банковского сектора. Про третью волну боли: разработка банковских продуктов накладывает особые ограничения. Административные права не разрешены (и так во всех банках), доступ в интернет ограничен, рабочее окружение строго регламентировано. Даже шутливая просьба сотрудника дать другой компьютер превращается в почти философский диспут — большинство ребят мечтает работать не через виртуальные машины и RDP, а на собственном ноутбуке, желательно с яблочком на крышке. Однако реалии в банковском секторе совсем другие: в то время пока Яндекс меняет м2 про на м4 про, некоторые компании переходят с Lenovo на Квадру.
Вот так постепенно формируется наша удивительная команда. Команда, которая состоит из талантливых одиночек, разбросанных по стране, готовых преодолевать временные барьеры ради общей цели и смирившихся с отсутствием административных привилегий ради перспектив развития, интересного проекта и коллектива.
Так что да, пожалуй, собирать команду — это приключение, полное эмоций и сюрпризов. Но главное, что в конце пути ждёт награда — дружный коллектив настоящих профи, объединенный единой целью и общим делом.
Старт разработки: первые шаги
Сначала мы создали технические компоненты, критичные для импортозамещения:
1. Фронтенд(UI-Kit): Переход с IE на современный стек (React + TypeScript).
2. Проработка архитектуры.
3. Проектирование базовых сервисов (ядровые компоненты платформы, перечислены в начале статьи).
4. Интеграции: Замена IBM на Apache Kafka и Artemis.
Импортозамещение: двойная нагрузка. Параллельно с разработкой ЕЦП приходилось поддерживать legacy-системы, интегрировать их с новыми импортозамещёнными сервисами (например, Kafka вместо IBM шины), работать с вендорами, которые часто «исчезали» из-за санкций. Пример: Переход на Artemis потребовал доработать все интеграции. Каждый сценарий тестировали дважды — на старой и новой шине.
Чего не хватало. Банковские ограничения добавили сложностей, например, не было доступа к продакшен-данным. Это норм, но даже взглянуть было нельзя. Тестировали на обезличенных данных, что приводило к багам в проде.
Ограничения банковского сектора: развёртывание новых серверов и сервисов занимало больше времени, чем мы планировали, в связи с необходимостью соблюдать политики конфиденциальности клиентов банка и другие требования регулятора.
Запрещённые технологии. Частенько встречались ситуации, когда на рынке есть десяток хороших решений, но они были импортные и их нельзя было втащить за пару дней «клац-клац и в продакшен», приходилось разрабатывать свои аналоги.
Отсутствие инструментов разработки (в самом начале):
Kafka UI — для работы с топиками, а доступ к Кафке был только у сервиса, развернутого в дев окружении банка.
CloudBeaver — веб-интерфейс для СУБД (требовалось работать сразу с несколькими видами БД).
Debezium — CDC для синхронизации данных.
Тестирование: Playwright vs. Java. Изначально автотесты писали на Java, но столкнулись с дефицитом специалистов. Перешли на Playwright, потому что нам были важны такие параметры:
Low-code: Тесты можно «накликивать» без глубоких знаний программирования.
Скорость: Параллельный запуск 50+ сценариев.
Поддержка микросервисов: Интеграция с API Gateway.
У решения были и минусы — высокие требования к инфраструктуре, каждый тест — отдельный контейнер.
Что в итоге?
За первый год нам удалось:
Сформировать команды ядра и продуктовые,
Запустить ЕЦП в пилотной эксплуатации,
Перенести 3 из 5 бизнес-направлений в виде MVP,
Сократить время выпуска релизов с 1 месяца до 1 недели.
За второй год:
Перенесли полностью функционал 4 из 5 направлений,
Перешли от стадии импортозамещения к стадии развития действующих продуктов,
Часть продуктовых команд переключились на развитие новых процессов вместо импортозамещения и даже успели какую-то часть внедрить в промышленную эксплуатацию.
Вернусь на Хабр с историями, что и как мы импортозамещали в 2025 году, как мы проектировали архитект��ру ЕЦП, почему выбрали React вместо Angular.
Сталкивались ли вы с импортозамещением legacy-систем? Сталкивались ли с заменой Oracle/Siebel? Чем заменили? Какие инструменты и подходы оказались полезными?
P.S. Если есть вопросы по стеку или организации процессов, спрашивайте в комментариях!