Проектирование решений на основе выявленных проблем
~ 10 минут
После выявления узких мест разрабатывают решения для их устранения: выбирают стратегии миграции, создают дорожную карту и планируют постепенные изменения. Это снижает риски, повышает эффективность и позволяет создать гибкие архитектуры, адаптирующиеся к меняющимся потребностям бизнеса.
Преобразование унаследованной тесно связанной среды в современную распределённую архитектуру — поэтапный процесс. После выявления причин задержек выхода на рынок, зависимостей между командами, конфликтов данных и монолитных циклов выпуска важно найти методы для плавного перехода.
В этом уроке рассмотрим ключевые подходы — Parallel Run, High-Level Design и Branch by Abstraction. А ещё разберёмся, как разработать технологическую дорожную карту для постепенной миграции.
Основные подходы к разработке решений
Эти подходы вы уже изучили: у каждого в основе лежит своя идея — и все по-разному влияют на риски. Разберёмся, как их применяют команды для решения задач миграции.
High-Level Design — высокоуровневое проектирование в реальных средах
Высокоуровневое проектирование согласует сервисы, базы данных и системы интеграции с бизнес-доменами и целями. С помощью сегментирования ответственности, определения границ и проектирования с ориентацией на домен (DDD) компании заменяют монолиты гибкими экосистемами сервисов.
Например, раньше HealthConnect объединяла учётные записи пациентов, биллинг и аналитику в единой базе. Высокоуровневая реорганизация разделила домены на два: записи и карты пациентов, проверку страховки и формирование счетов. Вместо единой таблицы
Patient_Info, используемой всеми командами, внедрили сервисы и базы для хранения данных о пациенте и для выставления счетов. Это сократило количество противоречивых данных и помогло согласовать системные модули с опытом работы.Parallel Run — снижение риска за счёт контролируемого перехода
Параллельный запуск старой и новой систем обеспечивает безопасность. Компания проверяет производительность, соответствие и удобство новой архитектуры до отключения старой. Обе системы получают входные данные, а их выходные данные сверяются.
Например, HealthConnect запустила новый сервис составления расписания приёмов параллельно с монолитной системой. Обе системы три месяца обрабатывали запросы, результаты сравнивали, выявляли расхождения, обеспечивали согласованность данных — постепенно доверие к новой системе укреплялось. После стабилизации работы старый модуль отключили с минимальными перебоями.
Другой пример — банк внедрил новую систему кредитного скоринга и запустил её параллельно с прежней. Обе оценивали кредитные заявки, а результаты регистрировались. Со временем точность и скорость работы нового механизма стали удовлетворять банк — и он отключил старый без риска принятия неверных кредитных решений.
Branch by Abstraction — инкрементная миграция компонентов
Метод Branch by Abstraction включает добавление слоя абстракции для унаследованной системы и поэтапную замену компонентов без ущерба для потребителей. Это снижает риск «большого взрыва» и обеспечивает плавный рефакторинг.
Например, в HealthConnect логика чтения записей пациентов была связана с монолитной базой данных. После внедрения слоя абстракции, например API PatientService, фронтенд и другие сервисы перестали напрямую обращаться к старой базе. Под этим слоем HealthConnect постепенно заменила старые вызовы базы новым микросервисом, получающим данные из специализированного сервиса. Когда все взаимодействия переключились на абстракцию, соединение с базой данных удалили. Изменения были изолированы в рамках абстракции — это минимизировало простой и ошибки.
Разработка плана перехода
Разработка решений включает планирование изменений, инструментов и мер безопасности — нужно составить план перехода. Он определяет приоритеты, сроки внедрения новых компонентов и процедуры миграций и откатов при проблемах.
Как искать узкие места в системе и расставить приоритеты, вы уже знаете. Давайте разберёмся в других этапах.
Поэтапное переключение
Переход от старой системы к новой лучше осуществлять поэтапно. Например, HealthConnect после обеспечения стабильной параллельной работы и проверки корректности постепенно направила больше трафика от старого модуля планирования к новому микросервису.
Наблюдение за метриками — задержками, количеством ошибок, отзывами пользователей — помогло определить время перехода на микросервис. На каждом этапе можно было получить информацию и при необходимости откатиться назад. Такой пошаговый подход минимизировал риски.
Глобальное туристическое агентство, к слову, тоже перешло с устаревшей системы бронирования на современную контейнерную микросервисную среду. Сначала оно направило 10% бронирований через новую систему. Спустя неделю стабильной работы показатель увеличили до 50%. Только убедившись в стабильном успехе, агентство полностью отказалось от старой системы. Постепенное переключение позволило предотвратить катастрофу из-за сбоя в одной точке.
Планирование отката — подстраховка на случай непредвиденных проблем
Проблемы могут возникнуть даже если миграция спланирована хорошо. С планом отката команда может вернуться к старой системе, если новое решение не соответствует стандартам производительности, соответствия или эксплуатации.
Например, HealthConnect разработала и задокументировала процесс отката — на случай, если новая служба планирования ошибалась в распределении назначений. План был такой:
- Восстановить старые правила маршрутизации и направить весь трафик обратно в монолитный модуль планирования.
- Повторно синхронизировать все обновления данных за тестовый период.
- Переоценить и устранить выявленные проблемы перед очередной попыткой инкрементного перехода.
Это сохранило доверие пациентов и сократило время простоя.
Проблемы и решения
Есть несколько типичных проблем при миграции в новые системы — к ним нужно быть готовыми. Разберём основные.
1. Распределение ролей и зон ответственности
Проблема
В новой архитектуре сеньоры занимаются только инфраструктурой, а джуны — бизнес-логикой. Общих точек взаимодействия и обмена опытом нет — качество бизнес-функций страдает, а инфраструктура слишком усложняется.
Как помогает закон Конвея
Если организационно команды выстроены так, что команда или группа экспертов замкнуты сами на себе и не пересекается с другими, то архитектура системы станет отражением этих разрывов. Сервисы будут проектироваться с учётом интересов отдельных групп, а не целостной картины.
Что делать
Вариантов несколько. Например, можно определить одного сеньора, который будет сопровождать реализацию логики; или организовать регулярные встречи между командой проектирования и командой реализации.
Есть радикальное решение — реформировать команды в кросс-функциональные группы. Каждая будет отвечать за конкретный домен или микросервис целиком: от бизнес-логики до деплоя и мониторинга. Микросервисы станут максимально автономными, а в их командах будут все необходимые компетенции. Архитектура станет модульной и будет отражать структуру небольших, но полных по навыкам команд. Это снизит риски провисания качества на стороне бизнес-логики или инфраструктуры — теперь есть общая ответственность и обмен знаниями внутри одной команды.
2. Обеспечение согласованности данных между старой и новой базами данных
Проблема
При параллельном ведении старого и нового решений нужна сложная система синхронизаций и ночных сверок — у команд, отвечающих за старую и новую базы, нет чёткой коммуникационной связки.
Как помогает закон Конвея
Если команды старой и новой систем мало пересекаются или взаимодействуют фрагментарно, архитектура передачи данных и механизмы синхронизации будут сложными и фрагментированными. Это приводит к неэффективному распределению ответственности.
Что делать
Создать общую группу или «треугольник» взаимодействия — в ней будут специалисты старой и новой баз и доменные эксперты с глубоким пониманием бизнес-процессов.
Команда будет совместно прорабатывать архитектуру миграции, настраивать понятные потоки репликации, разрабатывать единый интерфейс взаимодействия.
Итоговая архитектура синхронизации данных будет проще, логичнее и прозрачнее — в её основе будет лежать налаженная коммуникация между теми, кто отвечает за каждую сторону. Архитектура станет отражением налаженной организационной структуры, а не хаотичных линий между изолированными «столпами».
3. Недоучёт observability и инструментов мониторинга
Проблема
Сеньоры концентрируются на бизнес-логике, а наблюдаемость отдана на откуп джунам или вовсе игнорируется. Инфраструктура и сервисы не подготовлены к поддержке в продакшне, плохое логирование, отсутствует централизованный мониторинг.
Как помогает закон Конвея
Если организационная структура не предусматривает роль или команду, ответственную за наблюдаемость, или такой ответственности нет внутри кросс-функциональных команд, то архитектура наблюдаемости будет отражать эту «безответственность». Разные части системы будут логировать по-своему, не будет единой системы метрик и алертинга.
Что делать
Есть два варианта. Первый — выделить платформенную команду для инструментов мониторинга, логирования и алертинга. Она будет тесно взаимодействовать со всеми командами.
Второй — встроить людей с компетенцией в observability в каждую кросс-функциональную команду. Тогда архитектура мониторинга станет отражением такой коммуникации: появятся стандарты логирования, единый стек мониторинга и чёткие процессы обработки инцидентов.
4. Параллельный запуск и обеспечение согласованности данных
Проблема
Старая и новая системы работают параллельно. Данные пишутся в две базы данных, требуется сложная система сверок. Отсутствие целостной картины архитектуры приводит к хаотичным интеграционным решениям.
Как помогает High-Level Design
Во-первых, High-Level Design поможет определить архитектурный паттерн миграции данных — например, Strangler Fig. При нём новые сервисы постепенно перехватывают потоки данных.
Ещё он позволит предусмотреть централизованный Data Gateway или Data Proxy, который будет транслировать запросы в обе базы, а со временем — постепенно переключаться только на новую.
И последнее — с этим подходом можно отразить механизм синхронизации и консистентности на диаграммах высокого уровня до того, как начнётся детальная реализация. Это позволит вовремя понять, какие подсистемы нужны для обеспечения целостности: где нужны интерфейсы или API, а где можно использовать внутренние шины данных для асинхронной синхронизации — например, Kafka.
Пример
В компании Spotify или Netflix при масштабировании и миграциях между системами сначала разрабатываются архитектурные схемы высокого уровня. В них показываются потоки данных, точки интеграции с Legacy-компонентами и способы их поэтапного замещения. Эти схемы служат ориентиром при принятии мелких технических решений.
5. Тестирование производительности и регрессии перед переключением на новую систему
Проблема
Новая система разрабатывалась долго. К моменту ввода может быть неожиданная разница в производительности, логике или реакциях на нагрузку. Если сразу переключить весь трафик, есть риск создать проблемы в продакшне без возможности откатиться.
Как помогает Parallel Run
При параллельном запуске небольшой или зеркальный поток реальных запросов отправляется в новую систему одновременно со старой. Подход позволяет оценить нагрузку, время отклика, потребление ресурсов в реальных условиях.
Если что-то работает медленнее или некорректно, старый сервис продолжает обслуживать пользователей, а новый дорабатывается. Так команда может выявить и устранить проблемы с производительностью или регрессией без критических для бизнеса сбоев.
Пример
Компания, переходящая со старой CRM-системы на новую, запускает параллельный поток запросов к новой CRM. Новая CRM пока не обслуживает «живых» клиентов, но получает копию всех запросов и формирует ответы. Команда сравнивает время обработки и корректность данных, проводит нагрузочные тесты под реальной нагрузкой. Если всё в порядке — плавно переводит реальный трафик на новую систему.
Задание 1
Перенесите утверждения к подходам, для которых они характерны.
Задание 2
Выберите нужный подход для избежания возникновения перечисленных ниже проблем при миграции.
В новой системе не реализованы редкие или специфические для бизнеса процессы из старой системы
Parallel Run
Подход позволяет перед переводом пользователей на новую систему протестировать возможные сценарии поведения пользователей и предусмотреть их.
Система дорабатывается небольшими итерациями, постепенно добавляется новый функционал, который требует тщательного интеграционного тестирования
Новый функционал разрабатывается несколькими командами и требует тщательного тестирования
Branch by Abstraction
Использование подхода Branch by Abstraction помогает избежать дополнительных доработок системы в процессе миграции. Использование прокси-сервиса с таким же API позволяет переключать на него клиентов и постепенно дорабатывать новый сервис.
Новые системы разрабатываются на новом стеке технологий, для реализации которого в командах не хватает экспертизы
High-Level Design
Использование данного подхода позволит определить долгосрочное видение. Важно вовлечь стейкхолдеров. Например HR, и подсветить в какой период времени потребуются от сотрудников компетенции, которыми сейчас не владеют сотрудниками, и совместно проработать решения — обучение действующих специалистов, найм новых, изменения в выборе технологий и другие.
После запуска новая система не справляется с нагрузкой, система периодически становится временно недоступной
Parallel Run
Подход позволяет определить возможности новой системы. Например, провести Load Testing, сфомулировать по его итогу необходимые доработки системы и реализовать их совместно с разработчиками и инженерами.
Итоги
- Преобразование тесно связанной среды в распределённую архитектуру — поэтапный процесс. Плавно и беспроблемно перейти помогают три ключевых подхода — High-Level Design, Parallel Run и Branch by Abstraction, а также закон Конвея.
- High-Level Design применяет архитектурные принципы. Используется для концептуальной перестройки архитектуры. Уточняет долгосрочное видение, но требует большего предварительного планирования.
- Parallel Run запускает старую и новую системы одновременно для проверки новой архитектуры. Снижает риски, но увеличивает затраты на обслуживание.
- Branch by Abstraction позволяет постепенно переносить компоненты, изолируя изменения. Снижает риски рефакторинга и упрощает реализацию через небольшие шаги.
- Разработка решений включает планирование изменений, инструментов и мер безопасности. План перехода определяет приоритеты, сроки внедрения новых компонентов и процедуры миграций и откатов при проблемах.
- План должен включать шесть этапов — подготовку, расстановку приоритетов, определение этапов, определение механизмов переключения, инкрементные шаги и планирование отката.
- Резюмируя — разработка целевых решений на основе выявленных узких мест требует сочетания архитектурных подходов, методов снижения рисков и тщательного планирования. Успех возможен благодаря постепенным изменениям, чётким этапам миграции и надёжным планам на случай непредвиденных обстоятельств.