В какой-то момент crontab нашего сервера стал похож на спагетти. 20+ записей, каждая с комментарием «не трогать», некоторые запускались в одно время и конфликтовали за ресурсы. Однажды два скрипта одновременно обратились к eZee API и получили rate limit. В другой раз три задачи стартовали в :00 и сервер на минуту задохнулся. Нужен был оркестратор.
Проблема: cron не знает контекста
Cron — отличный инструмент для простых сценариев. Но когда задач 20+, возникают проблемы, которые cron принципиально не может решить. Пересечения по времени — два скрипта запускаются одновременно и конфликтуют за общий ресурс (база, API). Отсутствие зависимостей — задача B должна запускаться после задачи A, но cron об этом не знает. Нет мониторинга — если задача упала, cron не в курсе, что повтор нужен. Нет приоритетов — критический health-check и второстепенная очистка логов для cron равнозначны.
Решение: Alice Scheduler
Мы написали централизованный планировщик — alice_scheduler.py. Один Python-скрипт, который запускается каждые 2 минуты через единственную запись в cron. Он управляет очередью из 20 задач, следит за пересечениями, учитывает зависимости и ведёт лог выполнения.
Каждая задача описана как объект с параметрами: расписание (cron-выражение), приоритет (critical / normal / low), зависимости (список задач, которые должны завершиться перед запуском), таймаут, retry-политика. Планировщик проходит по очереди, проверяет, наступило ли время запуска, разрешены ли зависимости, и запускает задачу в subprocess.
Устранение пересечений
Первое, что мы сделали — развели задачи по времени. Раньше 5 скриптов стартовали в :00. Теперь: bot_health_monitor в :03, alice_pulse в :06, ezee_cleanup_reminder в :05, threads_autopublisher в :10, sync_dds_to_postgres в :10 (другой час). Это простое изменение убрало 70% пиковой нагрузки на сервер.
Вторая оптимизация — mutex на общие ресурсы. Если две задачи обращаются к eZee API, планировщик не запускает вторую, пока первая не завершится. Это решило проблему rate limit раз и навсегда.
Снижение шума уведомлений
Побочный эффект централизации — контроль над уведомлениями. Раньше каждый скрипт слал свои алерты в Telegram. В сумме получалось 30-40 сообщений в день. Мы добавили логику фильтрации: alice_pulse шлёт уведомление, только если есть новые задачи, срочное или полный пульс-отчёт. Снижение шума — примерно 70%.
Результат
Из 20+ строк в crontab осталась одна: запуск alice_scheduler каждые 2 минуты. Все остальные задачи управляются изнутри. Пересечения по времени устранены. Rate limit на внешние API больше не появляются. Пиковая нагрузка на сервер снизилась на 70%. Уведомления стали осмысленными вместо шумных. И главное — добавление новой задачи теперь занимает 5 минут вместо получаса отладки cron-конфликтов.