Как контролировать обмен интернет-магазина с 1С: мониторинг и регламент

4 августа 2026 · 20 мин чтения

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

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

Для интернет-магазина нужно отдельно контролировать как минимум два направления:

• каталог, цены и остатки из 1С на сайт;
• заказы и их статусы между сайтом и 1С.

У каждого направления свои расписание, допустимая задержка, доказательство успеха и владелец инцидента.

Коротко

Чтобы не узнавать об остановке обмена по жалобе менеджера:

1. зафиксируйте схему и владельцев обмена;
2. определите источник истины для каждого поля;
3. установите ожидаемое расписание и допустимую свежесть;
4. отправляйте heartbeat только после успешного завершения цикла;
5. контролируйте длительность, объём, ошибки и очередь;
6. проверяйте фактическое применение данных на сайте и в 1С;
7. отслеживайте аномальные массовые изменения;
8. разделите предупреждение, высокий и критический инцидент;
9. не запускайте полный обмен повторно без диагностики;
10. храните хронологию обеих сторон.

Почему обмен ломается тихо

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

Проблему часто замечают косвенно:

• покупатель заказал товар с устаревшим остатком;
• цена на сайте отличается от 1С;
• менеджер не видит интернет-заказы;
• заказ дважды появился в учётной системе;
• статус оплаты или отгрузки не вернулся на сайт;
• новый товар не опубликован;
• отсутствующий в пакете товар неожиданно деактивирован;
• выгрузка идёт несколько часов и блокирует следующий цикл;
• обмен завершился формально, но обработал ноль объектов.

Проверка главной страницы ничего из этого не обнаружит. Даже контроль endpoint обмена отвечает только на вопрос о доступности обработчика, а не о движении данных.

Как устроен обмен 1С и 1С-Битрикс

Конкретная схема зависит от конфигурации 1С, версии модуля, доработок и правил проекта. В типовом контуре 1С-Битрикс использует CommerceML для передачи коммерческих данных.

Упрощённо каталог движется так:

1С
→ подготовка данных
→ формирование пакета CommerceML
→ авторизация и передача на сайт
→ распаковка и пошаговая обработка
→ сопоставление объектов
→ применение товаров, предложений, цен и остатков
→ очистка временных данных
→ завершение цикла

Заказы могут двигаться в другую сторону:

Покупатель оформил заказ
→ заказ сохранён на сайте
→ попал в выборку обмена
→ передан в 1С
→ создан или обновлён документ
→ сопоставлены товары и контрагент
→ номер или статус вернулся на сайт

Официальная документация 1С-Битрикс описывает штатные компоненты импорта и экспорта в формате CommerceML v2. Но в реальном проекте между ними часто появляются кастомные обработчики, очереди, прокси, расписания и правила фильтрации. Их нужно включить в карту, а не считать обмен «одной кнопкой».

Сначала нарисуйте фактическую схему

Перед мониторингом заполните паспорт обмена.

Вопрос	Пример ответа
Какая конфигурация 1С участвует?	УТ, ERP или кастомная конфигурация; точная версия
Какой модуль или обработка выполняет обмен?	Название и версия
Кто инициирует цикл?	1С, cron, агент, внешний оркестратор
Как часто?	Каталог каждый час, заказы каждые 5 минут
Какой транспорт?	HTTP(S), файл, очередь, промежуточный сервис
Какая учётная запись?	Идентификатор без пароля
Где хранятся журналы?	1С, сайт, веб-сервер, Helpdesk
Кто владеет 1С?	Клиент или отдельный подрядчик
Кто владеет сайтом?	Студия
Какой источник истины?	Цена и остаток — 1С; заказ — сайт; статус отгрузки — 1С
Какой допустимый разрыв?	Цена — 90 минут; заказ — 15 минут
Какой обход?	Ручное подтверждение остатка, временный импорт заказов

Если схема неизвестна, сигнал «обмен упал» будет ходить между студией и специалистом 1С без владельца.

Разделите направления и наборы данных

Не используйте один общий статус «синхронизация работает».

Создайте отдельные контуры:

1. товары и разделы;
2. торговые предложения и характеристики;
3. цены по типам;
4. остатки по складам;
5. изображения и файлы;
6. заказы с сайта в 1С;
7. оплаты и отгрузки;
8. статусы из 1С на сайт;
9. справочники и пользовательские поля;
10. контрагенты, если они входят в проект.

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

Три уровня контроля

