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

Двери, слишком узкие для вилочного погрузчика, — это проблемы планировки, и они возвращаются, как бы хорошо вы ни организовывали пространство. Платформа сдерживает рост только тогда, когда ограничение сохраняется несмотря на лучшие практики внедрения. Что именно имеет место в вашем случае, зависит от фактов из вашего собственного магазина.

Является ли ваша платформа электронной коммерции узким местом? Короткий ответ

Проводите реплатформинг только тогда, когда у вас есть ограничение платформы, то есть предел, который возвращается несмотря на качественное внедрение; ограничение внедрения исчезает, как только вы исправляете код, конфигурацию или инфраструктуру. Медленное оформление заказа и дорогие релизы выглядят в зале заседаний совершенно одинаково.

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

Проблема платформы или плохое внедрение? Правило классификации

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

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

Правило применимо к каждому признаку:

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

Как выглядит плохо созданный магазин: исключите это в первую очередь

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

Каждая ошибка оставляет ранний след в профилировании или трассировках:

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

Все, что остается после устранения этих ошибок, является кандидатом в ограничения платформы, и только этот остаток имеет отношение к обоснованию миграции.

Признак 1: Сохраняется ли узкое место после теста на отключение?

Тест на отключение отключает ваши пользовательские модули и расширения, а затем проверяет, сохраняется ли узкое место; если да, то вы столкнулись с ограничением платформы. Говоря языком склада, вы очищаете собственные стеллажи и проверяете, продолжают ли заедать двери.

Запустите его на промежуточной копии (staging) с производственным каталогом и воспроизведением пикового трафика. Установите каждый целевой показатель перед началом, чтобы результаты нельзя было оспорить позже. Четыре контрольные точки:

Если целевые показатели достигаются на «голой» платформе, ошибка кроется в вашем коде, конфигурации или инфраструктуре. Такая проблема беспорядка переедет вместе с вами на любую новую платформу. Если целевые показатели по-прежнему не достигаются, переходите к Признаку 2.

У теста есть «слепые зоны». Некоторые модули невозможно отключить, поскольку от них зависит бизнес (например, движок промоакций), поэтому успешный проход доказывает скорость ядра, но не то, что оно поддерживает ваши требования. Синтетический трафик также пропускает реальные вызовы ERP и платежных систем.

Сбой индексации все еще может быть следствием нехватки ресурсов инфраструктуры, поэтому масштабируйте ресурсы, прежде чем считать сбой окончательным.

Признак 2: Выполняете ли вы требования только путем переопределения ядра?

Выполнение требований исключительно за счет переопределения ядра сигнализирует об ограничении платформы, если точек расширения не существует вообще, и об ограничении внедрения, если штатный механизм никогда не был настроен.

Переопределения ядра «ломаются» при следующем крупном мажорном обновлении. Исправленные классы и шаблоны расходятся с изменениями разработчика платформы, конфликты при слиянии накапливаются, а оценки стоимости обновления начинают превышать оценки функционала. В результате команды откладывают обновление. Отложенный путь обновлений заканчивается прекращением поддержки, когда исправления безопасности прекращаются, а разработчики расширений теряют совместимость.

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

Прежде чем считать требование пробелом, сначала проверьте штатный механизм:

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

Признак 3: Исчезает ли поддержка или путь обновления?

Исчезающая поддержка или сужающийся путь обновления являются ограничением платформы только тогда, когда ни одно исправление на уровне стека не способно это исправить. Все остальное из этого списка обычно является техническим долгом внедрения, который выглядит как риск вендора.

Окончание поддержки вендором — это чистый случай платформы. Как только разработчик перестает выпускать патчи безопасности для вашей мажорной версии и не предлагает поддерживаемого преемника на вашей архитектуре, качественная инженерия тут бессильна. Magento 1 — яркий тому пример. Механика ухода описана в руководстве по миграции с Magento на VTEX.

Компромиссы, признак за признаком:

Риск ключевого сотрудника — это проще всего перепутать. Единственный сопровождающий — это кадровый пробел. Он становится сигналом платформы только тогда, когда вы не можете нанять второго инженера по рыночным ставкам.

Само по себе небольшое сообщество не является основанием для миграции. Движок со слабой поддержкой все еще может работать хорошо, но он также может вас подвести, поэтому перед принятием решения проведите тест на отключение.

