გადაუდებელი აღდგენის სცენარები

1) რატომ არის საჭირო DR და რა მიზანი

Disaster Recovery (DR) არის არქიტექტურების, პროცესებისა და ვარჯიშების ერთობლიობა კატასტროფების შემდეგ მომსახურების აღდგენის მიზნით (დანიის ცენტრის/რეგიონის უკმარისობა, მონაცემთა დაკარგვა, მასობრივი კონფიგურაციის შეცდომები). DR- ის მიზანია შეასრულოს სამიზნე RTO/RPO კონტროლირებადი ღირებულებითა და რისკით, შეინარჩუნოს მომხმარებელთა ნდობა და შესაბამისობა მარეგულირებლთან.

RTO (Recovery Time Objective): დასაშვები დრო.
RPO (Recovery Point Objective): დასაშვები მონაცემთა დაკარგვა (ბოლო თანმიმდევრული წერტილიდან დრო).
RLO (რეკონსტრუქციის დონე): ფუნქციონალური დონე, რომელიც პირველ რიგში უნდა დაბრუნდეს (მინიმალური სიცოცხლისუნარიანი მომსახურება).

2) სისტემების კლასიფიკაცია კრიტიკულად

Tier 0 (სასიცოცხლო): გადახდები, ლოგინი, KYC, გარიგების ბირთვი - RTO - 15 წთ, RPO - 1-5 წთ

Tier 1 (მაღალი): ოპერაციული პანელები, მოხსენებები D-1 - RTO - 1 საათი, RPO - 15-60 წთ.
Tier 2 (საშუალო): სარეზერვო ოფისი, რეალურ დროში ანალიტიკა - RTO - 4-8 საათი, RPO - 4-8.

Tier 3 (დაბალი): არა კრიტიკული დამხმარე - RTO - 24-72 საათი, RPO - 24;

თითოეულ სერვისს მიანიჭეთ Tier + სამიზნე RTO/RPO მომსახურების კატალოგში; გადაწყვეტილებები და ბიუჯეტები შეამოწმეთ მათთან.

3) მუქარისა და სცენარის მოდელი

ტექნოგენური: AZ/რეგიონის/პროვაიდერის უკმარისობა, ქსელის/DNS დეგრადაცია, BD/საცავის უკმარისობა, მასობრივი გამოშვება.
ადამიანის ფაქტორი: არასწორი კონფიგურაცია/IaC, მონაცემების წაშლა, გასაღებების კომპრომისი.
ბუნებრივი/გარე: ხანძარი/წყალდიდობა, ენერგიის შეფერხება, იურიდიული დაბლოკვა.
ყველასთვის - შეაფასეთ ალბათობა/ზემოქმედება, დააკავშიროთ DR სცენარი და ფლეიბუკი.

4) არქიტექტურის ნიმუშები DR

1. აქტიური აქტივობა: ორივე რეგიონი ემსახურება ტრაფიკს.

დადებითი: მინიმალური RTO/RPO, მაღალი სტაბილურობა.
უარყოფითი: მონაცემთა სირთულე/თანმიმდევრულობა, მაღალი ფასი.
სად: კითხვა-მძიმე, ქეშირებული დატვირთვები, სახელმწიფო სერვისები, მრავალფუნქციური DB (კონფლიქტის მკაცრი წესები).

2. Active-Passive: ცხელი ვნება ინარჩუნებს სრულად დათბობის ასლს.

RTO: წუთი; RPO: წუთი. მოითხოვს ავტომატიზირებულ failover- ს და რეპლიკაციას.

3. Warm Standby: გამკაცრებული რესურსების ნაწილი, სკალირება უბედური შემთხვევის დროს.

RTO: ათობით წუთი; RPO: 15-60 მმ უფრო ეკონომიური, მაგრამ უფრო გრძელი.

4. Pilot Light: მინიმალური „ნაპერწკალი“ (მეტამონაცემები/სურათები/სკრიპტები) + სწრაფი შემობრუნება.

