Оркестрація завдань

1) Навіщо оркестрація

• зниження MTTR і «ручної рутини»;
• виконання SLA і регуляторних термінів;
• справедливий розподіл потужностей між тенантами і регіонами;
• прозорість статусів і відповідальності (RACI).

2) Принципи

Orchestrate the critical, choreograph the rest. Критичні ланцюжки (платежі, висновки, сеттл) - під централізованим оркестратором; вторинні - подієво (pub/sub).
SLA-first. У кожного завдання є пріоритет, SLO, дедлайн і стратегія ескалацій.
Ідемпотентність і at-least-once. Будь-яка дія повторюється без побічних ефектів.
Компенсації замість відкату БД. Саги для зовнішніх ефектів.
Fair-share та ізоляція. Квоти per-тенант/регіон/клас завдань, захист від «прожора».
Policy-as-Code. Правила маршрутизації, ретраїв, допусків - версіоновані політики.
Спостережуваність by design. Метрики/трейси/логи на кожному кроці.

3) Модель домену оркестрації

Task (атомарна робота) → Activity (крок процесу) → Process/Workflow (наскрізний ланцюжок).
Стани задачі: `queued → leased → running → (succeeded | failed | timed_out | cancelled) → archived`.
Ключові атрибути: `priority`, `deadline`, `tenant`, `region`, `cost_class`, `risk_class`, `idempotency_key`.

4) Архітектура

Оркестратор: зберігає граф процесів, черги, таймери, дедлайни, RACI, маршрутизацію.
Воркери (executors): статeless, підписані на черзі домену (Payments/KYC/Games/Infra). Lease-модель + heartbeat.
Шлюз подій: outbox/inbox для гарантованої інтеграції із зовнішніми системами.
Сховище стану: журнал процесів (WORM/immutable частини для аудиту).
Каталог політик: пріоритизація, квоти, ретраї, відкати, SoD.

5) Черги, пріоритети та планувальник

• A (Real-time): депозити/ставки/сеттли - p95 затримки секундні, окремі черги і пули.
• B (Operational): KYC, звіти провайдерам - хвилини.
• C (Batch/Analytics): агрегації/експорти - годинник.
• Планувальник: multi-queue с priority + deadline; Алгоритми: priority + EDF, weighted fair-share per-тенант/регіон.
• Work-stealing: виконуючі пули «крадуть» завдання з сусідніх черг всередині того ж класу QoS.
• Дедлайни: при ризику прострочення → підвищення пріоритету або degrade-гілка.

6) Гарантії та стійкість

At-least-once + ідемпотентність.'idempotency _ key'( бізнес-ключ) і фіксація результату.
Retriable by policy: експоненціальний backoff + jitter; бюджет спроб; circuit-breaker на зовнішні залежності.
Timeouts: 'task _ timeout <SLA_step','process _ deadline <регуляторного'.
DLQ: окремі черги для «отруйних» завдань; ручний розбір з повним контекстом.
Компенсації (saga): визначені для кожної «сильної» операції (capture/refund, ledger_post/revert і т.д.).

7) Backpressure і захист платформи

Квоти та ліміти: per-тенант/регіон/тип задачі (QPS, concurrent, memory/CPU).
Admission control: відмова/дефер низькопріоритетного при заповненні пулу.
Shedding: м'яке зниження навантаження (partial results, degrade-фічі) замість тотального фейла.
Rate-limits: на вхід, на провайдера (PSP/KYC), на банк/BIN.
Гістерезис: запобігає флапінг включень/вимкнень.

8) Мульти-регіон і відмовостійкість

Локалізація трафіку: оркестратор тримає процеси ближче до даних/провайдерів.
Крос-регіональний фейловер: тільки для ідемпотентних кроків і після quorum-перевірок.
Сторадж стану: реплікація з RPO/RTO цілями; write-fence проти split-brain.
Регіональна ізоляція інцидентів: «stop the bleed» - зупинка нових завдань в ураженому регіоні, відлив існуючих в безпечні гілки.

9) Human-in-the-loop и RACI

Human-tasks: вбудовані кроки з чек-листом, SLA, вкладеннями.
SoD/4-eyes: несумісні ролі на чутливі дії (висновки, ліміти бонусів, PSP-роутинг).
Ескалації: таймери «nudge → reassign → L2/L3 → IC».
Аудит: хто/що/коли/навіщо, посилання на тікет/політику.

10) Політики як код (Policy-as-Code)

• Маршрутизація PSP: `route = PSP2 if PSP1. health < SLO && tenant in {A,B} && within_quota(PSP2)`
• Підвищення пріоритету: `priority = P1 if deadline < 10m && process in {withdrawal, payout}`
• Блок експортів PII: `deny if export. rate > baselineK &&!ticket && data_class=PII`

Політики версіонуються, тестуються, рев'юляться як звичайний код.

11) Спостережуваність

