چگونه DRP بنویسیم؟ راهنمای برنامه بازیابی از بحران برای IT

Disaster Recovery Plan یا DRP سندی نیست که فقط زمان Audit باز شود. در لحظه بحران باید آن‌قدر روشن باشد که تیم بداند چه چیزی را، با چه اولویتی و چگونه بازیابی کند.

Scope را مشخص کنید

DRP باید مشخص کند چه Site، Application، Database، Network و Serviceهایی پوشش داده می‌شوند. برنامه کلی و مبهم در بحران ارزش کمی دارد.

Dependency Map بسازید

سامانه بدون DNS، Identity، Network یا Database شاید قابل بازیابی نباشد. ترتیب Recovery باید بر اساس Dependency طراحی شود.

RTO و RPO را از کسب‌وکار بگیرید

اهداف بازیابی نباید فقط بر اساس توان فعلی زیرساخت نوشته شوند. نیاز Business از BIA می‌آید و Gap فنی باید آشکار شود.

Runbook عملی بنویسید

• Trigger فعال‌سازی DR
• نقش‌ها و تماس‌ها
• ترتیب Recovery
• Credential و دسترسی اضطراری
• Validation بعد از بازیابی
• Communication و Escalation

Backup با DR یکی نیست

Backup یکی از Controlهاست. DR شامل زیرساخت، Configuration، Network، Identity، Application و Data می‌شود. Backup بدون Restore Test تضمین Recovery نیست.

Exercise را برنامه‌ریزی کنید

Tabletop، Partial Failover و Full Exercise سطح‌های مختلف تمرین هستند. نتیجه باید Evidence، Finding و Action Plan تولید کند.

سناریو: خرابی Database

Runbook باید مشخص کند آخرین Replica یا Backup کجاست، چه کسی Failover را تأیید می‌کند، Application چگونه به Database جدید متصل می‌شود و چه Testی سلامت داده را تأیید می‌کند.

Lessons Learned را وارد چرخه کنید

اگر Exercise نشان داد Recovery بیشتر از RTO طول کشیده، این فقط یادداشت تست نیست؛ یک Gap است و باید Remediation ایجاد کند.

DRP در GRC

DRP می‌تواند به BIA، Risk، Control، Exercise و Action متصل شود. مقاله تفاوت BCM و DR جایگاه این برنامه را در مدل بزرگ‌تر توضیح می‌دهد.

سخن پایانی

DRP خوب در روز بحران قابل اجراست، نه فقط قابل خواندن. بهترین معیار کیفیت آن، نتیجه Exercise واقعی است.