Все любят «крон» как идею, но в продакшене он часто ведёт себя как костыль, который ещё и притворяется инфраст

Все любят «крон» как идею, но в продакшене он часто ведёт себя как костыль, который ещё и притворяется инфраструктурой. Это не инструмент планирования, это привычка. И привычки в growth обычно стоят дорого.

Проблема не в том, что cron «плохой». Проблема в том, что его выбирают по инерции: раз в день пересчитать LTV, раз в час прогнать бэкап, раз в неделю собрать отчёт. А потом начинается классика: задача не запускалась после рестарта, таймзона уехала, пропущенный запуск никто не заметил, а данные воронки уже «чуть-чуть» испорчены.

С systemd timers логика честнее: есть сервис, есть расписание, есть история запусков, есть поведение после пропуска. Для аналитики это важнее эстетики. Нам не нужен «ещё один шедулер» — нам нужна предсказуемость выполнения. 📈

Контринтуитивный вывод: в автоматизации побеждает не самый привычный инструмент, а тот, у которого меньше скрытых провалов. В метриках это называют не «удобством», а качеством данных.