Cron-завдання на хостингу: як автоматизувати рутину і звільнити собі 10 годин на тиждень

Щоранку о 7:15 один мій знайомий адміністратор заходив на сервер, вручну чистив кеш, запускав бекап бази, перевіряв лог-файли, відправляв звіт на пошту. Кожен. Божий. День. Так тривало два роки, поки одного ранку він просто проспав - і нічого не зламалось. Бо за тиждень до того я показав йому cron. Ця маленька утиліта Unix, якій вже більше 40 років, досі залишається найпотужнішим інструментом автоматизації на будь-якому хостингу. І якщо ви досі робите щось на сервері руками - ця стаття для вас.

Що таке cron і чому він працює як швейцарський годинник

Cron - це планувальник задач у Linux/Unix-системах. Уявіть собі надійного будильника, який ніколи не розряджається, не забуває і не бере відпустку. Ви кажете йому: "кожну середу о третій ночі зроби ось це" - і він виконує. Без питань, без нагадувань, без помилок.

Кожен хостинг - від найдешевшого шареда за $2 на місяць до потужного виділеного сервера - має cron. Але за статистикою Plesk, лише 23% користувачів хостингу використовують хоча б одне cron-завдання. Решта 77% або не знають про нього, або бояться "щось зламати". Давайте це виправимо.

Анатомія crontab: розшифровуємо п'ять зірочок

Серце cron - файл crontab. Кожен рядок у ньому виглядає лякаюче, але насправді це простіше, ніж рецепт борщу. Ось формула:

* * * * * /шлях/до/команди

П'ять зірочок - п'ять позицій. Зліва направо:

1. Хвилина (0-59) - коли саме протягом години
2. Година (0-23) - котра година доби
3. День місяця (1-31) - якого числа
4. Місяць (1-12) - який місяць року
5. День тижня (0-7, де 0 і 7 - неділя) - який день

Зірочка означає "будь-яке значення". Тобто * * * * * - це щохвилини. Страшно? Не хвилюйтеся, ніхто так не робить (майже ніхто).

Бачите? Жодної магії. П'ять цифр, один шлях до скрипта - і сервер працює на вас, а не ви на нього.

Сім завдань, які варто автоматизувати прямо зараз

Окей, синтаксис зрозумілий. Але що конкретно автоматизувати? Ось мій перевірений список, сформований за роки роботи з десятками проектів:

• Бекапи бази і файлів - щоденно о 3:00-4:00, коли трафік мінімальний
• Очищення тимчасових файлів - /tmp, кеш-директорії, сесії старше 24 годин
• Перевірка SSL-сертифікатів - скрипт, що попереджає за 14 днів до закінчення
• Оновлення sitemap.xml - критично для SEO, особливо для великих сайтів
• Ротація логів - щоб один access.log не з'їв весь диск за місяць

Реальна історія: інтернет-магазин із 50 000 товарів не оновлював sitemap автоматично. Google індексував лише 12 000 сторінок. Після додавання одного cron-завдання 0 4 * * * /usr/bin/php /var/www/generate_sitemap.php за три тижні індексація зросла до 47 000 сторінок. Трафік подвоївся. Один рядок у crontab.

"Автоматизація - це не про лінь. Це про те, щоб розум людини працював над складними завданнями, а машина займалась повторюваними." - Тім Феріс, автор "The 4-Hour Workweek"

Як налаштувати cron: три шляхи для різних рівнів

Залежно від вашого хостингу і досвіду, є три способи дістатися до cron. Від найпростішого до хардкорного.

Шлях 1: Панель керування (cPanel, Plesk, DirectAdmin)

Заходите в панель, знаходите розділ "Cron Jobs" або "Scheduled Tasks". Обираєте частоту з випадаючого меню, вставляєте команду. Готово. Це варіант для 90% користувачів шаред-хостингу. У cPanel це буквально 4 кліки.

Шлях 2: SSH і команда crontab -e

Підключаєтеся до сервера через SSH, набираєте crontab -e, додаєте рядок, зберігаєте. Все. Цей варіант для VPS і виділених серверів. Файл відкриється у текстовому редакторі (зазвичай nano або vi). Якщо vi вас лякає - наберіть EDITOR=nano crontab -e і працюйте у зручнішому nano.

Шлях 3: Системний crontab /etc/crontab

Тут можна задавати завдання від різних користувачів. Формат трохи інший - між часом і командою додається ім'я користувача: 0 3 * * * root /usr/local/bin/backup.sh. Це вже для адміністраторів, які керують сервером цілком.

