Обмен с 1С ломается: как стабилизировать сопровождение Битрикс

Утром отдел продаж замечает пустоту: заказы с сайта не появляются в 1С. Накануне «чуть подкрутили» обмен — поле, фильтр, время выгрузки, обработку свойства. Правка казалась мелкой. Тестовый контур не было. Регрессионной проверки сценария «заказ → оплата → документ в учётной системе» тоже не было. К обеду уже считают упущенную выручку, спорят «это веб или 1С» и ищут, кто последний трогал интеграцию.

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

Разберём, как обычно ломается exchange, какие ошибки делают команды и как выстроить сопровождение, чтобы «мелочь» не останавливала продажи и не превращала пятничный релиз в понедельник без выручки.

Как exchange умирает в реальной жизни

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

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

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

Типовые ошибки, из-за которых чинят дольше

Нет тестовый контур с копией обмена. Любая правка сразу бьёт в боевой поток заказов. Откат превращается в ручной квест по бэкапам, воспоминаниям и чатам «как было вчера».

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

Логи смотрят только после паники. Агенты падают неделями, письма об ошибках уходят в спам технического ящика, который никто не читает. К моменту симптома в продажах след уже холодный.

Зона ответственности размыта: «это 1Сники», «это веб», «это хостер». Пока спорят, заказы не идут. Нужен единый владелец интеграционного контура и понятный порядок эскалации с обеих сторон учёта и сайта.

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

Практический порядок, когда обмен уже сломан

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

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

Сверьте время последней успешной синхронизации, объём очереди и свежие записи в журналах сайта и-1С. Часто корень виден за пятнадцать тридцать минут-—-если журналы доступны, часы синхронизированы и кто-то умеет читать оба контура, а не только-«свой».

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

После восстановления-—-короткий постмортем: что изменили, почему не поймали на тесте, какой контроль добавить, кто теперь владелец. Без этого через месяц история повторится с другой-«мелкой» правкой в другой пятницу.

Как не ломать обмен в следующий раз

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

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

Подключите наблюдаемость: алерт, если нет успешного обмена-N-минут; если растёт очередь; если доля ошибок выше порога; если расходятся контрольные суммы по остаткам. Узнать о поломке от клиента-—-уже провал процесса, а не-«неудачный день».

Планируйте обновления Битрикс и конфигурации-1С как совместные окна с владельцем обмена, а не как независимые активности двух отделов. Большинство-«внезапных» поломок-—-следствие несогласованных изменений.

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

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

Бизнес результат, а не «починили агент»

Стабильный exchange — это непрерывность продаж и складской правды. Цены и остатки совпадают, заказы не теряются между сайтом и 1С, отдел не сидит на ручных выгрузках в Excel и не спорит с бухгалтерией о том, какой документ «настоящий».

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

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

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