Автоматизация после сбоя: где хранить состояние между CRM, человеком и воркером

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

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

Что изменилось в источниках

Microsoft в разборе Durable Task от 12 октября прямо отделяет долговечную координацию от внешнего эффекта, который приложение обязано подтверждать самостоятельно. Temporal 1.32.1 от 8 октября включает исправления маршрутизации задач и данных очереди. Даже специализированный исполнитель имеет собственный цикл обслуживания.

Материал n8n от 12 октября различает задачи CI/CD, инфраструктуры и координации инструментов. Отчёт Workato от 13 октября описывает опыт клиентов с повторно используемым интеграционным слоем. Это позиция поставщика и рассказ участников, а не независимый тест превосходства продукта.

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

Три разных состояния одного поручения

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

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

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

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

Условный пример: подключение партнёра

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

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

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

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

Когда отдельный движок оправдан

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

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

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