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