Стоимость монолита: полное руководство по оценке за один день

Когда речь заходит о миграции с монолитной архитектуры на микросервисы, первый и самый сложный вопрос — «С чего начать?». Часто проект останавливается на этапе оценки: слишком сложно, слишком дорого, слишком рискованно. Однако существует методика, которая позволяет за один день провести первичную, но структурированную оценку стоимости и сложности монолита. Это не даст точной сметы, но предоставит четкую картину для принятия стратегического решения.

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

Утренняя сессия начинается с анализа кодовой базы. Цель — понять структуру и связанность. Используйте инструменты статического анализа кода для вашего языка программирования. Ключевые метрики: количество строк кода (SLOC), цикломатическая сложность модулей, количество внешних библиотек и их версии. Но главное — визуализация зависимостей. Постройте граф модулей/пакетов. Ищите «звезд» — модули, от которых зависит большая часть системы, и «изоляты» — независимые модули. Изоляты — лучшие кандидаты для первого выноса в сервис. Оцените состояние тестового покрытия. Монолит с высоким покрытием модульными и интеграционными тестами мигрировать в разы дешевле и безопаснее.

Вторая сессия посвящена данным. Монолит часто использует единую базу данных. Необходимо нарисовать схему БД и проанализировать связи между таблицами. Определите, какие сущности «принадлежат» каким бизнес-доменам (например, пользователи, заказы, каталог товаров). Оцените объем данных и паттерны доступа: какие таблицы чаще всего читаются, в какие пишутся. Проанализируйте транзакции, которые затрагивают несколько доменов — они станут главной проблемой при разделении базы. Используйте логи запросов, чтобы понять реальные связи, которые могут быть неочевидны из схемы.

После обеда переходите к инфраструктуре и зависимостям. Как монолит развернут? Это один WAR-файл, исполняемый бинарник или набор скриптов? Каковы требования к ресурсам (CPU, память, диск)? Запустите нагрузочное тестирование (даже краткое) на прод-like среде, чтобы зафиксировать базовые метрики производительности. Далее составьте карту внешних зависимостей: сторонние API, очереди сообщений, сервисы аутентификации, SMTP-серверы. Поймите, как монолит взаимодействует с ними. Также зафиксируйте все «скрытые» зависимости: конфигурационные файлы, переменные окружения, файлы на диске.

Финальная сессия — синтез. Соберите все данные в единую таблицу или доску (Miro, Mural). Начните с выделения бизнес-возможностей (Business Capabilities). Сопоставьте с ними модули из анализа кода и сущности из анализа данных. Теперь у вас есть карта потенциальных сервисов.

Оценка стоимости происходит по трем осям: Сложность выноса (технический долг, связанность), Бизнес-ценность (частота изменений, критичность для бизнеса) и Риск. Разделите потенциальные сервисы на четыре квадранта: 1) Низкая сложность, высокая ценность (быстрые победы), 2) Высокая сложность, высокая ценность (стратегические проекты), 3) Низкая сложность, низкая ценность (кандидаты на отложенный вынос), 4) Высокая сложность, низкая ценность (кандидаты на рефакторинг внутри монолита).

Итогом дня должен стать документ, содержащий: 1) Карту модулей и их связанности, 2) Карту данных и транзакционных границ, 3) Список инфраструктурных зависимостей, 4) Приоритизированный список кандидатов на выделение в сервисы с примерной оценкой сложности (в story points или человеко-неделях), 5) Список ключевых рисков и архитектурных проблем (например, распределенные транзакции).

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