Импортозамещение крупных зарубежных платформ является одной из приоритетных задач для российского бизнеса. Сбер успешно мигрировал систему с иностранной платформы Pega на собственную разработку Platform V. Опыт реализации проекта станет полезным руководством для руководителей проектов, инженеров, аналитиков, архитекторов и специалистов, работающих над крупными ИТ-решениями.

Поскольку проект весьма масштабный, мы решили осветить отдельные этапы реализации и затронуть следующие актуальные темы миграции больших монолитных решений в режиме реального времени:

• стоящие вызовы в проекте миграции

• целевая архитектура замещаемого ПО

• технические паттерны миграции процессов.

Стоящие вызовы в проекте миграции

• Фрагментация процесса и сложная интеграция. Кредитный процесс оброс сотнями связей с внутренними системами, затрудняя миграцию на новое решение

• Полная доступность в период миграции. Система должна была сохранять работоспособность в течение всего периода миграции

• Сохранение user journey. Клиентские интерфейсы и работа сотрудников не могли изменяться кардинально, иначе возникли бы трудности в адаптации, миграция должна быть незаметной для пользователей.

Основные цели проекта:

• Обеспечить переход и миграцию на эффективное целевое решение за два года

• Сохранить текущую функциональность и бесперебойность работы для нескольких тысяч пользователей

• Отказаться от единой ответственности и общей оркестрации в архитектуре целевого решения.

Кроме технической стороны, проекту сопутствовали серьёзные организационные вызовы:

• Управление ресурсами сотен специализированных команд

• Координация параллельной работы десятков подразделений

• Непрерывное сквозное тестирование процесса, работающего одновременно в двух системах: новой и замещаемой.

Требовалось полностью заменить действующую систему, и мы приступили к разработке концепции масштабной миграции в реальном времени!

Разработка концепции и архитектурные принципы при миграции на целевое решение

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

Целевое решение основывается на концепции Composable-архитектуры с выделением трёх ключевых составляющих:

• Событийной архитектуры (Event-driven architecture, EDA)

• Принципов Domain-driven design (DDD), разделение и иерархия уровней и служб. Это позволило добиться разделения ответственности: выделения границ, слабой связанности и независимого развития.

• Перехода к хореографии выделяемых блоков.

Каждый компонент целевого решения в Composable-архитектуре представлял собой отдельный Business Building Block (далее — BBB), выделенный по критериям:

• уникальная специфика, бизнес-ценность;

• единая ответственность;

• событийность взаимодействия;

• «жёсткое зацепление» внутри функций BBB;

• «слабая связанность» с функциями других BBB;

• автономность;

• независимая поставка и управление бэклогом.

Была выстроена сomposable-архитектура, которая обеспечивает для каждого компонента BBB:

• Модульность: гранулярность блоков, бизнес-ценность через API.

• Автономность: независимость от окружения.

• Обнаружение: цифровая мета-модель и описание блоков.

• Взаимодействие и наблюдаемость: единый протокол взаимодействия, дашборды.

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

Основываясь на DDD, в каждом BBB выделяли API, внутренние данные, логику и интерфейсы.

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

Помимо этих архитектурных паттернов необходимо было учитывать, что не все смежные АС были готовы к изменениям или поддержке перехода на целевой событийный стек, а это означало необходимость сохранять действующую интеграцию в процессе миграции системы (по сути, закладывая адаптеры на соответствующие взаимодействия). Далее рассмотрим целевые паттерны миграции, которые заслуживают отдельного внимания.

Реализация архитектуры обеспечивалась технологическим стеком Сбера на базе Platform V:

• Backend-решение: собственная разработка на Java, Kotlin, Spring.

• Frontend-решение: единый интерфейс фронтальной системы, построен на основе популярной библиотеки React.js и языка JavaScript, поддерживает паттерн «microfrontends».

• Система хранения данных: СУБД Platform V Pangolin (Переезжаем на Platform V Pangolin: опыт Сбера)

Технические практики миграции

Разделение процесса на BBB 

Выстраивание процесса из отдельных компонент, отвечающих за собственные бизнес-сценарии и функционал, позволило создать цифровой кредитный процесс на основе композитных блоков-BBB. На примере компонента BBB «Формирование документации» - сценарий формирования кредитно-обеспечительной документации (КОД) запускается при получении соответствующего события о завершении всех сценариев предыдущего этапа "структурирования сделки" и начале следующего этапа - формирования КОД.

Ответственность за отслеживание статусов всех сценариев функциональных блоков и переход на следующий этап цифрового кредитного процесса обеспечивается компонентом BBB «Контекст сделки». Следуя концепции сomposable-архитектуры его функция - контроль выполнения сценариев и переходов между этапами целевого мигрируемого процесса.

Протокол событийного взаимодействия BBB реализован событиями трёх типов:

• Business: появился значимый факт (например, заполнение клиентом анкеты);

• Activity: изменение статуса сценария компонента (начат, ошибка, завершение сценария);

