Disaster Recovery Plan

1) დანიშნულება, სფერო და პრინციპები

მიზანი: კატასტროფების შემდეგ IT პლატფორმის დროული აღდგენის უზრუნველყოფა (მათ, კიბერ, ვენდორ, გეოპოლიტიკური), მარეგულირებელი მოთხოვნების დარღვევის, კონტრაქტებისა და მოთამაშეთა მოლოდინების გარეშე.
რეგიონი: პროდუქტიული გარემო (სათამაშო წრე, გადახდები, KYC/AML, ანტიფროდი, DWH/BI ფანჯრები), ინტეგრაცია (PSP, KYC, სტუდია/აგრეგატორები), ინფრასტრუქტურა (ღრუბელი/K8s, ქსელები, საიდუმლოებები/გასაღებები), მონაცემები (BD, ფაილები, ლოგოები).
პრინციპები: safety-first, RTO/RPO მინიმიზაცია, ავტომატიზაცია და რეპროდუქცია (IaC), „ნაგულისხმევი დადასტურება“, რეგულარული წვრთნები.

2) სისტემების კლასიფიკაცია და აღდგენის მიზნები

2. 1 კრიტიკის დონე

Tier-1 (სასიცოცხლო): გადახდები/კასაუტები, core თამაშები, ლოგინი/ავთენტიფიკაცია, KUS/სანქციები.
Tier-2: რეალურ დროში ანალიტიკა, მარკეტინგი/CRM, DWH ანგარიშები.
Tier-3: შიდა პორტალები, დამხმარე სერვისები.

2. 2 მიზნები

RTO (Recovery Time Objective): მომსახურების აღდგენის დრო.
RPO (Recovery Point Objective): დასაშვები დროის მონაცემების დაკარგვა.
RTA (Recovery Time Actual )/RPA (Recovery Point Actual): ფაქტობრივი მნიშვნელობები დაფიქსირებულია მოხსენებებში.
MTO/MBCO: მაქსიმალური გადაადგილების დრო/მომსახურების მინიმალური მისაღები დონე (degraded რეჟიმი).

• Tier-1 - RTO - 30-60 წთ, RPO - 15 წთ; Tier-2 — RTO ≤ 4 ч, RPO ≤ 1 ч; Tier-3 — RTO ≤ 24 ч, RPO ≤ 24 ч.

3) სტრატეგია DR და არქიტექტურა

3. 1 ტოპოლოგია

Active-Active (მულტფილმის რეგიონი): მინიმალური RTO/RPO, მოითხოვს შესაბამისობას და კონფლიქტს.
Active-Standby (ცხელი/თბილი/ცივი): ხარჯების/სიჩქარის ბალანსი.
მონაცემთა და გასაღებების Geo გამიჯვნა: KMS/HSM per-region, BYOK, დამოუკიდებელი რეპლიკაციის გზები.

3. 2 მონაცემები და ზურგჩანთები

PITR (წერტილის დროის ჩანაწერი): გარიგების ჟურნალები, არქივის ინტერვალები 5-15 წუთი Tier-1- ისთვის.
Snepshots/full-bacaps: ყოველდღიური/საათები, შენახვა 3-2-1 სქემის მიხედვით (3 ეგზემპლარი, 2 გადამზიდავი, 1 ოფლაინ/ოფსეტური).
Immutabelity: WORM/ობიექტის ლოყები, ხელმოწერა/არტეფაქტების მძიმე ჯაჭვები.
აღდგენის კატალოგი: ზურგჩანთების ინვენტარი, მთლიანობა, შენახვის ვადა, ტესტის გაშიფვრა.

3. 3 პროგრამები და ინტეგრაცია

Stateles სერვისები: სწრაფი განლაგება IaC/CI- ით.
Steitful კომპონენტები: შეთანხმებული სნაიპშოტები, გაშვების თანმიმდევრობის ორკესტრი.
ინტეგრაცია (PSP/KYC/აგრეგატორები): ორმაგი კრედიტი, fallback endpoints, ხელმოწერილი ვებჰუკები, ხელახალი მიწოდების კონტროლი (იდემპოტენტურობა).

