Сложности IT-инфраструктуры. Что произойдет, если с ростом интернет-магазина не менять внутренние процессы

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

СЕО ecom-продакшна Ctrlweb Николай Резун рассуждает о том, как понять, что инфраструктура онлайн-магазина сдерживает ваше развитие — и что лучше всего сделать в этой ситуации.

Чем плохи устаревшие веб-сервисы?

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

Три основных опасности, к которым приводит использование устаревших веб-сервисов:

1. Сложность и высокая стоимость изменений. Классический пример: магазин строился на CMS, годами разработчики что-то переделывали, добавляли куски кода. В итоге получилась сложная система — "монолит", которая существует в единичном экземпляре. Чтобы сделать из нее то, что хочет заказчик, нужно долго вникать в инфраструктуру. А потом делать кастомные изменения и подставлять "костыли" — иначе все может просто сломаться. 
2. Проблемы с масштабированием. Доработки коробочного решения, которые делают на этапе создания и первоначального роста интернет-магазина, могут удовлетворять потребности маленького или даже среднего бизнеса. Но когда начинается серьезное развитие, например, выход на новые рынки, сложная логика становится ограничением.
3. Риск утечек. Разработчики платформ постоянно ищут уязвимости и способы их устранения. Выходят обновления, с помощью которых можно обезопасить магазин. Но вот в чем проблема: из-за того, что большинство участников рынка ecom используют сильно модифицированные платформы, эти обновления не всегда могут нормально установиться и действительно решить вопрос с уязвимостями.

Мы видим, как это влияет на информационную безопасность магазинов в России. Только за последнее время произошли утечки у таких крупных игроков, как "Буквоед", "Леруа Мерлен", "Твое", "Едим Дома", "Аскона", Gloria Jeans, "Ашан" и "Твой дом". И одной из причин могло стать использование устаревшей версии платформы, которая была настольно сильно модифицирована, что ее крайне сложно обновить. 

Признаки того, что система устарела

Первый признак того, что вы уперлись в возможности старой инфраструктуры — неспособность быстро вносить изменения, тестировать гипотезы. Например, вы хотите провести A/B-тест или добавить новый способ доставки, но разработчики называют какие-то нелепые сроки —недели или месяцы. Или нельзя быстро подключиться к новому маркетплейсу. Или вы видите, что все конкуренты уже используют омниканальность, а вы только пытаетесь ее настроить в рамках своей архитектуры. Это сигналы о том, что нужно срочно что-то менять, причем глобально.

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

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

Как все исправить: три подхода

Для начала давайте разберемся, на каких подходах строятся современные интернет-магазины:

• Выделять для каждой логической задачи отдельный сервис. Для заказа, каталога, системы лояльности и так далее. В таком случае система не выглядит как монолит, а представляет собой некую сеть, состоящую из слабосвязанных сервисов.
• Отделять фронтенд и бэкенд. При этом подходе фронт — сайт, мобильное приложение, другие каналы взаимодействия с клиентами — и бэкенд магазина логически отделяются друг от друга. Можно быстро и удобно вносить изменения в каждый из них, не затрагивая все остальное.
• Composable e-commerce. Такой способ создания интернет-магазинов — это результат эволюции и взаимодействия двух предыдущих подходов. С помощью composable вы можете подключать уже готовые независимые сервисы и собирать из них магазин, как из элементов конструктора Lego. Чтобы это сработало, ваша архитектура должна быть изначально продумана с учетом такого метода разработки и с опорой на предыдущий подход . 

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

Разработать новый сайт с нуля 

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

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

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

Провести реплатформинг 

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

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

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

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

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

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

Не делать ничего

Да, это тоже решение, которое будет оптимальным для некоторых интернет-магазинов. В какой ситуации? Если CAPEX и OPEX — стоимость создания и последующего обслуживания IT-системы — не компенсируется прогнозируемым ростом доходов. Например, рынок маленький, или ваш магазин лишь является дополнением к основному бизнесу: терять эти деньги все равно не хочется, но и вкладываться в развитие нет смысла.

Тогда есть два основных выхода: 

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