استراتژی های DR و RTO/RPO

1) اصول اساسی

1. اهداف قبل از وسیله ابتدا RTO/RPO و سناریوهای بحرانی را فرموله می کنیم، سپس تکنولوژی را انتخاب می کنیم.

2. تقسیم بندی بر اساس اهمیت همه خدمات نیاز به «طلا» ؛ تقسیم بر اساس انتقاد تجاری

3. سازگاری، تکرار، تشخیص فساد و نقطه بازیابی مهم تر از سخت افزار است.
4. اتوماسیون و قابلیت اطمینان DR بدون IaC، تست های رگرسیون بازیابی و تله متری بی معنی است.
5. آموزه ها و شواهد یک برنامه بدون «روز بازی» منظم، توهم آمادگی است.
6. ایمنی و انطباق رمزگذاری، جداسازی، پشتیبان گیری WORM/تغییر ناپذیر، DPA/حوزه های قضایی.

2) شرایط و مکاتبات

RTO - زمان از لحظه رویداد تا زمانی که سرویس «عادی» بازگردانده شود.
RPO «سن» آخرین نقطه داده سالم در بازیابی است.
RLO (Recovery Level Objective): سطح عملکردی که باید بازسازی شود (حداقل سرویس قابل قبول).
MTD (حداکثر خرابی قابل تحمل) - آستانه ای که پس از آن کسب و کار آسیب غیر قابل قبول را متحمل می شود.
RTA/RPA (واقعی) - زمان واقعی/نقطه بازیابی از شیوه.

ارتباطات: RTO ≤ MTD ؛ RPA ≤ RPO شکاف بین اهداف و واقعیت موضوع پس از مرگ و بهبود است.

3) کلاس های استراتژی DR (سطح آمادگی)

قانون: حداقل سطح مناسب برای ریسک تجاری را انتخاب کنید.

4) سناریوهایی که ما از آن دفاع می کنیم

از دست دادن منطقه/ابر/مرکز داده (برق، شبکه، ارائه دهنده).
فساد داده ها/خطای اپراتور (حذف، کپی شکسته، فساد منطقی).
بدافزار/باج افزار.
نقص انتشار/پیکربندی (قطع جرم).
فروپاشی اعتیاد (KMS، DNS، اسرار، ارائه دهنده پرداخت).
رویدادهای حقوقی (مسدود کردن، ممنوعیت صادرات داده ها از حوزه قضایی).

برای هر سناریو، RTO/RPO، سطح DR، playbook، افراد مسئول را مشخص کنید.

5) استراتژی های داده (کلید RPO)

5. 1 پشتیبان گیری

کامل + افزایشی + سیاهههای مربوط به معامله (برای DB).
تغییر ناپذیر/WORM storages and offline copies («air-gapped»).
کاتالوگ پشتیبان گیری با ابرداده و امضای رمزنگاری ؛ تست برنامه ریزی شده بازیابی.

5. 2 تکرار

همزمان (RPO کم، ↑latentnost، خطر انتشار اسپویل).
ناهمزمان (تاثیر کم بر روی perf، RPO> 0 ؛ با کودک فاسد ترکیب کنید).
CDC (Change Data Capture) برای تکرار جریان و بازسازی وضعیت.

5. ۳ محافظت در برابر فساد منطقی

نسخه/» نقاط در زمان» (PITR) با یک پنجره ≥ N روز.
امضاهای ثابت (تعادل، مبالغ، chexums) تشخیص زودهنگام داده های «شکسته» هستند.
کانال های تکرار «آهسته» (تاخیر 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) برنامه، وضعیت، کش

لایه بدون حالت - مقیاس و راه اندازی مجدد در هر منطقه (تصویر/نمودار/مانیفست در Git).
وضعیت (DB/caches/kew): منبع حقیقت یکی از DB ها است ؛ کش ها و شاخص ها بیش از حد هستند.
Idempotence و دوباره درایو - تحویل مجدد از حوادث مجاز است; از outbox/inbox، dedup و نسخه ها استفاده کنید.

7) شبکه و نقطه ورود

