n8n + ИИ + CRM: контур, который переживёт ночное падение

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

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

Как собирается базовая цепочка «форма → ИИ → CRM → уведомление», я разбирал в статье про первый сценарий в n8n. Здесь — про то, что превращает такую цепочку в контур, которому можно доверить входящий поток компании.

Четыре требования вместо слова «стабильно»

Договоритесь с собой (и с заказчиком) о том, что именно вы обещаете. Формулировки должны быть проверяемыми.

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

Разделите приём и обработку

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

Рабочая схема — две части.

Приём. Вебхук делает минимум: проверяет секретный заголовок, кладёт сырое тело запроса в хранилище (таблица в PostgreSQL, отдельная база, на худой конец Google-таблица) со статусом new и сразу отвечает сайту 200 OK. Занимает миллисекунды, падать тут нечему.

Обработка. Отдельный сценарий раз в минуту берёт записи со статусом new, гоняет их через модель и CRM, меняет статус на done или failed. Упала модель — запись осталась в очереди и будет обработана, когда всё поднимется.

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

Ретраи: не все ошибки одинаково полезны

Повторять вслепую — верный способ получить двести карточек в CRM вместо сорока. Ошибки надо различать.

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

После исчерпания попыток запись уходит в отдельную очередь — по-взрослому это называется dead letter. Не удаляется, не теряется, ждёт человека. Раз в сутки её содержимое приходит списком в чат: «5 заявок не обработаны, причины такие-то».

Идемпотентность в пять строк

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

// Code-нода: ключ идемпотентности
const crypto = require('crypto');
const phone = ($json.phone || '').replace(/\D/g, '').replace(/^8/, '7');
const raw = phone + '|' + ($json.text || '').slice(0, 100) + '|' + new Date().toISOString().slice(0, 10);
return [{ json: { ...$json, phone, idem_key: crypto.createHash('sha1').update(raw).digest('hex') } }];

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

Логи, по которым разбор занимает минуты

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

время | id заявки | шаг | статус | длительность мс | текст ошибки | попытка №

Три причины, почему это окупается на первой же аварии. Во-первых, поиск по телефону клиента находит всю его историю за секунду. Во-вторых, видно, какой шаг тормозит: обычно это вызов модели, и цифры позволяют спорить предметно. В-третьих, история выполнений в самом n8n чистится (и должна чиститься — база пухнет и валит сервис), а ваша таблица остаётся.

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

Алерты: ошибки и тишина

Два типа сигналов, и второй важнее.

По ошибке. У каждого рабочего сценария подключён Error Workflow: упало — в чат летит сообщение с названием сценария, шагом и текстом ошибки. Не «произошла ошибка», а конкретика, по которой понятно, звать разработчика или это протух токен.

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

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

И ежедневная сводка в 9:00: принято, обработано, ошибок, в ручной очереди, среднее время обработки. Пять строк, которые читаются за десять секунд и дают ощущение контроля.

Когда упало ночью

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

ЧТО ДЕЛАТЬ, ЕСЛИ ПРИШЁЛ АЛЕРТ

1. Открыть таблицу очереди. Записи со статусом new не пропали?
   Есть — заявки в безопасности, паниковать не нужно.
2. Посмотреть текст ошибки в сообщении:
   - "401/403" -> протух токен CRM. Перевыпустить в Credentials, включить повтор очереди.
   - "429" -> лимит API. Ничего не делать, разгребётся само за час.
   - "ECONNREFUSED/таймаут" -> сервис недоступен. Проверить, открывается ли CRM в браузере.
   - "не JSON" -> модель вернула мусор. Заявки в ручной очереди, разобрать утром.
3. Если очередь пустая, а заявки не идут -> проблема на входе.
   Отправить тестовую заявку с сайта, проверить адрес вебхука.
4. Ничего не понятно -> написать в чат, заявки не теряются, ждут в очереди.
   НЕ перезапускать сценарий пачкой: получите дубли.

Последняя строка написана кровью. Дежурный, который в панике жмёт «повторить всё» пять раз подряд, вредит сильнее самой аварии.

Версии, бэкапы и правка на живом

Сценарии — в git. n8n умеет отдавать процесс в JSON. Экспорт раз в сутки в репозиторий даёт то, чего в интерфейсе нет: историю изменений и ответ на вопрос «что мы правили перед тем, как всё сломалось».

Секреты — в Credentials, а не в полях нод. Тогда экспортированный JSON можно спокойно отдать коллеге и положить в репозиторий.

Копия для отладки. Правка боевого процесса на живом потоке — это лотерея, где приз в лучшем случае «никто не заметил». Держите дубль сценария и тестовый чат для уведомлений.

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

Разбор: как мы поймали тихую потерю заявок

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

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

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

Третье: у нас на одном из серверов исходящие запросы к api.telegram.org резались провайдером, и уведомления не уходили. В интерфейсе это выглядело как «иногда не работает». Диагностика заняла в разы больше времени, чем сама починка через релей.

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

Чего от такого контура ждать не надо

Он не заменяет очередь сообщений на серьёзных объёмах. Десятки тысяч событий в час — это уже не про n8n, там нужен нормальный брокер и сервис на коде. Наша граница проходит примерно там, где схема перестаёт помещаться на экран: связывание сервисов остаётся в n8n, расчёты и тяжёлая логика уезжают в отдельный сервис на Python, который n8n дёргает как обычный HTTP-эндпоинт.

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

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

И он не бесплатный в поддержке. Час-два в месяц уходит стабильно: обновить n8n, посмотреть на ошибки в ручной очереди, проверить бэкап. Автоматизация без присмотра деградирует тихо и незаметно — ровно как в истории с формой.

Частые вопросы

Сколько нод занимает такой надёжный контур? Приём — три-четыре ноды, обработка — восемь-двенадцать вместе с проверками, сторож и Error Workflow — по три. Итого около двадцати вместо шести в учебном примере. Разница и есть цена надёжности.

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

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

Кто должен дежурить по контуру? Обычно тот же человек, кто отвечает за CRM. Разработчик нужен на настоящие поломки, а девяносто процентов алертов — это протухший токен или упавший чужой сервис.

Что делать, если сценарии писал подрядчик и уехал? Первым делом забрать экспорт всех процессов в JSON, доступы к серверу и список Credentials. Без этого вы владеете не автоматизацией, а зависимостью от чужого телефона.

Что сделать в ближайший вторник

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

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