ბიზნესის უწყვეტობის გეგმა
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 (გაფართოებული)
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, კომუნიკაცია და წვრთნები. შეინარჩუნეთ დოკუმენტი ცოცხლად, შეამოწმეთ რეგულარულად - და დიდი გაუმართაობაც კი არ შეაჩერებს ბიზნესს და არ დაარტყამს ლიცენზიებს.