Модернизация системы дистанционного банковского обслуживания
Контекст
Задача
Устаревшая архитектура, медленный отклик, накопленный технический долг, невозможность выпускать функциональность параллельно.
Работа
Решение
Рефакторинг кодовой базы, обновление архитектуры, автотесты и мониторинг, интеграция внешних сервисов. Работа итерациями без остановки эксплуатации.
Проблема бизнеса
Что происходило до проекта
Дистанционное банковское обслуживание — витрина банка: через него проходят платежи, выпуск карт и повседневные операции клиентов. Система развивалась больше десяти лет как единый монолит, и каждая доработка задевала соседние модули: релизный цикл растянулся, отклик под нагрузкой деградировал, а команды не могли работать над функциональностью параллельно — очередь изменений упиралась в одну кодовую базу.
Остановить ДБО «на переписывание» было невозможно: система обслуживает клиентов непрерывно, а регулятор и процессинг накладывают жёсткие требования к доступности. Нужен был способ обновлять архитектуру, не прекращая эксплуатацию ни на день.
Сдвиг
Как было — как стало
Как было
Как стало
Ход работы
Как решали
Аудит и карта монолита
Разобрали кодовую базу по бизнес-доменам: платежи, карты, личный кабинет, интеграции. Зафиксировали, какие модули меняются чаще всего — они и стали кандидатами на вынос в первую очередь.
API-шлюз как точка развязки
Поставили шлюз между клиентскими приложениями и ядром. Он позволил переключать трафик между старым и новым контуром по функциям — незаметно для пользователя.
Вынос доменов итерациями
Каждый домен выносили отдельным сервисом: новый код работал параллельно со старым, трафик переводился постепенно, при проблеме — мгновенный откат на прежний маршрут.
Автотесты и мониторинг до перевода трафика
Регрессионные и нагрузочные тесты стали условием перевода: домен не получал боевой трафик, пока не проходил проверку на копии реальных сценариев.
Интеграция внешних сервисов
По ходу модернизации подключили новые внешние сервисы и госсистемы — уже к новому контуру, не наращивая монолит.
Решение
Как устроено архитектурно
Strangler-паттерн
Шлюз маршрутизирует по функциям: переведённые — в сервисы, остальное — в монолит. Пользователь границы не видит.
Интеграционный слой
Процессинг, АБС и госсервисы подключены через адаптеры — сервисы не знают деталей внешних протоколов.
Платформа отдельно
CI/CD деплоит, телеметрия стекается в мониторинг: платформенные потоки не смешаны с бизнес-логикой.
Продукт
Как это выглядит в работе
Рабочий инструмент проекта — панель вывода доменов: по каждому видно долю переведённого трафика и статус проверок. Решение о переводе принимается по метрикам, а не по ощущениям.
Макет иллюстрирует механику интерфейса; данные на экране условные.
Границы решения
Что делает — и чего не делает
Честные рамки — часть архитектуры: они защищают результат не хуже кода.
Делает
- вынос доменов без остановки эксплуатации
- мгновенный откат трафика на старый маршрут
- автотесты и нагрузочные как условие перевода
- мониторинг каждого сервиса с алертами
- новые интеграции — сразу к новому контуру
Не делает
- переписывания «большим взрывом» — риск неприемлем для ДБО
- параллельной поддержки двух версий навсегда — монолит планово выводится
- зависимости от нашей команды: документация и код у банка
Итог
Результат
- Рост скорости обработки запросов
- Больше одновременных операций
- Снижение дефектов на релизе
Числовые показатели публикуются после сверки с заказчиком.
Передача
Что осталось у клиента
- Исходный код, модели и конфигурации — вместе с правами.
- Документация и описание архитектуры.
- Возможность развивать решение своей командой или любым другим подрядчиком.
Следующий шаг
Расскажите про задачу
Разберём, оценим сроки и стоимость. Если задача не наша — скажем прямо и подскажем, к кому обратиться.
Обсудить задачу →