Задания по расписанию (крон) на хостинге: выгрузки, рассылки и их контроль

У большинства сайтов есть невидимая «ночная смена»: пока команда спит, сервер сам выгружает заявки в учётную систему, обновляет цены и остатки, рассылает письма, делает резервные копии. Работает всё это через задания по расписанию, которые в технической среде называют кроном. Пока крон на хостинге выполняется исправно, о нём никто не вспоминает. Когда он тихо ломается, последствия обнаруживаются не сразу: на сайте старые цены, в Битрикс24 нет вчерашних обращений, рассылка не ушла. Разберём, что это за механизм, зачем он нужен сайту и как сделать так, чтобы упавшее задание не осталось незамеченным.

Что такое задания по расписанию

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

На практике хостинг-провайдеры, такие как Бегет, Таймвеб и Рег.ру, предоставляют в панели управления раздел «Задания по расписанию» или «Планировщик». Там вы указываете, что запускать и как часто. Специалисту это занимает пять минут, но правильный выбор того, что и когда запускать, определяет, будет ли сайт работать без постоянного ручного присмотра.

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

Для чего крон нужен именно сайту

Первая задача — выгрузка заявок и обмен данными с системами учёта. Форма на сайте принимает обращение, а дальше его нужно передать в амоСРМ или Битрикс24, создать сделку, уведомить менеджера. Часть сайтов делает это сразу при отправке, но надёжнее складывать заявки в очередь и разбирать её по расписанию: если учётная система на минуту недоступна, заявка не потеряется, а уйдёт при следующей попытке.

Вторая — обновление цен и остатков. Для интернет-магазина на ХостСМС это самый распространённый случай. Склад ведётся в учётной программе, а сайт раз в час или раз в сутки забирает свежий файл с ценами и количеством. Если задание остановилось, на сайте продолжают висеть цены недельной давности: покупатель оформляет заказ, а менеджер вынужден звонить и объяснять, что товара нет или цена другая. Репутация и заявки страдают одновременно.

Третья — рассылки и напоминания: письма о брошенных корзинах, уведомления об акциях, напоминания клиенту о записи. Четвёртая — резервные копии сайта и базы данных. Пятая — служебные задачи: очистка временных файлов, пересборка карты сайта, проверка ссылок, подготовка отчётов для руководителя к понедельнику. Каждая из них по отдельности кажется мелочью, но вместе они образуют фоновую «нервную систему» сайта.

Шестая задача, о которой часто забывают, — регулярные проверки самого сайта: доступна ли главная, отвечает ли страница с формой, приходит ли тестовое письмо. Такие проверки превращают крон из инструмента автоматизации в инструмент контроля, и к этому мы вернёмся ниже.

Как задания «тихо падают»

Причин у молчаливого отказа несколько, и почти все они возникают не из-за ошибки в самом задании, а из-за изменений вокруг него. Хостинг обновил версию ПХП, и скрипт, который работал годами, перестал запускаться. Сменился адрес сайта или перешли на защищённое соединение, а задание продолжает обращаться по старому адресу. Закончилось место на диске, и очередная выгрузка не смогла записать файл. Поменялся пароль к учётной системе, и обмен остановился.

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

Четвёртый и самый неприятный вид — задание «успешно» выполняется, но делает не то. Скрипт завершился без ошибок, хостинг считает всё в порядке, а в файле, который он забрал, ноль строк. Поэтому проверять нужно не только факт запуска, но и результат: сколько записей обработано, когда последний раз менялись цены, сколько писем отправлено.

Три главные ошибки при настройке

Первая — запускать слишком часто. Выгрузка каждую минуту выглядит солидно, но нагружает сервер и может привести к тому, что хостинг начнёт ограничивать сайт. Мы подробно писали о том, что делать, если сайт создаёт большую нагрузку. Для большинства малого бизнеса достаточно раз в час для остатков и раз в сутки для прайса.