• Monitoring: сообщение о работоспособности (health-check) BBB или срабатывание триггера запуска бизнес-сценария.

  Функциональные блоки постепенно вытесняли функциональность Pega, обеспечивая неизменный клиентский путь и полную доступность мигрируемого процесса (см. следующий паттерн замещения UI).

Паттерн последовательного замещения компонентов интерфейса

Интерфейс меняли пошагово, сохраняя минимальную видимость изменений для пользователей. Использовали метод pattern migration (последовательного замещения компонентов). Были декомпозированы все интерфейсы мигрируемого процесса и выделены паттерны их замещения, обеспечивая минимальный уровень риска и максимальное сохранение функциональности замещаемой АС.

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

Декомпозицию на отдельные компоненты интерфейса разделили на четыре паттерна вызываемых фреймов с бизнес-функциями:

1. Экран, открываемый как цельный фрейм целевой АС. Сюда относятся случаи, когда миграция экрана не требует возврата данных в исходную систему (в Pega), речь идёт об исключительно одностороннем взаимодействии, когда не требуется специальная обработка обратной связи от исходной АС. Примером может служить отображение справочной информации, которая генерируется исключительно на стороне новой системы.

2. Интерактивное взаимодействие между фреймами с передачей данных.

   а. Междоменное взаимодействие используется для передачи данных между доменами на уровне смежных приложений, при помощи события postMessage, позволяя отправлять JSON-данные между родительским окном и дочерним фреймом.

   b. API-вызовы. Иногда нужно передавать данные не только в рамках frontend, но и задействовать backend-компоненты. В таких случаях применяем обращение к API для отправки дополнительной информации.

3. Экран с чтением результатов из целевой АС после завершения задачи (обратный поток). Некоторые сценарии требуют возвращения данных обратно в исходную систему после выполнения задачи в новой. Для этого применяют pull-подписки, когда родительская система обращается за результатом самостоятельно.

4. Экран с ожиданием уведомлений и необходимостью чтения данных (реверсивный поток + уведомления). Иногда нужно настроить подписку на уведомления и получать обратную связь автоматически. Например, инициируется отправка данных в новый сервис, а уведомление приходит через веб-хуки или брокеры сообщений (например, Kafka).

Используя комбинацию этих паттернов с постепенным замещением интерфейсными фреймами нового процесса, мы реализовали принцип бесшовного перехода при миграции. Пользователи работали в привычной АС, но внутри были встроенные модули (фреймы) уже новой АС. Это помогло сделать миграцию более «плавной» для пользователей. 

Принцип feature toggle

При необходимости отладки был доступен оперативный возврат экранов со старой функциональностью мигрируемых компонентов (parallel run). Для этого мы внедрили механизм feature toggle, позволяющий плавно вводить функциональность в эксплуатацию, регулируя доступность определённых функций как в исходной, так и в целевой системах, незаметно для конечных пользователей. Такой подход позволял безболезненно менять настройки и проверять нововведения в реальных условиях. 

Использование DMN

Ещё одной важной частью стали модели Decision Management Notation (DMN), используемые для быстрой модификации настроек системы без переписывания кода. Например, таблица конфигурации выглядела так:

Такая организация данных помогла избежать жёсткой привязки к настройкам и облегчила изменение правил без перезапуска сервиса, упростила развёртывание и позволила проще вносить изменения в бизнес-логику.

Эффекты проекта 

Таким образом, мы создали событийно-ориентированную систему из элементов-Bisuness Building Blocks, позволяющую масштабировать:

• Разработку: команды-участники цифрового кредитного процесса получили возможность вносить изменения независимо от остальных команд.

• Методологию и бизнес-архитектуру: владелец поддомена независимо создает новые фичи, улучшающие предоставляемые клиенту сервисы.

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

Выводы проекта

• Важность правильной декомпозиции и сегментирования функций.

• Применение современных архитектурных моделей (практики сomposable, событийной, доменной архитектуры) снижает зависимость компонентов.

• Тщательное управление рисками помогает избегать последствий.

• Этап тестирования играет ключевую роль, особенно на стыках интеграций.

• Параллельное замещение (parallel run) и поэтапное внесение изменений существенно повышают отказоустойчивость и минимизируют негативное влияние изменений.

Что ещё стоит помнить?

ИТ-менеджмент — это баланс между силами команд, используемыми технологиями, управлением рисками и принятием решений. При планировании важно учитывать:

• R&D: вовремя найденное решение обеспечит успешность миграции.

• Постоянный диалог между всеми участниками проекта: инженеры, аналитики и менеджеры  должны тесно сотрудничать.

• Фиксация архитектуры и плана миграции с акцентом на совместимость и возможность быстрого отката назад.

• Тщательная настройка механизмов оповещения и мониторинга, чтобы вовремя выявлять аномалии и оперативно реагировать на них.

• Превентивное управление рисками: любой критический срок должен учитывать дополнительное время на его компенсацию.

Будьте внимательны к мелочам, и ваши проекты будут успешными. Хорошего полёта! 

Александр Зыкрин.

Григорий Неваров.