Признак 4: Уперлись ли вы в жесткий архитектурный предел или лимит лицензии?

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

Примените этот тест к каждому кандидату в лимиты:

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

Запустите тест на отключение перед этой проверкой. Лимит, которого вы достигаете только из-за пользовательских модулей, — это проблема сборки, и миграция перенесет эту проблему на следующую платформу. Лимит, который сохраняется при отключенных расширениях и исчерпанном потенциале тюнинга, является ограничением платформы, и на следующем этапе он заносится в реестр затрат.

Признак 5: Является ли стоимость изменений несоразмерно высокой?

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

Ограниченный эксперимент по очистке позволяет разделить их:

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

Если время выполнения и количество регрессий снижаются, значит, затраты были связаны с техническим долгом, а ограничение кроется в реализации. Если они остаются на прежнем уровне, каждое изменение по-прежнему затрагивает общий код платформы или противоречит пути обновления. Это указывает на структурные затраты и на саму платформу.

Здесь действуют два нюанса. Одна область и несколько релизов — это небольшая выборка, поэтому воспринимайте результат как направление, а не как доказательство. Кроме того, команда без покрытия тестами должна сначала написать тесты, иначе количество регрессий будет измерять отсутствие тестов, а не поведение платформы.

Признак 6: Сокращаются ли результаты оптимизации?

Результаты оптимизации сокращаются, когда каждый раунд настройки снижает p95 задержки в часы пик меньше, чем предыдущий, а разрыв до целевого показателя пиковой нагрузки сохраняется.

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

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

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

Признак 7: Есть ли у платформы модель для ваших следующих двух лет?

У платформы есть модель для ваших следующих двух лет, когда она добавляет рынки и B2B-канал посредством конфигурации, без создания скопированного экземпляра для каждого рынка. Если камнем преткновения является B2B-канал, сравнение ведущих платформ для B2B-коммерции покажет, насколько далеко каждая из них позволяет продвинуться за счет одной лишь конфигурации.

Правило классификации применимо и здесь. Если для плана требуется повышение потолка лицензионного тарифа или переопределение ядра, ограничение заключается в платформе. Если конфигурация охватывает план, а ваша сборка — нет, это вопрос реализации.

Возьмем гипотетический план с предполагаемыми сроками: второй рынок на 6-й месяц, B2B-аккаунты с согласованными прайс-листами на 10-й месяц, третий рынок на 14-й месяц. Сравнение двух путей выглядит следующим образом:

При скопированном подходе каждое обновление безопасности, обновление версии и исправление оформления заказа применяются отдельно для каждого экземпляра, и эти копии начинают расходиться. Такое расхождение представляет собой разрастание пользовательских подсистем, а стоимость изменений для каждой функции увеличивается с каждой копией.

Сопоставьте задокументированные ограничения платформы в отношении витрин магазинов, локалей и функций B2B с вашим планом. Аудит магазина выполняет эту проверку на основе вашего кода и уровня контракта.

Исчезли ли бы 10 главных статей расходов на новой платформе?

Десять крупнейших статей расходов за прошлый год исчезнут на новой платформе только в том случае, если они вызваны ограничением платформы; остальные последуют за вами на новую платформу.

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

В таблице показано, как распределяются типичные статьи расходов:

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

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

Остаться или мигрировать: что показывает сравнение на горизонте 2-3 лет?

Сравнение вариантов «остаться или мигрировать» работает, когда вы оцениваете три варианта на одном и том же горизонте в 2-3 года: остаться и оптимизировать, мигрировать и базовый сценарий «ничего не мигрировать». Базовый сценарий — это то, что команды часто пропускают, и именно он делает два других варианта объективными.

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

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

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

Оцените вариант «остаться и оптимизировать» как целевые исправления для элементов, которые тест на отключение отнес к реализации. Оцените миграцию как затраты на сборку, параллельный запуск и риски. Миграция побеждает только тогда, когда базовые затраты плюс блокируемая ими выручка превышают оба альтернативных варианта.

Компромиссы в зависимости от ситуации:

Миграция не исправляет плохие процессы. Команда без автоматизированных тестов, CI/CD или четкого владения кодом каталога и оформления заказа воссоздаст те же затраты на изменения на новой платформе.

