Операції та Управління → Автоматизовані воркфлоу

Автоматизовані воркфлоу

1) Навіщо це потрібно

Автоматизовані воркфлоу зменшують ручні операції, прискорюють «час від ідеї до грошей» і знижують ризик помилок. У iGaming/фінтехе це критично для депозитів/висновків, KYC/AML, управління бонусами/джекпотами, оновлення контенту, інцидент-реакції і бек-офісних завдань.

• Стійкі, прозоро спостережувані процеси від тригера до результату.
• Мінімум ручних кроків, передбачувані SLO процесу.
• Контроль помилок: ретраї, компенсуючі дії, чіткі ескалації.
• Масштабування по подіям і навантаженню без «штормів» і дублікатів.

2) Базова термінологія

Воркфлоу (WF): ланцюжок кроків (tasks) для досягнення бізнес-результату.
Оркестрація: центральний координатор керує кроками та їх порядком.
Хореографія: кроки реагують на події, немає «центрального мозку».
Компенсація: зворотні дії при частковій невдачі (саги).
HITL (Human-in-the-loop): контрольовані «ручні» рішення всередині WF.
SLO процесу: цільовий час завершення/успіху конкретного WF (наприклад, «95% депозитів ≤ 3 сек»).

3) Де застосовувати (приклади)

Платіжні флоу: депозити, антифрод, постинг в бухоблік, повідомлення.
KYC/AML: збір документів, перевірки провайдерами, ескалація в комплаєнс.
Управління контентом/лімітами: публікація ігор, квоти, гео-правила.
Бонуси/джекпоти: нарахування, утримання, розрахунок умов, виплати.
Інциденти: авто-діагностика, скорочені чек-листи, комунікації.
Дані/ETL: вивантаження звітів, reconciliation, архівація.

4) Оркестрація vs Хореографія

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

Гібрид: довгоживучі саги керує оркестратор, а локальні реакції виконуються через події.

5) Архітектурні принципи

Ідемпотентність: кожен крок повинен безпечно повторюватися (idempotency-key, дедуп по message-ID).
Явні таймаути і ретраї: backoff + джиттер, ліміти спроб, ретраї тільки для безпечних помилок.
Компенсації (саги): відкати по ланцюжку при частковій невдачі.
Ізоляція кроків: bulkhead (окремі пули/ліміти на зовнішні даунстрими).
Контракти: OpenAPI/AsyncAPI для всіх зовнішніх викликів, CDC-тести.
Версіонування WF: зміна схеми вхідних/вихідних даних без «масових» падінь старих інстансів.

6) Модель подій і тригерів

• подія домену ('deposit. requested`),
• розклад (cron),
• ручний запуск (оператор/саппорт),
• сигнал з алерта (інцидент-авто-воркфлоу).
• Контекст: кореляційний'trace _ id','workflow _ instance _ id', користувач/регіон, версія фічефлагів.
• Дешеві фільтри на вході: рання валідація і відсікання дублів.

7) Дизайн кроків (tasks)

Кожен крок описується: вхід, вихід, SLO, таймаут, спроби, умови ретраїв, компенсація, права/секрети.

task: call_psp input: { user_id, amount, currency, idempotency_key }
timeout: 200ms retries:
max: 2 on: [5xx, connect_error]
backoff: exponential jitter: true compensation: reverse_authorization secrets: [PSP_TOKEN]
sla: p99 <= 300ms

8) Компенсації та саги

Локальна транзакція + подія: «зберегти intent → опублікувати подію».
Компенсація: скасування авторизації, повернення бонусу, перерахунок балансу, закриття тікету.
Ідемпотентність компенсацій: повторне скасування не повинно ламати інваріанти.

9) Безпека і секрети

KMS/Secrets Manager: зберігання токенів, ротація, доступ за ролями.
Найменші привілеї: WF-рушію видаються рівно потрібні скоупи.
Підпис вебхуків/колбеків: HMAC/JWS, перевірка таймстемпа.
Політики даних: маскування PII в логах/трасуваннях, шифрування.

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

Метрики процесу: 'workflow _ started/completed','success _ rate','aborted','mean/p95/p99 duration', «висять» інстанси, «dead letter».
Метрики кроків: `task_latency`, `error_rate`, `retry_count`, `open_circuit`, `cost_per_1k_calls`.
Трасування: спаний на кожен крок, теги'workflow. name`, `step`, `attempt`.
SLO: наприклад, "95% депозитів ≤ 3 сек, 99% ≤ 5 сек; abort ≤ 0. 3 %/добу".
Дашборди: теплова карта кроків, «вузькі місця», карти залежностей.

11) Людина-в-контурі (HITL)

Критерії: спірні кейси (risk/AML), ручне підтвердження великих виплат.
Дедлайни: таймаут очікування рішення, нагадування/ескалації.
Аудит: хто/коли/що вирішив, обґрунтування, зв'язка з тікетом.

12) Управління змінами та релізи

Версії воркфлоу: 'v1'і'v2'паралельно; міграція інстансів неможлива - завершуйте старі природним шляхом, новий трафік - на'v2'.
Канарний трафік: 1% → 10% → 100%, порівняння метрик'success/p95/abort'.
Фічефлагі: швидкий відкат на попередню реалізацію кроку/гілки.
CDC/контракти: гейт в CI, щоб зміни кроків не ламали споживачів/провайдерів.

13) Тестування

Unit кроків: позитив/негатив + ідемпотентність.
Contract tests: проти мока/стейджа провайдера.
WF-симуляції: happy-path + timeouts, 4xx/5xx, «повільний провайдер», втрата подій, часткові помилки.
Game-days: ін'єкція збоїв (падіння PSP/KYC, лаг черг, закритий брейкер).
Replay: відтворення історичних подій для перевірки міграцій.

