برنامه بازیابی فاجعه

1) هدف، دامنه و اصول

هدف: اطمینان از بازیابی به موقع پلت فرم فناوری اطلاعات پس از بلایای (کسانی که، سایبر، فروشنده، ژئوپولیتیک) بدون نقض الزامات قانونی، قراردادها و انتظارات بازیکنان.
منطقه: محیط های تولیدی (مدار بازی، پرداخت، KYC/AML، ضد تقلب، فروشگاه های DWH/BI)، ادغام (PSP، KYC، CDN، استودیو/جمع آوری)، زیرساخت (cloud/K8s، شبکه ها، اسرار/کلید)، داده ها (پایگاه داده ها، فایل ها، سیاهههای مربوط).
اصول: اول ایمنی، به حداقل رساندن RTO/RPO، اتوماسیون و تکرارپذیری (IaC)، «قابلیت اثبات به طور پیش فرض»، تمرینات منظم.

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

2. 1 سطح انتقاد

ردیف 1 (حیاتی): پرداخت/نقدی، بازی های اصلی، ورود/احراز هویت، ICC/تحریم ها.
Tier-2: تجزیه و تحلیل زمان واقعی، بازاریابی/CRM، گزارش DWH.
Tier-3: پورتال داخلی، خدمات کمکی.

2. 2 اهداف

RTO - هدف زمان بازیابی

Recovery Point Objective (RPO) - از دست دادن زمان مجاز داده ها.
RTA (Recovery Time Actual )/RPA (Recovery Point Actual) - مقادیر واقعی در گزارش ها ثبت می شوند.
MTO/MBCO: حداکثر خرابی قابل تحمل/حداقل سطح خدمات قابل قبول (حالت تنزل).

• ردیف 1 - RTO ≤ 30-60 دقیقه، RPO ≤ 15 دقیقه ؛ - RTO 4 ، RPO 1 ؛ - RTO 24 ، RPO 24.

3) استراتژی DR و معماری

3. 1 توپولوژی ها

فعال فعال (چند منطقه): حداقل RTO/RPO، نیاز به ثبات و حل تعارض.
فعال در حالت آماده به کار (گرم/گرم/سرد): تعادل هزینه/سرعت.
جداسازی جغرافیایی داده ها و کلیدها: KMS/HSM در هر منطقه، BYOK، مسیرهای تکثیر مستقل.

3. 2 داده ها و پشتیبان گیری

PITR (بازیابی نقطه در زمان): سیاهههای مربوط به معاملات، فواصل بایگانی ≤ 5-15 دقیقه برای Tier-1.
عکس های فوری/پشتیبان گیری کامل: روزانه/ساعتی، ذخیره سازی با توجه به طرح 3-2-1 (3 نسخه، 2 رسانه، 1 آفلاین/خارج از سایت).
غیر قابل تغییر: قفل WORM/شی، زنجیره امضا/هش مصنوعات.
کاتالوگ بازیابی: موجودی پشتیبان، یکپارچگی، تاریخ انقضا، رمزگشایی تست.

3. 3 برنامه ها و ادغام

Statles Services - استقرار سریع از طریق IaC/CI

اجزای Statefull: عکس های فوری سازگار، ارکستراسیون دنباله راه اندازی.
یکپارچگی (PSP/KYC/aggregators): اعتبار دوگانه، نقاط پایانی عقب، وب سایت های امضا شده، کنترل تحویل مجدد (idempotency).

4) ترتیب بازیابی (runbook عمومی)

1. اعلام یک اسکریپت DR → تعیین DR فرمانده حادثه (DR-IC)، راه اندازی یک اتاق جنگ.
2. ارزیابی آسیب: مناطق آسیب دیده/زیر سیستم ها، RTA/RPA فعلی، تصمیم به فعال کردن feilover.
3. جداسازی/مهار: مسدود کردن علل اصلی (ACL های شبکه، اسرار، قطع اتصال ارائه دهنده).

• شبکه/اسرار/KMS →
• DB/خرک/کش →
• API/خدمات → جلو/CDN → ادغام خارجی.
• 5. بررسی یکپارچگی: شمارنده. مقادیر، درخواست های «خشک»، نمونه های بهداشتی.
• 6. آشتی مالی/بازی: آشتی پرداخت، شرط، تعادل، تکرار idempotent از معاملات.
• 7. ارتباطات: صفحه وضعیت، بازیکنان/شرکا/تنظیم کننده ها ؛ جدول زمانی به روز رسانی.
• 8. مشاهده و تثبیت: غیر فعال کردن تخریب به عنوان عادی سازی ادامه می یابد.
• 9. پس از مرگ: RCA، CAPA، به روز رسانی DRP.

5) کتابهای تخصصی (قطعه)

5. 1 فعال آماده به کار → آماده به کار

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 فساد DB/بازیابی از 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) یکپارچگی و آشتی داده ها

امور مالی: آشتی سپرده/پرداخت/کمیسیون، دوباره ارسال اطلاعیه ها و webhooks با deduplication (idempotency-کلید).
کانتور بازی: بازیابی کشورهای دور، تکرار شهرک در صورت لزوم، حفاظت در برابر اتهامات دو برابر/اتهامات.
Logs/audits: قبل/بعد از WORM log mapping, signatures/hashes, consistency reports.
DPO/گزارش انطباق: در صورت تاثیر PII، مقیاس ضبط، جدول زمانی و اطلاعیه ها.

7) DR برای فن آوری های کلیدی (مثال)

