GH GambleHub

תוכנית המשכיות עסקית

1) מטרה, היקף ועקרונות

המטרה: להבטיח המשך שירותים קריטיים (הפקדות, הימורים/משחקים, מסקנות, תמיכה ב-KYC/AML) במקרה של כשלים והחזרה מהירה מבלי להפר רישיונות וחוזים.
תחום: פלטפורמה מקוונת, לולאת תשלום, אנטי הונאה/CUS, DWH/BI, תמיכה, תפעול ופונקציות משפטיות, ספקי מפתח (PSP/KYC/Cloud/CDN/Studios/aggregators).
עקרונות: בטיחות קודם כל, שחקן ראשון, תקינות רגולטורית, מיזעור RTO/RPO, מצבי השפלה פשוטים, התמדה ותרגילים רגילים.

2) ניתוח השפעה עסקית

זיהוי תהליכים קריטיים, כניסות/יציאות, תלויות, חלופות ידניות ומטרה של RTO/RPOS.

דוגמה של מקטע BIA (YAML):
yaml process: payouts owner: head_of_payments criticality: tier1 dependencies: [psp1, psp2, bank_api, kyc_service, ledger_db]
rto: "4h"
rpo: "15m"
manual_workaround: "limited manual VIP payments when the PSP is completely unavailable"
max_tolerable_downtime: "8h"
legal_constraints: ["AML/KYC check before payout," "regulatory notification windows"]

3) סיכון * השפעה @ action: inmenu

אלה: התרסקות אזור הענן, כשל בבסיס הנתונים, אובדן אשכול, התקפות DDOS, כשל CDN.
ספקים: PSP/KYC Delegradation, break with game aggregator, חוסר נגישות של אנטי הונאה/סנקציה.
סייבר: פשרת חשבון/מפתח, תוכנת כופר, דליפת מח "ש.
תהליכים/אנשים: שביתות/מחלות, יציאות מומחה מפתח, שגיאת שחרור.
Geo/Force majeure: תקשורת/הפסקות אנרגיה, סיכונים צבאיים/סנקציות, חסימות דומיין/תעבורה.

לכל אחד מהם: טריגרים, סף הסלמה, אמצעי בקרה, השפלת שירות ותבנית תקשורת.

4) ארכיטקטורת קיימות ואסטרטגיות

Active-active/active-standby region; כתשתית לעלייה מהירה.
מצבי הידרדרות: תצוגות קריאה בלבד, ניתוק של ספקי משחקים שאינם קריטיים, הגבלת תשלום, הפקדות בלבד עם קאשאוטים דחויים (אם מותר על פי חוק), אנליטיקה/תדר ETL נמוך יותר.
ניהול תנועה: כל CDN, איזון גיאו, בדיקות בריאות, ניתוב כנרית.
נתונים: גיבויים של PITR, רישומי שינוי, שכפול בין-אזורי, שלמות קריפטוגרפית (חשיש/תולעת).
מפתחות/סודות: KMS עצמאי לכל אזור, ”זכוכית פריצה” עם כריתת עצים.
PSP/KYC רב-ביות: כשל אוטומטי, ניתוב SLA/Latency.

5) מערכת פקודות תקרית

מפקד אירוע (IC) - נקודת החלטה אחת.
Ops Lead (SRE/Platform) - ייצוב טכני, פילובר, מדדים.
עופרת המשכיות עסקית - תיאום תהליכים/הליכים ידניים.
תקשורת עופרת - הודעות חיצוניות/פנימיות (שחקנים, שותפים, רגולטורים).
אבטחה/DPO - תקריות סייבר/פרטיות, חלונות רגולטוריים.
תשלומים/KYC Leads - תרחישי PSP/KYC.
קשרים: משפטי, תמיכה, VIP/CRM, Data/BI.

חוק: 1 איי-סי לכל תקרית, ערוצים ברורים ויומני החלטות.

6) תוכנית תקשורת

ערוצים: חדר מלחמה (צ 'אט/גשר), חיבורי גיבוי (טלפון/רדיו/אלט-שליח), מסומן מראש PSP/KYC/Bank.
תבניות הודעה חיצוניות: דף מצב, רשתות חברתיות, דוא "ל/דחיפה; צליל - עובדות, תזמון, צעדים הבאים.
רגולטורים ושותפים: כתובות מראש, הודעות SLA; ניסוח מוסכם.
שחקנים: ETAs שקופים, פיצויים/בונוסים (אם ישים), FAQs לתקופת ההשפלה.

7) תוכניות מבצעיות (ספרי ריצה)

