Avariya bilan tiklash stsenariylari

1) DR nima uchun kerak va qanday maqsad

Disaster Recovery (DR) - bu ofatlardan keyin xizmatlarni tiklash uchun arxitektura, jarayonlar va mashqlar to’plami (datacenter/mintaqaning ishdan chiqishi, ma’lumotlarning yo’qolishi, ommaviy konfiguratsiya xatolari). DRning maqsadi - mijozlarning ishonchini va tartibga soluvchiga muvofiqligini saqlab, nazorat qilinadigan qiymat va tavakkalchilikda maqsadli RTO/RPOni bajarish.

RTO (Recovery Time Objective): ruxsat etilgan toʻxtash vaqti.
RPO (Recovery Point Objective): maʼlumot yoʻqolishi (oxirgi konsistent nuqtadan vaqt).
RLO (Recovery Level Objective): birinchi bo’lib qaytadigan funktsional daraja (minimal hayotiy xizmat).

2) Tizimlarni tanqidiylik bo’yicha tasniflash

Tier 0 (hayotiy): to’lovlar, login, KYC, tranzaksiyalar yadrosi - RTO ≤ 15 daqiqa, RPO ≤ 1-5 daqiqa.
Tier 1 (yuqori): operatsion panellar, D-1 hisobotlari - RTO ≤ 1 soat, RPO ≤ 15-60 daqiqa.
Tier 2 (o’rta): bek-ofis, analitika near-real-time - RTO ≤ 4-8 soat, RPO ≤ 4-8 soat.
Tier 3 (past): tanqidiy yordamchi emas - RTO ≤ 24-72 soat, RPO ≤ 24 soat.

Har bir xizmatga servislar katalogida Tier + maqsadli RTO/RPO berish; qarorlar va byudjetlarni aynan ular bilan solishtirish.

3) Tahdidlar modeli va ssenariylar

Texnogen: AZ/mintaqa/provayder nosozligi, tarmoq/DNS degradatsiyasi, DB/omborxonalar nosozligi, ommaviy reliz xatosi.
Inson omili: noto’g’ri konfiklar/IaC, ma’lumotlarni o’chirish, kalitlarni buzish.
Tabiiy/tashqi: yong’in/suv toshqini, energiyaning uzilishi, huquqiy blokirovkalar.
Har bir kishi uchun - ehtimollik/impakt baholash, DR-stsenariy va pleybukka bog’lash.

4) DR arxitektura patternlari

1. Active-Active (Multi-Region): ikkala hudud ham trafikka xizmat qiladi.

Afzalliklari: minimal RTO/RPO, yuqori barqarorlik.
Kamchiliklar: ma’lumotlarning murakkabligi/konsistentligi, yuqori narx.
Qayerda: o’qish-og’ir, keshlanadigan yuklar, stateless-servislar, multi-master DB (nizolarning qat’iy qoidalari).

2. Active-Passive (Hot Standby): «issiq» passiv toʻliq isitilgan nusxani ushlab turadi.

RTO: daqiqa; RPO: daqiqa. Avtomatlashtirilgan failover va replikatsiyani talab qiladi.

3. Warm Standby: issiqlik resurslarining bir qismi, avariya paytida kattalashtirish.

RTO: o’nlab daqiqa; RPO: 15-60 daqiqa. Tejamkor, lekin uzoqroq.

4. Pilot Light: minimal «uchqun» (meta-maʼlumotlar/tasvirlar/skriptlar) + tezkor burilish.

RTO: soat; RPO: soat. Arzon, Tier 2-3 uchun mos keladi.

5. Backup & Restore: oflayn bekaplar + qoʻlda isitish.

RTO/RPO: soat-sutka. Faqat past tanqidiylik va arxivlar uchun.

5) Ma’lumotlar va muvofiqlik

