Business Continuity & Disaster Recovery

بعد از بحران، فقط روشن شدن سرورها کافی نیست

تداوم کسب‌وکار یعنی بدانیم اگر یک سرویس، سایت یا بخشی از زیرساخت از دسترس خارج شد، چه چیزی باید ادامه پیدا کند، با چه داده‌ای، در چه زمانی و با چه ترتیبی. DR بخشی از این تصویر است؛ نه کل آن. معماری باید برای لحظه بحران، مسیر بازیابی و بازگشت کنترل‌شده به وضعیت عادی از قبل برنامه داشته باشد.

درخواست جلسه فنی راهکارهای Backup

چه چیزی باید قبل از بحران روشن باشد؟

اگر سرویس اصلی از دسترس خارج شد، تصمیم بعدی چیست؟

RPO و RTO واقعی چقدر است؟
سرویس از کدام سایت ادامه پیدا می‌کند؟
Replica و Backup چقدر به‌روز هستند؟
چه چیزی باید اول بازیابی شود؟
Failover دستی است یا خودکار؟
بازگشت به سایت اصلی چطور انجام می‌شود؟

Backup، DR و Business Continuity یکی نیستند

Backup داده را نگه می‌دارد؛ DR سرویس را برمی‌گرداند؛ تداوم کسب‌وکار می‌پرسد عملیات چطور ادامه پیدا کند

ممکن است Backup سالم باشد اما بازگرداندن چند ترابایت داده ساعت‌ها طول بکشد. ممکن است سایت DR آماده باشد اما وابستگی یک سرویس مهم فراموش شده باشد. یا همه چیز از نظر فنی برگردد، اما تیم عملیات نداند کدام فرایند باید اول از سر گرفته شود. به همین دلیل این سه موضوع باید کنار هم طراحی شوند.

اجزای اصلی راهکار

یک برنامه DR واقعی فقط یک سایت دوم نیست

RPO و RTO واقعی

عددها باید بر اساس نیاز سرویس تعیین شوند، نه صرفاً بر اساس توان محصول. یک سرویس ممکن است چند دقیقه تحمل از دست رفتن داده داشته باشد و سرویس دیگر چند ساعت.

Replication و Data Protection

Replica برای ادامه سریع سرویس مفید است، اما جای Backup مستقل را نمی‌گیرد. هرکدام نقش متفاوتی در Recovery دارند.

سایت پشتیبان

محل سایت دوم، ظرفیت آن، Network، دسترسی به Storage و فاصله جغرافیایی باید با نوع بحران‌هایی که قرار است پوشش دهد هماهنگ باشد.

ترتیب بازگشت سرویس‌ها

همه سرویس‌ها ارزش و اولویت یکسان ندارند. باید مشخص باشد کدام سرویس، Database، DNS، Network یا Application باید زودتر برگردد.

Failover و Failback

انتقال به سایت پشتیبان نصف مسیر است. بازگشت امن به سایت اصلی، Sync داده و کنترل تغییرات بعد از بحران هم باید از قبل طراحی شوند.

تست و Runbook

سناریویی که هیچ‌وقت تست نشده، در روز بحران هنوز فقط یک فرض است. Runbook، نقش افراد و تست دوره‌ای بخش اصلی راهکارند.

سناریو قبل از ابزار

اول باید بدانیم با چه نوع خرابی‌ای طرف هستیم

خرابی یک VM با از دسترس خارج شدن Storage، قطع ارتباط بین دو سایت یا از دست رفتن کامل یک دیتاسنتر یکسان نیست. هر سناریو مسیر بازیابی، ابزار و زمان متفاوتی می‌خواهد. طراحی DR باید این تفاوت‌ها را صریح ببیند.

سناریوهایی که معمولاً بررسی می‌کنیم

خرابی یک Host یا Cluster
از دسترس خارج شدن Storage
قطع ارتباط Network یا WAN
خرابی یا آلودگی داده
حمله سایبری و نیاز به Recovery امن
از دسترس خارج شدن کامل یک سایت

لایه‌های معماری

DR خوب حاصل کار هماهنگ چند لایه است

اگر Network آماده نباشد، Replica به‌تنهایی کافی نیست. اگر Identity و DNS در دسترس نباشند، Application ممکن است بالا بیاید اما کار نکند. اگر Backup در همان دامنه حادثه باشد، Recovery امن زیر سؤال می‌رود.

Compute و Virtualization

ظرفیت سایت پشتیبان، نحوه انتقال Workloadها و وابستگی‌های Hypervisor یا Private Cloud باید مشخص باشند.

راهکارهای VCF ←

Network و Security

Routing، DNS، Firewall Policy، Segmentation و ارتباط کاربران با سایت دوم باید بخشی از سناریوی Failover باشند.

امنیت شبکه ←

Backup و Recovery

Backup برای سناریوهایی لازم است که Replica کافی نیست؛ از خرابی منطقی و حذف داده تا حمله سایبری و نیاز به نسخه سالم‌تر.

راهکارهای Backup ←

نحوه شروع پروژه

قبل از طراحی سایت DR، سرویس‌های حیاتی و وابستگی‌هایشان را مشخص می‌کنیم

ساخت سایت دوم بدون شناخت سرویس‌ها می‌تواند هزینه زیادی ایجاد کند اما در بحران جواب دقیقی ندهد. مسیر را از Business Impact، وابستگی سرویس‌ها و RPO/RTO شروع می‌کنیم و بعد به معماری و فناوری می‌رسیم.

۰۱

Business Impact

سرویس‌های حیاتی و هزینه یا اثر توقف آن‌ها مشخص می‌شود.

۰۲

RPO / RTO

هدف بازیابی برای هر سرویس بر اساس نیاز واقعی تعریف می‌شود.

۰۳

Architecture

Replication، Backup، Network، سایت دوم و Runbook کنار هم طراحی می‌شوند.

۰۴

Test

سناریوی Failover و Recovery در عمل تست و مستند می‌شود.

اگر فردا یکی از سرویس‌های اصلی متوقف شود، مسیر برگشت برایتان روشن است؟

می‌توانید معماری فعلی، سرویس‌های حیاتی و نگرانی اصلی درباره Recovery را با تیم فنی راگا مطرح کنید. هدف جلسه اول این است که مشخص شود کجای مسیر بازیابی هنوز مبهم یا پرریسک است.

درخواست جلسه فنی