Как жить-то, когда нет целевой архитектуры?
Кажется в кино кризис — хороших фильмов один на сотню. Могу предложить один сюжет — психологический триллер. Сценарий для него будет начинаться со строк: «Была у нас одна легаси-система. Монолитная. И задумали мы провести миграцию»…
Дисклеймер. Предупреждаю, текста много и он не всегда связанный. Впрочем, как и система, о которой расскажу.
Что происходит?
Сейчас у нас есть:
целевые стратегии банка;
огромная инфраструктура;
множество интеграций между системами;
множество команд развития;
бизнес-задачи команд развития;
не одна линия поддержки;
разнородные пользователи всевозможных масштабов;
разные требования потребителей и других стейкхолдеров;
требования учёта изменений законодательства;
необходимость соблюдения стандартов безопасности;
современные технологии и не только;
влияние политической обстановки;
стремительное изменение мировой ситуации;
и многое другое.
И в этом окружении есть задача миграции — отказа от системы, точнее замены!
Было раньше (ну как «было», оно и сейчас есть) старое приложение (старый интернет-банк). Новое приложение (новый Интернет Банк) браузерное, частично имеет: новую логику, частично синхронизацию со старым.
Здесь на картинке отображено из чего состоят старая и новая системы, и какое есть окружение систем.
В старой системе слева есть некое ядро (платформа), есть часть где описана логика, клиентский и админский интерфейс, публичные сервисы (которыми пользуются другие системы, чтобы получить информацию из БД), своя БД и отдельная БД Аудита интернет-банка.
Что касается новой системы справа — есть веб-версия и мобильная версия, развивается админ-панель. Есть некая идея, что часть системы как отдельный продукт представлен в разных каналах (проходит по всем, как-то идет переиспользование модулей).
Новая и старая системы в картинках.
Если без картинок, а схематично, то условно синее — это старая система, желтое — целевые системы, новые, куда всё переезжает, и где находится около 80% задач по реализации целевых сервисов (это основные потребители старого интернет-банка как бэка) и около 20% — это интеграции с разными бэк офисными ПО (которые должны будут переехать на целевые решение и при отказе от старой системы). Часть функционала, реализованного в старом приложении, отсутствует.
Есть ещё мобильное приложение, оно «живёт» частично на переиспользовании логики нового приложения, а также немного использует логику старого. С ним в каких-то вопросах дела обстоят сложнее, так как его придется обновлять у клиента (изменения местами нужны на фронте), если убирать логику использования бэк-а старого приложения. Вот так и живет до сих пор!
Переход от монолита к микросервисной архитектуре весьма незаурядная задача. Чаще она звучит как «распил» монолита на микросервисную архитектуру. В нашей компании «распил» уже прошел, у нас есть новый фронт на старом бэке, который осталось «подчистить».
Вроде задача чисто техническая, но немного сложнее, чем хотелось бы — для пользователя переход должен пройти бесшовно: как привык он работать в системе так и должен продолжать — без видимых изменений. Задача распила монолита трансформируется в задачу миграции: нужно «просто» переселить фронтовую логику на другие сервисы.
Нам нужно собраться: «заморозиться» → стабилизироваться →перестать улучшать/развивать, чтобы как-то суметь обрисовать границы необходимого → разработаться и перейти → обжиться, внеся правки, а дальше радостно продолжать работать и развиваться.
При этом процесс размазывается на ХХ команд и возникает множество вопросов…
Что требуется-то?
Как всё найти?
Как ничего не потерять?
Кто за что отвечает?
Как все собрать, разделив?
Надо разбираться
Полезли мы тогда в документацию. Тексты и документация — классная штука…Но черт возьми в ней можно закопаться. Из документации родились «схемы».
Вот некая схема интеграции и связей внутри самой системы.
Можно выделить отдельно БД и интерфейсы (платформу/модули и разные публичные сервисы — thrift, soap, rest). Почти у каждого модуля есть своя схема в БД. Некоторые модули внутри себя вызывают другие, и так мы получаем, что внутри системы есть множество нелинейных связей.
Публичные сервисы под собой всегда вызывают модуль интернет-банка (старого). Потребителей сервисов может быть много, как извне, так и внутри системы.
Тут было важно найти связи, какими данными оперируют те или иные сервисы, в каких схемах БД это лежит, на что аффектят. То есть кроме процессной части, у нас есть и миграция данных.
Как корректно мигрировать данные, если много потребителей?
Нужно сначала немного разобраться и выделить функциональные области, понять куда и какие данные можно положить, как их заполнять, как их передавать при первичном наполнении, как апдейтить…
Потом понять как собирать эти данные в аналогичные сервисы, ведь контракты мы не меняем, и то что происходило в одной системе монолита, будет происходить в Х системах.
То есть сначала надо провести первичную аналитику до уровня связей по данным, далее понять, какое целевое решение по хранению определить, какие методы нужны, с какими данными нужно работать и запланировать работы.
И не забывать, что нужно будет реализовать интеграционный сервис, который пройдется про ХХ методам и соберёт информацию в нужном объёме и переедет в нужный формат. А так как не все потребители готовы переходить на новые сервисы, нужно сохранить исходный контракт.
Основным сложным вопросом остается работа с учетными данными. Как корректно поделить существующие сервисы по текущим командам в новом интернет-банке? Говоря «учетные данные», нужно понимать, что это ряд настроечных параметров — роли, статус блокировки и тд.
Если разбираться в блокировках старого банка и целевых решениях, возникает много вопросов. Точно ли так нужно делать или есть какое-то другое решение? Чей это бизнес процесс и кто может блокировать данные?
На картинке ниже попробовала собрать первично какие связи есть у уполномоченного лица и у юридического лица. Синие круги слева — это попытка показать, что блокировать можно через публичный сервис или в самой админке старого банка. К какой команде это относится, кстати? Вопрос…
Встречи, встречи, встречи
Начали мы тогда встречаться с разными командами и оповещать, призывать к ответственности, ведь скоро система будет выключена и нам нужно собрать максимальную информацию — о том, что они знают о миграции и какие у них планы, от кого зависят и на кого влияют. Ведь так надо делать по правилам?
Но чем больше наш продукт, тем больше у него проектная команда, и тем сложнее контролировать происходящее. А при миграции ещё сложнее — команды друг о друге мало знают. С учётом того, что люди уходят из компании, иногда мы не найдем истоков создания архитектуры того или иного процесса.
Чем сложнее продукт, тем больше у него заказчиков, тем больше предъявляется к нему требований, больше возникает ограничений и необходимости договариваться между стейкхолдерами, и находить ответственного за каждую из этих позиций.
При этом бывают решения верные и оптимальные с точки зрения архитектуры, но с точки зрения бизнеса — не всегда понятные. И наоборот. Например, разбираясь с сервисами, я нашла, что есть те, которые обновляют или читают определённые данных из одних схем БД, и сталкиваюсь с вопросом, что я не всё могу логически объяснить и придумать кейсы, почему это так. Архитекторы тоже не понимают и задают вопросы. Поэтому в календарик записываем встречу с заинтересованными лицами.
К одной из таких встреч по обсуждению основных процессов работы с уполномоченным лицом и организацией, на стыке бизнес-подразделений, архитектуры и команд разработки, готовила схему ниже. Цель в том, чтобы внутри (ключевое слово) себя навести порядок и суметь конструктивно задавать вопросы, и объяснить сложности.
В рамках данной встречи сейчас ведется переписка по обсуждению процессов вокруг этих процессов. Собрано много коллег в получателях, но так больше шансов, что все заинтересованные в процессах и реализации смогут повлиять на процесс и знать актуальную информацию по необходимому ему процессу.
Смутное время, «переход от одного к другому», развивает в нас стойкость и повышает коммуникабельность, доверие жизни и высшим смыслам!
А кто вообще такой — аналитик в миграции?
Не столько «художник» схем, но человек, который ищет ответы на вопросы:
Какие цели и задачи, планы, сроки?
Кто ответственный в переходный период?
У кого аккумулируется вся информация и зависимости?
Как уследить за всей логикой функционала и всеми интеграциями, которыми оброс монолит за время своей жизни?
Писать сервис как проксю или писать свою логику лишь без изменений контракта?
Точно ли можно отключить уже старый функционал?
Нужна ли еще синхронизация?
И всё равно всё опять сводится ко встречам и обсуждениям.
Команды много сил и времени вкладывают в обсуждение и планирование того, что делать и как, но, условно никто не берет ответственность за весь процесс целиком. Каждый, условно, понимает один кусок, а как это будет все вместе выглядеть…По пути разберёмся.
Множество вопросов и большая неопределенность, которую нужно как-то осветить, а многомерную реальность разложить в чёткие планы и сроки. Потом поставить цели и достичь их в назначенный дедлайн! Да, есть проектный менеджер для достижения целей, но он смотрит на процесс с одной стороны с идеей достижения цели, а аналитик с другой и чуть приземлённее понимает технические процессы.
Разбираемся. Например, мы сделали выгрузку по упоминанию сервисов старого ИБ в репозитории банка. Получили предположительный список потребителей. Но тут есть нюанс что-то может быть не задеплоено в прод или что-то уже выведено. Надо искать ответственных и разбираться в процессах, в вызовах.
А дальше узнали, что есть проекты, которые реализуются вендорами и тогда у нас нет доступа к коду и проверке…
Ещё получилось достать выгрузку по вызовам внешних сервисов в логах нашей системы. Конечно с особенностями (авторизации при вызове сервисов у нас нет), но все таки так можно увидеть точно, что дёргают.
Ещё договорились получить выгрузку по вызовам от нагрузочников. По их выгрузке стало понятнее с каких хостов вызывают.
И так, сопоставляя, я нашла нюанс, что есть тесты на проверку работы системы, где вызываются определенные урлы, прописанные в БД.
Таким образом, у нас есть 3 выборки, что вызывается в старом интернет-банке, с условным понимаем кто потребитель. В то же время был проведен небольшой опрос основных команд и получены их ответы. Это была только часть, основные сложные клубки все не вскрывались.
На основе выгрузки стало лишь понятнее, что потребителей больше и что часть сервисов безхозная и никто в них не хочет погружаться. Попытки зайти со стороны бизнеса, со стороны архитектуры непонятны, потому что нужно обоснование и понимание текущей логики, гипотез как это должно быть в новых условиях. Никто не горел желанием погружаться в это всё.
На энтузиазме и интересе погрузилась и начала потихоньку двигать сложные процессы, подсвечивать серые зоны. Составили список ответственных по сервисам старого интернет-банка на основе того, кто главный потребитель, чья функциональная область и источников данных.
Приходя в команды, всегда возникал вопрос «Куда нужно переходить, на что менять?» и был ответ — «Вам самим нужно найти решение». Теперь же на вопросы потребителей, появилась рекомендаци:
Пообщаться с командой ответственной за функциональную область, они подскажут целевое решение.
Предложить пересмотреть процессы.
Обсудить с архитектором как это делать.
Далее одно из важных вещей внести в бэклог задач и корректно спланировать реализацию целевого решения и период на переход сторонних систем на него.
Команды зачастую не знают, что дёргают старый ИБ, поэтому креативность наша все. Как собрать серые пятна и их осветить? Без разбора просто писать письма не вижу смысла, но определенно нужно зафиксировать договорённости и иметь их подтверждение.
И опять всё сводится ко встречам.
Мне здесь важно занимать срединный путь — быть союзником на пути решения сложной задачи: организовать встречи, обсудить сложности, разбираться с каждой интеграцией, с каждым вызовом.
Потому что тут и так много фактов, которые могут повлиять, и важно иметь картину в целом, и разбирать каждый вызов. Нет неважных сервисов пока не проведён полный анализ задачи, дублей, потребители-источников вызовов, количества вызовов, оценки влияние на заполнение БД, интеграций к БД за этими данными, смежных сервисов.
Особенно, если выносятся данные БД. Работать с данными нужно аккуратно, важно их не потерять, и иметь возможность работать из старой и из новой системы. Только в момент полного принятия решения об отказе от старого ИБ можно забить и ограничить работу с данными и с сервисами потребителями данных.
В нашем случае задача осложнена ещё тем, что нужно оставить рабочим старый фронт (хотя бы на время), а новый фронт имеет свой аналог в виде мобильного приложения. Получается 3 фронта и условно 3 бэка :) Кажется, всех клиентов в мгновение ока не переключить на новое приложение.
И что тогда?
Миграция в 2 этапа
Решение — делить миграцию на 2 этапа: клиентскую, с точки зрения фронта, и с точки зрения бэка, логики и работы функционала/всех интеграций. Хорошо это или нет? Не знаю — нужно делать экономическое обоснование — прикинуть.
Попробуем:
нужно железо для разворачиваний достаточных мощностей для новой системы;
нужно рассчитать нагрузку;
оценить затраты на модернизацию и репутацию (учтя и репутационные риски);
оценить завоевание лояльности клиента;
оценить повышение его удовлетворенности, ведь новое чаще бывает более удобное — так скажем, юзер френдли, но есть часть клиентов, которая привыкла к стабильности, которые слишком консервативны и переходить не захотят;
оценить поддержку двух систем сложности в поддержке и в отслеживании соответствия функционала;
оценить затраты на работы и команды развития/миграции;
и учесть другие критерии.
В общем, в клиентской миграции важно находить именно тех потребителей, которые будут удовлетворены использованием нового фронта или тех, которые не заметят разницы! Важно следить за тем, что доработки не затронули привычного функционала или сделали его лучше, ухудшения потребительских свойств- недопустимо. Контроль клиентского пути и метрик — наше все!
Можно ли построить новое на обломках старого?!
А может и не надо мигрировать?
Чем плох старый монолит? Основная проблема — его сложно поддерживать («больно» вносить изменения), так как:
Появляются новые процессы, и необходимость их автоматизировать, и новые «хотелки» — потребности клиентов, которые невозможно «впихнуть» в монолит.
Нет спецов, которые стояли у истоков, и никто не знает, как это работает, точнее не понимает как изменить, не поломав всё (конечно, же всё можно сделать при наличии важнейших ресурсов — времени и денег)
Отсутствие полной и понятной документации. Мы это уже поняли.
ПО было разработано вендором, и его поддержка или уже закончилась или что-то аналогичное — у нас нет исходного кода.
А ведь монолитная архитектура не так уж и плоха, и в своих кейсах она имеет плюсы. Зачастую разработать фронтальную часть намного проще, чем бэк с учётом всех необходимых интеграций и требований заказчика, поэтому нередко принимается решение об изменении фронтальной части с использованием старого бэк-а (ведь это быстрее, а иногда и дешевле).
Если смотреть в перспективу, то в какой-то момент у нас получается «полтора продукта», а со временем должно стать два самостоятельных продукта. Под фразой «полтора продукта» подразумеваются два фронта, которые смотрят и используют один бэк. С точки зрения разработки это все-таки bad practices, потому что поддерживать сложнее и т.д.
Сейчас мир «быстрый» и с изменениями нужна необходимость простой и гибкой разработки и доработки проектов, поэтому от монолита отказываемся.
Реинжиниринг или полный перенос?
Существует расхожее мнение, что реинжиниринг и миграция не могут идти вместе. С одной стороны, можно с этим согласиться, а с другой — важно посмотреть на процессы иначе.
На практике данный вопрос нужно рассматривать со многих сторон:
С точки зрения бизнес-процессов и их актуальности/корректности. Часто найти полные требования на функционал невозможно, при миграции приходится разбираться в коде и писать новую документацию на старый функционал. И только так можно понять куда и как идти дальше!
С точки зрения реальной оценки возможности разобраться в требованиях/коде и понять, что в них и почему так, а может проще что-то новое сделать. Разобраться в старом коде иногда сложно, порой невозможно, иногда человеческий фактор играет роль (разный бэкграунд и прозорливость сотрудников). Точнее логически разработчик может найти что-то, а вот обосновать с точки зрения бизнеса, почему это так, а не иначе — вряд ли.
С точки зрения стека технологий старого и нового, совместимости и легкого перехода.
С точки зрения фронтальной реализации, клиентского пути. Но… есть вопрос насколько важен данный функционал, насколько он критичен и сможем ли мы открывать его сразу на всех, возможен ли откат… Как подстраховаться во множестве рисков?!
С точки зрения необходимости доработок других систем, готовы ли они к изменениям или нужно оставить интеграции как есть. Чаще целевое решение команды реализуют в несколько этапов, начиная с минимальных изменений в текущей логике, сохраняя логику и контракт взаимодействия, чтобы после просто поменять endoint, протестировать и внедряться на бой!
Миграция может идти как ребрендинг — реинжиниринг — накрутка функционала, если все готовы принять риски — сроков/стоимости/целесообразно/отстроить процесс.
Наша миграция движется
Вы только подумайте какой сложный и насыщенный путь мы прошли, чтобы дойти до этой статьи. Сколько навыков нужно было освоить, сколько выборов сделать…
За каким-то «простым» действие лежит множество подготовительных, второстепенных, вспомогательных процессов. Но потребителю главное результат, чтобы все работало, а что внутри никого не волнует. Как и заказчику — он желает получить результат, а как это будет достигнуто, это другой критерий и не всегда важный.
Поэтому со стороны бизнеса, конечно, намного проще собрать бэклог задач бизнесовых — фронтовых задач, а не разбираться что же под капотом, что с данными, что с базой данных, что с сервером, с бэком, админкой… Где грань технической картинки и потребительского восприятия, кто за что отвечает, кто что должен знать и понимать?
Эх.
Наша миграция движется, я потихоньку превращаюсь в мастера Екселя: сведение и выведение разных табличек, сопоставление разно уровневых выгрузок, в которых нахожу нюансы, противоречия и «интересные» факты, которые не могла себе представить.
Мы собрали файл с сервисами.
Собрали какую-то выгрузку по логам.
Собрали выгрузку по вызовам проходящим через систему учета нагрузки и запилили «программульку», которая по Гиту ищет наши сервисы.
Получили какой-то результат опроса команд…
И вот у нас есть разнородная информация и нужно по ней собрать план. Надеюсь мы справимся.
Ведь я столкнулась с тем, что некоторые программы на аутсорсе и у нас просто нет исходников, некоторые программы могут использовать одни и те же креды для вызовов сервисов (у нас не было предусмотрено авторизации при вызове сервисов),
логи ограничены по времени — сроком хранения.
Анализируя, возникает множество вопросов! Но так я начинаю видеть картину шире и могу более взвешенно предлагать сервисы для выключения.
Вместо вывода
Проект идет и заканчиваться не собирается. Что я извлекла для себя из опыта проекта:
создайте свой список, того что нужно учесть;
обозначьте чёткие границы проекта/цели и задачи;
соберите команду, определите роли и разделите ответственность;
назначьте человека, отвечающего за процессы и коммуникации, который будет отслеживать зависимости и вести, в целом, проект;
лучше работать спринтами, так удобнее корректировать планы;
постройте матрицу зависимостей задач/команд;
имейте таблицу источников и сбора информации;
имейте матрицу контроля сроков и планов;
создайте таблицу с заинтересованными людьми, которые более-менее в курсе происходящего;
создайте матрицу ответственности и компетенций;
проводите общие встречи;
давайте разным командам хоть немного познакомиться с чужими задачами, особенно тем, кто активно включен в процессы миграции;
закладывайте риски;
взаимодействуйте с командой старого ПО;
умейте отказывать и находить аргументы или другие решения — креативность;
будьте готовы, что сроки поедут;
информируйте всех кого может задевать изменение (ребята могут подсветить нюансы);
повторяйте и будьте готовы, что ваши идеи не всегда воспримут на ура: я достаточно долго убеждала, что стоит перепланировать и посмотреть на задачу шире, и потихоньку подкидывала аргументы в эту сторону.
