Планувальник і фонові завдання

(Розділ: Операції та Управління)

1) Призначення

Планувальник і фонові завдання забезпечують позакористувацьку роботу платформи: періодичні розрахунки, публікації артефактів, кліринг і реплеї черг. Цілі - детермінованість, стійкість до збоїв і аудитопридатність.

2) Таксономія завдань

Time-based: за розкладом (cron/календар): кліринг, закриття вікон RTP, вивантаження, архівації.
Event-driven: тригери з шини (PaymentsSettled, PriceListUpdated).
One-off/Ad-hoc: разові джоби з TTL.
Long-running: бекоф/саги, стрімінгові компакшени.
Maintenance: ротації ключів, репекідж, індекси, прогрів кешу.

3) Архітектура (референс)

1. Scheduler (control-plane): зберігає розклади, CAL/cron, вікна обслуговування, таймзони, обмежувачі.

2. Dispatcher: план → черга (per-priority/tenant/region), проставляє дедлайни, ідемпотентні ключі.

3. Workers: статичні/автоскейл під пули завдань; heartbeats, leases.

4. Queue/Bus: FIFO/пріоретизація, DLQ, відкладені повідомлення.

5. Locker/Coordination: розподілені блокування (leases), лідер-елекція (Raft/ZK/Consul).

6. Vault/KMS: JIT-секрети, короткі TTL.

7. Observability: traces/metrics/logs, дашборди, алерти.

8. Audit/WORM: незмінювані квитанції виконання, Merkle-зрізи.

Патерни: outbox/CDC, idempotency, компенсації (саги), backpressure, circuit-breakers.

4) Розклади: cron і календарі

Cron v3: секунда/хвилина/година/день/місяць/день-тижні; підтримка «/5 », діапазонів, списків.
Календарі/винятки: бізнес-календар, «вікна тиші», свята/DST.
Таймзони: зберігайте «tz» на задачі; запуск за локальним часом тенанта.
Мультирегіон: копії розкладів per-region або «провідний регіон + фоловери» з дрейном/перевибором.

5) Черги, пріоритети, SLA

Класи пріоритету: P0 (критично), P1, P2, P3; окремі пули воркерів.
SLA/дедлайни: `must_start_by`, `must_finish_by`; пропуск - ескалація/ретрай.
Квоти та fairness: caps на задач/хв/тенант, токени на «бурсти», ізоляція noisy-neighbors.
Відкладені завдання: «не раніше ніж» (delay/visibility timeout).

6) Конкурентність і блокування

Leases: оренда роботи з авто-продовженням (heartbeat); по тайм-ауту - перевидання.
Mutex/семафори: per-ресурс (наприклад, «прайс-лист х пише тільки один воркер»).
Шардування: по `tenant/region/hash(key)`; sticky-routing для кеш і локальності даних.
Лідер-елекція: один лідер публікує «системні» джоби (наприклад, «закрити всі RTP вікна»), фоловери - гарячий standby.

7) Надійність: ретраї, ідемпотентність, дедуп

Ідемпотентний ключ: `(task_type, business_id, window)`; повтори → та ж квитанція.
Ретраї: експоненціальний бек-офф + джиттер, ліміт спроб, стратегія on-error (retry/cancel/compensate).
Poison-pill: швидкий переклад в DLQ після N збоїв, алерт власнику.
Dedup: seen-cache (in-memory + KV) на TTL вікна.
Exactly-once ефекти: підтвердження побічних ефектів через транзакційний журнал/квитанції.

8) Управління тривалими і важкими завданнями

Chunking: розбивка на батчі, чекпоінти/продовження.
Time-boxing: обмеження CPU/IO/мережевого egress; переривання зі збереженням прогресу.
Саги/компенсації: семантика «undo» для міжсервісних кроків.
Concurrency-caps: ліміти одночасних завдань на тип/тенант/регіон.

9) Спостережуваність і метрики

Traces: 'trace _ id', кроки саги, зовнішні виклики.

• Lag до старту, черга (довжина, вік p95).
• Success Rate, error-rate, retry-rate.
• Latency p50/p95, time-to-complete.
• Cost per 1k завдань, egress/ingress.
• DLQ rate, poison-pill rate.

• P0 старт ≤ 60 с, P1 ≤ 5 хв; Success ≥ 99. 5%; DLQ ≤ 0. 1%; Freshness (опершина) ≤ 30 з p95.

10) Аудит і доказовість

Квитанції: 'receipt _ hash'на старт/успіх/помилку, DSSE-підписи для критичних типів (платежі, прайс-листи, RTP).
WORM: зберігання логів виконання і маніфестів завдань.
Chain-of-custody: хто поставив/схвалив/змінив розклад; SoD-перевірки.

11) Безпека та доступи