4) აღდგენის წესი (ზოგადი რუნბუკი)

1. DR სცენარის გამოცხადება - DR Incident Commander (DR-IC) დანიშვნა, ომის ოთახი.
2. დაზიანების შეფასება: დაზარალებული რეგიონები/ქვესისტემები, შესაბამისი RTA/RPA, გადაწყვეტილება ფეილოვერის გააქტიურების შესახებ.
3. იზოლაცია/კონტეინერი: საწყისი მიზეზების დაბლოკვა (ქსელის ACL, საიდუმლოებები, პროვაიდერის გამორთვა).

• ქსელი/საიდუმლოებები/KMS)
• BD/საცავი/ქეში
• API/სერვისები ფრონტზე/CDN არის გარე ინტეგრაცია.
• 5. მთლიანობის შემოწმება: უკანა. თანხები, „მშრალი“ მოთხოვნები, ჯანმრთელობის ტესტები.
• 6. ფინანსების აღრიცხვა/თამაშები: გადახდების, განაკვეთების, ნაშთების შერიგება, ოპერაციების იდემპოტენტური განმეორება.
• 7. კომუნიკაციები: სტატუსის გვერდი, მოთამაშეები/პარტნიორები/რეგულატორები; განახლებების დრო.
• 8. დაკვირვება და სტაბილიზაცია: დეგრადაციის დეაქტივაცია ნორმალიზაციის გზით.
• 9. პოსტ-mortem: RCA, CAPA, DRP განახლება.

5) სპეციალიზირებული runbooks (ფრაგმენტები)

5. 1 ძირითადი რეგიონის დაკარგვა (Active-Standby - Standby)

yaml trigger: "loss_of_region_primary OR quorum_fail >= 5m"
prechecks:
- "secondary region green"
- "replication_lag <= 15m"
steps:
- DR-IC approves region_failover
- Platform: GSLB switch → secondary
- Data: promote replicas, enable PITR streams
- Apps: redeploy with region vars; warm caches
- QA: smoke tests (login, deposit, bet, payout)
- Comms: status-page + partner notice rollback: "switch-back after 60m stability window"

5. 2 კორუფცია BD/აღდგენა PITR- დან

yaml trigger: "data_corruption_detected OR accidental_drop"
steps:
- Freeze writes (feature flag), snapshot evidence
- Restore to timestamp T (<= RPO)
- Reindex/consistency checks
- Replay idempotent events from queue (from T)
- Reopen writes in throttle mode validation: ["checksum_ok", "balance_diff=0", "orders_gap=0"]

5. 3 PSP დეგრადაცია DR რეჟიმში

yaml trigger: "auth_rate_psp1 < baseline-3σ for 15m"
steps:
- Route X%→psp2, cap payouts, enable manual VIP
- Reconciliation plan T+0, alerts Finance
- Notify players in cashier; vendor escalation

6) მონაცემთა მთლიანობა და რეკონსტრუქცია

ფინანსები: დეპოზიტების/გადასახადების/საკომისიოს შერიგება, შეტყობინებების და ვებჰუკების ხელახალი გაგზავნა დედუპლიკაციით (იდემპოტაცია).
თამაშის წრე: რაუნდის სახელმწიფოების აღდგენა, გამოთვლების გამეორება, საჭიროების შემთხვევაში, ორმაგი ჩამოწერის/დარიცხვისგან დაცვა.
ჟურნალები/აუდიტი: WORM ლოგოების შედარება „ადრე/შემდეგ“, ხელმოწერები/ჰეში, მოხსენებები თანმიმდევრულობის შესახებ.
DPO/შესაბამისობის ანგარიში: PII- ზე ზემოქმედების შემთხვევაში - მასშტაბის, დროისა და შეტყობინებების დაფიქსირება.

7) DR საკვანძო ტექნოლოგიებისთვის (მაგალითები)

