Автоматизация сломалась: что делать в первые сутки

4 августа 2026 · 11 мин чтения

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

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

Как понять, что сломалось именно оно

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

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

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

Первые три действия

1. Зафиксируйте картину. Время последней успешной операции, идентификатор дошедшей заявки, точный текст ошибки, что видит клиент. Эти пять минут окупаются позже: часть причин видна прямо в тексте ошибки, а после починки наугад следы исчезают.
2. Воспроизведите отказ. Отправьте тестовую заявку тем же путём, каким идёт настоящая. Если она проходит, сбой был разовым или касается одного канала. Если повторяется, у вас появился быстрый способ проверять гипотезы.
3. Включите ручной обход и предупредите людей - до того как искать причину. Менеджеры должны знать, что заявки временно приходят на почту, иначе к сбою добавятся обращения, которые никто не взял в уверенности, что их взял робот.

Чего делать нельзя

• Не перезапускайте вслепую. Без защиты от повторной обработки каждый повтор рождает второй результат: второй счёт, вторую отгрузку, второе письмо. Сначала журнал, потом кнопка.
• Не чистите очередь. В ней лежат необработанные обращения клиентов, и часто это их единственная копия: в источнике сообщение уже помечено как забранное. Очистка обнуляет счётчик, но на деле это удаление заявок.
• Не меняйте токены и пароли наугад. Новый ключ обрывает соседние сценарии, а старый обычно уже не вернуть. Доступы меняют, когда на них указывает ошибка, а не на всякий случай.
• Не удаляйте логи и не обновляйте платформу заодно. Обновление посреди аварии превращает одну неизвестную причину в две, а журнал - единственное, по чему восстанавливают ход событий.

Симптом, вероятная причина и что проверить первым

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

Локализация: на чьей стороне отказ

Любая связка состоит из пяти участков, и задача первого часа - понять, до какого из них доехали данные. Двигайтесь по цепочке от начала, а не от места, где сбой заметили.

• Источник. Сайт, форма, мессенджер, почта, маркетплейс. Проверка: есть ли событие у самого источника - письмо в ящике, сообщение в диалоге, запись в админке. Если события нет, сценарий ни при чём.
• Оркестратор. Платформа, где живёт сценарий. Проверка: был ли запуск, на каком шаге он остановился, включён ли сценарий и не сдвинулось ли расписание.
• Приёмник. CRM, таблица, учётная система, чат. Проверка: доходит ли запись, если создать её вручную теми же данными. Частая причина - новое обязательное поле или переименованный этап воронки, подробнее в руководстве по интеграции с CRM.
• Сеть и инфраструктура. Проверка: отвечает ли сервер, не просрочен ли сертификат, есть ли место на диске. Признак слоя - падает сразу всё, включая несвязанные сценарии. Регулярная проверка доступности собирается отдельно, как в кейсе контроля доступности сайта, API и сервера.
• Лимиты и деньги. Квоты API, тариф платформы, баланс сервиса. Слой обидный: всё исправно, а работа стоит из-за неоплаченного счёта или превышенной квоты.

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

Типовые причины, которые проверяют первыми

1. Истёк или отозван токен доступа. Причина, с которой обычно начинают проверку: ключи выпускают со сроком жизни, пароли меняют по политике безопасности, сотрудник увольняется, а робот ходил под его учёткой. Профилактика - своя учётка на каждого робота и календарь ротации, подробно в статье про безопасность автоматизации.
2. Источник поменял структуру ответа. Сервис обновил API, переименовал поле, добавил уровень вложенности. Сценарий запускается и не падает, поэтому сбой видят по пустым полям, а не по ошибке.
3. Кончились лимиты API. Всплеск после рассылки, вторая копия сценария, забытый цикл, который ходит к источнику тысячу раз вместо десяти.
4. Упал сервер или переполнился диск. Логи растут незаметно и однажды занимают всё место. Отсюда правило: ротация логов и оповещение о свободном месте настраиваются в день установки.
5. Изменилась форма на сайте. Приём заявок ломается тихо, а связь между переделанным лендингом и пропавшими лидами замечают на третий день.
6. Изменения в приёмнике. Новое обязательное поле в CRM, переименованный статус, перестроенная воронка. Робот шлёт данные в прежнем формате, система их не принимает.
7. Сеть, домен, сертификат. Просроченный сертификат, сменившийся адрес сервиса, авария у провайдера. Чинится обычно не вами и требует ручного обхода на время.
8. Человеческий фактор. Сценарий выключили на минуту во время правок, кто-то удалил папку в облаке, тестовый режим остался включённым.

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

Как вернуть процесс руками на время починки

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

• Назначьте дежурного. Один человек отвечает за ручную обработку. Без имени ответственного задача расплывается между всеми.
• Поднимите временный приёмник. Заявки переключаются на почту или в чат, документы формируются по шаблону вручную, статусы клиентам уходят пакетом раз в два часа. Медленно, но это работа, а не простой.
• Ведите журнал ручной обработки. Список: что обработали, когда, кем. Он нужен, чтобы не задвоить всё, когда накопленное поедет по сценарию заново.
• Заранее решите судьбу очереди. Определите до включения: дообрабатывать всё, пропустить сделанное руками или взять только свежее.
• Назначьте точку пересмотра. Ручной режим удобен и незаметно становится постоянным.

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

Что писать подрядчику, чтобы починили быстро

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

