🧑‍💻 Вопросы с собеседований для DevOps

1. Чем отличаются обычные сенсоры от deferrable-сенсоров?
Обычные сенсоры постоянно занимают worker во время ожидания. Deferrable-сенсоры освобождают worker и «засыпают» до наступления события. Они используют асинхронную модель ожидания. Это позволяет существенно снизить нагрузку на систему. Deferrable-сенсоры лучше подходят для долгих ожиданий.

2. Как работать с несколькими окружениями (Dev / Test / Prod) и релизным пайплайном?
Окружения Dev, Test и Prod используются для разделения этапов разработки. Dev — для разработки, Test — для проверки, Prod — для игроков. Каждое окружение имеет свои настройки и данные. Релизный пайплайн автоматизирует сборку, тестирование и выкладку игры. Это снижает количество ошибок и упрощает выпуск обновлений.

3. Как дождаться готовности базы данных при старте приложения в Docker Compose?
Готовности базы данных можно дождаться через healthcheck, скрипты ожидания или retry-логику в приложении. Самый надёжный способ — комбинация healthcheck и повторных попыток подключения. Docker Compose сам по себе не ждёт готовности сервиса. Поэтому ожидание нужно реализовывать явно. Это стандартная практика.

4. Как реализуется собственный сенсор в Airflow?
Собственный сенсор создаётся путём наследования от BaseSensorOperator. В нём реализуется метод poke, который проверяет условие. Airflow вызывает этот метод с заданным интервалом. Для асинхронной версии используется deferrable-модель и триггеры. Такой подход позволяет реализовать ожидание любых внешних условий.

5. Какие проблемы с ресурсами могут возникать при неправильном использовании сенсоров?
При неправильном использовании сенсоры могут занимать worker-ы на долгое время. Это приводит к нехватке слотов для реальных задач. Scheduler начинает работать медленнее, а DAG-и встают в очередь. Также растёт нагрузка на внешние системы из-за частых проверок. В итоге Airflow становится нестабильным.

#deferrable #sensor #environment #pipeline #docker #compose #database #custom #basesensoroperator #resource