250 000 SKU от 200+ арендаторов: каталог, который собирает себя сам

Мы делали этот проект дважды. И во второй раз спроектировали его принципиально иначе — потому что за это время у него изменился масштаб. Это кейс не столько про PIM, сколько про то, как объём данных ломает архитектуру, которая была для него не предназначена, и что с этим делать.

Коротко о проекте

Клиент	Торговый комплекс «Тандем», Ярославль
Отрасль	Товары для дома, дачи и ремонта; управление коммерческой недвижимостью
Задача	Единая витрина 200+ магазинов-арендаторов на сайте торгового комплекса
Решение	OpenPIM + 1С-Битрикс: Управление сайтом, редакция «Бизнес»
Масштаб	250 000+ SKU, 200+ независимых источников данных
Стек	PHP 8.1, Bitrix VM 9, CentOS Stream 9, JavaScript, S3-совместимое объектное хранилище
Срок по сайту	61 рабочий день. Модуль «Каталог товаров» сознательно вынесен в отдельный этап
Проект	tandem76.ru

Результат: было и стало

Показатель	Было	Стало
Обработка товарных данных	До 100 часов ручной работы в неделю	Автоматически, около 2 часов в неделю на контроль
Кто обрабатывает фиды	Сам Битрикс: и витрина, и импорт в одном контуре	Выделенная PIM-система на отдельном сервере
Импорт каталога	На больших объёмах падал или подвешивал сайт надолго	Стабильно держит 250 000+ SKU, загрузка дельтами
Форматы поставщиков	Зоопарк файлов и ручная правка каждого	Любой формат, автоматический маппинг по правилам
Скорость обновления цен	Через ручную выгрузку, дни	10 минут от файла поставщика до витрины
Характеристики товаров	5 полей «размер», 10 «диаметр», 25 «цвет»	Единый управляемый справочник атрибутов
Доступ к правкам	Все контент-менеджеры в админке сайта — риск поломки	Только PIM. Доступ в админку сайта у одного человека
Хранение изображений	На сервере сайта, расход дискового пространства	Отдельное S3-хранилище
Восстановление после сбоя	Не регламентировано	RPO — 24 часа, RTO — 4 часа

Предыстория: витрина, которая переросла свою архитектуру

Несколько лет назад первую версию сайта и товарной витрины разрабатывали мы же. Тогда всю работу с данными закрывал сам 1С-Битрикс: он был и витриной, и предобработчиком фидов от арендаторов — по сути выполнял роль PIM-системы.

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

А потом проект вырос. Не по плану, а по факту: 200+ арендаторов, 250 000 SKU и, что важнее количества, сотни уникальных свойств товаров, свои у каждого поставщика. Именно эта комбинация нагружала Битрикс так сильно, что ему переставало хватать любых мощностей.

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

Год назад клиент вернулся.

Точка входа: что мы получили год назад

• Собственный проект в бэкапе. Живой, рабочий, но на стеке, который за два года успел устареть: CentOS 7, Bitrix VM 7.5, PHP 7.4.
• Интерактивная схема комплекса, оставшаяся от периода внутренней разработки. Без документации, без связи с разработчиками: как именно она работает, не знал никто. Логику восстанавливали по коду.
• Требование к схеме — полная автономность. Она должна остаться кликабельной, вести в карточки магазинов и перестать зависеть от разработчиков, чтобы контент-менеджеры сами меняли SVG и привязывали магазины через админку.
• Сроки. Как обычно — «вчера».
• Тот самый ручной труд. Команда контент-менеджеров тратила до 100 часов в неделю, чтобы обработать и вывести на сайт товары. Это полторы ставки, занятые только копипастом.

Этап 1. Реанимация и фундамент

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

Что сделали

• Подняли бэкап и обновили платформу: CentOS 7 до CentOS Stream 9, Bitrix VM 7.5 до Bitrix VM 9, PHP 7.4 до PHP 8.1. Развернули тестовое окружение, перенесли данные без потерь.
• Настроили безопасность: белый список адресов для админки, проактивная защита, двухфакторная аутентификация, отключение доступа root по SSH, ограничение попыток авторизации, резервное копирование в два независимых хранилища.
• Переработали дизайн и вёрстку: главная, магазины и бренды с плиткой, списком, фильтрами и поиском с подсказками, акции и новости, раздел «Арендаторам» с каталогом свободных объектов и формами заявок, фотогалерея, UI Kit.
• Разобрали и перезапустили интерактивную схему комплекса: SVG-карта с привязкой магазинов по идентификаторам, переключение этажей, фильтрация по категориям, всплывающие подсказки. И главное — контент-менеджеры управляют ею сами, без разработчиков.
• Перенесли на продакшн, выпустили сертификат, настроили аналитику, SEO и карту сайта, обучили администраторов и оставили документацию.

Сайт сдали за 61 рабочий день — и сознательно без модуля «Каталог товаров». Каталог вынесли в отдельный этап. Это и было ключевое архитектурное решение всего проекта: не пытаться повторить первую версию.

