عملیات و → مدیریت گردش کار خودکار

گردش کار خودکار

1) چرا شما به آن نیاز دارید

گردش کار خودکار باعث کاهش عملیات دستی، سرعت بخشیدن به «زمان ایده به پول» و کاهش خطر اشتباهات می شود. در iGaming/fintech، برای سپرده ها/برداشت ها، KYC/AML، مدیریت پاداش/جکپات، به روز رسانی محتوا، واکنش های حادثه و وظایف پشت صحنه بسیار مهم است.

• قوی، فرآیندهای شفاف مشاهده از ماشه به نتیجه.
• حداقل مراحل دستی قابل پیش بینی توسط SLO فرآیند.
• کنترل خطا: بازپرداخت، اقدامات جبرانی، افزایش واضح.
• مقیاس بندی توسط حوادث و بار بدون طوفان و تکراری.

2) اصطلاحات عمومی

گردش کار (WF): زنجیره ای از مراحل (وظایف) برای دستیابی به یک نتیجه کسب و کار.
ارکستراسیون: هماهنگ کننده مرکزی مراحل و سفارش خود را مدیریت می کند.
رقص: مراحل واکنش به حوادث، هیچ «مغز مرکزی» وجود دارد.
جبران خسارت: اقدامات معکوس در شکست جزئی (sagas).
HITL (انسان در حلقه): راه حل های «دستی» کنترل شده در WF.
SLO فرآیند: زمان هدف تکمیل/موفقیت یک WF خاص (به عنوان مثال، «95٪ از سپرده ≤ 3 ثانیه»).

3) کجا استفاده شود (مثال ها)

جریان پرداخت: سپرده، ضد تقلب، ارسال در حسابداری، اطلاعیه ها.
KYC/AML: جمع آوری اسناد، بررسی توسط ارائه دهندگان، تشدید به انطباق.
مدیریت محتوا/محدودیت: انتشار بازی ها، سهمیه ها، قوانین جغرافیایی.
پاداش/جکپات: اقلام تعهدی، کسر، محاسبه شرایط، پرداخت.
حوادث: تشخیص خودکار، چک لیست های مختصر، ارتباطات.
داده/ETL: گزارش ارسال، آشتی، بایگانی.

4) ارکستراسیون در مقابل رقص

ارکستراسیون زمانی مناسب است که: منطق شاخه پیچیده، SLO های دقیق، مهلت ها/زمان بندی های صریح، یک «نقشه فرایند» بصری توسط کسب و کار مورد نیاز است.
رقص - زمانی که: رویداد بالا، اتصال ضعیف، بسیاری از مصرف کنندگان مستقل از یک رویداد.

ترکیبی: ساگا های طولانی مدت توسط یک ارکستر کنترل می شوند و واکنش های محلی از طریق رویدادها انجام می شود.

5) اصول معماری

Idempotency: هر مرحله باید با خیال راحت تکرار شود (idempotency-key، dedup توسط شناسه پیام).
زمان های صریح و عقب نشینی: عقب نشینی + jitter، محدودیت ها را امتحان کنید، فقط برای اشتباهات ایمن عقب نشینی کنید.
جبران (sagas): بازگشت زنجیره ای در شکست جزئی.
جداسازی مراحل: bulkhead (استخرهای فردی/محدودیت در downstreams خارجی).
قراردادها: OpenAPI/AsyncAPI برای همه تماس های خارجی، تست های CDC.
نسخه بندی WF: تغییر شمای داده های ورودی/خروجی بدون قطره های «جرم» نمونه های قدیمی.

6) رویداد و مدل ماشه

• رویداد دامنه ("سپرده. درخواست شده)،
• برنامه (cron),
• شروع دستی (اپراتور/پشتیبانی)،
• سیگنال از هشدار (حادثه خودکار گردش کار).
• Context: correlation 'trace _ id', 'workflow _ instance _ id', user/region, phicheflag version.
• فیلترهای ورودی ارزان: اعتبار سنجی اولیه و قطع برداشت.

7) طراحی مرحله (وظایف)

