Привет, Хабр! Импортозамещение в ИТ — это не просто смена вендоров или технологий. Это сложнейшая хирургическая операция на живом организме бизнес-процессов компании. Я Станислав Тульчинский, руководитель блока кредитного корпоративного бизнеса РСХБ.Цифра. В этой статье расскажу про наш проект по замене информационной системы управления жизненным циклом залогов и договоров залога (и это не одно и тоже) по кредитам юридических лиц в банке.

Замененная система — это монолит, написанный на 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. Давайте разберем, с какими вызовами мы столкнулись и какие практические меры помогли их митигировать.

Стратегия управления рисками: практические советы из опыта проекта

0. Риски разрастания scope проекта

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

Стратегия управления:

Создание двух ИТ команд: приняв за аксиому, что полностью изменений избежать не удастся, пришлось создавать две команды. Первую полнофункциональную «с нуля» для разработки новой системы, начиная с solution-архитектора и до 3-й линии поддержки, вторую сильно усеченную по capacity по поддержке старого решения. Создавать надо было и вторую – потому что старые Seibel-исты после известия об импортозамещении стали задумываться о побеге. Пришлось договариваться и искать компромиссы.

Организация работы поддержки и эксплуатации по принципу «одного окна»: работу 1-2-3 линии двух команд пришлось объединить в единый процесс с регулярным общим daily для общего разбора дефектов, инцидентов и разрешения противоречий в смеси кусков кода на тесте, деве и проде в процессе жизни всего проекта.

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

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

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

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

1. Риски технологической связности и незрелости архитектуры

Вызов: Одновременная замена Siebel, ОС (Windows на Astra Linux), СУБД (Oracle на PostgreSQL), middleware (Golden Gate на Kafka/ДатаФлот) и архитектуры (монолит на микросервисы) создавала колоссальную нагрузку на команду и риск возникновения узкоспециальных проблем, особенно в области совместимости и производительности.

Стратегия управления:

Создание группы пилотных стендов: Первый. После выкатки первого кода front-end и донастройки адаптера был развернут стенд, где Astra Linux, Java-микросервисы и адаптер работали вместе с Siebel. Времени на нагрузочное тестирование решения не хватило. Поэтому выявлять и решить проблемы с настройками ОС, драйверами и правами доступа пришлось в опытной эксплуатации и доделывать при стабилизации системы.

Принцип «одна новая переменная за раз»: на первом этапе мы не трогали базу данных и интеграции. Команда могла сфокусироваться на отладке нового front-end и его работы через адаптер на знакомом железе и новой ОС. На втором этапе, когда front-end уже был стабилен, мы могли все проблемы относить на счет нового back-end.

Создание группы пилотных стендов: Второй. После появления прототипа нового back-end пришлось создать второй пилотный стенд. После этого пришлось синхронизировать процедуры merge кода в Git в общую ветку. Именно тут пришлось столкнуться с тем, что замена монолитного адаптера Siebel на микросервисный back, потребует архитектурной переделки front-end. Недосмотрели на этапе архитектурной проработки.

 Архитектура приложения: на этом проекте пришлось столкнуться с тем, что недостаточно было просто разработать грамотную архитектуру приложения. Необходимо было проектировать архитектуру каждого этапа внедрения информационной системы и проектировать переход от одной архитектуры к другой. Более того! Система интегрирована с дюжиной систем, которые тоже находились в активной фазе импортозамещения. А значит и с ними нужно было продумать целевую архитектуру интеграции на дату запуска в прод, а также архитектуры перехода. Одного solution-архитектора для такого явно не хватает.

Активное участие в кросс-функциональных командах: для таких решений, как ДатаФлот, Kafka, интеграционная платформа, все внешние системы, мы закладывали время и бюджет на контакты, обсуждение решения, а далее разработку и тестирование специалистами сторонних ЦК. В построении интеграции работа с экспертами внешних ЦК, сильные горизонтальные связи — это не просто устранение рисков, это наше ВСЕ, а управление этими рисками — возможность усилить свою экспертизу.

2. Риски миграции данных

Вызов: Перенос исторических данных о залогах из сложной реляционной модели Siebel в структуру PostgreSQL, оптимизированную под микросервисы, с минимальными потерями.

Стратегия управления:

Разработка ETL-стратегии «в три прохода» :

1. Первый проход (за месяц до отключения): перенос полного объема исторических данных для репетиции и оценки времени.

2. Второй проход (за день до выхода в опытную): перенос инкрементальных изменений, накопившихся за время после первого прохода.