GSLB/DNS-feilover: تاخیر/مبتنی بر سلامت، TTL کوتاه برای سقوط پنجره.
پروکسی Anycast/L7: IP واحد، مسیریابی بهداشت منطقه ای.
حوزه های منطقه ای و سیاست های قضایی (جغرافیایی برای 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: زیرساخت منطقه دوم = کد، استقرار «تک دکمه».
سیاست به عنوان کد: دروازه «هیچ DR manifests/پشتیبان گیری/هشدار - بدون انتشار».
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، افت منطقه، حد خروج ناگهانی.
فرکانس: سه ماهه برای ماموریت بحرانی ؛ هر شش ماه یک بار - برای بقیه.
معیارهای ورزش: RTA/RPA در مقابل اهداف، نسبت مراحل اتوماتیک، تعداد مداخلات دستی، خطاهای کتابچه راهنمای کاربر.
هرج و مرج دود در انتشار: تخریب وابستگی نباید «شکستن» مسیرهای 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

تاخیر ماکت (ثانیه)، RPO رانش (تفاوت بین هدف و RPO واقعی).
بازگرداندن SLI: زمان بهبودی سرد/گرم توسط محیط.
پوشش:٪ از خدمات با playbooks/پشتیبان گیری/PITR ≥ N روز.
نمره مته: نسبت مراحل اتوماتیک، توزیع RTA، میزان خطا.
غیر قابل تغییر:٪ از پشتیبان گیری در WORM/air-gapped.
معیارهای رویداد: طول صف/سرعت درایو مجدد پس از جعلی.

12) هزینه و تجارت آف

CapEx/OpEx: پایه گرم ارزان تر از Active/Active است، اما گران تر از نور خلبان است.
خروج: تکرار بین منطقه ای/بین ابر هزینه پول ؛ کش/فشرده سازی/تجمع محلی.
RTO/RPO در مقابل $: هر «نه» در دسترس بودن و یک دوم از RPO چندین برابر گران تر است - هماهنگ با کسب و کار.
پنجره های سبز: تکرار دسته ای - در ساعات ارزان/» سبز«.

13) ایمنی و انطباق

رمزگذاری «در حالت استراحت» و «در حال انتقال»، دامنه های KMS را بر اساس منطقه جدا می کند.
پشتیبان گیری غیر قابل تغییر، حفاظت از باج افزار: «3-2-1» (3 نسخه، 2 رسانه، 1 آفلاین)، MFA-حذف.
حوزه های قضایی: جغرافیایی برای PII، محلی سازی پشتیبان گیری، نگهداری قانونی در بالای TTL.
دسترسی به زمان: نقش موقت برای عملیات DR، ورود به سیستم حسابرسی.

14) ضد الگوهای

«بیایید بعداً یک برنامه بنویسیم» - DR بدون تمرین.
تکرار بدون محافظت در برابر فساد منطقی - بلافاصله خطا را چند برابر می کند.
یک منطقه KMS/اسرار - بدون feilover ممکن است.

پشتیبان گیری بدون بازیابی منظم - «Shredinger» دکتر

معاملات همزمان نزدیک بین مناطق، تأخیر/سقوط آبشار هستند.
بدون اولویت بندی: همان سطح DR برای همه چیز (گران و بی فایده).

15) چک لیست معمار

1. RTO/RPO/RLO تعریف شده توسط سرویس و سناریو ؟

2. داده های طبقه بندی شده: منبع حقیقت، PITR/پنجره، WORM/تغییر ناپذیر ؟

3. آیا DR (پشتیبان گیری/بازگرداندن، خلبان، گرم، A/P، A/A) در هر سرویس انتخاب شده است ؟

4. شبکه: GSLB/Anycast، گواهینامه ها/کلید ها با حاشیه، پرچم های فقط خواندنی ؟

5. برنامه: idempotence، outbox/inbox، معاملات جبران ؟

6. IaC/GitOps/سیاست به عنوان کد: یک کلیک بر روی نورد کردن منطقه دوم ؟

7. تمرین: برنامه، KPI RTA/RPA، فعالیت های پس از آموزش ؟

8. نظارت: تاخیر، RPO-رانش، بازگرداندن SLI، مته نمره، پشتیبان گیری تغییر ناپذیر ؟

9. امنیت/انطباق: دامنه های KMS، حوزه های قضایی، حقوقی ؟

10. هزینه: خروج از بودجه، پنجره های سبز، سطح اقتصادی صدا ؟

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 سوئیچینگ ترافیک (GSLB شبه API):

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

16. 4 بررسی ناوردا پس از feilover (pseudocode):

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

نتیجه گیری

DR توانایی تصمیم گیری فنی و سازمانی سریع تر از آسیب رشد می کند. RTO/RPO های واقع بینانه را شناسایی کنید، در دسترس بودن کافی را انتخاب کنید، زیرساخت ها و چک ها را خودکار کنید، به طور مرتب ورزش کنید و RTA/RPA های واقعی را اندازه گیری کنید. سپس حادثه به یک فاجعه تبدیل نمی شود، بلکه به یک حادثه کنترل شده با نتیجه قابل پیش بینی تبدیل می شود.