Тема: сбой автоматизации, [название сценария]
1. Не работает: [что именно, в терминах бизнеса].
2. Заметили: [дата, время]. Последний раз работало: [дата, время последней успешной операции, идентификатор заявки].
3. Что видит человек: [описание, скриншот приложен].
4. Текст ошибки: [точная копия из журнала или «в журнале ошибок нет»].
5. Уже проверили: [пункты из таблицы выше]. Уже сделали: [перезапуск, правки, смена ключа - либо «ничего не меняли»].
6. Влияние: [сколько заявок или документов в час], ручной обход [включён с ... / не включён].
7. Доступы: [есть у вас / нужно выдать, ответственный такой-то]. На связи: [имя, контакт, часы].
Приложения: скриншоты, выгрузка журнала за [период].

Если срок реакции на аварию нигде не записан, вопрос «когда почините» превращается в спор. Это обсуждают до старта работ: критерии приёмки и поддержка - в статье про техзадание на автоматизацию, выбор исполнителя - в разборе, как выбирать подрядчика по автоматизации.

Как считать ущерб от простоя

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

1. Упущенная выгода = число потерянных обращений × конверсия в сделку × средний чек × доля маржи.
2. Стоимость ручной работы = часы ручной обработки × стоимость часа сотрудника.
3. Стоимость восстановления = работа исполнителя плюс разбор последствий: чистка дублей, догрузка пропущенного, извинения клиентам.

Пример с оговоренными допущениями. Пусть в сутки приходит 40 заявок, в сделку превращается каждая пятая, средний чек 30 тыс. ₽, доля маржи 30%. Тогда сутки тишины дают 40 × 0,2 × 30 000 × 0,3 = 72 тыс. ₽ упущенной маржи - при допущении, что ни один клиент не вернётся сам. Допущение сильное: часть людей пишет повторно. Если возвращается половина, оценка падает до 36 тыс. ₽. Плюс 6 часов дежурного по 500 ₽ - ещё 3 тыс. ₽. Итог дня - 39-75 тыс. ₽ в зависимости от того, какое допущение честно для вашего бизнеса.

Считать имеет смысл по своим числам: у мастерской с тремя заявками в день сутки простоя стоят мало, у оптовой компании с документооборотом - заметно больше. Методика расчёта разобрана в статье про окупаемость автоматизации.

Что настроить заранее, чтобы узнавать первым

Разница между неприятностью и репутационной потерей измеряется одним вопросом: кто сообщил о сбое, ваша система или клиент. Минимальный набор выглядит так.

• Алерт на ошибку и журнал с историей. Сценарий упал - в чат ответственного уходит имя сценария, время и текст ошибки, а сам запуск остаётся в журнале на три месяца и дольше. Как это собирается, показано в кейсе уведомлений об ошибках в автоматизациях.
• Алерт на тишину. Важнее предыдущего. Сценарий не падал, но и не запускался шесть часов, хотя должен каждые пятнадцать минут. Отвалившийся вебхук и просроченный токен выглядят именно так и без оповещения живут до первой жалобы.
• Тестовая заявка по расписанию. Самая честная проверка: робот раз в час проходит путь клиента и удаляет за собой тестовую запись. Она ловит то, что не видно изнутри платформы, - например, форму, переставшую отправляться после редизайна.
• Сверка счётчиков раз в сутки. Число отправок формы против числа карточек, число оплат против числа документов. Расхождение показывает частичные потери, которых не видит ни один алерт по ошибкам.
• Дежурный контакт и срок реакции. Один человек внутри компании и одна договорённость с исполнителем: кому писать в нерабочее время и за какой срок ответят.
• Бэкап сценариев и доступов. Экспорт сценариев, список интеграций и владельцев ключей на вашей стороне. Схема - в кейсе резервного копирования сценариев, а вопрос владения контуром - в статье про n8n на своём сервере.

По деньгам это скромная позиция рядом со стоимостью самой автоматизации: сценарий-сторож с алертами и тестовой заявкой относится к мониторингу и стоит от 10 000 ₽, эксплуатация одного сценария - 4-15 тыс. ₽ в месяц. Сравнивать это с расчётом ущерба стоит на своей экономике, а не на чужой.

Честно: часть сбоев неизбежна

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

Поэтому вопрос ставится иначе: не как добиться нуля сбоев, а как сократить время между поломкой и её обнаружением. Три дня тишины и двадцать минут - разные события с разной ценой при одной причине. Зрелость контура измеряется не отсутствием инцидентов, а тем, узнаёте ли вы о них первыми, есть ли ручной обход и понятно ли, кому писать. Если ответ на любой из вопросов «не знаем», начинать стоит с аудита автоматизации.

Чек-лист первых суток

1. Первые 20 минут. Зафиксируйте время последней удачной операции, текст ошибки и то, что видит клиент. Отправьте тестовую заявку. Ничего не перезапускайте.
2. 20-60 минут. Включите ручной обход, назначьте дежурного, предупредите команду. Пройдите по пяти участкам цепочки и найдите, между какими живёт отказ.
3. 1-4 часа. Проверьте типовые причины: токен, структура ответа источника, лимиты, сервер, форма, изменения в приёмнике. Напишите подрядчику по шаблону.
4. До конца суток. Решите судьбу накопленной очереди, догрузите пропущенное, проверьте дубли, посчитайте ущерб.
5. На следующий день. Разберите причину письменно: что сломалось, почему заметили не сразу, какой алерт поймал бы это раньше. Один новый алерт после каждого инцидента - и слепых зон в контуре становится меньше.

Итог

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

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

Не готовы обсуждать проект? Оцените выгоду сами: калькулятор ROI автоматизации - 1 минута, без контактов. Или заберите чек-лист «Что автоматизировать первым».