Как восстановить CRM после суточного сбоя интеграции

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

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

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

Зафиксируйте границы инцидента

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

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

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

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

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

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

Посчитайте время разбора очереди

Пусть в очереди B записей, система устойчиво обрабатывает μ записей в секунду, а новые приходят со скоростью λ. При постоянных скоростях и μ больше λ ориентировочное время сокращения очереди равно B / (μ − λ).

Условный пример: накопилось 360 тысяч событий, обработка идёт со скоростью 150 в секунду, новый поток — 100 в секунду. На старую очередь остаётся 50 в секунду; ориентир составляет 7 200 секунд, или два часа. Расчёт не учитывает повторы, неодинаковую стоимость записей и ограничения отдельных каналов.

Если μ не больше λ, очередь не сокращается. Тогда нужно увеличить доступную обработку, уменьшить некритичную нагрузку или изменить порядок восстановления. Отправлять больше повторов в уже перегруженный участок обычно не помогает.

Следите за возрастом и составом очереди

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

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

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

Не отправляйте накопленные сообщения автоматически

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

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

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

Сохраните контрольный баланс восстановления

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

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

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

Возобновляйте поэтапно

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

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

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

Источники

Amazon Web Services. Available CloudWatch metrics for Amazon SQS. Amazon SQS Developer Guide. Показатели очереди и ApproximateAgeOfOldestMessage. Проверено 22.09.2026.