GH GambleHub

ბიზნესის უწყვეტობის გეგმა

1) მიზანი, სფერო და პრინციპები

მიზანი: უზრუნველყოს კრიტიკული სერვისების გაგრძელება (ანაბრები, განაკვეთები/თამაშები, დასკვნები, KYC/AML, sport) წარუმატებლობის დროს და სწრაფი აღდგენა ლიცენზიების და ხელშეკრულებების დარღვევის გარეშე.
რეგიონი: ონლაინ პლატფორმა, გადახდის წრე, ანტიფროდი/KUS, DWH/BI, საფოსტო, ოპერაციული და იურიდიული ფუნქციები, საკვანძო მოვაჭრეები (PSP/KYC/ღრუბელი/CDN/სტუდიები/აგრეგატორები).
პრინციპები: safety first, მოთამაშე, პირველ რიგში, მარეგულირებელი სისწორე, RTO/RPO მინიმუმამდე შემცირება, მარტივი დეგრადაციის რეჟიმები, დადასტურება და რეგულარული წვრთნები.

2) BIA - ბიზნესის გავლენის ანალიზი

დაადგინეთ კრიტიკული პროცესები, შეყვანა/გასასვლელი, დამოკიდებულება, „სახელმძღვანელო“ ალტერნატივა და მიზნობრივი RTO/RPO.

BIA ფრაგმენტის მაგალითი:
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) სკრიპტები/საფრთხეები (Risk - Impact - Response)

ისინი: ღრუბლის რეგიონის ვარდნა, BD- ის უკმარისობა, კლასტერის დაკარგვა, DDoS შეტევები, CDN- ის უკმარისობა.
გამყიდველები: PSP/KYC დეგრადაცია, თამაშების აგრეგატორთან უფსკრული, ანტიფროდული/სანქციების სკრინინგის მიუწვდომლობა.
კიბერი: ანგარიშების/გასაღებების კომპრომისი, ransomware, გაჟონვა PII.
პროცესები/ხალხი: გაფიცვები/დაავადებები, ძირითადი სპეციალისტების წასვლა, გამოშვების შეცდომა.
გეო/ფორსმაჟორი: კომუნიკაციების/ენერგიის გამორთვა, სამხედრო/სანქციების რისკები, დომენების/ტრაფიკის დაბლოკვა.

ყველასთვის: გამომწვევი, ესკალაციის ბარიერი, საკონტროლო ზომები, მომსახურების დეგრადაცია და კომუნიკაციის შაბლონები.

4) სტაბილურობისა და სტრატეგიის არქიტექტურა

აქტიური/აქტიური-სტანდარტი რეგიონებში; infrastructure as code სწრაფი ასვლისთვის.
დეგრადაციის რეჟიმები: read-only ფანჯრები, თამაშების არაკრიტიკული პროვაიდერების გამორთვა, გადახდის შეზღუდვები, გადავადებული კასაუტებით „მხოლოდ დეპოზიტები“ (თუ ლეგალურად დასაშვებია), ანალიტიკის/ETL- ის სიხშირის შემცირება.
ტრეფიკის მენეჯმენტი: Anycast CDN, გეო-დაბალანსება, ჯანმრთელობის შემოწმება, საკანალიზაციო მარშრუტიზაცია.
მონაცემები: PITR bacaps, ცვლილებების ჟურნალები, ინტერრეგიონის რეპლიკაცია, კრიპტოგრაფიული მთლიანობა (HESH/WORM).
გასაღებები/საიდუმლოებები: დამოუკიდებელი KMS per-region, „break-glass“ ჟურნალით.
PSP/KYC multi-homing: ავტომატური ფეილოვერი, SLA/ლატენტობის მარშრუტიზაცია.

5) ბრძანების სტრუქტურა (Incident Command System)

Incident Commander (IC) გადაწყვეტილების მიღების ერთი წერტილია.
Ops Lead (SRE/Platform) - ტექნიკური სტაბილიზაცია, ფეილოვერი, მეტრიკა.
Business Continuity Lead - პროცესების/სახელმძღვანელო პროცედურების კოორდინაცია.
Comms Lead - გარე/შიდა შეტყობინებები (მოთამაშეები, პარტნიორები, რეგულატორები).
უსაფრთხოება/DPO - კიბერდანაშაულები/კონფიდენციალურობა, მარეგულირებელი ფანჯრები.
Payments/KYC Leads - PSP/KYC სცენარები.
Liaisons: Legal, Support, VIP/CRM, Data/BI.

წესი: ინციდენტის ერთი IC, მკაფიო არხები და გადაწყვეტილებების ლოგოები.

