Сломанная автоматизация редко сообщает о себе. Она продолжает работать, горит зелёным и тихо теряет заказы. Поэтому вымышленная керамическая мастерская из этого демо узнаёт о проблеме, только когда клиент спрашивает, где его заказ.
Это демо я сделала сама, чтобы целиком воссоздать такую ситуацию. Palewood Ceramics — вымышленная компания. Её сценарий в n8n забирал заказы из магазина в таблицу, письмо с подтверждением и канал в Slack, и пришли четыре жалобы: заказов нет в таблице, некоторым клиентам письмо пришло дважды, Slack молчит по часу, а владелец снова проверяет каждый заказ вручную.
Первым делом я ничего не чинила, а сначала измерила. Одну обычную смену я воссоздала как сценарий, который можно прогонять заново: 120 заказов за пять часов, 60 запусков по расписанию и сбои, которые бывают на самом деле. Сайт магазина перезапускается на семь минут, почтовый сервис упирается в дневной лимит, три заказа публикуются на несколько минут позже, четыре клиента исправляют адрес после заказа, у одного клиента только имя без фамилии, у одного нет телефона, у одного пустое поле почты, а один адрес постоянно возвращает письма.
На этой смене старая версия безвозвратно потеряла 14 заказов из 120, это 2 504 EUR выручки. Шести клиентам она отправила письмо дважды, семь подтверждений не отправила вовсе и десять раз упала, никому не сообщив.
У каждой жалобы была своя причина. Повторных попыток не было, поэтому несколько секунд простоя выбрасывали целый запуск: так пропали одиннадцать заказов. Жёсткое окно «последние пять минут» молча пропускало заказы, опубликованные с опозданием, а запас, который кто-то добавил для надёжности, начал дублировать всё, что попадало в перекрытие. Одного клиента с одним только именем хватало, чтобы вместе с ним сломались все нормальные заказы из той же пачки. Ничто не проверяло, обработан ли заказ раньше. А ошибка при отправке письма обрывала запуск до сообщения в Slack, которое бы её показало.
Исправленная версия точно запоминает, где остановилась, и сдвигает эту отметку только после того, как заказ надёжно сохранён, поэтому сбой не может перескочить через заказ. Она помнит, какие заказы уже сохранила: точный повтор отбрасывается, а настоящая правка переписывает существующую строку и сообщает команде, не отправляя клиенту второе письмо. Заказы проверяются по одному, поэтому одна плохая запись больше не тянет за собой нормальные, а совсем непригодное передаётся человеку в Slack. Всё, что всё равно не получилось (магазин недоступен, адрес возвращает письма), превращается в оповещение: что сломалось и где. API-ключ я убрала из файла сценария в хранилище учётных данных.
За ту же смену: ни одного потерянного заказа, ни одной повторной строки, ни одного повторного письма, ни одного упавшего запуска. И четыре оповещения о том, что человеку действительно нужно было увидеть.
Ничего из этого не нужно принимать на веру. Страница прогоняет оба файла сценария на той же смене прямо в браузере, гораздо быстрее секунды, и выводит, что сделала каждая версия, запуск за запуском. 45 автоматических проверок подтверждают, что каждая неисправность действительно есть в сломанном файле, каждое исправление действительно есть в починенном, а каждая цифра выше получается из прогонов. В отчёте также сказано, что ещё стоит сделать и чем прогон отличается от самого n8n: я не делаю вид, что работа идеальна.
В настоящем проекте вы получаете: причину каждого сбоя простыми словами, исправленный сценарий, прогон вашей самой тяжёлой недели через обе версии и ежемесячное наблюдение за запусками. Тогда об упавшем запуске я узнаю раньше, чем ваш клиент.