Как перестроить e-com-платформу и не парализовать бизнес
Пройдя путь от товарного контента до разработки, архитектуры программного обеспечения и руководства технической командой, я смотрел на одну платформу с разных сторон — как специалист, которому нужно связывать технические решения с задачами бизнеса.
Компания работает преимущественно в B2B: производит и поставляет профессиональное оборудование и мебель. Для такого бизнеса интернет-магазин — это не только страницы товаров и форма заказа. За ними находятся ассортимент, данные поставщиков, правила работы с ценами и остатками, корпоративные системы и сотрудники, которые ежедневно используют результат работы платформы.
Разработку новой e-commerce-платформы мы начали примерно в 2020 году, а в конце 2022 года запустили ее в production. Она продолжает развиваться и сейчас. Этот опыт заставил меня иначе ответить на вопрос, который в начале большого проекта кажется довольно простым: что именно мы меняем, когда решаем заменить интернет-магазин?
Старая система еще работает, но развивать ее все труднее
Решение о новой платформе редко возникает в день, когда старая полностью перестает работать. В нашем случае прежняя система продолжала обслуживать покупателей и сотрудников, но уже не соответствовала масштабу и долгосрочным задачам бизнеса. Ограничения касались производительности и масштабирования, растущего каталога и данных поставщиков, автоматизации цен и остатков, интеграций и внедрения нового функционала.
Поэтому новая платформа задумывалась не как замена оформления сайта, а как основа для дальнейшей работы с каталогом, поставщиками, заказами и интеграциями. При этом новая архитектура сама по себе не определяет, какая система отвечает за цену товара и что должно происходить при ошибке в данных поставщика.
Какие процессы стоят за страницей товара
Посетитель видит карточку товара: название, характеристики, цену, наличие, фотографии, возможность оформить заказ. Для бизнеса это результат работы нескольких связанных процессов. Данные о товаре должны появиться в каталоге, пройти обработку, получить нужный контент и отобразиться на сайте. Цена и остаток могут изменяться независимо от описания. Заказ после оформления становится частью дальнейшей работы сотрудников и корпоративных систем.
Когда проект ограничивают формулировкой «сделать новый сайт», значительная часть этих связей остается за пределами первоначального обсуждения. Затем выясняется, что изменение правил обработки данных поставщика влияет на каталог, обновление цены — на требования к актуальности страницы, а изменение внутреннего процесса — на то, какая информация нужна сотруднику в административном интерфейсе.
Я не стал бы представлять все эти зависимости одной универсальной схемой: в каждой компании они устроены по-своему. У нас платформа связана с товарным каталогом, контентом, поставщиками, ценами, остатками, заказами, CRM, 1С и внешними сервисами. Уже сам состав этих связей показывает, почему при проектировании недостаточно описать только страницы сайта и доступные пользователю функции.
Рис.1. E-commerce-платформа как часть цифрового контура бизнеса
Перед большой модернизацией полезно описать не только путь пользователя по сайту, но и путь данных: откуда они появляются, где меняются, через какие системы проходят и кто обнаружит ошибку при расхождении. Эти ответы определяют требования к интеграциям и эксплуатации не меньше, чем макеты страниц.
На этапе подготовки новой платформы я участвовал в анализе существующей системы, формировании требований и подготовке технического задания. В дальнейшем этот документ использовался как основа для работы с командами разработки. Но даже подробное ТЗ не может раз и навсегда описать живой бизнес: ассортимент, процессы и внешние сервисы продолжают меняться после запуска.
Бизнес-задачу приходится переводить на язык систем
Бизнес обычно формулирует желаемый результат. Ему нужны актуальные цены и остатки, меньше ручной работы, страницы, которые быстро открываются, и система, которую можно развивать без постоянных сбоев. Руководитель коммерческого направления не обязан указывать, какой API нужен разработчикам и на каком уровне следует хранить кэш.
Работа технического руководителя начинается между исходной просьбой и техническим заданием. Нужно выяснить, какие данные участвуют в процессе, откуда они поступают, кто с ними работает и какое поведение системы бизнес считает правильным. Только после этого можно обсуждать архитектуру и разработку.
Один пример — работа с прайс-листами поставщиков. Бизнес-задача состояла в том, чтобы уменьшить объем ручных операций и поддерживать на сайте актуальные цены и наличие. При разборе стало понятно, что у поставщиков различаются структуры данных. Напрямую загружать такие сведения в основную платформу было нельзя: сначала требовались сопоставление товаров и настройка правил обработки цен и остатков.
Для решения этой задачи мы выбрали отдельную внешнюю систему обработки прайс-листов. В системе данные поставщиков подготавливаются и сопоставляются с каталогом, после чего результат передается в e-commerce-платформу.
Рис.2. Упрощенный поток обработки данных поставщиков
Задачу сокращения ручной работы нельзя было решить одной кнопкой импорта: сначала требовалось определить, как неоднородные данные поставщиков станут пригодными для использования в основном каталоге.
Другой пример появился уже по мере роста платформы. Нужно было ускорять загрузку страниц и одновременно сохранять актуальность каталога, цен и другой динамической информации. Универсальное правило кэширования не давало бы одинаково подходящего поведения для всех страниц и данных. Поэтому в платформе используются разные уровни кэша — Nginx, Next.js и прикладное кэширование, а динамические и пользовательские разделы требуют отдельных правил.
В ходе эксплуатации необходимо было анализировать эту схему, разбирать конфигурацию Nginx, поведение серверного рендеринга и кэшей приложения, анализировать серверные логи и причины появления устаревших данных. Именно такие production-задачи постепенно изменили мой взгляд на кэширование: его недостаточно рассматривать только как способ ускорения сайта.
Технические детали этой схемы заслуживают отдельного разговора. Для текущей темы существеннее другое: «ускорить сайт» и «показывать актуальную цену» — две бизнес-потребности, которые нельзя рассматривать по отдельности. Решение о кэшировании одновременно становится решением о допустимой задержке обновления данных, способах диагностики и порядке действий при изменении информации.
Оба примера показывают, почему техническое задание не должно быть буквальным переводом первой просьбы бизнеса. Оно должно фиксировать результат анализа: какое поведение требуется, какими данными система располагает и какие ограничения придется учитывать в эксплуатации.
Данные часто оказываются сложнее реализации функции
С товарными данными сложнее, чем с отдельной функцией: они приходят из разных источников, имеют разную структуру и меняются с разной частотой. В нашем проекте это особенно заметно на работе с поставщиками. Даже при технически работающей интеграции остаются вопросы: какой источник считается основным, где проверяется сопоставление товаров и как обнаружить некорректное обновление?
Я бы сформулировал необходимый разговор так: сначала определить источники и владельцев данных, затем правила их изменения и контроля, и только после этого закреплять ответственность систем. Для каждого важного потока следует понимать, какие операции проходят автоматически, где требуется участие сотрудника и что считается ошибкой.
После запуска новой платформы каталог вырос примерно с 40–50 тыс. до свыше 96 тыс. товаров; число поставщиков, данные которых требуется обрабатывать, — примерно с 40 до 98. Эти цифры показывают масштаб работы системы, а не эффект одного технического решения. Чем больше объем данных и число источников, тем заметнее цена неоднозначных правил: исправлять приходится уже не отдельную запись, а процесс ее появления и обновления.
При смене команды нужно передавать причины решений
Большая платформа живет дольше, чем отдельный этап разработки. Над проектом, в разные периоды, работали внешние команды. Для длительного проекта смена участников означает риск потери контекста: новая команда получает код и задачи, но не всегда сразу понимает, почему было выбрано именно такое поведение системы.
Мы столкнулись с необходимостью передачи проекта между подрядчиками еще до production-запуска. Чтобы следующая команда могла продолжить работу с достигнутого этапа, я организовал передачу исходного кода, технической документации, доступов, макетов, требований, списка выявленных ошибок и текущих приоритетов. Затем мы продолжили подготовку платформы к запуску: разбирали критические ошибки, поиск, тестирование и производительность.
Без сохраненного контекста новой команде приходится восстанавливать причины решений по косвенным признакам. Документация полезна, когда в ней можно найти актуальный ответ на конкретный вопрос: какие ограничения учитывали при выборе решения, какие системы участвуют в процессе, что уже проверено, а что остается открытым. Техническая преемственность зависит не только от документов. Нужна и роль человека, который сохраняет общую картину проекта и может связать решения разных этапов.
Со временем я стал придавать больше значения записи причин архитектурных решений. Спустя несколько лет само решение может выглядеть странно, если неизвестны условия, в которых его принимали. При этом условия меняются: то, что подходило при запуске, не обязательно остается лучшим вариантом при новом объеме каталога и ином составе интеграций.
Production проверяет не только работоспособность
В конце 2022 года новая платформа вышла в production. Но запуск не завершил архитектурную работу: после него решения начали проверяться реальными данными, нагрузкой, поисковыми системами, внешними сервисами и ежедневной работой сотрудников.
После запуска продолжили технически развивать платформу и разбирать production-задачи. Вместе с командой мы анализировали ошибки и серверные логи, оптимизировали работу базы данных, инфраструктуры и кэширования. Продолжалась работа над поиском, каталогом, фильтрацией и техническим SEO. Эти задачи не обязательно свидетельствуют о неверной архитектуре на старте. У production есть свойство обнаруживать ограничения, которые трудно полностью увидеть до запуска, а бизнес тем временем продолжает ставить новые задачи.
Хороший пример — соотношение скорости и актуальности данных. Кэш помогает ускорять страницы и снижать нагрузку, но после его появления приходится отвечать на новые вопросы. Когда изменение цены станет видно покупателю? Как определить, на каком уровне остались старые данные? Можно ли сбросить нужную часть кэша без затрагивания остального сайта? Чем больше уровней оптимизации, тем важнее способность проследить путь данных до страницы.
Похожая логика действует и для интеграций. Недостаточно знать, что обмен однажды успешно запустился. Через год понадобится понять, какое звено отвечает за конкретную запись, почему она не обновилась и кто может безопасно восстановить процесс. Поэтому мониторинг, логи, диагностика и контроль актуальности данных — часть архитектуры, а не исключительно задачи администрирования после релиза.
Что я сегодня сделал бы иначе
Работающая платформа не означает, что все решения на каждом этапе были оптимальными. Некоторые вопросы стали заметнее уже после запуска и в ходе дальнейшего роста системы. Если бы я снова начинал проект такого масштаба, три темы определил бы раньше и жестче.
Первая — владельцы данных и границы ответственности систем. Для цены, остатка, товарной информации и других значимых данных я бы на старте отдельно зафиксировал основной источник, допустимые преобразования и место, в котором принимается окончательное значение. Это особенно полезно там, где сведения проходят через внешнюю систему обработки и затем попадают в e-commerce-платформу. Когда границы описаны явно, проще обсуждать изменения и искать причину расхождения.
Вторая — документация архитектурных решений. Я бы уделил больше внимания не только описанию устройства системы, но и фиксации причин: какую задачу решали, какие ограничения учитывали, что считали приемлемым компромиссом. Такой контекст нужен прежде всего будущим участникам проекта, в том числе при смене подрядчика. Подробное первоначальное ТЗ важно, но оно не заменяет историю решений, принятых после его составления.
Третья — эксплуатация и наблюдаемость. Мониторинг, логирование, управление кэшем, диагностику интеграций и контроль актуальности данных я бы проектировал вместе с архитектурой платформы. Часть этих решений в реальном проекте приходится добавлять уже по мере появления production-задач. Это возможно, но при раннем проектировании проще определить, какие сигналы нужны для разбора ошибок и кто будет ими пользоваться.
Я не свел бы эти выводы к призыву заранее предусмотреть все. В длительном проекте это невозможно: меняются объем данных, бизнес-процессы и состав команды. Речь о том, чтобы раньше договориться о правилах, которые помогут разбираться с изменениями, когда они неизбежно появятся.
Что проверить перед модернизацией B2B-платформы
Из описанного опыта я бы предложил команде до начала большой разработки пройти семь вопросов. Это рабочая рамка для обсуждения, а не универсальный рецепт для любой компании.
- Какие бизнес-процессы затронет замена платформы? Перечня будущих страниц недостаточно. Нужно увидеть, как сотрудники работают с каталогом, данными поставщиков и заказами.
- Какие системы связаны с e-commerce? Следует перечислить не только очевидные интеграции, но и все места, где информация создается, изменяется и используется.
- Кто отвечает за каждый вид данных? Для цены, остатка, карточки товара и других сущностей нужен понятный источник и порядок исправления ошибки.
- Где проходят границы ответственности систем? Нужно определить, какая система подготавливает сведения, какая хранит или показывает их и где действуют бизнес-правила.
- Можно ли восстановить причины решений? Помимо требований и кода полезно сохранять принятые ограничения, компромиссы и открытые вопросы.
- Как система будет диагностироваться после запуска? Мониторинг, логи, проверка интеграций и управление кэшем нужны для повседневной работы, а не только для аварий.
- Кто будет развивать платформу после релиза? Production-запуск — важный этап, но процессы обновления, сопровождения и передачи знаний продолжаются после него.
Платформа, запущенная в конце 2022 года, остается действующей и развивается вместе с задачами компании. Этот опыт показал мне, что в зрелом B2B-бизнесе e-commerce становится частью операционной инфраструктуры. Поэтому при модернизации недостаточно выбрать технологический стек и реализовать набор функций: нужно понимать, откуда берутся данные, как они проходят через системы и что требуется людям, которые работают с платформой каждый день.
Опубликовано 22.10.2026