Уровень 1. Запуск

Проверяет, что регламентное действие началось в ожидаемое время.

Сигналы:

• время последнего старта;
• идентификатор цикла;
• версия обработчика;
• источник и направление;
• отсутствие параллельного незавершённого запуска.

Этот уровень обнаруживает сломанное расписание, выключенную 1С, cron или агент. Но успешный старт ничего не говорит о завершении.

Уровень 2. Техническое завершение

Проверяет, что цикл дошёл до конечного состояния.

Сигналы:

• время окончания;
• статус;
• длительность;
• количество принятых и обработанных объектов;
• количество ошибок и предупреждений;
• размер пакета;
• номер последней обработанной порции;
• отсутствие зависшей блокировки;
• heartbeat после завершения.

Heartbeat нельзя отправлять при старте. Иначе зависшая посередине выгрузка будет считаться успешной до следующего окна.

Уровень 3. Бизнес-результат

Проверяет фактическое состояние принимающей системы.

Примеры:

• контрольный товар имеет ожидаемую цену;
• остаток обновлён не позже допустимого времени;
• последний интернет-заказ появился в 1С;
• номер документа 1С вернулся на сайт;
• статус отгрузки обновился;
• число активных товаров не изменилось аномально;
• менеджер видит новые заказы.

Именно этот уровень отвечает на вопрос бизнеса. Первые два нужны, чтобы быстрее локализовать причину.

Какие показатели собирать

Для любого цикла

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

Для каталога

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

Для заказов

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

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

Главная метрика — свежесть

Факт последнего успеха удобнее бинарного «работает/не работает».

Свежесть = текущее время − время последнего подтверждённого
применения данных на принимающей стороне

Пример для каталога, который должен обновляться каждый час:

Возраст последнего результата	Состояние	Действие
До 75 минут	Норма	Наблюдение
75–90 минут	Допуск	Проверить длительность текущего цикла
90–180 минут	Предупреждение	Создать P3/P2 и назначить владельца
Более 180 минут	Критично для активного магазина	Эскалация по бизнес-влиянию

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

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

Heartbeat успешного обмена

Heartbeat — короткий сигнал, который задача отправляет после выполнения проверяемого результата.

Пример полезного события:

{
  "job": "catalog_import",
  "exchange_id": "2026-08-04T12:00:00+03:00_catalog_1842",
  "status": "success",
  "started_at": "2026-08-04T12:00:05+03:00",
  "finished_at": "2026-08-04T12:08:41+03:00",
  "processed": 12483,
  "updated_prices": 417,
  "updated_stocks": 932,
  "errors": 0,
  "source_timestamp": "2026-08-04T11:59:48+03:00"
}

Правила:

• отправлять после всех критических шагов;
• использовать уникальный exchange_id;
• передавать время с часовым поясом;
• не считать статус success, если обработана только часть обязательных данных;
• не включать пароль, токен и персональные данные;
• при ошибке отправлять отдельный сигнал, но отсутствие ожидаемого heartbeat тоже считать событием;
• защищать endpoint и ограничивать частоту.

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

Как это настроить в Pingvera

Богатое JSON-событие выше (с processed, updated_prices, errors и так далее) — это внутренняя телеметрия студии: его есть смысл писать в свой журнал или отправлять в свою систему до отдельного шага. Сам факт «цикл завершился успешно» в Pingvera передаётся отдельным, более простым механизмом — heartbeat-монитором.

Heartbeat-монитор Pingvera даёт URL пульса вида https://app.pingvera.ru/hb/{token} (метод GET или POST, токен-секрет зашит прямо в путь; есть вариант с явным сигналом — https://app.pingvera.ru/hb/{token}/{signal}). У монитора задаётся:

• schedule — расписание в cron-выражении, когда обмен должен запускаться;
• schedule_tz — часовой пояс этого расписания;
• grace — сколько ждать после ожидаемого времени, прежде чем считать пропуск инцидентом.

Логика обратная обычному мониторингу: Pingvera не опрашивает цель, а ждёт, что цель сама отчитается. Молчание дольше расписание + grace — это и есть сигнал сбоя.

Вызов пульса добавляется в самый конец обработки — после того, как обмен реально завершился успехом (см. правило выше «heartbeat нельзя отправлять при старте»):

# ...весь обмен отработал, критические шаги подтверждены...
curl -fsS "https://app.pingvera.ru/hb/{token}"