6) კომუნიკაციის გეგმა

არხები: ომის ოთახი (ჩატი/ხიდი), სარეზერვო კომუნიკაციები (ტელეფონი/რადიო/ალტ მესენჯერი), წინასწარ დამოწმებული PSP/KYC/ბანკების კონტაქტები.
გარე შეტყობინებების შაბლონები: სტატუსის გვერდი, სოციალური ქსელები, email/push; ტონი - ფაქტები, ვადები, შემდეგი ნაბიჯები.
რეგულატორები და პარტნიორები: წინასწარ განსაზღვრული მისამართები, SLA შეტყობინებები; შეთანხმებული ფორმულირებები.
მოთამაშეები: გამჭვირვალე ETA, ანაზღაურება/პრემია (თუ გამოიყენება), FAQ დეგრადაციის პერიოდისთვის.

7) Runbooks

ფრაგმენტების მაგალითები:

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) IT და მონაცემების აღდგენა (DR)

სისტემების კატეგორიები: Tier-1 (პლატფორმა/გადახდა/KUS), Tier-2 (თამაშები/ანალიტიკა), Tier-3 (შიდა).
ამაღლების პროცედურა: ქსელი - საიდუმლოებები/KMS - BD - kash - API - from/CDN - ინტეგრაციისა და ანალიტიკისთვის.
მთლიანობის შემოწმება: მაკონტროლებელი თანხები, ჟურნალების/რეპლიკაციის გადამოწმება, გარიგების შერიგება (რეკონსტრუქცია).
DR ტესტები: ყოველწლიურად სრული (switch-over), კვარტალურად ნაწილობრივი; ფაქტობრივი RTO/RPO დაფიქსირება.

9) ხალხი, ოფისები და ლოჯისტიკა

Remote ready: სარეზერვო ლეპტოპები/მოდემები, SSO/MFA წვდომა, IC- სთვის „წითელი“ წვდომა.
ალტერნატიული ადგილები: სათადარიგო ოფისები/თანამშრომლები, საგუშაგოების სიები, ევაკუაციის გეგმა.
ცვლის როტაცია: კომპეტენციის მატრიცა, საკვანძო როლების დუბლირება, ჩანაცვლების გეგმა.
საკომუნიკაციო/ენერგიის კრიტიკული პროვაიდერები: კონტაქტები, SLA, გენერატორები/UPS (თუ შესაბამისი).

10) მოვაჭრეები და მიწოდების ჯაჭვი

BCP/DR მოთხოვნები ხელშეკრულებებში: RTO/RPO, სავალდებულო ტესტები, აუდიტის უფლება და ერთობლივი წვრთნები.
სუბპროცესორების რეესტრი: კონტაქტები, გარედან გეგმები, მონაცემთა მოცილების/ექსპორტის დადასტურება ოფშორული საშუალებით.
კვარტალური შურისძიება Tier-1: ინციდენტები, DR პროტოკოლები, სერთიფიკატების სტატუსი, SLA.

11) ტრენინგი, სწავლება და ტესტირება

კვარტალში Tabletop: PSP/KYC/ღრუბელი/კიბერ სცენარები.
ეს სწავლებები: DR ნაწილობრივი/სრული; DDoS/CDN შეცვლა; „kill-switch“ SDK პროვაიდერები.
საკომუნიკაციო სავარჯიშოები: პრესრელიზი/სტატუსის განახლება/მარეგულირებელი წერილები.
რეტროსპექტივები: დრო, RCA, CAPA, runbooks და BIA განახლება.

12) მეტრიკი (KPI/KRI)

RTO/RPO ფაქტი (Tier-1- ის მიხედვით): შეესაბამება მიზნებს 95% -ით.
MTTD/MTTR: შემცირების ტენდენცია; კრიტიკული ინციდენტების MTTR სამიზნე ხდება.
Faylover- ის წარმატება: მონაცემთა/შეკვეთების/განაკვეთების დაკარგვის გარეშე, X წუთიანი დეგრადაციის გარეშე.
წვრთნები: 2 სრული DR ტესტირება/წელი + 4 tabletop.
კომუნიკაცია: პირველი განახლება 15 წუთი, განახლების სიხშირე პოლიტიკის შესაბამისად.
Vendor resilience: Tier-1- ის წილი დადასტურებული DR ტესტებით 12 თვის განმავლობაში - 100%.

13) RACI (გაფართოებული)

