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