سناریوهای بازیابی فاجعه

1) چرا DR مورد نیاز است و هدف چیست

Disaster Recovery (DR) مجموعه ای از معماری ها، فرایندها و آموزش برای بازیابی خدمات پس از فاجعه (خرابی مرکز داده/منطقه، از دست دادن داده ها، خطاهای پیکربندی توده) است. هدف DR این است که برای رسیدن به RTOs هدف/RPOs در هزینه کنترل و خطر در حالی که حفظ اعتماد مشتری و انطباق قانونی.

Recovery Time Objective (RTO) - زمان مجاز برای بازیابی

بازیابی نقطه هدف (RPO) - از دست دادن داده ها مجاز (زمان از آخرین نقطه سازگار).
RLO (Recovery Level Objective): سطح عملکردی که باید اول بازگردد (حداقل سرویس قابل قبول).

2) طبقه بندی سیستم ها با انتقاد

ردیف 0 (حیاتی): پرداخت، ورود به سیستم، KYC، معاملات اصلی - RTO ≤ 15 دقیقه، RPO ≤ 1-5 دقیقه.
ردیف 1 (بالا): پانل های عملیاتی، گزارش D-1 - RTO ≤ 1 ساعت، RPO ≤ 15-60 دقیقه.
ردیف 2 (متوسط): دفتر عقب، تجزیه و تحلیل تقریبا در زمان واقعی - RTO ≤ 4-8 ساعت، RPO ≤ 4-8 ساعت.
ردیف 3 (کم): کمکی غیر بحرانی - RTO ≤ 24-72 ساعت، RPO ≤ 24 ساعت.

اختصاص ردیف + RTO/RPO هدف به هر سرویس در کاتالوگ خدمات ؛ تصمیمات و بودجه باید در برابر آنها بررسی شود.

3) مدل تهدید و سناریوها

انسان ساخته شده: شکست AZ/منطقه/ارائه دهنده، تخریب شبکه/DNS، شکست پایگاه داده/ذخیره سازی، اشکال انتشار جرم.
عامل انسانی: پیکربندی اشتباه/IaC، حذف داده ها، سازش کلیدی.
طبیعی/خارجی: آتش سوزی/سیل، قطع برق، انسداد قانونی.
برای هر - ارزیابی احتمال/تاثیر، لینک به سناریوی DR و playbook.

4) الگوهای معماری DR

1. Active-Active (Multi-Region): هر دو منطقه در خدمت ترافیک هستند.

مزایا: حداقل RTO/RPO، ثبات بالا.
معایب: پیچیدگی/سازگاری داده ها، قیمت بالا.
جایی که: خواندن سنگین، بارهای ذخیره شده، خدمات بدون حالت، چند استاد DB (قوانین درگیری سخت).

2. Active-Passive (Hot Standby): یک Passive داغ دارای یک کپی کاملا گرم است.

RTO: دقیقه; ر. پ: چند دقیقه. نیاز به شکست خودکار و تکرار.

3. آماده به کار گرم: بخشی از منابع گرم می شوند، مقیاس بندی در صورت تصادف.

RTO: ده دقیقه ؛ RPO: 15-60 دقیقه اقتصادی تر اما طولانی تر

4. نور خلبان: حداقل «جرقه» (ابرداده/تصاویر/اسکریپت) + گسترش سریع.

RTO: ساعت ؛ RPO: ساعت. ارزان، مناسب برای ردیف 2-3.

5. پشتیبان گیری و بازیابی: پشتیبان گیری آفلاین + گرم کردن دستی.

RTO/RPO: ساعت/روز. فقط برای انتقاد کم و آرشیو.

5) اطلاعات و سازگاری

