Очередь ошибок нужна, чтобы недоставленные события не исчезали и не блокировали исправные обращения. В ней должны быть причина остановки, ответственный и безопасный способ повторной обработки. Бесконечные попытки отправить одну и ту же запись только увеличивают нагрузку и скрывают проблему от сотрудников.
Разделите ошибки по следующему действию
Временная недоступность сервиса обычно допускает повтор через паузу. Некорректное значение поля требует исправления данных. Отсутствие прав или истёкший доступ требуют восстановления подключения. Неизвестный результат создания требует сверки, поскольку карточка могла появиться до обрыва связи.
Классификацию строят по документации конкретного API и фактическому ответу. Один общий статус «не отправлено» не помогает принять решение. При этом сообщения пользователю должны быть понятными: «не найден код филиала» полезнее необъяснённого технического кода.
Определите содержимое записи
Для каждого события сохраните идентификатор источника, тип операции, время возникновения, число попыток, последнюю причину сбоя и связанный объект назначения, если он известен. Состояния «ожидает», «повторяется», «нужен разбор» и «завершено» должны иметь однозначные переходы.
Полезно хранить исходную версию события отдельно от исправлений. Тогда оператор видит, что пришло из источника и что изменено при восстановлении. Секреты доступа и полные массивы персональных данных в обычный диагностический журнал включать не нужно.
Ограничьте автоматические повторы
Паузы между повторными попытками увеличивают, чтобы недоступный сервис не получал лавину запросов. Небольшое случайное отклонение времени помогает разнести синхронно упавшие задачи. Конкретные интервалы и предел попыток выбирают под допустимую задержку и ограничения поставщика.
После исчерпания автоматического режима событие переводят на разбор. Это не означает удаления. Новые корректные обращения продолжают идти, а проблемный объект не теряет связи со своей историей. Если порядок событий важен, блокируют только зависимую цепочку объекта, а не всю интеграцию.
Условный разбор трёх обращений
Предположим, в очередь попали три заявки. У первой CRM временно не ответила. Во второй передан неизвестный код подразделения. У третьей создание могло завершиться, но ответ потерялся.
Первая заявка получает отложенный повтор. Вторая направляется владельцу справочника, который сопоставляет подразделение и фиксирует исправление. По третьей интеграция сначала ищет созданную карточку по внешнему ключу. Кнопка «повторить всё» без этих различий могла бы создать дубль и одновременно снова отправить заведомо ошибочные данные.
Дайте оператору рабочий регламент
В инструкции укажите, какие ошибки он исправляет самостоятельно и какие передаёт разработчику или владельцу процесса. Для ручного повтора нужны комментарий, автор действия и сохранение прежней ошибки. Массовое восстановление лучше начинать с небольшой проверяемой группы.
Отдельно определите, что делать с устаревшими событиями. Если клиент уже обслужен вручную, создание новой задачи менеджеру может быть лишним. Решение о пропуске должно быть документированным бизнес-действием с причиной, а не незаметной очисткой очереди. Роли сопровождения можно связать с порядком передачи CRM интегратору.
Примите восстановление по результату
На испытании отключите принимающий сервис, измените справочник и смоделируйте неопределённый ответ. Убедитесь, что число принятых событий равно числу завершённых, ожидающих и явно исключённых, без необъяснимого остатка.
После восстановления проверьте возраст старейшей записи, появление дублей и порядок зависимых изменений. Оператор должен найти любое тестовое обращение по ключу и объяснить его состояние. Только после такой проверки очередь становится инструментом управления инцидентами, а не складом забытых ошибок.
Применить в вашей компании
Обсудим вашу задачу?
Поможем разобраться с процессом, данными и настройками. Работаем удалённо с компаниями по всей России.