DBMS (რელაქსაცია): სინქრონული/ასინქრონული რეპლიკაცია, WAL სლოტები, სწრაფი პრომოტი, ცხელი სტენდები.
NoSQL/ქეში: მულტიკლასტერი, TTL ინვალიდობა, ცივი შევსება, cross-region write- ის უარყოფა რეზინის კონფლიქტის გარეშე.
რიგები/ნაკადები: სარკის ღერძი/მტევანი, გადაადგილების კონტროლი, მომხმარებელთა დედაპლაცია.
ობიექტის საცავი: ვერსია, რეპლიკაცია „ბუნკერში“, ობიექტების ინვენტარი და რეპლიკაციის პოლიტიკა.
CI/CD/არტეფაქტები: რეესტრების რეპლიკები, არტეფაქტების ხელმოწერა, კრიტიკული კონტეინერების ოფლაინ ასლები.
საიდუმლოებები/გასაღებები: KMS per-region, დამოუკიდებელი ფესვის გასაღებები, ჟურნალის გასაღებები და TTL.

8) უსაფრთხოება და კონფიდენციალურობა DR- ში

მინიმალური უფლებების პრინციპი: DR წვდომა ცალკეულ როლებს/პროფილებს (JIT/PAM).
Imputable bacaps: offline/offsyte, აღდგენისა და გაშიფვრის ტესტი.
მარეგულირებელი ფანჯრები: მოვლენების დაფიქსირება და შეტყობინებების შესახებ გადაწყვეტილება (მარეგულირებელი/ბანკი/PSP/მომხმარებლები) Legal/DPO.
ტრეკირება: DR გუნდის მოქმედების სრული ჟურნალი, ტაიმლაინის ხელმოწერა.

9) სწავლებები და ტესტები

Walkthrough/Review: დოკუმენტის/როლების/კონტაქტების შემოწმება (კვარტალურად).
Tabletop: სკრიპტების პროვოცირება „მშრალი“ კონფლიქტის მოგვარებით.
ტექნიკური წვეულება: ცალკეული მომსახურების აღდგენა/BD.
Full failover/switch-over: ტრაფიკის და მონაცემების გადაცემა სარეზერვო რეგიონში.
Chaos დღეები (კონტროლირებადი): ავტომატიზაციის გადამოწმების წარუმატებლობის/წარუმატებლობის ინექცია.

თითოეულ ტესტს აქვს ანგარიში RTA/RPA, გადახრების სია, CAPA და DRP განახლება.

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

RTA/RPA vs RTO/RPO (Tier-1): კორესპონდენციების 95%.
DR Test Coverage: 2 სრული DR ტესტირება/წელი + რეგულარული ნაწილობრივი.
Time-to-First-Status: 15 წუთი DR- ის გამოცხადებიდან.
რეკონსტრუქცია Zero-Diff: ყველა ფულადი და თამაშის კრიკეტი შეუსაბამობის გარეშე.
Backup Integrity: შერჩევითი აღდგენის 100% წარმატებულია კვარტალში.
Config Drift: 0 დრიფტი პრემიუმ/საშუალო (IaC შედარება) შორის.
უსაფრთხოება DR- ში: 100% DR მოქმედება ჟურნალთან და დადასტურებით.

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

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

12. 1 მზადყოფნა DR- სთვის

• განახლებულია DR გუნდის/გამყიდველების/რეგულატორების კონტაქტები
• მწვანე რეპლიკაცია, PITR ჩართულია ბეკის ტესტის გაშიფვრა
• JIT/PAM წვდომა, შემოწმებულია „break-glass“
• Faylover playbooks და გარემო ცვლადები რეალურია
• ორმაგი კრედიტი/ვებ ჰუკები PSP/KYC, ალტერნატიული მარშრუტები
• სტატუსის გვერდი/შეტყობინებების შაბლონები მზად არის

12. 2 DR- ის დროს