RTO: საათი; RPO: საათი. იაფი, შესაფერისია Tier 2-3- ისთვის.

5. Backup & Restore: offline bacaps + სახელმძღვანელო დათბობა.

RTO/RPO: საათი-დღე. მხოლოდ დაბალი კრიტიკულობისა და არქივისთვის.

5) მონაცემები და შესაბამისობა

• სინქრონული - თითქმის ნულოვანი RPO, მაგრამ ლატენტობა/ღირებულება.
• ასინქრონული - უკეთესია პროდუქტიულობა, RPO> 0 (ჟურნალის კუდი).
• კოორდინაცია: შეარჩიეთ მოდელი (strong/eventual/causal). გადახდებისთვის - მკაცრად, ანალიტიკოსებისთვის - ღონისძიება.
• Snapshots: რეგულარულად შექმნათ თანმიმდევრული წერტილები + შეინახეთ ჟურნალები (WAL/redo).
• ჯვარედინი რეგიონალური გარიგებები: თავიდან აიცილეთ 2PC; გამოიყენეთ idempotent ოპერაციები, deli-i-fray (რეპროდუქცია დედოპლიკაციით), ღონისძიება sourcing.
• რიგები/საბურავები: რეპლიკაცია/მარცვლეული, DLQ, შეკვეთა და კონსიუმერების იდემპოტენტურობა.

6) ქსელი, ტრაფიკი და DNS

GSLB/Anycast/DNS: failover/failback პოლიტიკოსები, დაბალი TTL (მაგრამ არც ისე ბევრი), ჯანმრთელობის შემოწმებები რამდენიმე რეგიონიდან.
L7 მარშრუტიზაცია: რეგიონალური რუქები, დეგრადაციის დროშები (ფუნქციების შეზღუდვა).
პირადი ბმულები/VPN: სარეზერვო არხები პროვაიდერებისთვის (PSP/KYC/CDN).
Rate limiting: ქარიშხლისგან დაცვა აღდგენის დროს.

7) Stateful vs Stateless

სახელმწიფო გადადის სკრიპტით/სკალით; stateful მოითხოვს შეთანხმებულ მონაცემთა სტრატეგიას (რეპლიკაცია, სნაიპშოტები, რეპლიკების პოპულარიზაცია, კვორუმი).
ქეში/სესიები: გარე (Redis/Memcached) ჯვარედინი რეგიონალური რეპლიკაციით ან ჟურნალებით re-seed; სესიების შენახვა ტოკენებში (JWT) ან საერთო საცავში.

8) გამომწვევები და ავტომატიზაცია DR

SLO გარდერობები და ზონდის კვორუმი არის ავტომატური რეგულირება-failover runbook.
Change freeze უბედური შემთხვევის დროს: ჩვენ ბლოკავს არარელევანტურ გამოშვებებს/მიგრაციას.
Infrastructure as Code: მანიფესტების განლაგება, დრიფტის შემოწმება.
როლის პოპულარიზაცია: BD + writers/საიდუმლოებების ავტომატური რეპლიკა.

9) კომუნიკაციები და შესაბამისობა

War-room: IC/TL/Comms/Scribe; Apdates- ის ინტერვალები SEV- ზე.
სტატუსის გვერდი: გავლენის გეოგრაფია, ETA, შემოვლითი გზები.
მარეგულირებელი: შეტყობინებების დრო, მონაცემთა უსაფრთხოება, ვადების უცვლელი შენახვა.
პარტნიორები/პროვაიდერები: დადასტურებული კონტაქტები, გამოყოფილი არხი.

10) ტესტები და სწავლებები DR