Базовый вариант побеждает чаще, чем предполагают бюджеты на миграцию, особенно для небольших магазинов. Члены нашей команды неоднократно наблюдали это в своих предыдущих компаниях до прихода в Netguru: магазины, которые просили о спасении от ненадежного IT-поставщика, часто переставали нуждаться в миграции, как только была исправлена пятая часть их худших проблем.

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

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

Что включает в себя и предоставляет аудит магазина от Netguru?

Аудит магазина от Netguru оценивает ваш репозиторий и конфигурацию развертывания по более чем двадцати параметрам и предоставляет первый отчет, готовый к принятию решений, примерно через неделю после предоставления доступа к репозиторию.

Эти параметры включают архитектуру, качество кода, безопасность, производительность, инфраструктуру, интеграции, путь оплаты, соответствие требованиям GDPR и доступность, которые суммируются на карте состояния. Внутри них аудиторы ищут переопределения ядра, особенности индексации каталога и связанный фронтенд монолита. Именно в этих трех областях ограничение платформы и ограничение реализации выглядят абсолютно одинаково со стороны.

Каждая высокоприоритетная находка независимо подтверждается три раза. Она имеет уровень критичности, уровень достоверности, местоположение в коде и предлагаемое исправление. Ваша команда может взять найденное в работу как тикет, и вы сможете увидеть, находится ли исправление внутри реализации или указывает на саму платформу.

В отчете совету директоров и технической команде предоставляются одинаковые данные:

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

Работа выполняется в три этапа:

Первый отчет (около одной недели): анализ репозитория и развертывания с выводами по наиболее критическим проблемам.
Полный аудит (2–4 недели): к проверке кода добавляются бизнес-семинары и воркшопы с ИТ-отделом. Продолжительность зависит от масштаба, объема системы и количества приложений.
Необязательный второй этап: нагрузочное тестирование, профилирование запросов к базе данных и тест на проникновение. Они позволяют определить 95-й перцентиль (p95) задержки в часы пик и показать, какие запросы и эндпоинты падают первыми.

Рекомендация всегда сопоставляется с базовым сценарием «отказа от миграции». Таким образом, предложение о миграции должно быть экономически выгоднее сохранения текущего состояния магазина, а решение «исправить реализацию» также должно превосходить его по эффективности.

Заключение: проверьте план помещения перед переездом

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

Аудит разделяет эти два фактора и сопоставляет результат с вариантом отсутствия миграции, поэтому совет директоров получает рекомендацию, которую может профинансировать или отклонить. Если платформенное ограничение сохраняется, VTEX — одна из платформ, которую стоит рассмотреть, а руководство по платформе VTEX описывает степень ее соответствия. Если ограничений нет, вы оставляете текущую платформу и исправляете сборку.

Чтобы получить такой ответ для своего магазина, запросите аудит магазина.

Часто задаваемые вопросы

Как понять, что проблема именно в вашей платформе электронной коммерции?

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

Сколько времени занимает аудит платформы электронной коммерции?

Первый готовый к принятию решений отчет может быть готов вскоре после того, как команда получит доступ к репозиторию, в то время как полный аудит магазина с бизнес-воркшопами и техническими семинарами занимает несколько недель. Диапазон сроков зависит от объема работ, масштаба системы и количества приложений. Нагрузочное тестирование, профилирование и тест на проникновение представляют собой необязательный второй этап, который увеличивает время выполнения.

Поможет ли миграция на новую платформу исправить медленное оформление заказа?

Миграция исправит медленное оформление заказа только в том случае, если этот процесс успешно пройдет тест на отключение. Оформление заказа, замедленное синхронным вызовом платежной системы, налогового сервиса или ERP, неиндексированным запросом или наслоением переопределений ядра, обычно переносится и на новую платформу. Сначала замерьте p95 задержки в пиковые часы, чтобы бюджет не тратился на проблему, которая просто воспроизведется в новом стеке.

Что включает в себя аудит интернет-магазина?

Аудит магазина оценивает архитектуру, качество кода, безопасность, производительность, инфраструктуру, интеграции, платежный шлюз, соответствие требованиям GDPR и доступность. Аудит изучает индексацию каталога, переопределения ядра и кастомные подсистемы путем прямого анализа репозитория. Каждая обнаруженная проблема сопровождается предлагаемым решением, а рекомендация оценивается в сравнении с вариантом отказа от миграции, чтобы совет директоров мог сравнить варианты сохранения текущего состояния и переезда.

Можно ли исправить плохие процессы путем реплатформинга?

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