Вторая — запускать всё в одно и то же время. Если на три часа ночи назначены резервная копия, выгрузка заявок, пересборка карты сайта и рассылка, то задания мешают друг другу и сервер упирается в ограничения. Лучше разнести их по времени с запасом: копия в три, выгрузка в четыре, рассылка утром в девять.

Третья — не записывать, что и зачем настроено. Через год никто не вспомнит, что за загадочное задание запускается в 02:17 и что будет, если его отключить. Заведите простой реестр: название, что делает, как часто, кто отвечает, куда пишется результат. Хватит таблицы в общем облачном хранилище. Когда придёт время переезжать на другой хостинг, этот реестр сэкономит неделю расследований.

Журнал выполнения: основа контроля

Каждое задание должно оставлять след. Минимум — записывать в журнал время начала, время окончания, результат (успех или ошибка) и краткое описание сделанного: «обновлено 1 240 строк прайса», «отправлено 37 писем», «передано 5 заявок в амоСРМ». Журнал может быть обычным файлом на сервере, таблицей в базе данных или отдельной страницей в административной части сайта, где видно последние запуски.

Хорошая практика — выводить в административной части ХостСМС простую сводку: когда последний раз успешно выполнялась каждая задача и сколько записей она обработала. Менеджеру не нужно разбираться в технических деталях, ему достаточно увидеть, что последнее обновление цен было сегодня утром. Если там написано «шесть дней назад», стоит насторожиться.

Журнал должен иметь предел хранения. Файл, в который сервер дописывает строки каждую минуту, через год разрастается до огромных размеров и сам начинает создавать проблемы. Храните подробные записи за последние тридцать дней, остальное сворачивайте до краткой статистики. А в журнале всегда сохраняйте не только успехи, но и причины неудач: именно по ним специалисты быстро находят, что сломалось.

Уведомления об ошибках: чтобы узнавать первым

Журнал полезен, только если в него кто-то заглядывает. Поэтому вторая половина контроля — уведомления. Самый простой вариант: при ошибке задание отправляет письмо на рабочую почту ответственного. Но письма имеют обыкновение теряться среди сотни других, поэтому лучше дублировать важные сообщения в Телеграм или Макс: короткое «Выгрузка цен не выполнена, причина такая-то» в рабочем чате видят сразу.

Второй уровень — уведомление об отсутствии события. Это самое важное, и именно его чаще всего не делают. Если задание вообще не запустилось, оно не может прислать сообщение об ошибке, потому что не запущено. Значит, нужен независимый «сторож», который проверяет: а было ли сегодня обновление цен? Если до десяти утра свежего запуска нет, приходит предупреждение. Так же устроена проверка заявок: если за рабочий день не поступило ни одного обращения, хотя обычно их приходит десяток, нужно выяснить, не сломалась ли форма.

Для такого сторожа подходит отдельное задание на другом сервисе или внешняя проверка доступности. Многие российские сервисы мониторинга умеют ожидать «пульс» от вашего задания: вы после успешного запуска обращаетесь к специальному адресу, а если пульс не пришёл вовремя, сервис пишет вам. Принцип простой: тревога срабатывает не от шума, а от тишины.

Не превращайте уведомления в спам. Если ежедневно приходит пятьдесят сообщений «всё хорошо», их перестанут читать, и одно «всё плохо» затеряется. Хорошее правило: об успехе сообщать раз в неделю сводкой, об ошибках — сразу и коротко, с указанием, что сломалось и что нужно сделать.

Что делать при первом подозрении

Допустим, менеджер заметил, что в магазине висят вчерашние остатки. Порядок действий лучше проговорить заранее, чтобы не паниковать. Сначала посмотреть журнал: когда задание запускалось в последний раз и чем закончилось. Затем проверить, не менялось ли что-то в окружении: версия ПХП, адрес сайта, права доступа, свободное место на диске. Если причина не очевидна, запустить задание вручную и посмотреть, что скажет система.