• همزمان - تقریبا صفر RPO، اما ↑latentnost/stoimost.
• ناهمزمان - عملکرد بهتر، RPO> 0 (دم سیاهههای مربوط).
• سازگاری: یک مدل (قوی/نهایی/علی) را انتخاب کنید. برای پرداخت - به شدت، برای تجزیه و تحلیل - نهایی.
• عکس های فوری: ایجاد نقاط سازگار به طور منظم + سیاهههای مربوط به فروشگاه (WAL/redo).
• معاملات بین منطقه ای: اجتناب از 2PC ؛ استفاده از عملیات idempotent، deli-and-repeat (تکرار با deduplication)، sourcing رویداد.
• صف/اتوبوس: تکرار/معکوس، DLQ، سفارش و توانایی مصرف کنندگان.

6) شبکه، ترافیک و DNS

GSLB/Anycast/DNS: سیاست های شکست خورده/شکست خورده، TTL کم (اما نه خیلی زیاد)، بررسی سلامت از چندین منطقه.
مسیریابی L7: نقشه های منطقه ای، پرچم های تخریب (محدودیت عملکرد).
لینک های خصوصی/VPN: کانال های پشتیبان به ارائه دهندگان (PSP/KYC/CDN).
محدود کردن نرخ: حفاظت از طوفان در طول بازیابی.

7) Stateful در مقابل بی ثبات

بدون حالت توسط اسکریپت/autoscale انجام می شود ؛ stateful نیاز به یک استراتژی داده سازگار (تکرار، عکس های فوری، ارتقاء ماکت، حد نصاب).
کش/جلسات: خارجی (Redis/Memcached) با تکرار متقابل منطقه یا دوباره بذر توسط سیاهههای مربوط ؛ جلسات را در نشانه ها (JWT) یا ذخیره سازی مشترک نگه دارید.

8) DR triggers و اتوماسیون

SLO gardrails و quorum probes → یک runbook اتوماتیک منطقه شکست خورده.
تغییر یخ در صورت تصادف: انتشار/مهاجرت های نامناسب را مسدود کنید.
زیرساخت به عنوان کد: استقرار تظاهرات آماده به کار، بررسی رانش.
ارتقاء نقش: به صورت خودکار ترویج ماکت DB + نویسندگان/اسرار پانسمان.

9) ارتباطات و انطباق

اتاق جنگ: IC/TL/Comms/Scribe ؛ SEV فواصل به روز رسانی.
صفحه وضعیت: جغرافیای نفوذ، ETA، راه حل.
مقررات: مهلت اطلاع رسانی، امنیت داده ها، ذخیره سازی شواهد غیر قابل تغییر.
همکاران/ارائه دهندگان: مخاطبین تایید شده، کانال اختصاصی.

10) آزمایشات و تمرینات DR

Tabletop: بحث در مورد سناریو و راه حل.
روز بازی (مرحله/تولید نور): شبیه سازی شکست AZ/مناطق، خاموش کردن ارائه دهنده، تنظیم مجدد DNS.
بازیابی تست ها: به صورت دوره ای پشتیبان گیری را در انزوا و اعتبار یکپارچگی بازیابی کنید.
هرج و مرج/تزریق شکست: شبکه کنترل/گره/وابستگی شکست.
ورزش KPI: به دست آورد RTO/RPO، نقص playbook، CAPA.

11) مالی و انتخاب استراتژی (FinOps)

شمارش $ برای کاهش RPO/RTO: اهداف پایین تر، گران تر کانال ها، مجوزها، ذخایر.
ترکیبی: ردیف 0 - فعال فعال/گرم ؛ ردیف 1 - گرم ؛ ردیف 2-3 - خلبان/پشتیبان.
داده های گران قیمت: استفاده از لایه های سرد (بایگانی/S3/GLACIER)، عکس های فوری افزایشی، deduplication.
بررسی دوره ای هزینه های DR-infra و گواهینامه ها/مجوزها.

12) معیارهای بلوغ DR

RTO (واقعی) و RPO (واقعی) برای هر ردیف.
پوشش DR:٪ از خدمات با یک اسکریپت/playbook/test طراحی شده است.
Backup Success & Restore Success: موفقیت روزانه پشتیبان گیری و بازیابی اثبات شده.

