Планировщик (Центр автоматических заданий)

Планировщик (/admin/tsync_scheduler) — это пульт управления фоновыми заданиями, которые поддерживают работу TSync: ежедневное обновление курсов валют, проверки низких остатков, рассылка отчётов по расписанию, проверки рабочих процессов и др. Он не заменяет cron-задачу на сервере; он даёт видимость и кнопку ручного запуска поверх того, что cron уже делает.

Открыть

Планировщик в боковом меню или /admin/tsync_scheduler. Доступен из Центра конфигурации, когда включён режим хаба.

Что вы видите

Задания — каждое зарегистрированное задание, что оно делает, когда запускалось и здорово ли оно.
Запуски — история каждого запуска с его статусом (успех / ошибка / пропущено).
Сбои — запуски с ошибкой, чтобы быстро заметить проблему.
Блокировки — задание выполняется под блокировкой, чтобы не накладываться само на себя; можно увидеть (и при необходимости сбросить) зависшую блокировку.
Диагностика — быстрый обзор состояния всего планировщика.

Запустить задание сейчас

У каждого задания есть кнопка Запустить сейчас (безопасное POST-действие с подтверждением). Используйте её, чтобы принудительно выполнить, например, обновление курсов, не дожидаясь ежедневного тика. Ручной запуск записывается в Запуски, как любой другой.

Корпоративный вид

Планировщик → Enterprise (/admin/tsync_scheduler/enterprise) показывает расширенное планирование: задания, зависящие от других (выполняются в правильном порядке), приоритеты, лимиты SLA (слишком долгое задание помечается), пробные запуски и обнаружение аномалий (запуск намного медленнее обычного выделяется).

Как отключить задание

У каждого задания есть переключатель включено/выключено. Отключение убирает его из того, что подхватывает cron, но сохраняет историю — удобно, когда одно задание ведёт себя плохо, а остальное расписание должно продолжать работать, вместо того чтобы выключать cron целиком.

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

Репетиция задания — dry run

В разделе Планировщик → Enterprise задание можно запустить как dry run: оно проходит свои реальные шаги, но помечается как репетиция и — что важно — его длительность не попадает в базовую линию задания. Это важно из-за того, как определяются аномалии (ниже): иначе несколько репетиций научили бы систему, что задание медленнее, чем есть на самом деле.

Результат показывается сразу — со статусом и затраченным временем.

Как читать список запусков

Три исхода, и третий понимают неправильно чаще всего:

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

Столбец «Последний запуск» отвечает на заданный вопрос

Большинство заданий в этом списке — управляемые: cron платформы вызывает их напрямую, а Планировщик только наблюдает. До v11.1.6 столбец показывал лишь последний запуск, начатый из этой консоли, поэтому ежедневное обновление курсов могло показывать 10 июня, хотя курсы были получены тем же утром, — и администратор закономерно решал, что задание мертво.

Теперь столбец показывает более поздний из двух запусков и указывает его происхождение: на вопрос «когда это выполнялось в последний раз» приходит настоящий ответ, а не сноска о том, о каком механизме следовало подумать.

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

Три плитки сходятся

Запуски (24ч), OK (24ч) и Сбои (24ч) оставляли разрыв: 2 805 запусков, 2 649 OK и пустая плитка «Сбои» — 156 запусков, которые не относились ни к тем, ни к другим и не показывались нигде. Они никогда не пропадали: OK считает успех и предупреждение, Сбои считают сбой и таймаут, поэтому пропущенные, заблокированные, выполняющиеся и устаревшие не попадали никуда.

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

Когда блокировка «залипла»

На время работы задание держит блокировку, чтобы никогда не пересечься с самим собой. Если запуск прерван — процесс PHP убит, сервер перезапустился в середине — блокировка может его пережить, и тогда задание пропускает каждый цикл, считая, что копия ещё работает.

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

Как определяется аномалия

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

Нарушение SLA — отдельная, абсолютная проверка: задание объявило максимальную длительность и превысило её.

Планировщик только наблюдает и позволяет запускать существующие задания — он не переписывает cron. Если задание вообще не запускается, сначала проверьте, что cron-задача на сервере настроена.

Задача «Хранение телеметрии доступа»

Начиная с v10.2.0 в списке появляется новая управляемая задача: Хранение телеметрии доступа (security.telemetry_prune). Она удаляет данные измерения доступа старше 30 дней.

Почти на всех установках она будет сообщать «пропущено», и это правильно. Измерение доступа поставляется выключенным, поэтому удалять нечего. Задача говорит об этом прямо, а не сообщает «успех» — проход, который ничего не сделал, потому что никуда не заглянул, и есть тот самый отчёт, из-за которого весь список перестают читать.

Настраивать ничего не нужно, и если вы не включите измерение, эта задача никогда ничего не сделает.

Дней до эскалации критического сигнала

Рядом с настройкой хранения журналов есть ещё одна: дней до эскалации критического сигнала, по умолчанию 7, в диапазоне от 1 до 365.

Консоли TSync обнаруживают проблемы надёжно; чего никто не узнавал — что критическая висит открытой неделями. По истечении этого срока такой сигнал поднимает оповещение «Сигнал открыт слишком долго» в Центре уведомлений и появляется в панели «Требует внимания». Подтверждённый вами сигнал не эскалируется, а переставший подниматься полностью теряет свой отсчёт.

Поставьте меньше, если хотите узнавать раньше; больше — если команда и так пересматривает сигналы реже.