DBMS (رابطه ای): تکرار همزمان/ناهمزمان، اسلات WAL، سریع ترویج، standbys داغ.
NoSQL/caches: multicluster، TTL-disability، پر کردن سرد، رد نوشتن متقابل منطقه بدون حل تعارض.
صف/جریان: topicals آینه/خوشه، کنترل افست، deduplication مصرف کننده.
ذخیره سازی شی: نسخه، تکرار بانکر، موجودی شی و سیاست های نگهداری.
CI/CD/مصنوعات: کپی از ثبت، امضای مصنوعات، نسخه های آفلاین ظروف بحرانی.
اسرار/کلید: KMS در هر منطقه، کلید ریشه مستقل، شکستن شیشه با ورود به سیستم و TTL.

8) امنیت و حریم خصوصی در DR

اصل حداقل حقوق: دسترسی DR توسط نقش/پروفایل های فردی (JIT/PAM).
پشتیبان گیری غیر قابل تغییر: تست آفلاین/خارج از سایت، بازیابی و رمزگشایی.
پنجره های نظارتی: ضبط رویداد و تصمیم اطلاع رسانی (تنظیم کننده/بانک/PSP/کاربران) همراه با قانونی/DPO.
قابلیت ردیابی: ورود کامل فعالیت فرمان DR، امضای جدول زمانی.

9) تمرینات و انواع تست ها

خرید/نقد و بررسی: سند/نقش/تماس با نقد و بررسی (فصلنامه).
Tabletop: اجرای سناریوها در «خشک» با حل تعارض.
جزئی فنی: بازیابی یک سرویس/پایگاه داده واحد.
failover/switch-over کامل - انتقال ترافیک و داده ها به منطقه پشتیبان گیری.
Chaos-days (کنترل شده): تزریق خرابی/خرابی برای بررسی اتوماتیک.

هر تست → یک گزارش با RTA/RPA، لیست انحراف، CAPA و به روز رسانی DRP.

10) معیارها (KPI/KRI)

RTA/RPA در مقابل RTO/RPO (ردیف 1): 95٪ ≥ بازی.
پوشش تست DR: ≥ 2 کامل تست DR/سال + به طور منظم جزئی.
زمان اولین وضعیت: ≤ 15 دقیقه پس از اعلام DR.
آشتی صفر تفاوت: همه پول نقد و آشتی بازی بدون اختلاف.
یکپارچگی پشتیبان گیری: 100٪ از بازیابی نقطه در یک چهارم موفق هستند.
پیکربندی رانش: 0 رانش بین اولیه/ثانویه (مقایسه IaC).
امنیت در DR: فعالیت های 100٪ DR با ورود و تایید.

11) RACI (بزرگ شده)

12) چک لیست

12. 1 آمادگی DR

• DR تیم/فروشنده/تنظیم کننده اطلاعات تماس به روز شده
• تکرار سبز، PITR فعال، رمزگشایی تست پشتیبان گیری
• دسترسی JIT/PAM، شیشه ای تایید شده است
• playbooks جعلی و متغیرهای محیطی معتبر هستند
• PSP/KYC اعتبار دوگانه/Webhooks، مسیرهای جایگزین
• صفحه وضعیت/قالب پیام آماده

12. 2 در طول DR

• DR-IC اختصاص داده شده، اتاق جنگ باز، جدول زمانی رویداد
• به دلیل انزوا، برنامه نویسی، در حال اجرا runbooks
• بررسی یکپارچگی، آزمایش های بهداشتی، آزمایش های دود
• اولین به روز رسانی عمومی ≤ 15 دقیقه ؛ اطلاعیه ها به شرکا/تنظیم کننده ها در SLAs
• ضبط مصنوعات برای تحقیق

12. 3 بعد از دکتر

• آشتی کامل پول/بازی ها و مجلات
• پس از مرگ، RCA، CAPA با تاریخ و صاحبان
• DRP/BIA/تماس/IaC به روز رسانی
• رفع طرح مجدد

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: موجودی خدمات و وابستگی، طبقه بندی ردیف، اهداف RTO/RPO، انتخاب توپولوژی، گذرنامه DR.
هفته 3-4: پیاده سازی پشتیبان گیری/PITR/غیر قابل تغییر, تکرار مخفی/KMS, آماده سازی کتاب اجرا و وضعیت.
هفته 5-6: تست های فنی جزئی (پایگاه داده/کش/صف)، تبلت با توجه به سناریوهای PSP/KYC/منطقه.
هفته 7-8: سوئیچ کامل (در صورت امکان)، گزارش با RTA/RPA، CAPA، DRP به روز رسانی و طرح آزمون به طور منظم.

15) ادغام با دیگر بخش های ویکی

لینک به: BCP، ثبت ریسک، مدیریت حادثه، سیاست ورود (WORM)، TPRM و SLA، ISO 27001/27701، SOC 2، PCI DSS، RBAC/حداقل امتیاز، سیاست رمز عبور و MFA، مدیریت تغییر/انتشار.

TL ؛ دکتر متخصص

DRP کار = روشن RTO/RPO توسط Tier → معماری فعال فعال/آماده به کار + پشتیبان گیری تغییر ناپذیر/PITR → کتابهای قابل پخش و feilover → آشتی پول/بازی → تمرینات منظم و CAPAs. سپس هر شکست بزرگ به یک روش قابل کنترل با زمان بهبودی قابل پیش بینی و شگفتی صفر برای تنظیم کننده ها و بازیکنان تبدیل می شود.