تعامل تیم ها در عملیات

1) چرا

پلت فرم iGaming ده ها دامنه (پرداخت، بازی/هسته، خطر/KYC، داده ها، Infra/SRE، پشتیبانی، انطباق) است. بدون قابلیت همکاری رسمی، MTTR، CFR و خطرات عملیاتی افزایش می یابد. هدف این است که توابع متفاوت را به یک سیستم عامل واحد تبدیل کنیم: مخاطبین قابل پیش بینی، صف های شفاف، سیگنال های مشترک و اولویت سازگار.

2) اصول

1. SLO اول: راه حل های مشترک به بودجه SLO/خطا گره خورده است.
2. یک منبع واحد از حقیقت: داشبورد مشترک، وضعیت یکنواخت و مصنوعات.
3. پاک کردن مرزها و رابط ها: هر جفت فرمان دارای یک قرارداد توصیف شده (OLA/Runbook/API) است.
4. دسته های کوچک و برگشت پذیری: تغییرات از طریق phicheflags/قناری، بازگشت سریع.
5. بدون سرزنش - بله داده ها: تجزیه در حقایق، بهبود - یک بخش اجباری از چرخه.
6. حداقل امتیازات مورد نیاز و SoD: جداسازی نقش برای عملیات حساس.
7. روال را خودکار کنید، بقیه را استاندارد کنید.

3) نقش ها و RACI (پایان به پایان)

رئیس Ops/SRE Lead صاحب چارچوب عملیاتی KPI/KRI است. یک نفر

صاحبان خدمات (پرداخت ها/بازی ها/KYC/داده ها) - اهداف دامنه، تغییرات، ریسک. A/R

پلت فرم/Infra - دسترسی، عملکرد، انتشار/قناری. تحقیق و توسعه

ریسک/انطباق/امنیت - SoD، RG/KYC/PII، ممیزی. C/A

پشتیبانی/CRM - جلوی شکایات، ارتباط با بازیکنان. تحقیق و توسعه

در تماس با IC/CL - مدیریت حوادث و به روز رسانی های خارجی. تحقیق و توسعه

مدیر انتشار - تقویم، CAB، وضعیت تغییرات. تحقیق و توسعه

داده ها/تجزیه و تحلیل - معیارهای محصول و عملیاتی، پشتیبانی RCA. تحقیق و توسعه

4) قراردادهای تعامل (OLA/SLx)

• مناطق مسئولیت: که منطقه (به عنوان مثال، مسیریابی PSP - پرداخت ؛ کش/DB - مادون قرمز).
• معیارهای اهداف/آستانه: MTTA حادثه، زمان پاسخ تشدید، پنجره پس از نظارت.
• صف ها و اولویت ها: P1-P4، بحرانی بودن کسب و کار، پنجره های یخ زده.
• رابط ها: کانال ها، دستورات ربات، API/Runbook، دایرکتوری های مالک.
• مصنوعات: چه اسناد/سیاهههای مربوط/داشبورد مورد نیاز برای همراهی با این رویداد است.

5) کانال های ارتباطی و پروتکل ها

چت عملیاتی (تغییر): به روز رسانی روزانه، مینی مراسم، تحویل.
اتاق های Var برای حوادث: ایجاد شده توسط یک ربات ؛ نقش های IC/CL توسط فرمان تعیین می شوند.
کانال CAB/Change: بحث در مورد تغییرات، خطرات، تقویم انتشار.

فقط خواندنی SLO/حادثه/خلاصه فعالیت برنامه ریزی شده

تشدید: الگوهای فرمان «/صفحه »، «/تشدید»، گزارش SLA.

Unified message protocol: «fact → impact → ETA/ETR → next update window → owner».

6) تحویل بین شیفت ها و مناطق

1. SLO/SLI: جایی که خطر فرسودگی بودجه وجود دارد.

2. حوادث/تشدید و ETA های آنها را باز کنید.

3. آثار برنامه ریزی شده/منتشر شده در 24-48 ساعت آینده.

4. ارائه دهندگان (PSP/KYC/استودیوها): بلیط های فعال، انتظارات.

