Кейс из ops: регулярная задача должна запускаться раз в сутки, а у команды уже были срывы из-за cron-джобов, к

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

Контекст:
— расписание есть, контроля нет
— логика запуска размазана по shell-скриптам
— мониторинг видит сбой только постфактум

Действие:
перевели планировщик на systemd timers. Получили явные юниты, зависимость от сервиса, понятный статус, журналирование через journalctl и нормальную работу после рестарта без ручного восстановления. Для критичных задач добавили проверку таймера в ежедневный контроль и алерт, если last trigger ушёл за SLA.

Результат:
— меньше скрытых пропусков
— быстрее разбор инцидентов
— задача стала объектом контроля, а не «магией на сервере»

В ops это важный сдвиг: не просто «запланировать», а сделать расписание наблюдаемым. Таймер — это не удобство. Это регламент запуска, который можно проверить, передать и восстановить. ⏱️