SLI процесу: частка успішних завершень, p95/p99 тривалість, відсоток прострочень.
SLI черг: вік завдань, throughput, відмова по admission, DLQ-rate.
Трейси: спани на кожному кроці (кореляція'trace _ id'з платежем/ставкою/КУС).
Логи: структуровані, без PII; причини ретраїв/тайм-аутів/компенсацій.
Дашборди: Exec (SLA/прострочення/вартість), Ops (lag/reties/DLQ), Domain (PSP-гілки, KYC SLA).
Алерти: burn-rate дедлайнів, сплеск DLQ, зростання часу кроку, «гарячі» черги.

12) Вартість (FinOps оркестрації)

KPI: $/процес, $/завдання, $/ретрай, $/хв SLA-порушення.
Оптимізації: batch для Class-C, агрегація сигналів, downsampling довгих журналів, ліміти на «довгі» процеси.
Шоу/чардж-бек: тенант бачить свій слід (черги/зберігання/ретраї).

13) Безпека та комплаєнс

ABAC/RBAC: доступ до процесів по ролях/тенанту/регіону/оточенню.
JIT/PAM: тимчасові підвищення для ручних кроків.
Підпис вебхуків/мTLS: цілісність події.
WORM-аудит: непідмінювані журнали; політика TTL/маскування для PII.
SoD: заборона поєднання «initsiirovat→odobrit→provesti» в одній особі.

14) Каталог типових оркестрацій (iGaming)

1. Депозит: `init → 3DS/auth → capture → ledger_post → bonus_credit → notify`.

Компенсації: `ledger_revert, refund_capture`.
Політики: перерозподіл PSP при падінні auth-success.

2. Висновок: `request → risk_score → 4-eyes approve → payout → registry → notify`.

Ескалації по SLA, блок при velocity-аномаліях.

3. KYC/AML: `collect → providerA → (fallback providerB) → manual review → finalize`.

Дедлайни регуляторики; DLQ для помилок сканів.

4. Ставка/сеттл: `reserve → fix_odds → confirm → settle → payout`.

Degrade-гілка при lag черг (обмеження вторинних фіч).

5. Інцидент: `detect → classify (P1–P4) → war-room → actions → close → post-mortem`.

15) Шаблони (фрагменти)

yaml id: payments. capture qos: A priority: P1 deadline: 2m timeout: 2s retry:
strategy: exponential_jitter max_attempts: 5 idempotency_key: ${payment_id}
saga:
compensate: payments. refund_capture

yaml rule: "priority-escalation"
if:  "deadline < 5m && qos == 'A'"
then: "priority = P1"

yaml id: withdrawal. approval type: human sod: true approvers: [Risk, Finance]
sla: 2h on_timeout: escalate:L2

16) Процеси експлуатації

Release-gates: блок небезпечних релізів при червоних SLI черг/процесів.
Tabletop/chaos-дні: відключення PSP/реплік/черг; перевірка ретраїв/компенсацій.
Квартальний review: пороги, квоти, вартість, DLQ-тренди, SoD-винятки.

17) Дорожня карта впровадження (8-12 тижнів)

Нед. 1–2: інвентаризація ланцюжків (депозит/виведення/КУС/сеттл), цілі SLA, класи QoS, матриця пріоритетів і квот.
Нед. 3–4: оркестратор + черги, MVP процесів «Депозит/Висновок», ідемпотентні обробники, DLQ, базові політики ретраїв/тайм-аутів.
Нед. 5–6: саги і компенсації, human-tasks (4-eyes), fair-share per-тенант, дашборди і SLI черг.
Нед. 7–8: мульти-регіон (локалізація/фейловер), release-gates, алерти (burn-rate дедлайнів), FinOps-панель.
Нед. 9–10: розширення каталогу (КУС/бонуси/інциденти), кат. політик (PSP-роутинг/PII-експорт), аудит WORM.
Нед. 11–12: chaos-навчання, оптимізація вартості, регламенти RACI/SoD, навчання он-колла.

18) KPI/KRI оркестрації

SLA процесів (виконання вчасно), p95/p99 тривалість.
Прострочення та їх частка по доменах/тенантах.
Retried/Task ratio, DLQ-rate, Compensation-rate.
Fair-share дотримання (тенант не «голодує»).
Вартість: $/процес, $/завдання, $/ретрай.
Інциденти через оркестрацію (флапінг, дедлоки, перевантаження черг).

19) Антипатерни

Один «універсальний» пріоритет без класів QoS.
Ретраї без ідемпотентності → дублі платежів.
Liveness-рестарти воркерів при зовнішніх збоях → лавина.
Немає квот per-тенант/регіон → сусід «з'їв» весь пул.
Довгі кроки без тайм-аутів/дедлайнів → висячі процеси.
Відсутність саг → ручні «розрулювання» і фінансові ризики.
Порожні журнали/немає трас → не довести коректність.

Підсумок

Оркестрація завдань - це керована фабрика процесів: правильна сегментація за QoS і пріоритетами, гарантії доставки та ідемпотентність, компенсації і дедлайни, справедлива ізоляція тенантів/регіонів, плюс спостережуваність і безпека як частина дизайну. Такий контур забезпечує передбачувані операції, стійкість до збоїв провайдерів і відповідність вимогам регуляторів - без ціною «ручного» мікроменеджменту.