Airflow 3 для действующего ИИ-конвейера внедряют через инвентаризацию DAG и providers, проверку несовместимостей, резервную копию metadata DB и испытания на отдельном контуре. Решение о переключении принимают после сравнения результатов заданий и проверки восстановления из копии. Это план будущего пилота для команды, которая уже работает с Airflow 2: он помогает определить границы перехода без обещания готового результата.
Карта миграции
Официальное руководство Apache Airflow называет Airflow 3 крупным обновлением с несовместимыми изменениями и рекомендует начать с проверки исходной версии, DAG и резервной копии metadata DB.
Составьте реестр действующего конвейера: расписания DAG, версии Airflow и Python, установленные providers, пользовательские операторы, плагины, Connections, Variables, внешние хранилища и владельцы результата. Для каждой задачи отметьте, какие данные она читает, куда пишет ответ модели, какие журналы сохраняет и что запускается при повторе. Такой перечень нужен для миграции среды исполнения. Отдельная статья о регулярном контроле аналитики описывает рабочую логику наблюдения; здесь предметом служит перенос самого конвейера между версиями Airflow.
Зафиксируйте текущие признаки исправной работы до любых изменений: наличие DAG в интерфейсе, успешный разбор файлов, ожидаемый порядок задач, выходные артефакты и поведение при отказе сервиса модели. Эталон лучше хранить как список проверок с ссылками на тестовые входы и ожидаемые свойства результата. Для полного перечня запусков используйте выгрузку и скрипт сверки: языковая модель может объяснить отклонения и предложить гипотезы, а инженер подтверждает вывод по исходным журналам.
Выпишите зависимые команды: разработчики DAG отвечают за импорты и логику задач, администратор платформы — за компоненты и базу метаданных, владелец ИИ-сценария — за смысл результата. Миграция оператора внутри одного DAG составляет лишь часть работы. Обзор отдельных операторов отвечает на вопрос о выборе шага конвейера; план перехода на Airflow 3 охватывает все исполняемые DAG и общую платформу.
Точки несовместимости
В Airflow 3 задачи и workers обращаются к ресурсам Airflow через API server; прямой доступ к metadata DB из кода задач ограничен. Поэтому найдите пользовательские операторы, которые открывают сессию базы Airflow, читают её модели или меняют служебные таблицы. Их перенос требует отдельного технического решения на поддерживаемых интерфейсах. Проверяйте существующий код и его фактические зависимости от окружения.
| Участок | Что сверить | Критерий для перехода |
|---|---|---|
| DAG и импорты | Пути импортов, удалённые возможности, зависимости от контекста | Файлы разбираются в целевой среде, предупреждения изучены |
| Providers и плагины | Совместимые выпуски, стандартный provider, пользовательские расширения | Нужные операторы доступны, пользовательские плагины проверены |
| Архитектура | API server, отдельный dag processor, доступ workers | Компоненты запускаются в тестовом контуре с нужными правами |
| Metadata DB | Согласованная копия, объём служебных данных, порядок восстановления | Копия проверена отдельным восстановлением до миграции |
В руководстве Apache указано, что часть привычных операторов, сенсоров и триггеров вынесена в пакет стандартного provider. Там же перечислены удалённые возможности и изменения API. Отметьте каждое использование по реальному коду и документации установленного provider. Отдельно проверьте расписания и ручные запуски: смысл интервалов данных и логической даты способен влиять на выборку для ИИ-расчёта. Сравнивайте фактические входные наборы после переноса с заранее подготовленным эталоном.
Список несовместимостей должен содержать владельца исправления и проверку, которая покажет результат. Общая формулировка «DAG выглядит совместимым» оставляет риск скрытой ошибки при выполнении. Статический анализ подсказывает места для ревью, а испытание задачи показывает её поведение в новом окружении.
Подготовка контура
Соберите изолированный контур с копией конфигурации и разрешёнными тестовыми данными. Секреты подайте через принятый механизм управления доступом; текстовые дампы и отчёты проверки храните без ключей и сырых промптов. До работы с metadata DB создайте согласованную резервную копию и проверьте её восстановление отдельно. Руководство Apache подчёркивает риск частично мигрированной базы при сбое и важность согласованной копии. Файл резервной копии требует подтверждения пробным восстановлением.
- Проверьте исходную версию Airflow и совместимость Python по руководству к выбранному выпуску. Зафиксируйте состав пакетов, providers и инфраструктурных компонентов.
- Запустите на копии DAG статическую проверку Ruff с правилами AIR для несовместимостей. Сохраните отчёт, затем вручную разберите каждое замечание и спорное автоматическое исправление.
- Проверьте импорты, стандартный provider, пользовательские операторы и обращения к metadata DB. Свяжите каждое изменение с тестом поведения.
- Подготовьте согласованную копию metadata DB и выполните пробное восстановление в отдельном окружении. Зафиксируйте способ повторного развёртывания прежнего приложения.
- Лишь после завершения этих проверок составьте план миграции тестовой базы и запуска компонентов Airflow 3. Команды изменения схемы выполняет ответственный администратор по утверждённому порядку.
Статическая проверка DAG через правила AIR в Ruff из официального руководства полезна как фильтр известных изменений. Она пропускает ошибки бизнес-логики, особенности providers и поведение сторонних сервисов. Поэтому результат Ruff включают в перечень вопросов к ревью; акт приёмки готовят по результатам испытаний всего конвейера. Для полной выгрузки замечаний используйте скрипт группировки по файлам; модель помогает сформулировать причины и варианты исправления, инженер сверяет каждый пункт с кодом.
Нужен план миграции для вашего действующего конвейера?
Прогон и приёмка
После подготовки целевого контура предложите пробный запуск на обезличенных входах. Начните с проверки разбора всех DAG, затем исполните цепочку задач по согласованным сценариям: нормальный вход, отказ модели, повтор задания и ручной запуск. Просмотрите промежуточные артефакты, записи о состоянии задач и итоговый результат. Журналы и входы сравнивает скрипт по явным полям, а языковая модель может объяснить найденные различия. Ответственный инженер подтверждает, что интерпретация соответствует данным.
Для ИИ-конвейера особенно важны границы повторного вызова. Повтор после сбоя должен следовать правилам проекта: у одних шагов безопасно повторное чтение, у других повтор способен создать дубликат внешнего действия. Проверьте фактические ключи идемпотентности, способ сохранения ответа и маршрут ручного разбора спорного результата. Права на запись во внешнюю систему контролирует сервер и политика доступа, тогда как текстовый промпт лишь описывает допустимое поведение. Содержимое закрытых запросов и секретов исключите из диагностического журнала.
Приёмка требует сравнения с эталоном исходного конвейера: одинаковые тестовые входы, ожидаемое число логических результатов, сохранённая связь с источником и понятная причина любого расхождения. Разница версий может менять контекст запуска; оцените смысл используемых дат и интервалов отдельно. Если выход модели по природе вариативен, сравните проверяемые свойства результата и обязательные ограничения вместо буквального совпадения текста. Материал о сценариях тестирования ИИ-агентов помогает продумать отказ, а здесь те же проверки служат воротами для обновления платформы.
Записывайте открытые расхождения вместе с владельцем решения. Успех одного запуска подтверждает конкретный сценарий; покрытие остальных сценариев видно по отдельному протоколу. Такой протокол нужен перед решением о переключении действующего потока.
Откат и решение
Для будущего пилота заранее задайте условие остановки: потеря DAG при разборе, ошибка доступа к ресурсу, расхождение выходного набора или невозможность прочитать журналы. Для каждого условия назначьте ответственного и маршрут фиксации признаков. Решение о переключении принимает владелец платформы вместе с владельцем конвейера после просмотра протокола. Такой подход описывает проектную схему будущего пилота.
Откат включает прежнюю версию приложения, прежние конфигурации и восстановление согласованной копии metadata DB. Обратимость миграции базы следует считать открытым вопросом, пока команда сама проверит восстановление в отдельном контуре. Старый и новый процесс записи в одну служебную базу одновременно создают риск неоднозначного состояния; порядок остановки и запуска систем требуется зафиксировать до переключения. При расхождении внешних результатов понадобится отдельный разбор уже выполненных действий, поскольку после восстановления metadata DB судьбу внешних действий выясняют отдельно.
Цена такого перехода зависит от состояния DAG, количества providers, пользовательских расширений, размера базы метаданных и требований к испытаниям. Смету обсуждают после инвентаризации и подтверждения объёма работ; тарифы указывают по актуальным условиям поставщиков без переноса чужих цифр в план. Для проектирования маршрута перехода можно обратиться к команде по автоматизации бизнес-процессов. На встрече полезно показать реестр DAG, список замечаний статической проверки и критерии восстановления: по ним легче определить состав будущего пилота.