DR სტრატეგიები და RTO/RPO

1) ძირითადი პრინციპები

1. მიზნები უფრო ადრეა, ვიდრე თანხები. ჯერ ჩვენ ჩამოვაყალიბებთ RTO/RPO და კრიტიკულ სცენარებს, შემდეგ ვირჩევთ ტექნოლოგიას.
2. სეგმენტი მნიშვნელოვანია. ყველა სერვისს არ სჭირდება ოქროს; გაუზიარეთ ბიზნესის კრიტიკა.
3. მონაცემები - DR- ის ბირთვი. თანმიმდევრულობა, რეპლიკაცია, დაზიანების აღმოჩენა და აღდგენის წერტილი უფრო მნიშვნელოვანია, ვიდრე „რკინა“.
4. ავტომატიზაცია და შემოწმება. DR უაზროა IaC- ის გარეშე, აღდგენისა და ტელემეტრიის რეგრესიული ტესტები.
5. სწავლებები და მტკიცებულებები. რეგულარული „თამაშის დღის“ გეგმა მზადყოფნის ილუზიაა.
6. უსაფრთხოება და შესაბამისობა. დაშიფვრა, იზოლაცია, WORM/immutable-bacaps, DPA/იურისდიქცია.

2) ტერმინები და შესაბამისობა

RTO - მოვლენის მომენტიდან დაწყებული დრო „ნორმალურად“ მომსახურების აღდგენამდე.
RPO - აღდგენის დროს ბოლო ჯანმრთელი მონაცემთა წერტილის „ასაკი“.
RLO (რეკონსტრუქციის ხე ობჟექტივი) არის ფუნქციონალური დონე, რომლის აღდგენაც საჭიროა (მინიმალური სიცოცხლისუნარიანი მომსახურება).
MTD (Maximum Tolerable Downtime) არის ბარიერი, რომლის შემდეგაც ბიზნესი მიუღებელ ზიანს აყენებს.
RTA/RPA (Actual) - ფაქტობრივი დრო/აღდგენის წერტილი პრაქტიკისგან.

კომუნიკაცია: RTO და MTD; RPA ≤ RPO. სამიზნესა და ფაქტს შორის უფსკრული პოსტმორტემისა და გაუმჯობესების საგანია.

3) DR სტრატეგიების კლასები (მზადყოფნის დონე)

4) სკრიპტები, რომელთა წინააღმდეგაც თავს ვიცავთ

რეგიონის/ღრუბლის/მონაცემთა ცენტრის დაკარგვა (ელექტრიკოსი, ქსელი, პროვაიდერი).
მონაცემთა კორუფცია/ოპერატორის შეცდომა (მოცილება, „გატეხილი“ შენიშვნები, ლოგიკური დაზიანება).
მავნე პროგრამა/დაშიფვრა (ransomware).
გამოშვების/კონფიგურაციის დეფექტი (მასობრივი გარედან).
დამოკიდებულების დაშლა (KMS, DNS, საიდუმლოებები, გადახდის პროვაიდერი).
იურიდიული მოვლენები (დაბლოკვა, იურისდიქციიდან მონაცემების ექსპორტის აკრძალვა).

თითოეული სცენარისთვის მიუთითეთ RTO/RPO, DR დონე, პლეიბუკი, პასუხისმგებელი.

5) მონაცემთა სტრატეგია (RPO გასაღები)

5. 1 ბეკაპი

სრული + დამატებითი + გარიგების ჟურნალები (მონაცემთა ბაზისთვის).
Imputable/WORM საცავები და ოფლაინ ასლები („air-gapped“).
ზურგჩანთების კატალოგი მეტამონაცემებითა და კრიპტოვალუტებით; ტესტის აღდგენა გრაფიკით.

5. 2 რეპლიკაცია

სინქრონული (დაბალი RPO, ლატენტობა, გაფუჭების გავრცელების რისკი).
ასინქრონული (დაბალი გავლენა პერფზე, RPO> 0; დეტალებთან ერთად ზიანი).
CDC (Change Data Capture) ნაკადის რეპლიკაციისა და სტატუსის რეკონსტრუქციისთვის.

5. 3 ლოგიკური გაფუჭებისგან დაცვა

ვერსია/“ დროის წერტილები“ (PITR) ფანჯრით N დღის განმავლობაში.
ინვარიანტების ხელმოწერები (ბალანსი, თანხები, ჩექსუმმა) - „გატეხილი“ მონაცემების ადრეული დეტალი.
„ნელი“ რეპლიკაციის არხები (delay 15-60 წუთი), როგორც ბუფერი მყისიერი დაზიანების წინააღმდეგ.

python def pick_restore_point(pitr, anomaly_signals, max_age):
healthy = [p for p in pitr if not anomaly_signals. after(p. time)]
return max(healthy, key=lambda p: p. time if now()-p. time <= max_age else -1)

6) დანართი, მდგომარეობა, ქეში

