Обработка ошибок и повторная синхронизация

Любой обмен рано или поздно падает: недоступен API, битые данные, таймаут. Вопрос не в том, случится ли сбой, а в том, восстановится ли связка автоматически. Разберём, как проектировать обработку ошибок и безопасную повторную синхронизацию на 1С-Битрикс.

Классификация ошибок обмена

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

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

Ретраи с экспоненциальной задержкой

Для транзиентных ошибок применяют повтор с экспоненциальным backoff и джиттером. Это защищает внешний API от лавины одновременных повторов и даёт ему время восстановиться.

• Задержки растут: 1с → 2с → 4с → 8с → 16с (с ограничением сверху).
• Джиттер — случайная добавка, чтобы повторы не били синхронно.
• Ограничение числа попыток: например, 5, после чего задание уходит в dead letter.

В 1С-Битрикс повторы удобно реализовать через собственную таблицу заданий обмена с полями attempts, next_retry_at и status. Агент или cron выбирает задания, у которых наступило время следующей попытки.

Идемпотентность как основа повторов

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

• Перед созданием сущности — проверка по внешнему ключу: есть — обновляем, нет — создаём (upsert).
• Уникальный идентификатор операции (idempotency key) в журнале обработанных.
• Складские движения — через документы, а не прямое изменение остатка.

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

Карантин и dead letter queue

Задания, которые исчерпали попытки или содержат битые данные, нельзя терять и нельзя оставлять в основной очереди. Их отправляют в карантин (dead letter) — отдельное хранилище проблемных сообщений.

1. Задание помечается статусом failed с сохранением полезной нагрузки и текста ошибки.
2. Администратор получает уведомление (почта, Telegram, лог).
3. После исправления причины задание можно переотправить вручную одной кнопкой.

Ключевая ценность dead letter — исходные данные никогда не пропадают. Даже если обмен упал на сотне заказов, все они лежат в карантине и восстанавливаются после устранения причины, а не теряются молча.

Безопасная повторная синхронизация

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

• Батчами. Не всё сразу, а порциями по N позиций с паузами, чтобы не положить API и сайт.
• По приоритету. Сначала критичное (остатки, активные заказы), потом остальное.
• С контролем расхождений. Сравнить состояние до и после, зафиксировать, что изменилось.

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

Логирование и алерты

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

• Структурный лог каждой операции: время, тип, ключ сущности, результат, длительность, текст ошибки.
• Уровни: info для успеха, warning для ретраев, error для карантина, critical для фатальных сбоев.
• Алерты на рост ошибок и на фатальные события — в почту или мессенджер.

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

Итог

Устойчивый обмен — это не отсутствие ошибок, а способность их пережить. Опоры надёжности: классификация сбоев, ретраи с backoff для транзиентных ошибок, идемпотентность операций, карантин (dead letter) для неисправимых заданий и наблюдаемость через логи и алерты. Повторная синхронизация проводится батчами по watermark, а не слепой полной переливкой.

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