Tabletop: ჩვენ განვიხილავთ სცენარს და გადაწყვეტილებებს.
Game Day (stage/prod light): AZ/რეგიონების უკმარისობის იმიტაცია, პროვაიდერის გათიშვა, DNS- ის გამოტოვება.
Restore ტესტები: პერიოდულად აღვადგინოთ bacaps იზოლირებულად და ვალიდაციით მთლიანობაში.
Chaos/Failure injection: კონტროლირებადი ქსელის/კვანძების/დამოკიდებულების გაუმართაობა.
KPI წვრთნები: მიღწეული RTO/RPO, პლეიბუკების დეფექტები, CAPA.

11) ფინანსები და სტრატეგიის არჩევანი (FinOps)

განიხილეთ დოლარი შემცირებული RPO/RTO: რაც უფრო დაბალია მიზანი - უფრო ძვირია არხები, ლიცენზიები, რეზერვები.
ჰიბრიდი: Tier 0 - აქტიური აქტიური/ცხელი; Tier 1 — warm; Tier 2–3 — pilot/backup.
მონაცემები ძვირია: გამოიყენეთ ცივი ფენები (არქივი/S3/GLACIER), სავარაუდო ჭურვები, დედუპლიკაცია.
ხარჯების და სერთიფიკატების/ლიცენზიების პერიოდული რეპროდუქცია DR ინფლაცია.

12) სიმწიფის მეტრიკა DR

RTO (ფაქტი) და RPO (ფაქტი) თითოეული Tier- ისთვის.
DR Coverage: სერვისების%, რომლებიც დამზადებულია სცენარის/ფლეიბუკის/ტესტის საშუალებით.
Backup Success & Restore Success: backap- ის ყოველდღიური წარმატება და დადასტურებული აღდგენა.
დრო Declare Disaster: გადაწყვეტილების მიღების სიჩქარე failover- ზე.
Failback Time: ნორმალურ ტოპოლოგიაში დაბრუნება.
გამოუსწორებელი სავარჯიშოები: ნაპოვნი ხარვეზები/სწავლებები.
კომპლექტი Evidence Completeness: არტეფაქტების სისრულე.

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

DR- ს დანერგვამდე

• კატალოგის სერვისი შეიცავს Tier, RTO/RPO, დამოკიდებულებას და მფლობელებს.
• შეირჩა ნიმუში (AA/AP/WS/PL/BR) Tier და ბიუჯეტში.
• თანმიმდევრულობისა და რეპლიკაციის შესახებ შეთანხმებები დოკუმენტირებულია.
• GSLB/DNS/მარშრუტიზაცია და ჯანმრთელობის შემოწმება შედგენილია და ტესტირებულია.
• Bacaps, Snaphots, ცვლილებების ჟურნალები - შედის, შემოწმებულია restore- სთვის.
• DR ფლეიბუკები და პროვაიდერების კონტაქტები შესაბამისი ფორმით.

უბედური შემთხვევის დროს (მოკლედ)

• გამოაცხადეთ SEV და შეაგროვეთ ომის ოთახი; გაყინული გამოშვებები.
• შეამოწმეთ ზონდის კვორუმი; გავლენის/გეოგრაფიის დაფიქსირება.
• შეასრულეთ Failover Runbook: ტრეფიკი, BD აქციები, რიგები, ქეში.
• ჩართეთ degrade-UX/ლიმიტები; გამოაქვეყნეთ apdates SLA.
• შეაგროვეთ evidence (დრო, გრაფიკა, ლოგოები, გუნდები).

უბედური შემთხვევის შემდეგ

• დააკვირდით SLO N ინტერვალებს; შეასრულეთ failback გეგმის მიხედვით.
• ჩაატარეთ AAR/RCA; გამოსცეს CAPA.
• განაახლეთ ფლეიბუკები, ალერტის კატალიზატორები, DR ტესტის შემთხვევები.
• შეატყობინეთ სტეიკჰოლდერებს/რეგულატორებს (საჭიროების შემთხვევაში).

14) შაბლონები

14. 1 DR სცენარის ბარათი (მაგალითი)