14) Інциденти та авто-реакції

Авто-воркфлоу інциденту: збір метрик, перевірка даунстрімів, повідомлення, підготовка workaround (перемикання провайдера, деградація).
Runbook-кроки: як «розплутати» завислі інстанси, коли дозволений ручний abort/force-complete.

15) Управління витратами

Квоти і «soft-cap»: ліміти на дорогі кроки/провайдерів.
Кеш/дедуп: не робити повторних зовнішніх викликів без потреби.
Звіти: 'cost _ per _ 1k _ workflows', «вартість успіху» за типами WF.

16) Міні-шаблон воркфлоу (псевдо-YAML)

workflow: deposit_v1 trigger:
event: deposit.requested filters: [amount > 0, currency in [USD,EUR,TRY]]
sla:
p95_ms: 3000 abort_rate_daily: 0.3%
steps:
- name: reserve_funds timeout_ms: 150 retries: {max: 2, on: [5xx, connect_error], backoff: exponential, jitter: true}
compensation: release_reserve
- name: call_psp timeout_ms: 200 retries: {max: 2, on: [5xx, connect_error]}
circuit_breaker: {error_rate: 0.05, window_s: 10, open_s: 30}
- name: post_ledger type: async topic: ledger.post
- name: notify_user channel: push hitl:
when: amount > 10000 or risk_score > 0.8 timeout_m: 30 escalate_to: "compliance@oncall"
observability:
emit_metrics: true trace: true security:
secrets: [PSP_TOKEN, PUSH_API_KEY]

17) Політики ретраїв і таймаутів (рекомендації)

Таймаут кроку = 70-80% від його бюджету латентності.
Ретраї ≤ 2-3, тільки на ідемпотентні операції і мережеві збої.
Джиттер обов'язковий; заборона ретраїв на таймаути вузьких місць без фоллбека.
Компенсації - як окремі кроки, теж ідемпотентні.

18) Дашборди (мінімум)

WF Overview: запуски/успіх/abort, p95/p99 тривалості, виси/діди.
Step Drilldown: топ повільних/помилкових кроків, ретраї, відкриті брейкери.
Provider Panel: вихідні p95/error-rate/квоти/вартість.
HITL Board: «очікують рішення», терміни, SLA комплаєнсу.

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

• Карта ключових WF і власники (on-call, чат, репо).
• Опис кроків: вхід/вихід, SLO, таймаути, ретраї, компенсації, секрети.
• Контракти OpenAPI/AsyncAPI + CDC.
• Ідемпотентність/дедуп на вході і на кроках.
• Дашборди, трасування, алерти (SLO процесу і по кроках).
• Канарка + фічефлаги для релізів WF.
• Runbook: як «лікувати» завислі/частково виконані WF.
• План деградації: альтернативні провайдери, вимкнення «важких» гілок.
• Політики секретів/доступів/аудиту.
• Game-days/xaoc-сценарії раз в спринт.

20) Приклади алертів (ідеї)

ALERT WorkflowSLOBreached
IF workflow_p95_duration_ms{name="deposit_v1"} > 3000 FOR 15m
LABELS {severity="critical", team="payments"}

ALERT WorkflowAbortRateHigh
IF rate(workflow_aborted_total{name="deposit_v1"}[30m]) > 0.005
LABELS {severity="warning", team="payments"}

ALERT StepRetryStorm
IF step_retry_count{name="call_psp"} > 2 baseline_1w FOR 10m
LABELS {severity="warning", team="integrations"}

ALERT StuckInstances
IF workflow_in_progress_age_p95_m{name="kyc_v2"} > 60
LABELS {severity="warning", team="risk"}

21) Анти-патерни

«Великий монолітний WF» зі 100 + кроками і жорсткою зв'язністю - ламається складно і шумить.
Ретраї на неідемпотентні операції (подвійні списання/нарахування).
Таймаути «довші за життя» запиту користувача → вісяки і «зомбі».
Відсутність компенсацій → ручні виправлення і довгі постмортеми.
Немає версіонування WF → релізи ламають старі інстанси.
Секрети всередині конфігів/змінних без ротації та аудиту.

22) KPI якості воркфлоу

Success rate і Abort rate за типами WF.
p95/p99 тривалості кроків і процесу.
MTTD/MTTR щодо інцидентів процесів.
Retry storm count/місяць (цільове → 0).
Вартість на 1k WF і «вартість успіху».
Частка автоматизації: % кейсів без HITL.

23) Швидкий старт (дефолти)

Почніть з 3-5 критичних WF (депозит, виведення, KYC).
Оркеструйте довгоживучі саги; локальні реакції - подіями.
Таймаут кроку ≤ 80% бюджету; ретраї ≤ 2 з backoff + джиттер.
Компенсації визначені письмово і протестовані.
Увімкніть канарку на 5-10% трафіку з дашбордом порівняння.
Кожному WF - власник, runbook і алерти SLO.

24) FAQ

Q: Що вибрати: оркестратор чи події?
A: Якщо потрібна наочна карта, дедлайни і довгі саги - оркестратор. Якщо переважають прості реакції на події і багато споживачів - хореографія. Часто найкращий варіант - гібрид.

Q: Як уникнути дублікатів?
A: Idempotency-key на вході WF, дедуп по'message _ id'і зберігання «seen-events». Кроки ідемпотентні.

Q: Чи потрібна людина-в-контурі?
A: Так, для спірних/дорогих кейсів. Але вимірюйте і знижуйте частку HITL за рахунок кращої автоматизації і правил.