RBAC/ABAC/ReBAC: хто створює/схвалює/запускає; SoD: «створити виплату» ≠ «затвердити».
JIT-секрети: воркер запитує токени з коротким TTL по скоупу завдання.
Ізоляція: пули воркерів per-tenant/region/сітка; sandbox-виконання.
PII-гігієна: маскування/токенізація, заборона логування первинки.

12) FinOps і вартість

Бюджети/кап-алерти на compute/storage/egress.
Автоскейл воркерів по чергах і SLO.
Класи зберігання: гаряче (7-30 днів) → OLAP (6-24 міс) → архів.
Cost-aware планування: вікно запуску в «дешеві години», ліміти на egress.

13) Модель даних (спрощено)

14) API контракти (управління/інтеграція)

'POST/schedules'- створити розклад (cron/cal, tz, вікна).
'POST/jobs'- поставити ad-hoc; повернути'job _ id','receipt _ hash'.
'GET/jobs/{ id}'- статус/лог/квитанції.
'POST/jobs/{ id }/cancel'- скасування з компенсацією.
'GET/queues/stats'- довжини, лаги, p95.
Вебхуки: `JobStarted`, `JobSucceeded`, `JobFailed`, `JobDroppedToDLQ`, `SLOViolated`.

15) Плейбуки (типові сценарії)

Retry-storm: включити глобальний бек-офф, підняти таймаути залежностей, включити circuit-breaker, дроблення батчів.
DLQ-лавина: зупинити прийом, приоритизувати розбір DLQ, буферизувати нові завдання.
Лідер впав: перевибор, верифікація «подвійних публікацій» за ідемпотентністю, аудит.
Завис провайдера (PSP/KYC): маршрут на резерв, знизити частоту polling/вебхуків, перевести транзакції в карантин.
Витік секретів воркера: відгук ключів, ротація, пошук «аномальних» запусків за 30 днів, рев'ю прав.

16) Специфіка iGaming/фінтех

Платежі/виплати: асинхронні джоби з квитанціями, карантин «сірих» транзакцій, реплей черг з дедупом.
RTP вікна/ліміти: закриття за календарем, спостережуваний vs теоретичний RTP, авто-пауза промо при дрейфі.
Прайс-листи/FX/Tax: публікації за розкладом, версії артефактів, форс-інвалідація кешу.
Афіліати: звірка конверсій, дедуп вебхуків, акти/підписи, ескроу по спорах.

17) Метрики якості (приклад набору)

Schedule Adherence: частка завдань стартували у вікні ≥ 99%.
Queue Lag p95: P0 ≤ 60 c, P1 ≤ 5 хв.
Success/Retry/DLQ Rate: ≥ 99. 5% / ≤ 0. 4% / ≤ 0. 1%.
Idempotency Errors: ≤ 0. 01%.
Cost/1k jobs і Egress/job - в межах бюджету.
Audit Completeness: 100% критичних завдань з квитанціями.

18) RACI

19) Чек-лист впровадження

• Виділити класи завдань, пріоритети і SLA; визначити календарі і таймзони.
• Розгорнути Scheduler/Dispatcher/Queue/Workers з лідер-елекцією і шардуванням.
• Ввести ідемпотентність, ретраї, DLQ, компенсації (саги).
• Налаштувати RBAC/ABAC/ReBAC, SoD і JIT-секрети для воркерів.
• Включити traces/metrics/logs, дашборди і алерти; SLO и error-budget.
• Підписані квитанції (DSSE) і WORM-журнали для критичних типів.
• Автоскейл і кап-алерти за вартістю (compute/storage/egress).
• Плейбуки: retry-storm, DLQ-лавина, відмова лідера, деградація провайдера.
• Тести: GameDay по кожному плейбуку, ін'єкції затримок/помилок.
• Регулярні рев'ю розкладів, завалів черг і ROI автоматизації.

20) FAQ

Чому cron недостатньо?
Без черг, ідемпотентності, блокувань і аудиту cron ламається на збоях і часових поясах.

Чи можна об'єднувати time-based і event-driven?
Так: cron - страховка для catch-up; події - для реактивності.

Як домогтися «рівно-одного разу»?
Дедуп за ключем, транзакційний журнал ефектів, квитанції та ідемпотентні побічні дії.

Що робити з «довгими» джобами?
Чанк, чекпоінти, time-boxing, можливість перервати і продовжити.

Як не «з'їсти» бюджет?
Автоскейл по чергах і SLO, дешеві годинники для важких джоб, жорсткі капи egress/compute.

Резюме: Планувальник і фонові завдання - це виробничий конвеєр платформи. Вбудувавши розклади і черги, ідемпотентність, блокування і спостережуваність, додавши квитанції/аудит, ізоляцію тенантів і FinOps-контроль, ви отримаєте передбачувані терміни виконання, швидкий recovery і юридично витримані операції в будь-яких регіонах і навантаженнях.