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