Перейти к основному содержимому

Расписание

Замер: 2026-08-14 · чем проверено: замер карты блоков (26 записей cron на s3), порождаемое расписание Читать перед тем, как менять расписание, деплой или что-либо про свежесть данных.

Какой цели служит​

Данные должны приходить сами — в заданное время, без человека, — чтобы к плановому сроку расчёты могли обновиться и никого не надо было просить «собери уже».

Для чего это нужно​

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

Расписание объявлено в реестре и порождается из него, а не правится руками на сервере. Ручная правка невидима никому, кроме того, кто её сделал: её нельзя проверить ревью и нельзя воспроизвести на новом сервере. Когда объявленное расходится с живым, мы теряем уверенность, что сбор вообще пойдёт, — поэтому выкладка сверяет расписание побайтно. Живой пример расхождения есть: на s3 его нет, на s2 восемь задач живут вне версионного crontab.

Что станет невозможным без этого​

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

Какой ценой это даётся​

  • Задержкой: число на экране — это последний прогон, а не сию минуту.
  • Хрупкостью: прогон, попавший на сбой площадки, оставляет дыру до следующего окна.
  • Сложностью: расписание, проверки свежести и сверки — целая служба, и у неё свои правила выкладки.

Что здесь работает, а что только объявлено​

Работает порождение расписания из реестра и побайтная сверка при выкладке: на s3 расхождений нет, на s2 есть восемь живых задач вне версионного файла. Но расписание доказывает запуск, а не успех: снимок s3 содержит 73 успешных и 13 частичных последних состояний. Шесть таблиц учёта слотов пусты на 14.08: писатель в дереве есть (LedgerStore, scheduler/ledger_store.py:56), но ни одна запись расписания его не зовёт — механизм построен и не включён. Включение объявлено отложенным: контракты P3-B и P3-C имеют статус DEPLOYED / DARK / NOT ACTIVATED (строки 3 обоих; P3-B, P3-C; подробно в СЛУЖЕБНОЕ).

Как это устроено​

Расписание порождается из реестра и выкладывается целиком: блок «Сбор». Точный состав по хостам и временам — в порождаемом расписании.