Stateless ფენა - ჩვენ მასშტაბებს და გადატვირთვას ნებისმიერ რეგიონში (გამოსახულება/გრაფიკი/მანიფესტები Git- ში).
მდგომარეობა (BD/ქეში/კუ): ჭეშმარიტების წყარო არის ერთ - ერთი BD; ქეში და ინდექსები გადაკეთებულია.
Idempotence და re-drive - მოვლენების განმეორებითი მიტანა დასაშვებია; გამოიყენეთ outbox/inbox, დედაპლატი და ვერსიები.

7) ქსელი და შესასვლელი წერტილი

GSLB/DNS Faylover: latency/Health-based, მოკლე TTL შემთხვევის ფანჯარაში.
Anycast/L7 მარიონეტები: ერთი IP, მარშრუტიზაცია რეგიონების ჯანმრთელობაზე.
რეგიონალური დომენები და იურისდიქციის პოლიტიკა (geo-pinning for PII).
სერთიფიკატების ფეილოვერი/KMS: სათადარიგო ჯაჭვები, ორმაგი კეი.

python if slo_breach("region-a") or health("region-a")==down:
route. shift(traffic, from_="region-a", to="region-b", step=20) # канарим enable_readonly_if_needed()

8) ოპერაციული მოდელი და ავტომატიზაცია

IaC/GitOps: მეორე რეგიონის ინფრასტრუქტურა = კოდი, „ერთოთახიანი“ განლაგება.
Policy as Code: კარიბჭე „არ არსებობს DR მანიფესტები/ბეიკაპები/ალერტები - არ არსებობს გამოშვება“.
Runbooks: ეტაპობრივი ინსტრუქციები და „წითელი ღილაკი“, რომელიც იდენტურია ორივე რეგიონისთვის.
საიდუმლოებები: მოკლევადიანი კრედიტები, OIDC ფედერაცია, კომპრომისული/მიმოხილვის გეგმა.

rego package dr deny["Missing PITR ≥ 7d"] {
input. db. pitr_window_days < 7
}
deny["No restore test in 30d"] {
now() - input. db. last_restore_test > 3024h
}

9) სწავლებები და ტესტები (თამაშის დღეები)

სცენარის ცხრილი: მონაცემთა ბაზის დაკარგვა, „გატეხილი“ მონაცემები, KMS- ის უკმარისობა, რეგიონის ვარდნა, მოულოდნელი egress ლიმიტი.
სიხშირე: კვარტალი კრიტიკული მისიისთვის; ექვს თვეში ერთხელ - დანარჩენებისთვის.
სავარჯიშო მეტრიკა: RTA/RPA მიზნები, ავტომატური ნაბიჯების წილი, ხელის ჩარევების რაოდენობა, პლეიბუკის შეცდომები.
Chaos-smoke გამოშვებებში: დამოკიდებულების დეგრადაციამ არ უნდა „დაარღვიოს“ DR გზა.

T0: cut off the primary database (firewall drop)
T + 2m: GSLB shift 20% of traffic, then 100% at SLO_ok
T + 6m: checking business invariants and lag replication
T + 10m: post-drill: fixing RTA/RPA, playbook improvements

10) პლეიბუკი (კანონიკური შაბლონი)

yaml playbook: "dr-failover-region-a-to-b"
owner: "platform-sre"
rto: "15m"
rpo: "5m"
triggers:
- "health(region-a)==down"
- "slo_breach(payments)"
prechecks:
- "backup_catalog ok; last_restore_test < 30d"
- "pitr_window >= 7d"
steps:
- "Announce incident; open war-room; assign IC"
- "Freeze writes in region-a (flag write_readonly)"
- "Promote db-b to primary; verify replication stopped cleanly"
- "Shift GSLB 20%→50%→100%; monitor p95/error"
- "Enable compensations and re-drive queues"
validation:
- "Business invariants (balances, duplicate_checks)"
- "Synthetic tests green; dashboards stable 30m"
rollback:
- "If db-b unhealthy: revert traffic; engage restore from PITR T-Δ"
comms:
- "Status updates each 15m; external note if SEV1"

11) DR დაკვირვების მეტრიკა

Replica lag (წ.), RPO-drift (განსხვავება მიზნობრივ და რეალურ RPO შორის).
Restore SLI: ცივი/თბილი გამოჯანმრთელების დრო გარემოში.
Coverage: სერვისების% playbucks/bacps/PITR - N დღის განმავლობაში.
Drill score: ავტომატური ნაბიჯების წილი, RTA განაწილება, შეცდომების სიხშირე.
Immutabelity: bacap- ის% WORM/air-gapped.
ღონისძიების მეტრიკა: რიგის სიგრძე/სიჩქარე re-drive ფალოვერის შემდეგ.

12) ღირებულება და კომპრომისი