Если обмен не запустился или упал раньше этой строки, пульс не придёт, и после истечения schedule + grace Pingvera откроет инцидент «ночной обмен не отметился» — без отдельного опроса состояния 1С или сайта.

Контрольные объекты

Контрольный объект помогает подтвердить, что данные дошли до конца.

Варианты:

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

Требования:

• объект однозначно определяется;
• его изменение безопасно;
• он не портит аналитику и отчёты;
• его не удалит обычная очистка;
• мониторинг знает ожидаемое значение;
• есть процедура удаления тестовых заказов;
• доступ к проверке не раскрывает коммерческие данные.

Не меняйте автоматически остаток продаваемого товара ради мониторинга. Ошибка теста не должна создать реальный дефицит или ложное наличие.

Аномалии важнее строки «без ошибок»

Обмен может завершиться со статусом успеха и выполнить опасное массовое действие.

Добавьте правила:

• деактивировано больше обычного числа товаров;
• число активных предложений упало на заданный процент;
• у значительной доли товаров цена стала нулевой;
• пакет неожиданно пустой;
• объём пакета резко отличается от обычного;
• длительность выросла в несколько раз;
• количество пропущенных объектов не равно обычному диапазону;
• один заказ передан повторно;
• очередь растёт несколько циклов подряд;
• тип цены или склад изменился;
• сумма заказа на сайте и в 1С расходится.

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

Риски настроек импорта 1С-Битрикс

Официальные настройки торгового каталога позволяют определить действие над товарами, которых нет в CommerceML-файле:

• удалить;
• деактивировать;
• оставить как есть.

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

Также проверьте:

• в какой инфоблок загружаются данные;
• какие типы цен связаны;
• что происходит с предложениями;
• как сопоставляются внешние идентификаторы;
• разрешены ли изменения вручную на сайте;
• кто выигрывает при конфликте;
• как обрабатываются изображения;
• какие кастомные события выполняются после импорта.

Журналы, которые нужно связать

На стороне 1С

Собирайте:

• журнал обменов;
• журнал регистрации в объёме, согласованном с администратором;
• состояние регламентного задания;
• протокол обработки;
• время формирования пакета;
• ошибку подключения или авторизации;
• идентификатор последнего объекта.

Актуальный учебный курс 1С-Битрикс описывает форму «Журнал обменов», где протоколы можно смотреть по датам, типам и другим разрезам, в том числе фильтровать ошибки.

На стороне сайта

Проверяйте:

• журнал обмена и модуля;
• журнал событий 1С-Битрикс;
• PHP error log;
• access/error log веб-сервера;
• состояние cron и агентов;
• временные файлы обмена;
• свободное место и inode;
• длительные запросы базы;
• блокировки и параллельные сессии;
• очередь импорта;
• историю изменения контрольного товара или заказа.

В общей карточке

Сводите временную шкалу:

11:59:48 — 1С сформировала пакет
12:00:05 — началась передача
12:01:12 — сайт принял архив
12:01:20 — началась обработка
12:08:41 — импорт завершён
12:09:03 — контрольное значение подтверждено

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

Типовые поломки и сигналы

Поломка	Что видно	Как обнаружить
Задание не стартовало	Нет нового цикла	Отсутствие ожидаемого старта и heartbeat
Ошибка авторизации	Повторные ответы отказа	Код категории + журнал обеих сторон
Передача оборвалась	Неполный пакет, повторы	Размер, номер порции, незавершённый цикл
Закончилось место	Ошибка распаковки или записи	Диск и inode + журнал импорта
Обработка зависла	Время старта есть, окончания нет	Максимальная длительность и блокировка
Пакет пуст	Технический успех, ноль объектов	Минимальный ожидаемый объём
Цены не применились	Товары обновились, цены старые	Отдельная метрика цен и контрольный объект
Заказы не уходят	Каталог свежий, очередь заказов растёт	Возраст старейшего заказа
Дубли заказов	Повторная обработка	Уникальный ID и сверка дубликатов
Массовая деактивация	Импорт успешен, каталог исчезает	Контроль дельты и числа активных товаров
Статус не вернулся	Заказ есть в 1С, сайт старый	Задержка обратного направления
Обмен стал медленнее	Циклы перекрываются	Длительность и процент сервисного окна

Уровни тревоги

Пример матрицы для магазина:

