---
title: Планировщик (Центр автоматических заданий)
description: Пульт управления фоновыми заданиями TSync — курсы валют, низкие остатки, отчёты по расписанию, проверки процессов: запуски, сбои, блокировки и запуск задания вручную.
product: TSync Intelligence 11.3.6
language: ru
canonical: https://docs.tsync.pro/ru/scheduler/
source: https://docs.tsync.pro/llms.txt
---

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

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

## Открыть

**Планировщик** в боковом меню или `/admin/tsync_scheduler`. Доступен из
[Центра конфигурации](configuration-center.md), когда включён режим хаба.

## Что вы видите

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

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

У каждого задания есть кнопка **Запустить сейчас** (безопасное 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-задача](setup-cron-job.md) на сервере настроена.

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

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

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

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

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

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

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

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