Операциялар және басқару → Автоматтандырылған воркфлоу

Автоматтандырылған воркфлоу

1) Бұл не үшін қажет

Автоматтандырылған воркфлоу қол операцияларын азайтады, «идеядан ақшаға дейінгі уақытты» жеделдетеді және қателесу қаупін азайтады. iGaming/финтехте бұл депозиттер/қорытындылар, KYC/AML, бонустарды/джекпоттарды басқару, контентті жаңарту, инцидент-реакция және бэк-кеңсе міндеттері үшін өте маңызды.

• Триггерден нәтижеге дейінгі тұрақты, айқын байқалатын процестер.
• Процестің SLO болжайтын ең аз қол қадамдары.
• Қателерді бақылау: ретрациялар, орнын толтыратын әрекеттер, айқын эскалациялар.
• Оқиғалар мен жүктемелер бойынша «дауылсыз» және телнұсқаларсыз масштабтау.

2) Базалық терминология

Workflow (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) Өзгерістерді басқару және релиздер

Workflow нұсқалары: '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

WF түрлері бойынша Success rate және Abort rate.
p95/p99 қадамдар мен процестің ұзақтығы.
Процестер инциденттері бойынша MTTD/MTTR.
Retry storm count/ай (мақсатты → 0).
1k WF құны және «табыс құны».
Автоматтандыру үлесі:% HITL-сіз кейстер.

23) Жылдам бастау (дефолттар)

3-5 сыни WF (депозит, шығыс, KYC) бастап.
Ұзақ өмір сүретін сағаларды оркестрлеңіз; жергілікті реакциялар - оқиғалармен.
Қадам уақыты ≤ бюджеттің 80%; ретраи ≤ 2 с backoff + джиттер.
Өтемақы жазбаша анықталып, сынақтан өткізілді.
Салыстыру дашбордымен трафиктің 5-10% -на канарейка қосыңыз.
Әрбір WF - SLO иесі, runbook және алерты.

24) FAQ

Q: Не таңдау: оркестр немесе оқиғалар?
А: Егер көрнекі карта, ұзын және ұзақ сағаттар қажет болса - оркестратор. Егер оқиғаларға қарапайым реакциялар басым болса және тұтынушылар көп болса - хореография. Көбінесе ең жақсы нұсқа - гибрид.

Q: дубликаттарды қалай болдырмау керек?
A: Idempotency-key WF кіре берісінде, «message _ id» дедупы және «seen-events» сақтау. Қадамдар - іспеттес.

Q: Контурлы адам қажет пе?
А: Иә, даулы/қымбат жағдайлар үшін. Бірақ ең жақсы автоматтандыру және ережелер арқылы HITL үлесін өлшеңіз және азайтыңыз.