• Sinxron - deyarli nol RPO, lekin ↑ yashirin/qiymat.
• Asinxron - yaxshi ishlash, RPO> 0 (jurnallar dumi).
• Muvofiqlik: modelni tanlang (strong/eventual/causal). To’lovlar uchun - qat’iy, tahlilchilar uchun - eventual.
• Kesmalar (snapshots): doimiy ravishda konsistent nuqtalarini yarating + jurnallarni saqlang (WAL/redo).
• Kross-mintaqaviy tranzaksiyalar: 2PC oldini olish; idempotent operatsiyalaridan foydalaning, deli-va-takrorlang (deduplikatsiya bilan retry), event sourcing.
• Navbatlar/shinalar: replikatsiya/ko’zgu, DLQ, buyurtma va idempotentlik.

6) Tarmoq, trafik va DNS

GSLB/Anycast/DNS: failover/failback siyosati, past TTL (lekin unchalik emas), bir nechta mintaqalardan health-checks.
L7-yo’naltirish: mintaqaviy xaritalar, degradatsiya ficha-bayroqlari (funksiyalarni cheklash).
Private-links/VPN: provayderlarga zaxira kanallar (PSP/KYC/CDN).
Rate limiting: qayta tiklanayotganda boʻrondan himoyalanish.

7) Stateful vs Stateless

Stateless skript/avtoskayl bilan koʻchiriladi; stateful ma’lumotlarning kelishilgan strategiyasini (replikatsiya, snapshotlar, reklama replikalari, kvorum) talab qiladi.
Kesh/sessiyalar: tashqi (Redis/Memcached) kross-mintaqaviy replikatsiya yoki jurnallar bo’yicha re-seed; sessiyalarni tokenlarda (JWT) yoki umumiy omborda saqlash.

8) DR triggerlari va avtomatlashtirish

SLO-gardreyllar va kvorum zondlari → avtomatik region-failover runbook.
Halokat paytida Change freeze: tegishli bo’lmagan relizlarni/migratsiyalarni to’sib qo’yamiz.
Infrastructure as Code: manifestlar boʻyicha stend-bai joylashtirish, dreyfni tekshirish.
Rol targ’iboti: avtomatik promote replika DB + writers/sirlarni bog’lash.

9) Kommunikatsiyalar va komplayens

War-room: IC/TL/Comms/Scribe; SEV bo’yicha yangilanishlar oralig’i.
Maqom-sahifa: ta’sir geografiyasi, ETA, aylanma yo’llar.
Tartibga solish: xabardor qilish muddatlari, ma’lumotlar xavfsizligi, evidence o’zgarmas saqlanishi.
Sheriklar/provayderlar: tasdiqlangan aloqalar, ajratilgan kanal.

10) DR testlari va mashqlari

Tabletop: stsenariy va yechimlarni muhokama qilamiz.
Game Day (steyj/prod-layt): AZ/mintaqalarning rad etilishiga taqlid qilish, provayderni uzib qo’yish, DNSni qayta tiklash.
Qayta tiklash testlari: vaqti-vaqti bilan bekaplarni izolyatsiyada tiklaymiz va yaxlitlikni tasdiqlaymiz.
Chaos/Failure injection: tarmoqning/uzellarning/bogʻlanishlarning boshqariladigan nosozliklari.
KPI mashqlar: erishilgan RTO/RPO, pleybuklar nuqsonlari, CAPA.

11) Moliya va strategiyani tanlash (FinOps)

Pasaytirilgan RPO/RTO uchun $ ni hisoblang: maqsad qanchalik past bo’lsa, kanallar, litsenziyalar, zaxiralar shunchalik qimmatroq bo’ladi.
Gibrid: Tier 0 - active-active/hot; Tier 1 — warm; Tier 2–3 — pilot/backup.
Maʼlumotlar qimmat: sovuq qatlamlar (arxiv/S3/GLACIER), inkremental snapshotlar, deduplikatsiyadan foydalaning.
DR-infra xarajatlari va sertifikatlari/litsenziyalarining vaqti-vaqti bilan ko’tarilishi.

12) DR etuklik metrikasi