زمان اعلام فاجعه: سرعت تصمیم گیری شکست خورده

زمان Failback به توپولوژی عادی باز می گردد.
تمرینات نرخ نقص: شکاف/آموزه های یافت شده.

کامل بودن شواهد انطباق

13) چک لیست

قبل از اجرای DR

• دایرکتوری سرویس شامل Tier، RTO/RPO، وابستگی ها و صاحبان است.
• الگوی انتخاب شده (AA/AP/WS/PL/BR) توسط ردیف و بودجه.
• توافقات سازگاری و تکرار مستند شده است.
• GSLB/DNS/مسیریابی و بررسی سلامت پیکربندی و آزمایش شده است.
• پشتیبان گیری، عکس های فوری، تغییر سیاهههای مربوط - فعال، بررسی برای بازگرداندن.
• playbooks DR و اطلاعات تماس ارائه دهنده به روز هستند.

در طول حادثه (به طور خلاصه)

• اعلام SEV و جمع آوری یک اتاق جنگ ؛ یخ آزاد کند.
• بررسی حد نصاب پروب; تاثیر/جغرافیا را ثبت کنید.
• اجرای Runbook Failover: ترافیک، ارتقاء DB، صف، کش.
• فعال کردن کاهش-UX/محدودیت ؛ انتشار به روز رسانی در SLA.
• جمع آوری شواهد (جدول زمانی، نمودار، سیاههها، دستورات).

بعد از حادثه

• SLO فواصل N را مشاهده کنید ؛ Failback را طبق برنامه اجرا کنید.
• انجام AAR/RCA ؛ موضوع یک کاپا
• به روز رسانی playbooks، کاتالیزور هشدار، موارد آزمون 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 «ترویج پایگاه داده ماکت» (قطعه)

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) ضد الگوهای

«پشتیبان گیری وجود دارد» بدون آزمون بازگرداندن منظم.
اسرار/نقاط پایانی به طور خودکار تغییر نمی کنند.
بدون idempotency → معاملات تکراری/از دست رفته در تحویل مجدد.
پیکربندی یکسان برای مناطق بدون پرچم ویژگی تخریب.
زمان طولانی برای اعلام برای ترس از «هشدار نادرست».
ارائه دهندگان Monoregional (PSP/KYC) بدون هیچ جایگزین.
هیچ برنامه شکست وجود ندارد - ما در یک توپولوژی اضطراری «برای همیشه» زندگی می کنیم.

16) نقشه راه پیاده سازی (6-10 هفته)

1. «ند». 1-2: طبقه بندی خدمات توسط Tier، تنظیم هدف RTO/RPO، انتخاب الگوهای DR.
2. «ند». 3-4: تنظیم تکرار/پشتیبان گیری، GSLB/DNS، روش های ارتقاء ؛ بازی ها و کتاب های اجرا و.
3. «ند». 5-6: اولین تمرین DR (tabletop → stage)، رفع معیارها و CAPA.
4. «ند». 7-8: چراغ راهنمایی با محدودیت ترافیکی ؛ اتوماسیون شکست خورده.
5. «ند». 9-10: بهینه سازی هزینه (FinOps)، انتقال Tier 0 به Hot/AA، تمرین سه ماهه و مقررات گزارش دهی.

17) خط پایین

DR موثر فقط در مورد پشتیبان گیری نیست. اینها معماری سازگار، اتوماسیون failover/failback، نظم داده (idempointency/replication)، آموزش و ارتباطات شفاف هستند. هنگامی که RTO/RPO ها واقعی هستند، playbooks کار می کنند و تمرینات منظم هستند، فاجعه به یک رویداد کنترل شده تبدیل می شود، پس از آن خدمات به سرعت و قابل پیش بینی به حالت عادی باز می گردند.