6 минИнтеграцииРазбор

790 товаров, которых не было на сайте полгода

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

У торговой компании работала синхронизация с учётной системой. Логи чистые, задачи выполняются по расписанию, ошибок нет. Никто ничего не подозревал, пока мы не сверили каталог целиком.

Оказалось: 161 живая позиция была скрыта на сайте как архивная, у 353 позиций врал остаток, а целый раздел на 790 товаров не показывался покупателям с марта. Полгода эти товары лежали на складе и не продавались через сайт — просто потому, что их там не было видно.

Почему так вышло

Синхронизация была инкрементальной: раз в несколько минут она спрашивала у учётной системы «что изменилось после такого-то времени» и обновляла эти позиции. Быстро, экономно, логично. И структурно слепо.

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

  • товар заархивировали — синхронизация этого не увидит, на сайте он останется как был;
  • товар вернули из архива — тоже не увидит, на сайте он так и будет скрыт;
  • товар удалили — не увидит, карточка останется висеть.

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

Как это ищется

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

Здесь легко ошибиться и удалить лишнее. В нашем случае первый прогон показал «1687 призраков» — карточек, которых якобы нет в учётной системе. На деле это были комплекты: они лежат в другой сущности, и запрашивать их нужно отдельно. Если бы мы доверились цифре и почистили каталог, потеряли бы полторы тысячи живых позиций.

Правило простое: прежде чем что-то удалять по результатам сверки, проверьте, из какого источника берётся каждая группа строк. Расхождение чаще означает ошибку в сверке, чем мусор в данных.

Что сделали

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

После первого же прогона на сайт вернулись 790 товаров, а покупатели перестали видеть позиции, которых нет на складе.

Как проверить у себя

Если у вас интернет-магазин, связанный с учётной системой, ответьте на три вопроса.

  • Сколько активных позиций в учётной системе прямо сейчас и сколько карточек показывает сайт? Цифры должны сходиться.
  • Что происходит на сайте, когда товар отправляют в архив? Проверьте вручную на одной позиции.
  • Когда последний раз сверялись остатки целиком, а не по изменённым товарам?

Если ответа нет ни на один вопрос — расхождение почти наверняка уже есть. Оно не проявляется падением сайта: просто часть товара не продаётся, а часть заказов приходит на то, чего нет на складе.

Самые дорогие поломки — не те, что роняют сайт, а те, что работают годами и тихо не показывают половину ассортимента.
Счётчик аналитики, который не работал ни дняМетрика была установлена, код на месте, ошибок в консоли нет. И ни одного визита в статистике. Причина — одна строчка, из-за которой браузер подменял функцию счётчика тегом скрипта.31% звонков не попадали в отчёты, и никто этого не виделРуководитель каждый вечер получал сводку по работе отдела продаж. Сводка врала: треть разговоров в неё не входила, а один сегмент был завышен втрое. Причина оказалась в одной строке кода.