Уровень	Условие	Действие
Информация	Цикл завершён в обычном диапазоне	Сохранить в истории без уведомления дежурного
Предупреждение	Длительность или свежесть приближается к допуску	Проверить текущий цикл и ресурсы
P3	Один цикл не завершён, бизнес-данные ещё в допустимом окне	Назначить владельца в рабочее время
P2	Данные устарели; заказы задерживаются; есть ограниченный ручной обход	Уведомить студию и клиента по регламенту
P1	Неверные цены массово опубликованы; заказы теряются; нет обхода; возможна порча данных	Остановить влияние, открыть критический инцидент

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

Регламент реакции

Шаг 1. Подтвердить направление и влияние

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

Шаг 2. Не запускать повтор вслепую

Повторный полный обмен может:

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

Сначала определите состояние текущего цикла и повторяемость операций.

Шаг 3. Ограничить ущерб

В зависимости от согласованных полномочий:

• временно остановить проблемное направление;
• скрыть неверный способ заказа;
• показать предупреждение об уточнении остатка;
• переключить менеджеров на ручное подтверждение;
• сохранить входной пакет и журналы;
• запретить параллельный запуск;
• остановить массовую деактивацию;
• зафиксировать новые заказы до восстановления.

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

Шаг 4. Локализовать слой

Проверьте по порядку:

1. инициатор и расписание;
2. формирование пакета;
3. сеть и авторизацию;
4. приём и свободное место;
5. распаковку;
6. пошаговую обработку;
7. сопоставление и правила;
8. применение данных;
9. обратное подтверждение;
10. контрольный бизнес-результат.

Шаг 5. Восстановить и доказать

После исправления недостаточно увидеть статус success.

Проверьте:

• контрольные цены и остатки;
• число активных товаров;
• очередь заказов;
• старейший заказ;
• отсутствие дублей;
• возврат статусов;
• следующий плановый цикл;
• пользовательский путь заказа.

Шаг 6. Сообщить

С [время] обновление [цен и остатков / заказов] задержано.
Последние подтверждённые данные применены в [время].

Влияние: [конкретный бизнес-результат].
Мы [действие] и используем [обход, если есть].

Следующее обновление — до [время].

Не пишите клиенту только «ошибка CommerceML». Объясните свежесть данных и работу заказов.

Копируемый паспорт мониторинга обмена

# Контроль обмена 1С ↔ сайт: [проект]

## Владельцы

- Бизнес-владелец: [имя]
- Сайт: [студия / контакт]
- 1С: [подрядчик / контакт]
- Инфраструктура: [контакт]
- Аварийное решение: [роль]

## Направление 1: [каталог / заказы / статусы]

Источник истины: [система]
Инициатор: [система / задача]
Расписание: [значение]
Часовой пояс: [значение]
Допустимая свежесть: [значение]
Максимальная длительность: [значение]
Критические часы: [значение]

### Доказательства

- Старт: [сигнал]
- Завершение: [сигнал]
- Бизнес-результат: [контрольное значение]

### Метрики

- [длительность]
- [число объектов]
- [ошибки]
- [очередь]
- [дельта активных данных]

### Пороги

| Условие | Уровень | Канал | Первое действие |
|---|---|---|---|
| | | | |

### Обход

[Безопасный ручной процесс, владелец и максимальная длительность]

### Восстановление

[Порядок без секретов]

### Критерий закрытия

[Какой факт на принимающей стороне должен быть подтверждён]

Пример набора проверок

Для магазина с часовым обновлением каталога и пятиминутной передачей заказов:

1. URL магазина и checkout — каждые 1–5 минут.
2. Heartbeat успешного каталога — ожидается каждый час с допуском 30 минут.
3. Длительность импорта — предупреждение выше исторического диапазона.
4. Контрольный товар — цена и доступность читаются после каждого цикла.
5. Массовая дельта — тревога при аномальной деактивации или нулевых ценах.
6. Очередь заказов — возраст старейшего элемента не более 15 минут.
7. Контрольный заказ — вручную после релизов и автоматически только по безопасному сценарию.
8. Свободное место — предупреждение до того, как архив нельзя распаковать.
9. Ошибки обмена — группируются по циклу, а не отправляются сотней сообщений.
10. Следующий реальный цикл — обязательная проверка после восстановления.

Отчёт клиенту

В ежемесячном отчёте полезно показывать:

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

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

Частые ошибки

Контролируется только endpoint

Доступный обработчик не доказывает успешное применение пакета.

Heartbeat отправляется в начале

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

Есть один статус для всех направлений