CapEx/OpEx: თბილი სტენდი იაფია, ვიდრე Active/Active, მაგრამ უფრო ძვირია, ვიდრე Pilot Light.
Egress: ინტერრეგიონალური/ცალმხრივი რეპლიკაცია ღირს ფული; ქეში/კომპრესია/ადგილობრივი ერთეულები.
RTO/RPO $ $: თითოეული „ცხრა“ ხელმისაწვდომობა და RPO წამი მრავალჯერადი ძვირია - შეთანხმდით ბიზნესთან.
მწვანე ფანჯრები: batch რეპლიკაცია - იაფი/„ მწვანე “საათებში.

13) უსაფრთხოება და შესაბამისობა

დაშიფვრა „მარტო“ და „ტრანზიტში“, ცალკეული KMS დომენები რეგიონებში.
Immutable bacaps, დაცვა ransomware- სგან: „3-2-1“ (3 ეგზემპლარი, 2 გადამზიდავი, 1 ოფლაინი), MFA-delete.
იურისდიქცია: geo-pinning PII- სთვის, ზურგჩანთების ლოკალიზაცია, იურიდიული ჰოლდი TTL- ზე.
წვდომა დროულად: დროებითი როლები DR ოპერაციებისთვის, აუდიტის ჟურნალი.

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

„ჩვენ მოგვიანებით დავწერთ გეგმას“ - DR ვარჯიშების გარეშე.
რეპლიკაცია ლოგიკური დაზიანებისგან დაცვის გარეშე - შეცდომა შაკიკურად გამრავლდება.
KMS/საიდუმლოებების ერთი რეგიონი - ფეილოვერი შეუძლებელია.
Bacaps რეგულარული აღდგენის გარეშე - „Shreedinger“ DR.
რეგიონებს შორის მჭიდრო კავშირშია სინქრონიზებული გარიგებები - კასკადის ლატენტობა/ვარდნა.
პრიორიტეტი არ არსებობს: ყველასთვის იგივე DR დონე (ძვირი და უსარგებლო).

15) არქიტექტორის ჩეკის სია

1. განსაზღვრულია RTO/RPO/RLO მომსახურებითა და სცენარებით?
2. მონაცემები კლასიფიცირებულია: ჭეშმარიტების წყარო, PITR/ფანჯარა, WORM/immutable?
3. შეირჩა DR (Backup/Restore, Pilot, Warm, A/P, A/A) პერ სერვისი?
4. ქსელი: GSLB/Anycast, სერთიფიკატები/გასაღებები ზღვარი, „read-only“ დროშები?
5. პროგრამა: idempotence, outbox/inbox, რომელიც ანაზღაურებს გარიგებებს?
6. IaC/GitOps/Policy as Code: ერთი დაწკაპუნება მეორე რეგიონის გასასვლელად?
7. სავარჯიშოები: გრაფიკი, KPI RTA/RPA, პოსტ-საგანმანათლებლო ოპერაციები?
8. მონიტორინგი: lag, RPO-drift, restore-SLI, drill-score, იმუნური ქუდები?
9. უსაფრთხოება/შესაბამისობა: KMS დომენები, იურისდიქციები, იურიდიული ჰოლდი?
10. ღირებულება: egress ბიუჯეტი, მწვანე ფანჯრები, ეკონომიკურად გონივრული დონე?

16) მინი რეცეპტები და ესკიზები

16. 1 PITR Postgres- ისთვის (იდეა):

bash base backup daily + WAL archive pg_basebackup -D/backups/base/$ (date +% F)
archive_command='aws s3 cp %p s3://bucket/wal/%f --sse'
restore pg_restore --time "2025-10-31 13:21:00Z"...

16. 2 დაცვა ლოგიკური დაზიანებისგან (დაკავებული შენიშვნა):

yaml replication:
mode: async apply_delay: "30m" # window to roll back on corruption

16. 3 ტრაფიკის შეცვლა (ფსევდო-API GSLB):

bash gslb set-weight api. example. com region-a 0 gslb set-weight api. example. com region-b 100

16. 4 ინვარიანტების შემოწმება ფეილოვერის შემდეგ (ფსევდო კოდი):

python assert total_balance(all_accounts) == snapshot_total assert no_duplicates(events_since(t_failover))

დასკვნა

DR არის ტექნიკური და ორგანიზაციული გადაწყვეტილებების მიღების უნარი უფრო სწრაფად, ვიდრე ზიანი იზრდება. შეადგინეთ რეალისტური RTO/RPO, შეარჩიეთ მზადყოფნის საკმარისი დონე, ავტომატიზაცია მოახდინეთ ინფრასტრუქტურასა და შემოწმებებზე, რეგულარულად გაიარეთ ტრენინგი და გაზომეთ ფაქტობრივი RTA/RPA. შემდეგ უბედური შემთხვევა გადაიქცევა არა კატასტროფად, არამედ პროგნოზირებადი შედეგის მქონე კონტროლირებად ინციდენტად.