3. Третий проход (прод): перенос изменений за время второго прохода при остановке старой системы на несколько часов.

 Валидация на лету: Мы разработали скрипты, которые не просто переносили данные, но и сразу проверяли консистентность, целостность ссылок и соответствие бизнес-правилам между старой и новой системами после миграции.

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

3. Риски интеграционного ландшафта

Вызов: Воспроизведение десятков интеграций с ядром банка, CRM, DWH, АБС и др., с внешними реестрами (например, Росреестр) с учетом необходимости замены технологического слоя (Golden Gate на ДатаФлот, MQ на AMQ).

Стратегия управления:

Инвентаризация и приоритизация: Мы составили полную карту всех интеграций, классифицировав их по критичности и типу (синхронные/асинхронные, инициатор/получатель), собрали логику трансформаций в ETL для DWH и АБС. От части интеграций удалось впоследствии отказаться после детальной проработки потребностей с заказчиком, так как стоимость этих решений явно превышала их полезность.

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

Поэтапное тестирование интеграций: Эта часть проекта была фактически разбита на дюжину мини-проектов, в которых каждая интеграция рассматривалась как отдельное решение со своей архитектурой, планированием, разработкой и тестированием. Следующим этапом тестировались пользовательские бизнес-процессы в системе с учетом интеграции end-to-end, далее ИФТ, и вишенкой на торте опытная эксплуатация.

4. Риски командной экспертизы и организационные риски

Вызов: Старая команда специализировалась на Siebel и Oracle, а в итоге была нужна команда на совершенно новым стеке: Java, микросервисы, Kafka, PostgreSQL, Astra Linux.

Стратегия управления:

Планирование: была разработана структура команды на первый и второй этапы разработки (а это две разных команды по сути — фронтэндеры и бэкэндеры), а также целевая структура ЦК после внедрения — смешанная команда. Был определен необходимый минимум своих сотрудников и определены компании по аутстафу для заполнения вакансий временных членов команды. Самым сложным в данной работе было как обычно бюджетирование этой работы. Решение  вопросов бюджетирования требует в пять раз больше времени, чем вы планируете.

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

Работа со старой командой: были проведены переговоры с теми, кто остался, о том, как они будут переходить на новый стек, определены их места целевой структуре ЦК.

Ресурсы на интеграцию: с владельцами внешних ресурсов были проведены три цикла планирования потребных ресурсов для воспроизведения интеграции: предварительное (годовое), рабочее (квартальное) и детальное с определением scope каждой работы, архитектуры, ресурсного планирования и плана графика работ, включая все этапы тестирования.

 Тесная работа с информационной безопасностью: с самого начала мы вовлекли ИБ-специалистов в процесс работы над проектом.

Результаты

Успешное управление рисками в таком проекте — это не составление красивого отчета в Excel. Это активная, проактивная деятельность всех участников проекта, встроенная в каждый этап жизненного цикла проекта, правильно выстроенные коммуникации и чья-то воля к достижению цели. Хорошо, когда такая воля есть не только у одного менеджера проекта. К каким выводам мы пришли:

1. Бюджет — всему голова. Нет ничего, что так сложно изменить, как бюджет. Временами кажется, что прошлое изменить легче. Но в этом есть и несомненные плюсы — это естественное ограничение «хотелок» заказчика, если этим грамотно управлять.

2. Заказчик — не только ваш босс, но и товарищ. На самых ранних этапах проекта лучше договориться, что вы в одной лодке и вы, как минимум, говорите на одном языке. И это едва ли не самая важная задача.

3. Сильная и мотивированная команда. Вторая по важности задача. По факту именно она выявляет риски, она предлагает варианты решений, и она несет всю тяжесть реализации. Осталось только не упускать её из поля своего внимания.

4. Декомпозиция — ваше главное оружие. Разбивка на этапы с изоляцией рисков — единственный путь усмирить сложность. При этом постоянный процесс планирования и перепланирования — важный инструмент этого.

5. Проектируете и тестируйте интеграцию раньше кода. Самая замечательная система в нашем бизнесе без интеграции — ничто. Все, что связано с реализацией интеграции, займет в три раза больше времени и будет стоить в три раза дороже, чем планировалось на старте.

6. Миграция данных, каждая интеграция — это отдельные подпроекты со своим планом, командой и репетициями.

7. Инвестируйте в команду. Риск «незнания» новых технологий смертелен. Его можно митигировать только обучением и привлечением экспертов. Обратная сторона медали: риск появления «ненадежных» членов команды в проекте не менее разрушителен — в ней должны быть только те, кто справляется с задачами.

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