Этап 2. Каталог: свалка из фидов на входе, «всё по полочкам» на выходе

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

Документации не существовало исторически, поэтому мы провели входной аудит, восстановили логику по коду, разработали техническое задание — и на его основе выбрали связку OpenPIM и 1С-Битрикс.

Почему отдельная PIM, а не снова Битрикс

Потому что мы уже знаем, где у этой схемы предел. CMS — прекрасная витрина и плохой ETL. Обработка 250 000 SKU с разнородными свойствами — это не задача сайта, это отдельная инженерная задача, и решать её нужно на отдельном сервере, отдельным инструментом, по своему расписанию. Тогда пиковая нагрузка на импорте физически не может уронить витрину: они больше не живут в одном контуре.

Почему именно OpenPIM

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

Что сделали на стороне PIM

Принимаем всё, что дали.

• YML по ссылке, Excel, CSV, парсинг сайта поставщика.
• Поставщик прислал кривой файл? PIM его пережуёт, а контент-менеджер поправит за минимум действий: есть редактор карточки товара с групповыми правками и массовыми обновлениями.

Умный маппинг.

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

Работа без рук.

• Загрузка дельтами: забираем только изменения. Не нужно каждый раз тащить 250 000 товаров и класть этим сервер. Это ровно то, чего не было в первой версии.
• Планировщик сам ходит по адресам поставщиков и забирает файлы выгрузок.
• Обработка ошибок: битая строка логируется, но в каталог не публикуется. Один кривой товар не ломает всю выгрузку.

Что сделали на стороне 1С-Битрикс

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

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

Архитектура и надёжность

• Отдельный сервер для сайта, отдельный — для PIM. Тяжёлая обработка данных больше не конкурирует за ресурсы с посетителями.
• Изображения вынесены в S3-совместимое объектное хранилище: они не занимают место на сервере, клиент не платит за гигабайты картинок на дорогом NVMe.
• RPO — 24 часа, RTO — 4 часа. Максимальная потеря данных при аварии — сутки, полное восстановление сервиса — четыре часа. Зафиксированные цифры, а не обещание «постараемся быстро».
• Мониторинг нагрузки сам предупреждает администратора, когда пора расширять серверное пространство. Никто не сидит и не смотрит в графики вручную.

Почему это было сложно

• 200+ независимых источников данных, ни один из которых нельзя заставить выгружать правильно. Арендаторы разные: маленькие и большие, технически подкованные и не очень, понимающие ценность каталога и те, у кого «можно, а зачем?». Единственный рабочий путь — принимать любой формат и нормализовать его на своей стороне.
• Интерактивная схема комплекса досталась от периода внутренней разработки без документации и без связи с разработчиками. Логику восстанавливали по коду.
• 250 000 SKU — тот объём, на котором наивная реализация импорта убивает сайт. Мы это знали не в теории. Дельта-загрузки и разделение серверов здесь не украшение, а условие работоспособности.

Что это дало бизнесу

• Экономия. Больше не нужно нанимать пять менеджеров для заливки фидов и сопоставления данных. Освободившиеся 100 часов в неделю команда тратит на контент и продажи, а не на копипаст.
• Управляемость. Арендатор сменил цену — через 10 минут она на сайте. Не «в следующую выгрузку», не «на неделе».
• Масштабируемость. Комплекс может добавлять новые форматы сбыта, интегрироваться с внешними системами и растить количество SKU. Новый канал сбыта — несколько часов настройки в PIM и интеграция формата с Битриксом, а не новый проект с нуля.
• Надёжность. S3-хранилище и загрузка дельтами означают, что сайт не ляжет ни в чёрную пятницу, ни в новогоднюю распродажу — то есть ровно тогда, когда падение стоит дороже всего.
• Поддержка под рукой. С проектом на постоянной основе работает наша команда сопровождения. У клиента уже есть идеи по развитию проекта — и есть команда, которая может их реализовать.

Главный вывод

Проблема была не в Битриксе. Проблема была в том, что нагрузку такого порядка никто не закладывал при старте проекта — её просто не существовало. Архитектура — это функция от масштаба, а не вопрос вкуса. Решение, идеально работающее на 20 000 SKU, разваливается на 250 000. Это не дефект платформы, это предел, который не был обозначен на входе.

Если ваша товарная база собирается из десятков внешних источников, вопрос не в том, какой у вас движок сайта. Вопрос в том, есть ли между поставщиками и витриной слой, который отвечает за качество и объём данных. Пока SKU немного, этот слой можно не строить, и это будет правильным решением. Но у него есть предел, и лучше знать его заранее, чем встретиться с ним во время распродажи.

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

Хотите так же?

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

• Поднимем PIM под любой зоопарк форматов.
• Разберёмся с чужим кодом без документации и с любым наследством, которое досталось вам от предыдущей команды.
• Настроим S3, чтобы вы не платили за гигабайты картинок на боевом сервере.
• Посчитаем, где предел вашей текущей архитектуры, — до того, как вы в него упрётесь.