Выгрузка из 1С стёрла половину каталога

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

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

Дальше выяснилось, что пропало примерно четыре тысячи позиций из восьми. Половина каталога.

Разберём, что произошло, почему сработало не сразу, во что это обошлось и что нужно было сделать заранее.

Как это выглядело

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

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

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

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

В понедельник утром обнаружили. К этому моменту прошло почти трое суток.

Почему никто не заметил раньше

Здесь несколько причин, и все они типичные.

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

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

Сайт работал. Главная открывалась, разделы открывались, формы работали. Внешне всё было в порядке.

Выходные. Самое неудачное время: сотрудники не работают, а покупатели ищут.

Не было контроля числа позиций. Простейшая проверка — сравнение количества товаров с предыдущим днём — не выполнялась.

Статистику никто не открывал в выходные. А там уже было видно: посещаемость каталога упала, число просмотров карточек товаров рухнуло.

Что пришлось делать

Понедельник ушёл на разбор и восстановление.

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

Это важный момент: копии были, а толку от них не было — потому что глубина хранения составляла одни сутки.

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

Часть данных восстанавливали руками. Описания, изображения, привязки к разделам. На это ушло около двух недель работы двух человек.

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

Во что это обошлось

Считали в три захода.

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

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

Стоимость восстановления. Две недели работы двух сотрудников плюс работа подрядчика.

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

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

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

Где были ошибки

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

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

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

Нет уведомлений об итогах. Никто не получал сводку по результатам обмена.

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

Нет контроля числа позиций. Простая проверка, которая обнаружила бы всё за минуты.

Нет уведомления при резком падении посещаемости раздела.

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

Обмен выполняется в пятницу ночью. Худший день: если что-то пойдёт не так, обнаружится в понедельник.

Уникальные данные хранятся только на сайте. Описания и фотографии, добавленные вручную, нигде не дублировались.

Что сделали после

Компания провела работу над ошибками. Вот что настроили.

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

Мягкий режим вместо удаления. Товары, отсутствующие в выгрузке, не снимаются сразу, а помечаются и остаются на сайте несколько дней. Если они не вернулись в следующих выгрузках — тогда снимаются.

Уведомления об итогах. После каждого обмена в мессенджер приходит короткая сводка: обновлено столько-то, добавлено столько-то, помечено к снятию столько-то.

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

Проверка восстановления раз в квартал. Копия разворачивается на тестовой площадке, проверяется работоспособность.

Перенос обмена на будни. Ночь со вторника на среду вместо пятницы.

Согласование работ. Любые изменения в справочниках складской программы согласуются с ответственным за сайт.

Контроль числа позиций. Ежедневная автоматическая проверка с уведомлением при резком изменении.

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

Как это связано с продвижением «3 в 1»

История про обмен данными кажется сугубо технической, но потери были во всех трёх каналах.

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

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

2ГИС. То же самое: переходы были, результата не было.

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

Похожие истории, которые случаются по той же схеме

Описанный случай не уникален. Механизм один и тот же: автоматика делает ровно то, что ей велели, на основании неверных данных, и никто этого не видит.

Прайс поставщика пришёл пустым. Автоматический импорт обнулил цены на весь раздел. Товары продавались по нулевой стоимости несколько часов, пока не заметили.

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

Сменили единицы измерения. Товар, продававшийся штуками, стал считаться упаковками. Цены на сайте оказались в разы ниже реальных.

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

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

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

Во всех случаях лечение одинаковое: порог на массовые изменения, уведомления об итогах, мягкое снятие вместо жёсткого удаления и резервные копии с достаточной глубиной хранения.

Как выстроить безопасный обмен

Разберём, как должен быть устроен обмен, чтобы подобное не повторялось.

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

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

Мягкое снятие. Отсутствующие в выгрузке товары не удаляются, а помечаются. Снятие происходит только после нескольких подряд выгрузок без них.

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

Журнал обмена. Что изменилось, сколько, когда. С хранением истории.

Уведомления. Короткая сводка после каждого обмена ответственному сотруднику.

Возможность отката. Состояние каталога до обмена сохраняется, чтобы можно было вернуться.

Тестовый прогон. Крупные изменения в учётной системе сначала прогоняются на тестовой копии сайта.

Что проверить у себя

Если у вас настроен обмен с учётной системой, пройдите этот список.

1. В каком режиме работает обмен: снимаются ли товары, отсутствующие в выгрузке.
2. Есть ли защита от массовых изменений — порог, при превышении которого обмен останавливается.
3. Приходят ли уведомления об итогах каждого обмена.
4. Какая глубина хранения резервных копий — за сколько дней назад можно откатиться.
5. Проверялось ли хоть раз, что копия разворачивается.
6. В какой день недели и в какое время выполняется обмен.
7. Согласуются ли работы в складской программе с ответственным за сайт.
8. Есть ли контроль числа товаров с уведомлением при резком изменении.
9. Дублируются ли где-то описания и фотографии, добавленные вручную на сайте.
10. Кто получит сообщение о сбое в выходной день и что он должен сделать.

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

Итог

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

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

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

Если у вас настроен обмен с учётной системой и вы не уверены, что он защищён от подобного, специалисты компании «Сайты Профессионально» проверят настройки обмена, добавят ограничения на массовые изменения, наладят уведомления и резервное копирование с проверкой восстановления. Обращайтесь за бесплатной консультацией — лучше потратить час на проверку, чем две недели на восстановление.