Представьте: вам нужно заменить сердце работающего пациента, пока он жив и работает. Причём пациент — это государственный банк, а сроки как обычно горят. Именно это пришлось делать нашей команде. В статье на Хабре Станислав Тульчинский, руководитель блока кредитного корпоративного бизнеса в команде РСХБ.Цифра, поделится конкретными практическими решениями, которые спасли проект.
Что мы сделали?
- Заменили монолит на Siebel на микросервисную архитектуру
- Мигрировали с Oracle на PostgreSQL
- Перешли с Windows на Astra Linux
- Заменили Golden Gate на Kafka и ДатаФлот
- Переделали десятки интеграций с ядром банка, CRM, DWH и внешними реестрами
Но главное — всё это без остановки работы подразделений, использующих информационную систему.
Замененная система — это монолит, написанный на Siebel командой умельцев несколько лет назад. Мы решили менять её на собственную разработку микросервисной архитектуры с использованием PostgreSQL. Так как проект касался импортозамещения, то в подарочном наборе шёл переход на Astra Linux и Kafka. Успех такого предприятия на 80% зависел не от кода и не выверенной стратегии управления рисками, а от безбашенной команды, готовой в условиях очень бюрократизированных процедур государственного банка с «нуля» (отправная точка – нет бюджета и нет команды) за 22 месяцев сделать проект.
Проект был организован более-менее по канонам PMBOK (Project Management Body of Knowledge) и потому утомлять описанием стандартных технологий управления рисками в проектной деятельности не буду. Основное внимание в статье уделим характерным для проекта особенностям и конкретным решениям по управлению рисками, с которыми приходилось работать в проекте.
Отправным решением, заложившим основу для успеха, стала двухэтапная архитектура реализации проекта по импотозамещению:
Этап 1: Замена Front-end. Создание нового микросервисного Java front-end с подключением к legacy СУБД Siebel через адаптер. Переход с ОС Windows на ОС Astra Linux рабочих станций и серверов. Нужно было сделать этот этап за 10 месяцев, фактически заняло 14 (учитывая стабилизацию системы).
Этап 2: Замена Back-end Siebel на микросервисный Back-end. Миграция исторических данных с СУБД Siebel на PostgreSQL, отказ от адаптера, внедрение Kafka для асинхронного взаимодействия, перенос данных и перестройка всех интеграций системы, замена в них GoldenGate на ДатаФлот. Нужно было сделать за 12 месяцев, заняло 15 (также из-за стабилизации)
С учетом особенностей организации работы и распараллеливания работ краткие итоги проекта таковы: scope работ удалось выполнить, в сроки удалось уложиться (запуск в прод с ограниченным списком ошибок), трудоёмкость проекта ожидаемо (особенности защиты планов и бюджета) увеличилась примерно в 1.5 раза от плановой, бюджет соответственно тоже.
Описанное выше разделение на этапы позволило разделить во времени риски и управлять ими точечно. Но с этим «приехал» дополнительный набор задач, связанных с особенностями отладки и борьбы за производительность адаптера из Java на Siebel, архитектурными особенностями перехода с монолитного адаптера на микросервисный back-end. Давайте разберем, с какими вызовами мы столкнулись и какие практические меры помогли их митигировать.
Хотите узнать о стратегиях управления и снижения рисков в проекте?Читайте на Хабре полный разбор с выводами, которые можно применить к вашим проектам.