• დაინიშნა DR-IC, გაიხსნა ომის ოთახი, მოვლენების დრო
• მიზეზების იზოლაცია, სცენარის არჩევა, runbooks- ის გაშვება
• მთლიანობის შემოწმებები, ჯანმრთელობის ტესტები, მცირე ტესტები

პირველი საზოგადოებრივი განახლება 15 წუთი; SLA პარტნიორების/მარეგულირებლების შეტყობინებები

გამოძიებისთვის არტეფაქტების დაჭერა

12. 3 DR შემდეგ

ფულის/თამაშების და ჟურნალების სრული შერიგება

• Post-mortem, RCA, CAPA თარიღებითა და მფლობელებით
• DRP/BIA/კონტაქტების განახლება/IaC
• Fix- ის ხელახალი ტესტის გეგმა

13) შაბლონები (ფრაგმენტები)

13. 1 მომსახურების ბარათი (DR პასპორტი)

yaml service: payments-api tier: 1 dependencies: [auth, ledger-db, psp1, psp2, kms-eu]
rto: "45m"
rpo: "15m"
backups: {pitr: true, snapshots: "hourly", immutability: "7d"}
failover: {mode: "active-standby", regions: ["eu1","eu2"]}
runbooks: ["rb_failover_region", "rb_psp_degradation"]
health_checks: ["/healthz","/readyz"]

13. 2 DR ტესტის ანგარიში (ჩამკეტი)

yaml test_id: DR-2025-10 scope: "Full switch-over eu1→eu2"
rta: "27m"
rpa: "11m"
issues:
- id: CAPA-117, desc: "долгое прогревание кэша", due: 2025-11-20, owner: SRE
- id: CAPA-118, desc: "устаревший webhook PSP#2", due: 2025-11-12, owner: Payments reconciliation: {finance: "ok", games: "ok"}
management_signoff: "2025-11-02"

13. 3 სტატუსის შეტყობინებების შაბლონი

[UTC+02] Идет аварийное переключение в резервный регион. Игры доступны, выводы временно ограничены. Средства игроков в безопасности. Следующее обновление через 15 минут.

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

კვირები 1-2: სერვისებისა და დამოკიდებულების ინვენტარიზაცია, Tier კლასიფიკაცია, RTO/RPO მიზნები, ტოპოლოგიის არჩევანი, DR პასპორტი.
კვირები 3-4: ზურგჩანთების/PITR/იმუნიტეტის განხორციელება, საიდუმლოების რეპლიკაცია/KMS, რუნბოქსის მომზადება და სტატუსი.
კვირები 5-6: ნაწილობრივი ტესტები (BD/ქეში/ეტაპი), tabletop PSP/KYC/რეგიონის სკრიპტების მიხედვით.
არგუმენტები 7-8: სრული დარტყმა (თუ ეს შესაძლებელია), ანგარიში RTA/RPA, CAPA, DRP განახლება და რეგულარული ტესტის გეგმა.

15) ინტეგრაცია wiki- ს სხვა მონაკვეთებთან

დააკავშიროთ: BCP, რისკების რეესტრი, ინციდენტის მენეჯმენტი, ლოგოების პოლიტიკა (WORM), TPRM და SLA, ISO 27001/27701, SOC 2, PCI DSS, RBAC/Least Privilege, პაროლის პოლიტიკა და MaNaNaNaNaNaNaSaNane, Mane, ცვლილების მენეჯმენტი/გამოშვება.

TL; DR

სამუშაო DRP = მკაფიო RTO/RPO Tier- ზე - Active-Active/Standby + Standby bacaps/PITR არქიტექტურა, რომელიც ასახავს runbooks და faylover - ს ფულის რეკონსტრუქციას/თამაშებს, რეგულირების/თამაშები და CAAPCaTaCAAACAAACAACAatieCaTatieCCatatieCAate ate atie- ს და c შემდეგ ნებისმიერი მთავარი მარცხი გადაიქცევა კონტროლირებად პროცედურად პროგნოზირებადი აღდგენის დროით და რეგულატორებისა და მოთამაშეებისთვის ნულოვანი სიურპრიზებით.