هر مرحله شرح داده شده است: ورود، خروج، SLO، timeout، تلاش، شرایط retray، جبران خسارت، حقوق/اسرار.

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) جبران خسارت و ساگا

معامله محلی + رویداد «ذخیره قصد → انتشار رویداد».
جبران خسارت: لغو مجوز، بازگشت پاداش، محاسبه تعادل، بسته شدن بلیط.
idemotence جبران خسارت: لغو تکرار باید invariants شکستن نیست.

9) امنیت و اسرار

KMS/Secrets Manager: ذخیره سازی توکن، چرخش، دسترسی به نقش.
حداقل امتیازات: موتور WF دقیقا محدوده مناسب داده می شود.
Webhook/Kolbek signature: HMAC/JWS، بررسی برچسب زمان.
سیاست های داده: PII ماسک در سیاهههای مربوط/آثار، رمزگذاری.

10) قابلیت مشاهده و SLO

معیارهای فرآیند: «workflow _ started/completed», «success _ rate», «aborted», «mean/p95/p99 duration», hanging instances, «dead letter».
معیارهای مرحله: «task _ latency»، «error _ rate»، «retry _ count»، «open _ circuit»، «cost _ per _ 1k _ calls».
ردیابی: طول برای هر مرحله، گردش کار برچسب ها. نام "،" گام "،" تلاش ".

SLO: "95٪ از سپرده ها ≤ 3 ثانیه، 99٪ ≤ 5 ثانیه ؛ سقط جنین ≤ 0 3 درصد در روز "

داشبورد: نقشه گام حرارتی، تنگناها، نقشه های وابستگی.

11) انسان در مدار (HITL)

معیارها: موارد بحث برانگیز (ریسک/AML)، تأیید دستی پرداخت های بزرگ.
مهلت: زمان انتظار برای تصمیم گیری، یادآوری/تشدید.
حسابرسی: چه کسی/چه زمانی/چه تصمیمی، توجیه، بسته نرم افزاری با یک بلیط.

12) تغییر مدیریت و انتشار

نسخه های گردش کار: 'v1' و 'v2' به صورت موازی ؛ مهاجرت نمونه امکان پذیر نیست - خاتمه دادن موارد قدیمی به طور طبیعی، ترافیک جدید به 'v2'.
ترافیک قناری: 1٪ → 10٪ → 100٪، مقایسه معیارهای 'success/p95/abort'.
Ficheflags: بازگشت سریع به مرحله قبلی/اجرای شاخه.
CDC/قرارداد: دروازه در CI برای حفظ تغییرات گام از شکستن مصرف کنندگان/ارائه دهندگان.

13) تست

مراحل واحد: مثبت/منفی + idemotency.
تست های قرارداد: در برابر ارائه دهنده moka/stage.
شبیه سازی WF: happy-path + timeouts، 4xx/5xx، «ارائه دهنده آهسته»، از دست دادن رویدادها، خطاهای جزئی.
روزهای بازی: تزریق اشکالات (افت PSP/KYC، تاخیر صف، قطع کننده بسته).
Replay: رویدادهای تاریخی را برای تأیید مهاجرت پخش کنید.

14) حوادث و واکنش های خودکار

گردش کار خودکار حادثه: جمع آوری معیارها، بررسی downstreams، اعلان ها، آماده سازی راه حل (ارائه دهنده سوئیچینگ، تخریب).
مراحل Runbook: چگونه «untangle» موارد آویزان زمانی که سقط دستی/نیروی کامل مجاز است.

15) مدیریت هزینه

سهمیه ها و «کلاه نرم»: محدودیت در مراحل گران قیمت/ارائه دهندگان.
Cache/dedup: تماس های خارجی را به صورت غیر ضروری تکرار نکنید.
گزارش ها: 'cost _ per _ 1k _ workflows', 'cost of success' by WF type.

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) سیاست های Retray و timeout (توصیه ها)

