Больше всего бесит не то, когда всё ломается. Ломается всегда. К этому привыкаешь быстро👀
Бесит момент, когда человек со стороны говорит:
Там же просто данные из источника перегрузить. Срочно надо.
И в этот момент ты уже примерно понимаешь, как закончится день 😔
Потому что “просто перегрузить данные” в реальности означает:
- сходить во внешнюю систему;
- вызвать функциональный модуль, который писал не ты;
- протащить данные через сетевое соединение;
- не убить Spark;
- не словить таймаут;
- не получить пустую выгрузку (иногда бывает и это отнимает время);
- не упереться в права (моя боль №1), лимиты, форматы, кодировки или внезапную “особенность реализации”.
Но снаружи это всё выглядит как одна маленькая задачка в духе:
Ну там же просто забрать данные.
Недавно у меня был ровно такой кейс.
Приходит срочная задача:
🤵‍
♂️:нужно перегрузить данные из внешней системы и забери всё дельтой
Сроки, разумеется, максимально бодрые.
В стиле “желательно вчера, но если сегодня - мы так уж и быть переживём”.
Ну что ж, задача принята. Мету выгрузил, метод загрузки и захвата данных прописал, ноо... Доходим до оркестратора...
Сначала всё выглядит нормально.
DAG стартует, таски пошли, ошибок нет.
Доходим до экстракта - и всё.
DAG просто зависает.
Не падает.
Не краснеет.
Не пишет тебе человеческую ошибку.
Он просто висит. Ну ладно, можно скинуть на инфру и немного подождать, но не несколько часов... Как в моём случае.
А это, честно говоря, один из самых мерзких типов проблем.
Когда пайплайн упал с понятной ошибкой - это ещё подарок.
У тебя есть traceback, код ошибки, место падения. Можно работать.
А когда он просто висит - начинается любимая игра😁
“Угадай, какая часть зоопарка сегодня решила умереть молча.”
Открываю мониторинг - чисто.
Смотрю логи Airflow - ничего полезного.
Смотрю состояние тасок - внешне всё будто живое.
Но данные не едут😱
И вот ты сидишь в этой прекрасной ситуации: задача срочная, бизнес ждёт, а система потихоньку открывает баночку пенного и готовится к надвигающимся выходным...
Начинаю копать глубже.
Сначала проверяю сам DAG.
Потом параметры запуска.
Потом окружение.
Потом подключение.
Потом уже лезу в Spark.
И БИНГО! Всплывает реальная причина: проблема с HTTP-соединением.
То есть Airflow сверху показывал просто зависание.
А настоящая проблема была глубже - на уровне взаимодействия Spark с источником.
После перезапуска Spark всё поехало (как и крыша от поторапливаний)
Данные начали грузиться.
Пайплайн ожил.
Задача технически разблокирована.
Но к этому моменту уже прошло время.
И вот тут начинается вторая часть цирка.
Потому что для тех, кто ставил задачу, всё это выглядит примерно так:
А почему так долго? Там же просто выгрузка.
И ВОТ ЭТО БОЛЬШЕ ВСЕГО БЕСИТ‼️
Ненормально - когда в сроки вообще не закладывают реальность и возможные факапы во время интеграции😡
Как сохранить себе нервы в такой ситуации?
Первое - никогда не обещать сроки без буфера.
Если задача связана с внешней системой, всегда закладывайте время на диагностику.
Второе - после каждого такого пожара улучшать наблюдаемость.
Если ошибку пришлось искать руками слишком долго, значит где-то не хватает логов, метрик или алертов.
Третье - объяснять бизнесу технические риски заранее.
Не в момент, когда всё уже горит, а до старта задачи. Потому что “срочно” не отменяет возможные проблемы.
Бомбёж окончен, спасибо за внимание🤗