דוגמאות של קטעים:

7. פיילובר 1 לאזור אחר

yaml trigger: "loss of primary availability> = 5m, p95_latency>threshold"
steps:
- IC approves region_failover
- SRE: flip traffic via GSLB to secondary
- Data: verify replication lag < RPO
- Apps: switch env vars/secrets; warm caches
- QA: smoke tests; Business: announce status rollback: "switch-back on 60m stability"

7. 2 פירוק PSP

yaml trigger: "auth_rate_psp1 < baseline-3σ 15m"
steps:
- Payments: route X%→psp2, include limits
- Comms: banner at the checkout, status page
- Finance: reconciliation plan for T + 0
- Legal: notification log and SLA letter

7. 3 ספק KYC לא זמין

yaml trigger: "kyc_sla_breach 30m"
steps:
- Risk: time limits of deposits/rates
- Ops: VIP/High-risk manual check
- Comms: KYC Time Increase Notice
- Vendor: escalation, protection switch

8) התאוששות נתונים (DR)

קטגוריות מערכת: Tier-1 (פלטפורמה/תשלומים/CCM), Tier-2 (משחקים/אנליטיקה), Tier-3 (פנימי).
Process: Seckrety/KMS = BD # kesh = API = front/CDN + integratsii @ analitika.
בדיקות שלמות - בדיקות, אימות רישום/שכפול, פיוס עסקה.

מבחני ד "ר: מדי שנה מלא (מתג-על), חלקי רבעוני; בצע RTOs/RPOs בפועל

9) אנשים, משרדים ולוגיסטיקה

מחשב נייד/מודמים מיותרים, גישה דרך SSO/MFA, גישה ”אדומה” עבור IC.
מקומות חלופיים: משרדי חילוף/מקומות עבודה, רשימות מעבר, תכנית פינוי.
סיבוב של משמרות: מטריצה כשירות, שכפול של תפקידי מפתח, תוכנית החלפה.
ספקי תקשורת/אנרגיה קריטיים: אנשי קשר, SLA, גנרטורים/UPS (אם זה רלוונטי).

10) ספקים ושרשרת אספקה

דרישות BCP/DR בחוזים: RTO/RPO, מבחני חובה, זכויות ביקורת ותרגילים משותפים.
רשום של תת-מעבדים: אנשי קשר, תוכניות להפסקה, אישור למחיקת נתונים/ייצוא בעת העליה למטוס.
ביקורות רבעוניות Tier-1: תקריות, פרוטוקולים DR, מעמד הסמכה, SLAs.

11) אימונים, תרגילים ובדיקות

שולחן פעם ברבע: PSP/KYC/ענן/תרחישי סייבר.
תרגילים טכניים: DR חלקי/מלא; החלפת DDOS/CDN; ספקי SDK ”מתג להרוג”.
תרגילי תקשורת: הודעה לעיתונות/עדכוני סטטוס/מכתבים רגולטוריים.
נקודות מבט: ציר זמן, RCA, CAPA, עדכון ספרי ריצה ו-BIA.

12) מטריצות (KPI/KRI)

RTO/RPO בפועל (על פי Tier-1): לעמוד ביעדים 95%.
MTTD/MTTR: מגמה כלפי מטה; MTTR של תקריות קריטיות סוכל ממוקד.
הצלחת פיילובר: ללא אובדן נתונים/הזמנות/תעריפים, X דקות של הידרדרות.
תרגילי כיסוי: בדיקות DR/year + 2 4.
זמן העדכון הראשון של 15 דקות, תדירות העדכונים בהתאם למדיניות.
עמידות הספק: החלק של Tier-1 עם בדיקות DR מאושרות ב -12 חודשים הוא 100%.

13) RACI (מוגדל)

פעילותICSRE/פלטפורמהאבטחה/DPOתשלומיםסיכון/KYCמוצרתמיכה/CRMחוקי/ציותתקשורת/יחסי ציבורנתונים/BI
הצהרת תקריתA/RRRRRCCCCC
ייצוב טכני/feiloverCA/RCCCCאניאניאניC
ניתוב PSP/KYCCCאניA/RA/RCאניאניאניאני
תקשורתAאניCCCCCCRאני
הודעות רגולטוריותאניאניA/RCCאניאניRאניאני
לאחר המוות/CAPAA/RRRRRRRCCR

