Logo GH

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

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

צרו קשר

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

התחלת אינטגרציה

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

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

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