Порада, яка врятує вам нерви: після створення завдання завжди перевіряйте, чи вказали повний шлях до інтерпретатора. Не php script.php, а /usr/bin/php /повний/шлях/script.php. Cron не знає ваших аліасів і змінних середовища. Це причина №1, чому "cron не працює".

Типові помилки, через які cron мовчить як партизан

Знаєте, що найгірше у cron? Він не скаже вам, що щось пішло не так. Він просто промовчить. Ваш скрипт впаде з помилкою - і ви дізнаєтесь про це через тиждень, коли бекапів не виявиться. Ось топ помилок, які я бачив сотні разів:

1. Відносні шляхи замість абсолютних. Cron запускає команди з домашньої директорії, а не з папки вашого проекту. Шлях ./backup.sh не спрацює - пишіть /home/user/scripts/backup.sh
2. Відсутність прав на виконання. Забули chmod +x script.sh? Cron теж не зможе його запустити
3. Неправильний інтерпретатор. На сервері може бути PHP 7.4 і PHP 8.2 одночасно. /usr/bin/php вказує на одну версію, /usr/bin/php8.2 - на іншу
4. Ігнорування виводу. Додайте >> /var/log/mycron.log 2>&1 в кінці команди. Так ви бачитимете і результат, і помилки
5. Часовий пояс. Сервер у Франкфурті, ви в Києві - різниця в годину. Перевірте timedatectl перед налаштуванням

Ще одна підступна штука - перекриття завдань. Якщо ваш скрипт бекапу працює 20 хвилин, а ви запускаєте його кожні 15 хвилин - два процеси перетнуться, навантажать сервер і можуть пошкодити дані. Рішення? Використовуйте flock: */15 * * * * /usr/bin/flock -n /tmp/backup.lock /home/user/backup.sh. Flock створює файл-замок і не дає запустити другу копію, поки перша не завершилась.

Просунуті прийоми: від аматора до профі за один вечір

Базу ви вже знаєте. Тепер - кілька прийомів, які відрізняють новачка від того, хто дійсно розуміє, що робить.

Сповіщення про збої у Telegram. Додайте в кінці вашого bash-скрипта перевірку exit-коду і відправку повідомлення через Telegram Bot API. Виглядає приблизно так: якщо скрипт завершився з помилкою - curl відправляє вам повідомлення в чат. Ви дізнаєтесь про проблему за секунди, а не за дні.

Спеціальні рядки замість цифр. Cron підтримує зручні скорочення:

• @reboot - виконати один раз при перезавантаженні сервера
• @daily - те саме, що 0 0 * * *
• @weekly - те саме, що 0 0 * * 0
• @hourly - те саме, що 0 * * * *

Набагато читабельніше, правда? @daily /home/user/cleanup.sh зрозуміє навіть людина, яка вперше бачить crontab.

Ланцюжки завдань. Потрібно спочатку зробити дамп бази, потім стиснути його, потім завантажити на S3? Не створюйте три окремі cron-завдання з різницею у 10 хвилин. Напишіть один bash-скрипт, де кожен наступний крок виконується тільки після успішного завершення попереднього (через &&). Один рядок у crontab, один скрипт, повний контроль.

Золоте правило: кожне cron-завдання повинне бути задокументоване. Коментар у crontab починається з #. Через рік ви не згадаєте, навіщо запускаєте якийсь process_queue.php кожні 5 хвилин. Але коментар # Обробка черги email-розсилок для маркетингового модуля все пояснить.

А що, якщо cron - це замало?

Cron ідеальний для простих періодичних завдань. Але якщо вам потрібна складна логіка - запуск задачі тільки після завершення іншої, повторні спроби при помилках, візуальний моніторинг - подивіться на інструменти типу Ofelia (для Docker-середовищ), Laravel Task Scheduling (для PHP-проектів) або Celery Beat (для Python). Вони побудовані поверх тієї ж ідеї, але дають більше гнучкості.

Втім, для 95% задач на типовому хостингу cron - це все, що вам потрібно. Серйозно. Не ускладнюйте те, що працює.

Ось вам виклик: відкрийте прямо зараз панель вашого хостингу, знайдіть розділ Cron Jobs і створіть хоча б одне завдання. Нехай це буде простий скрипт, що записує дату у файл - @hourly date >> /home/user/cron_test.log. Через годину перевірте лог. Якщо там є рядок з часом - вітаю, ви тільки що зробили перший крок до сервера, який працює на вас навіть коли ви спите. А скільки годин на тиждень ви витрачаєте на те, що міг би зробити один рядок у crontab?