5. ترکیب و مخاطبین در تماس (IC/CL/domains).

6. «Watchlist» - مناطق افزایش توجه (صف/تکرار/کش).

تحویل در یک ورود به سیستم تغییر، لینک ها - به var-rooms و داشبورد ثبت شده است.

7) همکاری حادثه

شروع: هشدار → ربات یک کارت ایجاد می کند «# inc-YYY-MM-DD-XXX»، اختصاص IC/CL و دامنه منجر می شود.
قانون یک رای: IC تصمیم نهایی است ؛ سی ال - ارتباطات.
حقایق و فرضیه ها: ما جدا می شویم ؛ سیگنال های «قرمز» - اولویت.
Guardrails: مسیریابی phicheflags/PSP تنها از طریق runbook با SoD/کنترل دوگانه تغییر می کند.
ارتباطات: پیش نویس به روز رسانی عمومی از طریق CL، شرکای - هدف قرار.
بسته شدن: نظارت پس از مرگ، تولید پس از مرگ و وظایف بهبود با صاحبان/مهلت.

8) همکاری در تغییرات

تقویم انتشار: عمومی، با دوره های انجماد و اسلات های تماس.
دروازه های کیفیت: واحد/قرارداد/e2e، امنیت، دروازه SLO مرحله بندی.
قناری نورد: گام به گام 5٪ → 25٪ → 100٪ برای GEO/مستاجران/بانک ها.
بازگشت خودکار: سیاست های کلید SLI/KRI، مجله WORM.
بسته های Comm: پیش نویس به روز رسانی در پیش با CL/حقوقی توافق.
تغییرات RACI: RM (A/R), SO (A/R), SRE (R), ثانیه/انطباق (C/A), CAB (A), IC/CL (R/C).

9) تله متری یکپارچه و مصنوعات

دایرکتوری معیارهای مشترک: SLI/SLO، معیارهای کسب و کار، KRI (صف، PSP، تکرار).
داشبورد «نقشه عملیات»: خلاصه بر اساس دامنه ها، مناطق، وضعیت حوادث/آثار.
Timelines: فرمت یکنواخت (زمان، نویسنده، عمل، نتیجه، لینک ها).
پس از مرگ: قالب بدون اتهام، اقدامات پیشگیری، تاریخ تجدید نظر.
کتابهای اجرا/چک لیست: نسخه ؛ لینک از هشدارها و کارت های حادثه.

10) اولویت بندی و برنامه ریزی

برنامه هفتگی Ops (30-45 دقیقه): هماهنگی خطرات بالا، انتشار، محدودیت ها، بهبود پس از مرگ.
Kanban عملیات: ستونهای «Backlog → Ready → In Progress → Validate Done»، محدودیتهای WIP.
معیارهای اولویت: تاثیر بر SLO/درآمد/انطباق، اندازه/برگشت پذیری، وابستگی به ارائه دهندگان.

11) ماتریس تشدید (فشار)

12) سیاست ها و SoDs

SoD/4-eyes: نتیجه گیری/پاداش/مسیریابی PSP/صادرات PII - فقط با تایید دو برابر.
حقوق JIT: افزایش موقت امتیازات برای اقدامات runbook.

سیاست های داده: ممنوعیت PII در کانال های باز/داشبورد ؛ مرزهای جغرافیایی

حسابرسی - گزارش فعالیت های غیر قابل تغییر (WORMs)، تجدید نظر در سیاست.

13) ابزار تعامل

ربات حادثه: «/incident new »، نقش ها، تایمر به روز رسانی، پیش نویس های comm، «/runbook»، «/flag »، «/config».
معیارهای API: نمایش SLO مشترک و KRI، نمونه (trace_id) برای RCA.
انتشار پورتال: مانیفست ها، دروازه ها، وضعیت نورد/رول بک.
دایرکتوری صاحبان/CMDB: دامنه ها، مخاطبین، کانال های پشتیبان.

14) معیارهای همکاری (KPI/KRI)

