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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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