Какие варианты запуска скриптов по расписанию существуют

Что проверяют

Знаете ли вы инструменты шире crontab -e и понимаете ли, что расписание это половина задачи. Вторая половина: что будет при сбое, наложении запусков и перезагрузке сервера. Следом обычно спрашивают: «Как вы узнаете, что ночной бэкап не отработал?»

Как отвечать

Разложите варианты по уровням:

• cron: классика на одной машине. Окружение минимальное (короткий PATH, нет переменных профиля), пропущенные при выключении запуски не наверстываются, вывод без перенаправления теряется или уходит в MAILTO;
• systemd timers: OnCalendar= задаёт расписание, Persistent=true догоняет пропущенный запуск, RandomizedDelaySec= разносит старт, логи сразу в journald, список в systemctl list-timers;
• Kubernetes CronJob: concurrencyPolicy: Forbid запрещает наложение, startingDeadlineSeconds ограничивает опоздание, timeZone задаёт часовой пояс;
• планировщики CI: scheduled pipelines в GitLab, on: schedule в GitHub Actions, cron-триггер в Jenkins. Хороши для задач вокруг репозитория, но запуск может ждать в очереди;
• облачные триггеры: таймер для serverless-функции, если своего сервера нет;
• внутри приложения: Celery beat, Quartz, а для цепочек с зависимостями Airflow.

Затем эксплуатация. Наложение закрывают flock -n /var/lock/job.lock или concurrencyPolicy. Скрипт делают идемпотентным, чтобы повтор не ломал данные. Мониторят и отсутствие запуска: задача в конце шлёт пинг, алерт срабатывает, если пинга не было.

Где спотыкаются

Не учитывают переход на летнее время: в поясах с переводом часов задача на 02:30 раз в год пропускается или выполняется дважды. Серверы держат в UTC.

Кладут в cron скрипт, который работает из терминала, и удивляются падению. Причина почти всегда в окружении и относительных путях.

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