بازگشت از بحران یا Desaster Recovery Plan(DRP) یک برنامه مستند و ساختاریافته هست که مشخص میکنه یک سازمان درصورت بروز حادثه یا خطای پیش‌بینی نشده چطور میتونه در سریع‌ترین زمان ممکن به روال معمولِ خودش برگرده. هر سازمان که به مشتری های خودش ضمانتِ یک سرویس یا پشتیبانی میده نیازمند برنامه‌ای دقیق برای بازگشت از بحران هست.
این برنامه به سازمان کمک میکنه چطور مشکلاتی نظیر از دست رفتن داده‌ها درصورت بروز خطا یا وجود مشکل در فانکشنالیتیِ یک سرویس رو برطرف کنه و در اون باید برای هر level از محصول یا سرویس برنامه دقیق وجود داشته باشه.
برنامه گام به گام شامل اقدامات احتیاطی برای به حداقل رساندن آثار یک فاجعه هست تا سازمان بتونه به فعالیت خود ادامه بده یا به سرعت وظایف مهم ماموریت را از سر بگیره. به طور معمول ، برنامه بازگشت از بحران شامل تجزیه و تحلیل فرایندهای تجاری و نیازهای متداوم هست. قبل از ایجاد یک برنامه، یک سازمان اغلب تجزیه و تحلیل تأثیرات تجاری (BIA) و تحلیل ریسک (RA) را انجام میده و اهداف Recovery رو تعیین می کنه.
برخی از انواع حوادثی که معمولا سازمان‌ها برای اون برنامه‌ریزی میکنند رو با هم نگاه کنیم:
توی حوزه زیرساخت برای بازگشت از بحران؛ اولین مبحثی که باید بهش توجه کنیم Failover System یا سیستم بازگردانی هست.
سیستم بازگردانی یک فرآیند بکاپ‌گیری هست که درصورت بروز اشکال توی سیستم های اصلی؛ سرور‌ها؛ پایگاه‌داده ها؛ شبکه و سرویس‌ها رو به صورت اتوماتیک روی یک سیستم سالم سویچ میکنه. و معمولا روی سیستم‌هایی که نیاز به always-on accessibility دارند پیاده میشه.
به عنوان مثال اگه سرور اصلی توی دیتاسنتر دچار مشکل بشه با توجه به زمان‌بر بودن فرآیند ریکاوری میشه نتیجه گرفت توی این زمان سرور پشتیبان بلافاصله بعد از بروز مشکل باید مسئولیت میزبانی رو به عهده بگیره.
سیستم بازگردانی میتونه توی هرکدوم از اجزای یک سیستم به صورت مجزا هم پیاده بشه؛ مثلا برای storage یا برای پایگاه‌داده ها.
تصور کنید چهار وب‌سرور زیر بار سنگین ریکوئست داریم و ناگهان یکی از اونها دچار مشکل بشه؛مواردی که توی failover باید بررسی بشن: آیا load balancer میتونه واکنش درستی داشته باشه؟ یا اصلا سه سرور دیگه میتونن بار رو تحمل کنند یا اگه بار بین اونها تقسیم بشه بقیه سیستم های درگیر هم آسیب میبینن؟ آیاوب‌سرور خراب شده مجددا راه‌اندازی میشه یا نیاز به مداخله دستی داره؟ ایا سیستم اطلاع رسانی خودکار درست عمل میکنه؟
حالا اولین سوالی که برای هرشخص ممکنه پیش بیاد این هست که چطور مطمئن شیم Failover system که طراحی کردیم درست کار میکنه؟
متاسفانه تنها راهی که بشه مطمئن بود درصورت وقوع یک disaster یا فاجعه سیستم بازگردانی ما درست کار میکنه؛ شبیه سازی فاجعه است. یعنی بروز یک مشکل در Crazy Load به صورت دستی!
به عنوان مثال برای تست Failover روی storage؛ SAN یا Storage area network فضای دیسک هست که بین server ها به اشتراک گذاشته میشه و فایل سیستمِ سرور‌های مجازی روی اون قرار میگیرن.
اگه خواستین استرس کارتون رو با یه متخصص شبکه وزیرساخت مقایسه کنید خودتون رو تو لحظه‌ای قرار بدین که توی یک کلاستر با ۱۰۰ ترابایت فضا که ۷۰۰ تا VM روش داره کار میکنه و داره به ۵-۶ تا شرکت و ارگان سرویس میده؛ قراره برای تست Failover؛ نودِ اکتیوِ SAN رو از برق بکشید!! از لحظه ای که SAN اکتیو رو از برق می‌کشی دیگه هیچ کنترلی روی چیزی نداری و زیرساخت فقط میتونه ۳۰ تا ۴۰ ثانیه تحمل کنه تا SAN پَسیو وارد مدار بشه وگرنه تمام VM ها و ESXi ها آسیب میبینن و همه مسئولیتش با شماست. تا وقتی روی VMware تو Datastore یه فولدر بسازی و فایل آپلود کنی و بعد حذفش کنی تا مطمئن بشی نه تنها Failover شده، از اون مهم تر داره درست کار می‌کنن حدود دو دیقه زمان میبره که اگه از من بپرسید میگم قطعا عمر آدم رو کوتاه میکنه xD.