Step timeout = 70-80٪ از بودجه تأخیر آن.
Retrai ≤ 2-3، فقط برای عملیات idempotent و شکست شبکه.
Jitter اجباری است. بان از زمانبندی تنگنا بدون follbeck عقب نشینی می کند.
جبران خسارت - به عنوان مراحل جداگانه، همچنین idempotent.

18) داشبورد (حداقل)

بررسی اجمالی WF: راه اندازی/موفقیت/سقط جنین، مدت زمان p95/p99، آویزان/پدربزرگ.
Drilldown Step: مراحل آهسته/اشتباه بالا، عقب نشینی، قطع کننده های باز.
پنل ارائه دهنده: خروجی p95/خطا نرخ/سهمیه/هزینه.
هیئت مدیره HITL: «تصمیم در انتظار»، جدول زمانی، SLA های انطباق.

19) چک لیست پیاده سازی

• نقشه کلید WF و صاحبان (در تماس، چت، repo).
• شرح مراحل: داخل/خارج، SLO، زمان بندی، بازپرداخت، جبران، اسرار.
• قراردادهای OpenAPI/AsyncAPI + CDC.
• idempotence/مرده در ورودی و در مراحل.
• داشبورد، ردیابی، هشدار (روند و مراحل SLO).
• Canary + phicheflags برای انتشار WF.
• Runbook: چگونه به «درمان» آویزان/نیمه اعدام WFs.
• طرح تخریب: ارائه دهندگان جایگزین، خاموش کردن شاخه های «سنگین».
• سیاست های مخفی/دسترسی/حسابرسی.
• بازی روز/سناریوهای 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 + مرحله و اتصال سفت و سخت - می شکند دشوار و پر سر و صدا.
Retrays برای معاملات غیر idempotent (دو برابر اتهامات/اتهامات).
Timeouts «طولانی تر از زندگی» از درخواست کاربر → جلادان و «زامبی».
عدم جبران → رفع دستی و طولانی پس از مرگ.
بدون نسخهبندی WF → نمونههای قدیمی را آزاد میکند.
اسرار داخل تنظیمات/متغیرها بدون چرخش و ممیزی.

22) KPI کیفیت گردش کار

میزان موفقیت و میزان لغو توسط نوع WF.
p95/p99 مدت زمان مراحل و فرآیند.
MTTD/MTTR در حوادث فرآیند.
تعداد طوفان مجدد/ماه (هدف → 0).
هزینه هر 1k WF و «هزینه موفقیت».
سهم اتوماسیون:٪ موارد بدون HITL.

23) شروع سریع (پیش فرض)

ساگا های طولانی مدت را هماهنگ کنید واکنش های محلی - حوادث

با 3-5 WF بحرانی (سپرده، برداشت، KYC) شروع کنید.
وقفه مرحله ≤ 80٪ از بودجه ؛ retrai ≤ 2 با عقب نشینی + jitter.
پاداش ها به صورت کتبی و تست شده تعیین می شوند.
قناری را برای 5-10٪ ترافیک با داشبورد مقایسه کنید.
هر WF دارای یک مالک، یک runbook و هشدارهای SLO است.

24) سوالات متداول

س: چه چیزی را انتخاب کنید: ارکستر یا رویدادها ؟

A: اگر شما نیاز به یک نقشه بصری، مهلت و sagas طولانی یک ارکستر است. اگر واکنش های ساده به حوادث و بسیاری از مصرف کنندگان غالب، طراحی رقص. اغلب بهترین گزینه ترکیبی است.

س: چگونه از تکراری جلوگیری می کنید ؟

A: Idempotency-key در ورودی WF، dedup توسط 'message _ id' و ذخیره سازی «رویدادهای دیده شده». "قدمها یکنواخت هستند.

س: آیا به یک مرد در مدار نیاز دارد ؟

A: بله، برای موارد بحث برانگیز/گران قیمت. اما اندازه گیری و کاهش سهم HITL از طریق اتوماسیون و قوانین بهتر.