აქტივობაICSRE/PlatformSecurity/DPOPaymentsRisk/KYCProductSupport/CRMLegal/ComplianceComms/PRData/BI
ინციდენტის განცხადებაA/RRRRRCCCCC
ტექნიკური სტაბილიზაცია/ფეილოვერიCA/RCCCCIIIC
PSP/KYC მარშრუტიზაციაCCIA/RA/RCIIII
კომუნიკაციებიAICCCCCCRI
მარეგულირებელი შეტყობინებებიIIA/RCCIIRII
პოსტ-mortem/SARAA/RRRRRRRCCR

14) ჩეკის ფურცლები

14. 1 Ready-to-Failover

  • მიმდინარე კონტაქტები IC/გამყიდველები/რეგულატორები
  • რეპლიკაციის ჯანმრთელობა, რეგულარული PITR bacap
  • შემოწმებულია „kill-switch“ SDK/webhuks
  • ტრაფიკის მენეჯერი (GSLB/CDN) დადასტურებული ჯანმრთელობის შემოწმებებით
  • სტატუსის/წერილების და გამოქვეყნების უფლების შაბლონები
  • Runbooks და წვდომა (SSO/MFA) ყოველთვიურად შემოწმებულია

14. 2 ინციდენტის დროს

  • დაინიშნა IC, გაიხსნა ომის ოთახი, დაიწყეთ გადაწყვეტილებების ლოგოები
  • კლასიფიკაცია (P1/P2), სცენარის არჩევანი და დეგრადაცია
  • Techdation (faylover/limites/გათიშვა)

პირველი საზოგადოებრივი განახლება 15 წუთი

  • მარეგულირებელი/პარტნიორობის შეტყობინებები SLA
  • პოსტმორტემისთვის არტეფაქტების დაჭერა

14. 3 ინციდენტის შემდეგ

  • Post-mortem 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- ის ვერსია საცავებში, change-log, დოკუმენტის მფლობელი.
გადასინჯვის დრო (კვარტალურად Tier-1- ისთვის), ოფლაინ ასლების ხელმისაწვდომობის კონტროლი.
სავარჯიშოების/ინციდენტების არტეფაქტების შენახვა და შესრულების მეტრიკა.

17) განხორციელების გზის რუკა (6-8 კვირა)

კვირები 1-2: BIA და კრიტიკული პროცესები, RTO/RPO მიზნები, სცენარების სია და მფლობელები.
კვირები 3-4: სტაბილურობისა და დეგრადაციის რეჟიმების არქიტექტურა, runbooks, საკომუნიკაციო შაბლონები, კონტაქტები.
კვირები 5-6: ინტეგრაცია ვენდორებთან (PSP/KYC/ღრუბელი), საპილოტე წვრთნები (tabletop + ნაწილობრივი DR), კორექტირება.
კვირა 7-8: სრული DR ტესტი (თუ ეს შესაძლებელია), სავარჯიშოების კვარტალური ციკლის გაშვება, დაფის ანგარიში და მარეგულირებელი პაკეტი (საჭიროების შემთხვევაში).

18) ვიკის დაკავშირებული მონაკვეთები

რისკების რეესტრი, ინციდენტები და გაჟონვა, DR/BCP ტესტები, TPRM და SLA, ISO 27001/27701, SOC 2, PCI DSS, IGA/RBAC/Least Privilege, LiGOOOaNaNAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAaდა მტკიცებულებები.

TL; DR

ეფექტური BCP = BIA - RTO/RPO - სკრიპტები და დეგრადაცია - მულტფილმის რეგიონი + მკაფიო Incident Command, კომუნიკაცია და წვრთნები. შეინარჩუნეთ დოკუმენტი ცოცხლად, შეამოწმეთ რეგულარულად - და დიდი გაუმართაობაც კი არ შეაჩერებს ბიზნესს და არ დაარტყამს ლიცენზიებს.

Contact

დაგვიკავშირდით

დაგვიკავშირდით ნებისმიერი კითხვის ან მხარდაჭერისთვის.ჩვენ ყოველთვის მზად ვართ დაგეხმაროთ!

Telegram
@Gamble_GC
ინტეგრაციის დაწყება

Email — სავალდებულოა. Telegram ან WhatsApp — სურვილისამებრ.

თქვენი სახელი არასავალდებულო
Email არასავალდებულო
თემა არასავალდებულო
შეტყობინება არასავალდებულო
Telegram არასავალდებულო
@
თუ მიუთითებთ Telegram-ს — ვუპასუხებთ იქაც, დამატებით Email-ზე.
WhatsApp არასავალდებულო
ფორმატი: ქვეყნის კოდი და ნომერი (მაგალითად, +995XXXXXXXXX).

ღილაკზე დაჭერით თქვენ ეთანხმებით თქვენი მონაცემების დამუშავებას.