Заказы перестали попадать с сайта в CRM: как обнаружить разрыв и не потерять повторную отправку

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

Найти последнюю согласованную границу

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

Сохраняйте границы периода и часовой пояс. Если сайт пишет локальное время, а журнал интеграции показывает UTC, сравнение «после последнего заказа» без преобразования сдвинет расследование. Для учебной таблицы достаточно отметок Т0, Т1 и Т2. В рабочей сверке время хранится вместе с зоной и назначением: создание заказа, начало попытки и подтверждение CRM относятся к разным событиям.

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

Разделить этапы цепочки

Цепочка может включать сохранение заказа, постановку задания, обработчик, внешний запрос, ответ и фиксацию результата. Не называйте её одним действием «выгрузка», если это мешает локализации. Для каждого этапа нужен наблюдаемый признак. Отсутствие сделки в интерфейсе CRM ещё не показывает, дошёл ли запрос до сервера и где именно оборвалась работа.

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

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

Отличать отказ от неизвестного результата

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

Учебный пример: сайт отправил заказ Б, CRM создала запись, а ответ потерялся по пути обратно. Если обработчик просто считает таймаут отказом и заново создаёт сделку, появится дубль. Поэтому состояние «результат неизвестен» нужно хранить отдельно. Оно переводит запись в проверку по внешнему ключу или в документированный механизм идемпотентного повтора, если он действительно поддерживается.

Нельзя объявлять любой повтор безопасным только потому, что запрос имеет тот же JSON. Принимающий сервис должен понимать повторное намерение либо интеграция должна надёжно сопоставлять запись. В AWS Builders Library разобран принцип клиентского ключа запроса для идемпотентных операций. Он полезен как архитектурный ориентир, но не доказывает, что произвольный метод конкретной CRM уже обладает такой семантикой.

Выбрать устойчивый внешний ключ

Ключ должен обозначать бизнес-заказ в пределах источника. Если несколько сайтов имеют одинаковую нумерацию, одного короткого номера недостаточно. Добавьте разрешённую область источника, не раскрывая её посетителю. При этом не используйте персональные данные покупателя как ключ: имя, телефон и email могут измениться и не являются надёжным идентификатором самого заказа.

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

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

Проверить изменения перед остановкой

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

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

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

Восстанавливать небольшой подтверждённой партией

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

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

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

Сделать остановку заметной

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

Выберите получателя и действие после сигнала. Сообщение «что-то сломалось» без диапазона времени и масштаба пропуска мало помогает. Достаточно безопасных сведений: источник, число ожидающих записей, возраст самой старой, категория последней ошибки и ссылка на закрытый инструмент диагностики. Реальные контакты покупателей и содержимое заказа в уведомление обычно не нужны.

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

Сверить хвост после восстановления

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

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

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

Оставить доказательства без лишних данных

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

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

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

Разберите три учебные записи: А уже подтверждена, Б имеет неизвестный результат, В ещё не получила попытки. Для А повторное создание не требуется; для Б сначала проверяют существующую связь; для В выясняют, почему не возникло задание. Укажите для каждой записи следующий проверяемый шаг и ответственного. Так статус хвоста отражает состояние передачи, а не просто наличие строки в журнале.

Связанный разбор: Разработка API для интернет-магазина: обмен и контроль ошибок.

Документация и источники

• AWS Builders Library: идемпотентные повторы: Различие повторного запроса и повторного бизнес-действия, ключ идемпотентности