MTTA/MTTR توسط دامنه و اسلات (روز/شب)، نسبت حوادث گرفتار قبل از شکایت.
کیفیت تحویل: نقص انتقال (موارد چک لیست در زمان بسته نیست).
تغییر همکاری:٪ از نسخه های با بسته های COMM آماده و بدون rollback.
رشته Guardrail: فرکانس نقض SoD/سیاست (هدف 0).
Comms Cadence: پایبندی به فواصل به روز رسانی عمومی هنگام P1/P2.
SLA پس از مرگ: نسبت مرگ و میر ≤ D + 5، تکمیل اقدامات.
Fair-share Load: توزیع شب ها/پیک ها توسط افراد/تیم ها.
سرب سیگنال مشتری: تاخیر بین تخریب هدف و شکایت اول.

15) نقشه راه پیاده سازی (6-10 هفته)

«ند». 1-2: موجودی دامنه/مالک ؛ قالب های OLA ؛ راه اندازی کانال جایگزین و چک لیست تحویل ؛ ماتریس تشدید پایه.
«ند». 3-4: ربات حادثه (MVP)، کانال وضعیت مشترک، کارت SLO/SLI/KRI تک ؛ دایرکتوری runbooks.

«ند». 5-6: تقویم CAB/انتشار، بسته های comm و پنجره های یخ زده ؛ SoD/4-eyes برای عملیات حساس

«ند». 7-8: نورد قناری و چرخش خودکار به عنوان استاندارد ؛ قالب پس از مرگ، همکاری Exec/Ops-dashboards.
«ند». 9-10: تمرینات P1، تحویل های بین منطقه ای، ممیزی WORM، گزارش های KPI/KRI، تنظیمات OLA.

16) قالب (قطعات)

16. 1 OLA (پرداخت ↔ Infra/SRE)

yaml ola:
scope: "Payments-Auth & Routing"
contacts:
payments_so: "@pay-so"
infra_oncall: "@sre-oncall"
objectives:
mtta_p1: "≤5m"
rollback_ttr: "≤10m canary"
interfaces:
runbooks: ["psp-failover", "reroute", "auth-throttle"]
dashboards: ["auth_success", "psp_latency", "queue_lag"]
escalation:
p1: ["IC","Payments Lead","SRE L2"]
p2: ["Payments OnCall","SRE OnCall"]
artifacts:
status_templates: ["public","partners"]
postmortem_due: "D+5"

16. 2 چک لیست تحویل (10 مورد)

1. وضعیت دامنه SLO

2. حوادث باز (ETA/صاحبان)

3. فعالیت های برنامه ریزی شده/انتشار + پنجره های مشاهده

4. ارائه دهندگان (PSP/KYC/Studios) - خطرات/انتظارات

5. صف/تکرار/کش - تاخیر/ناهنجاری

6. تغییرات محدود/فیچفلگ

7. شکایات/بلیط و آستانه بار

8. طرح های کاما و پیش نویس وضعیت

9. ترکیب و رزرو در تماس

10. «لیست تماشا» در هر اسلات

17) ضد گلوله

«کسی معامله خواهد کرد ؟» بدون RACI و مالک.
حوادث بدون IC/CL و تایمر به روز رسانی.
تغییرات پنهان (کلیک دستی)، بدون Git/Audit.
تله متری غیر معمول: اعداد مختلف در تیم های مختلف.
انتشار بدون بسته COMM و قناری.
نقض SoD «به خاطر سرعت».
تحویل به صورت خوراکی، بدون سوابق و چک لیست.
پس از مرگ بدون اقدامات و مهلت.

مجموع

تعامل تیم ها در عملیات یک همکاری قراردادی است: OLA/SLx، کانال ها و نقش های روشن، نظم و انضباط انتقال، تله متری عمومی، انتشار هماهنگ و فرآیندهای حادثه. چنین چارچوبی MTTR و CFR را کاهش می دهد، اولویت ها را هماهنگ می کند، SLO، درآمد و انطباق را محافظت می کند و عملیات روزانه را قابل پیش بینی و پایدار می کند.