ID: DR-REGION-FAILOVER-01
Scope: prod EU ↔ prod US
Tier: 0 (Payments, Auth)
Targets: RTO ≤ 15m, RPO ≤ 5m
Trigger: quorum(probes EU, US) + burn-rate breach + provider status=red
Actions:
- Traffic: GSLB shift EU→US (25→50→100% with green SLIs)
- DB: promote US-replica to primary; re-point writers; freeze schema changes
- MQ: mirror switch; drain EU DLQ; idempotent reprocess
- Cache: invalidate region-specific keys; warm critical sets
- Features: enable degrade_payments_ux
- Comms: status page update q=15m; partners notify
Guardrails: payment_success ≥ 98%, p95 ≤ 300ms
Rollback/Failback: EU green 60m → 25→50→100% with guardrails
Owners: IC @platform, DB @data, Network @netops, Comms @support

14. 2 Runbook „Promote რეპლიკები BD“ (ფრაგმენტი)

1) Freeze writes; verify WAL applied (lag ≤ 30s)
2) Promote replica; update cluster VIP / writer endpoint
3) Rotate app secrets/endpoints via remote config
4) Validate: read/write checks, consistency, replication restart to new secondary
5) Lift freeze, monitor errors p95/5xx for 30m

14. 3 DR სწავლების გეგმა (მოკლედ)

Purpose: to check RTO/RPO Tier 0 in case of EU failure
Scenario: EU incoming LB down + 60s replication delay
Success criteria: 100% traffic in US ≤ 12m; RPO ≤ 5m; SLI green 30m
Artifacts: switching logs, SLI graphs, step times, command output

15) ანტი შაბლონები

„არსებობს ზურგჩანთები“ რეგულარული სარეაბილიტაციო ტესტების გარეშე.
საიდუმლოებები/ენდოინტები ავტომატურად არ იცვლება.
იდემპოტენტურობის არარსებობა - დუბლიკატები/დაკარგული გარიგებები ხელახლა მიწოდებისას.
იგივე კონფისკაცია რეგიონებისთვის წინსვლის დროშის გარეშე.
გრძელი დრო ცრუ განგაშის შიშის გამო.
მონო-რეგიონალური პროვაიდერები (PSP/KYC) ალტერნატივის გარეშე.
არ არსებობს failback გეგმა - ჩვენ ვცხოვრობთ გადაუდებელ ტოპოლოგიაში „სამუდამოდ“.

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

1. ნვე. 1-2: Tier სერვისების კლასიფიკაცია, სამიზნე RTO/RPO ინსტალაცია, DR ნიმუშების არჩევანი.
2. ნვე. 3-4: რეპლიკების/ხელების კონფიგურაცია, GSLB/DNS, სარეკლამო პროცედურები; playbook და runbook '.
3. ნვე. 5-6: პირველი DR ვარჯიშები (tabletop-stage), მეტრიკის ფიქსაცია და CAPA.
4. ნვე. 7-8: შეზღუდული ტრაფიკის სავარჯიშოების მარტივი ლაითური; failover ავტომატიზაცია.
5. ნვე. 9-10: ხარჯების ოპტიმიზაცია (FinOps), Tier 0-ის გადაცემა ცხელი/AA- ში, კვარტალური წვრთნების და ანგარიშგების რეგულირება.

17) შედეგი

ეფექტური DR არ არის მხოლოდ ზურგჩანთები. ეს არის შეთანხმებული არქიტექტურა, failover/failback ავტომატიზაცია, მონაცემთა დისციპლინა (imempotence/რეპლიკაცია), ტრენინგი და გამჭვირვალე კომუნიკაციები. როდესაც RTO/RPO რეალურია, პლეიბუკები დამუშავებულია და სავარჯიშოები რეგულარულია, კატასტროფა ხდება კონტროლირებად მოვლენად, რის შემდეგაც სერვისები სწრაფად და პროგნოზირებულად უბრუნდება ნორმას.