Оркестрация задач

1) Зачем оркестрация

• снижение MTTR и “ручной рутины”;
• выполнение SLA и регуляторных сроков;
• справедливое распределение мощностей между тенантами и регионами;
• прозрачность статусов и ответственности (RACI).

2) Принципы

Orchestrate the critical, choreograph the rest. Критичные цепочки (платежи, выводы, сеттл) — под централизованным оркестратором; вторичные — событийнo (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` с платежом/ставкой/KYC).
Логи: структурированные, без 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: запрет совмещения “инициировать→одобрить→провести” в одном лице.

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: инвентаризация цепочек (депозит/вывод/KYC/сеттл), цели 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: расширение каталога (KYC/бонусы/инциденты), кат. политик (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 и приоритетам, гарантии доставки и идемпотентность, компенсации и дедлайны, справедливая изоляция тенантов/регионов, плюс наблюдаемость и безопасность как часть дизайна. Такой контур обеспечивает предсказуемые операции, устойчивость к сбоям провайдеров и соответствие требованиям регуляторов — без ценой “ручного” микроменеджмента.