Как передать конвейер данных дежурной команде

Автор конвейера уходит в отпуск. Расписание работает, дашборд зелёный, коллега умеет открыть Airflow. Первое ночное падение показывает, что этого мало: неизвестно, можно ли повторить задачу, кто разрешает заменить таблицу и кому сообщить о вчерашних данных. Передача заканчивается, когда другой человек способен принять правильное решение по наблюдаемым фактам.

Передавайте маршрут решения

Начните с потребителя. Укажите, какая таблица или API ему нужны, к какому времени и что произойдёт при опоздании. Затем нарисуйте короткий путь: источник, сохранённый вход, преобразование, место подготовки, публикация. Для каждого перехода нужны проверяемый результат и ссылка на конкретный журнал или экран. Большая схема всех технологий редко помогает в первые десять минут инцидента.

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

Опишите эти ветви заранее. Фраза «перезапустить DAG» слишком широка: у задания могут быть внешние действия, которые нельзя повторять, или чтение изменившегося источника. Чтобы повтор задачи давал тот же результат, она должна читать определённый вход и записывать его без повторного добавления уже принятых строк. Наличие кнопки повторного запуска ещё не определяет безопасность операции в вашем конвейере.

Сделайте карточку одного инцидента

Для витрины продаж карточка начинается так: «К 08:30 опубликован период за вчера; если новый период не принят, сохраняем предыдущую версию и показываем её дату». Далее укажите объект проверки: журнал публикаций, поля периода, версии преобразования и времени принятия. Проверять нужно именно результат, который читает отчёт, а не последнюю успешную внутреннюю задачу.

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

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

Разделите полномочия

Автор преобразования отвечает за смысл расчёта и объяснение расхождения. Владелец источника — за состав и срок поставки. Дежурный выполняет разрешённые операции восстановления. Владелец бизнес-показателя решает, можно ли использовать неполный или устаревший результат. В небольшой команде один человек совмещает роли, но решение всё равно должно быть названо.

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

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

Проведите передачу как небольшой экзамен

Выберите тестовый период и безопасно смоделируйте отсутствие части входа. Автор наблюдает, принимающий работает по инструкции. Засекайте не только время ремонта, но и момент правильного определения причины. Если человек нашёл команду, но не заметил неполную поставку, инструкция ещё не выполняет свою задачу.

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

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

Следующий шаг в практике

В Data Engineering Fast‑Track вы связываете Kafka, Spark, lakehouse и Airflow, получаете локальную среду Docker Compose, шаблоны DAG и сценарий backfill. На таком проекте можно отработать путь от исходных событий до проверяемой таблицы, а затем подготовить понятную передачу собственного конвейера. Откройте программу платного курса «Data Engineering Fast‑Track: Kafka → Airflow → Spark».

Связанный разбор: как повторять загрузку выбранного периода.