После исправления обязательно убедиться, что данные восстановились: сравнить несколько цен из прайса с учётной программой, проверить, что пропущенные заявки дошли в Битрикс24 или амоСРМ, при необходимости дослать то, что накопилось. И только потом решить, как не допустить повторения: добавить проверку, уведомление или ограничение по времени выполнения.

Отдельное внимание уделите любым работам на хостинге. После смены тарифа, переноса сайта, обновления версии ПХП или переезда к другому провайдеру нужно вручную пройтись по реестру заданий и убедиться, что каждое из них заведено на новом месте и срабатывает. Именно после переездов чаще всего и теряются «невидимые» задачи: на старом хостинге они были, на новый их никто не перенёс.

Как это связано с продвижением «3 в 1»

Фоновые задания влияют на обращения напрямую. Первый канал — поиск, поисковое продвижение и ГЕО. Если карта сайта не пересобирается, цены в описаниях устарели, а страницы с остатками показывают «нет в наличии» там, где товар есть, поисковая система и нейропоиск берут из сайта неверные факты. Хорошо, когда ответ на вопрос «сколько стоит» на странице совпадает с реальностью, и крон поддерживает это совпадение. Яндекс.Вебмастер подскажет, как робот видит страницы, а регулярное обновление данных даёт ему актуальную картину.

Второй канал — Яндекс Справочник и Яндекс Бизнес с Яндекс Картами. Часы работы, телефон, перечень услуг и цены в карточке должны совпадать с сайтом. Если у вас есть выгрузка данных в карточки по расписанию, её нужно контролировать так же, как и остальные задания: устаревший телефон в карточке — это потерянные обращения. Третий канал — 2ГИС: там своя аудитория и свои данные об организации, и актуальность ассортимента и прайса важна не меньше.

В подходе «3 в 1» обращения с карт считаются наравне с заявками с сайта, поэтому важно, чтобы автоматические процессы не подводили ни один из каналов. Ежемесячно проверяйте итоговые цифры: сколько обращений пришло с поиска, сколько с Яндекс Карт, сколько из 2ГИС, сколько из них дошло до сделки. Если одна строка внезапно просела, часто причина оказывается в тихо сломанном фоновом задании, а не в «рынке».

Условный пример: магазин, где цены обновлялись по ночам

Небольшой магазин строительных материалов на ХостСМС получал прайс из учётной программы каждую ночь. Задание работало три года без нареканий. После обновления тарифа у хостинг-провайдера изменилась версия ПХП, и скрипт выгрузки начал завершаться с ошибкой в самом начале. Журнала ошибок никто не смотрел, уведомлений не было. На сайте остались цены недельной давности, а на ряд товаров поставщик успел поднять стоимость.

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

Через месяц похожий сбой повторился при переносе сайта на другой тариф, но на этот раз сообщение пришло в течение часа, и цены вернули до открытия магазина. Разница между двумя случаями не в технике, а в наличии контроля: в первом ошибку нашли клиенты, во втором — система.

Простой план проверки на ближайшую неделю

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

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

Выводы и бесплатная консультация

Крон на хостинге — это тихий помощник, который выгружает заявки, обновляет цены, отправляет письма и делает копии. Опасность не в самих заданиях, а в том, что их поломки незаметны. Журнал выполнения, уведомления об ошибках и сторожевые проверки превращают скрытый механизм в управляемый процесс, а регулярная ревизия после любых изменений на хостинге не даёт заданиям пропасть при переезде.

Специалисты компании «Сайты Профессионально» готовы бесплатно посмотреть, какие задания работают на вашем сайте, есть ли у них журнал и уведомления, и подсказать, где вы рискуете потерять обращения. Заодно разберём, как сайт, карточка в Яндекс Бизнесе и 2ГИС работают вместе в подходе «3 в 1». Напишите нам, и мы проведём консультацию без оплаты и обязательств.