14) רשימות בדיקה

14. 1 מוכן לכישלון

[ ] אנשי קשר עכשוויים של ICC/Vendor/Regulator
[ בריאות שכפול ], גיבוי PITR רגיל
[ ] SDK/Webhook מתג להרוג מאומת
[ מנהל תנועה ] (GSLB/CDN) עם בדיקות בריאות מאומתות
[ ] תבניות סטטוס/אות וזכויות הוצאה לאור
[ ] ספרי ריצה ונגישות (SSO/MFA) נסקרו באופן חודשי

14. 2 במהלך האירוע

[ ] IC מוקצה, חדר מלחמה פתוח, יומני החלטה להתחיל
[ סיווג ] (P1/P2), בחירת תרחיש והשפלה
[ ] פעולות טכניות (feilover/limits/inteknections)
[ ] עדכון פומבי ראשון 15 דקות
[ ] SLA הודעות רגולטוריות/שותפות
[ ] לכידת חפצים לאחר המוות

14. 3 לאחר האירוע

[ ] לאחר המוות עם RCA ו CAPA
[ ] מעודכן BIA/סף/שגרה
[ ] אימונים/מבחנים חוזרים, דו "ח לוח
[ ] פיננסית/פיוס

15) תבניות (שברים)

15. כרטיס תסריט 1

yaml scenario: "Region outage: cloud-eu1"
triggers: ["error_rate>5%", "loss of quorum", "cdn health fail"]
degradation: ["disable live-casino", "payments=psp2 only", "payouts=VIP manual"]
rto_target: "30m"
rpo_target: "15m"
contacts: {cloud: "...", isp: "...", regulator: "..."}
comms_templates: ["status_page_v1", "partner_notice_v2"]

15. 2 הודעה לעמוד מצב


[UTC + 02] We are seeing the degradation of payments through PSP # 1. Transactions are automatically routed through an alternative provider. Player funds are safe. The next update is in 15 minutes.

16) ניהול מסמכים וגרסאות

ורסיונינג BCP/Runbooks במאגר, שינוי-רישום, בעל מסמך.
תקופת Revision (רבעון עבור Tier-1), שליטה על זמינות עותקים לא מקוונים.
אחסון מקדחה/חפצי תקרית ומדדי ביצועים.

17) מימוש מפת דרכים (שבועות 6-8)

שבועות 1-2: BIA ותהליכים קריטיים, מטרות RTO/RPO, רשימת תרחישים ובעלים.
שבועות 3-4: ארכיטקטורה של יציבות וצורות השפלה, ספרי הפעלה, תבניות תקשורת, אנשי קשר.
שבועות 5-6: אינטגרציה ספקית (PSP/KYC/Cloud), תרגילי פיילוט (טבלופ + חלקי DR), התאמות.
שבועות 7-8: מבחן DR מלא (במידת האפשר), השקת מחזור תרגילים רבעוני, דו "ח לוח וחבילת רגולציה (במידת הצורך).

18) קטעי ויקי קשורים

רישום סיכונים, תקריות והדלפות, מבחני DR/BCP, TPRM ו-SLA, ISO 27001/27701, SOC 2, PCI DSS, IGA/RBAC/Lest Policy/WORM - ללולולולולולולולאה אחת של RPBMBBBAAAAIAC IcE EsSSS MMS SMSMMS SS SSIcS MSS SSSSm

TL; DR

Active BCP = BIA * RTO/RPO # stsenarii and degradatsii _ multi-value-region + clear Incident Command, תקשורת ותרגילים. לשמור את המסמך בחיים, לבדוק באופן קבוע - ואפילו התרסקות גדולה לא תעצור את העסק או רישיונות פגיעה.

Contact

צרו קשר

פנו אלינו בכל שאלה או צורך בתמיכה.אנחנו תמיד כאן כדי לעזור.

Telegram
@Gamble_GC
התחלת אינטגרציה

Email הוא חובה. Telegram או WhatsApp — אופציונליים.

השם שלכם לא חובה
Email לא חובה
נושא לא חובה
הודעה לא חובה
Telegram לא חובה
@
אם תציינו Telegram — נענה גם שם, בנוסף ל-Email.
WhatsApp לא חובה
פורמט: קידומת מדינה ומספר (לדוגמה, +972XXXXXXXXX).

בלחיצה על הכפתור אתם מסכימים לעיבוד הנתונים שלכם.