Har bir Tier bo’yicha RTO (fakt) va RPO (fakt).
DR Coverage:% services bilan rasmiylashtirilgan stsenariy/pleybuk/test.
Backup Success & Restore Success: kundalik muvaffaqiyatlar va tekshirilgan tiklanishlar.
Time-to-Declare Disaster: failover haqida qaror qabul qilish tezligi.
Failback Time: normal topologiyaga qaytish.
Defect Rate Mashqlar: aniqlangan boʻshliqlar/mashqlar.
Compliance Evidence Completeness: artefaktlarning to’liqligi.

13) Chek-varaqlar

DRni joriy qilishdan oldin

• Xizmat katalogi Tier, RTO/RPO, qaramlik va egalarini o’z ichiga oladi.
• Tier va byudjet boʻyicha (AA/AP/WS/PL/BR) patterni tanlandi.
• Konsistentlik va replikatsiya to’g "risidagi bitimlar hujjatlashtirilgan.
• GSLB/DNS/marshrutlash va health-checks sozlandi va sinovdan o’tkazildi.
• Bekaplar, snapshotlar, o’zgartirish jurnallari - kiritilgan, restore-da tekshirilgan.
• DR pleybuklari va provayderlarning aloqalari.

Avariya vaqtida (qisqacha)

• SEV e’lon qilish va war-room yig’ish; relizlarni muzlatish.
• Zond kvorumini tekshirish; impakt/geografiyani qayd etish.
• Failover Runbook: trafik, DB-reklama, navbatlar, kesh.
• Degrade-UX/limitlarni kiritish; SLA bo’yicha yangilanishlarni e’lon qilish.
• Evidence (taymline, grafiklar, loglar, buyruqlar) ni yig’ish.

Avariyadan keyin

• SLO N oraliqlarini kuzatish; reja boʻyicha failbackni bajarish.
• AAR/RCA o’tkazish; CAPAni rasmiylashtirish.
• Pleybuklar, alerta katalizatorlari, DR test-keyslarini yangilash.
• Steykxolder/regulyatorlarga hisobot berish (agar kerak boʻlsa).

14) Namunalar

14. 1 DR-stsenariy kartochkasi (misol)

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 replika DB» (parcha)

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 mashqlari rejasi (qisqacha)

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) Anti-patternlar

Muntazam restore-testlarsiz «bekaplar bor».
Sirlar/endpointlar avtomatik ravishda almashtirilmaydi.
Qayta yetkazib berishda idempotentlik yo’qligi → dublikatlar/yo’qolgan tranzaksiyalar.
Tanazzulga uchragan mintaqalar uchun bir xil konfiklar.
«Noto’g’ri tashvish» qo’rquvi tufayli uzoq vaqt davom etdi.
Monoregional provayderlar (PSP/KYC) muqobilsiz.
Hech qanday failback rejasi yo’q - biz «abadiy» avariya topologiyasida yashaymiz.

16) Joriy etish yo’l xaritasi (6-10 hafta)

1. Ned. 1-2: Tier xizmatlarini tasniflash, maqsadli RTO/RPO o’rnatish, DR patternlarini tanlash.
2. Ned. 3-4: replikatsiyalar/backaplar, GSLB/DNS, promoushen-tartib-taomillarni sozlash; pleybuklar va runbook’i.
3. Ned. 5-6: birinchi DR-mashqlar (tabletop → stage), metrik va CAPA tuzatish.
4. Ned. 7-8: cheklangan trafikli prod-layt mashqlari; avtomatlashtirish failover.
5. Ned. 9-10: xarajatlarni optimallashtirish (FinOps), Tier 0 ni hot/AA ga o’tkazish, choraklik mashg’ulotlar va hisobotlar reglamenti.

17) Jami

Samarali DR - bu nafaqat orqada qolish. Bular kelishilgan arxitektura, failover/failback avtomatlashtirish, ma’lumotlar intizomi (idempotentlik/replikatsiya), mashg’ulotlar va shaffof kommunikatsiyalardir. RTO/RPO real bo’lganda, pleybuklar ishlab chiqilgan va mashg’ulotlar muntazam bo’lganda, falokat boshqariladigan hodisaga aylanadi, shundan so’ng xizmatlar tezda va oldindan aytib bo’lmaydigan darajada normal holatga qaytadi.