Работающий каталог скрывает остановку заказов. Разделяйте потоки.

Нет допустимой свежести

Команда видит время последнего обмена, но не понимает, когда эскалировать.

Повторный полный обмен — первое действие

Он увеличивает влияние и стирает контекст. Сначала диагностируйте состояние.

Проверяется количество, но не качество

Десять тысяч обработанных товаров могут иметь нулевые цены. Добавьте контроль значений и дельт.

Логи хранятся только на одной стороне

Сайт говорит, что пакет не пришёл, 1С — что отправила. Связывайте циклы по ID и времени.

В мониторинг уходят персональные данные

Для контроля очереди не нужны ФИО, телефон и адрес покупателя. Используйте технические идентификаторы и агрегаты.

Нет владельца бизнес-решения

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

Как помогает Pingvera

Pingvera может стать внешним слоем контроля:

• следить за доступностью магазина и checkout;
• проверять ожидаемое содержимое карточек;
• контролировать формы и доставку уведомлений;
• получать heartbeat от успешно завершившихся задач;
• считать отсутствие ожидаемого сигнала событием;
• принимать доступные внутренние сигналы CMS и сервера;
• доставлять уведомления в Telegram, email, MAX или webhook;
• хранить временную шкалу и показывать клиентский статус.

Для прямой проверки журнала 1С, очереди заказов или контрольного значения потребуется подходящий источник данных: безопасный endpoint, скрипт, webhook или интеграция. Pingvera не должна получать административный доступ к 1С и не меняет остатки автоматически. Она контролирует разрешённые доказательства и сообщает об отклонении.

Первый практический шаг: настройте два независимых сигнала — heartbeat успешного обмена и проверку фактической свежести результата. Затем подключите их к Pingvera.

Часто задаваемые вопросы

Как понять, что обмен с 1С действительно завершился?

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

Что делать, если обмен иногда длится дольше расписания?

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

Нужно ли запускать полный обмен после каждой ошибки?

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

Как мониторить заказы, если прямого API 1С нет?

Можно контролировать очередь на сайте, возраст старейшего непереданного заказа, техническое подтверждение обработки и периодически сверять контрольный заказ на стороне 1С. Полный end-to-end требует участия или безопасной интеграции со стороны 1С.

Какой порог задержки считать критическим?

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

Можно ли проверять обмен контрольным товаром?

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

Где искать причину, если 1С сообщает об успехе, а сайт не обновился?

Сопоставьте exchange_id и время, затем проверьте приём пакета, распаковку, пошаговую обработку, правила сопоставления, журнал импорта, состояние базы и фактическое поле контрольного объекта. Успех отправки со стороны 1С не равен успеху применения на сайте.

Нужно ли уведомлять клиента о каждом пропущенном цикле?

Нет. Пропущенный цикл может оставаться внутри технического допуска. Уведомление связывают с уровнем критичности, свежестью данных, очередью заказов и риском. Студия при этом должна видеть раннее предупреждение.

Главное

Работающий обмен — это не доступный URL и не запущенное задание. Это подтверждённое движение правильных данных с допустимой задержкой.

Разделите потоки, измеряйте свежесть, отправляйте heartbeat после завершения, проверяйте бизнес-результат и контролируйте аномальные дельты. Тогда веб-студия узнает об остановке обмена до жалоб покупателей и сможет говорить с клиентом не об абстрактной «ошибке синхронизации», а о конкретном влиянии на цены, остатки и заказы.

Источники и дополнительное чтение

• 1С-Битрикс: компоненты обмена с 1С
• 1С-Битрикс: импорт данных из 1С
• 1С-Битрикс: торговый каталог и CommerceML
• 1С-Битрикс: настройки импорта и действия над отсутствующими товарами
• 1С-Битрикс: журнал обменов
• Google SRE Workbook: Monitoring
• Google SRE Workbook: Data Processing Pipelines
• Pingvera: регламент мониторинга сайтов клиентов
• Pingvera: мониторинг фоновых задач

Следующие материалы курса: «Как проверить восстановление сайта из бэкапа, не рискуя production» и «Отчёт об инциденте сайта: русский шаблон для клиента».

Читайте также: Мониторинг как код для веб-студии: руководство · Terraform-провайдер Pingvera: мониторинг как код · CLI Pingvera: мониторинг из терминала и скриптов · Мониторинг, который не заходит на сервер клиента · Бесплатно проверить сайт.