آن‌چه باید یک کسب‌وکار از بازیابی پس از بحران (DRaaS) بداند

می‌توان گفت برای کسب‌وکارها و کاربران حرفه‌ای حوزه‌ی فناوری، روشن است که استراتژی بازیابی پس از بحران DRaaS یک راهکار مهم برای تداوم در روزهای حادثه‌های غیرمنتظره‌ شناخته می‌شود. آمارهای جهانی نشان می‌دهد که استفاده از Disaster Recovery به یک روند بین‌المللی مهم تبدیل شده است و کسب‌وکارها از آن به‌عنوان راهکاری برای تداوم در روزهای حادثه‌های غیرمنتظره استفاده می‌کنند. این راهکار در محصولات مختلفی مانند آبجکت استوریج، دیتابیس ابری، Cloud Security  و… خود را به‌ روش‌های گوناگونی نشان می‌دهد.

اما آن‌طرف ماجرا، وقتی یک کسب‌وکار به اهمیت استفاده از DRaaS در زنجیره‌ی ارایه‌ی خدماتش آگاه شد، چگونه می‌تواند برای بهره‌مندی از آن اقدام کند و شرکت‌های ارایه‌دهنده‌ی این راهکار برای ساده‌سازی استفاده از DRaaS باید چه پیشنهادهایی داشته باشند؟ و درنهایت چه مسیر گام‌به‌گامی برای بهره‌مندی از چارچوب‌های استاندارد (Well-Architected Framework) وجود دارد؟ برای پاسخ به همه‌ی این پرسش‌ها نیاز است که یک برنامه‌ی منسجم برای استفاده از «بازیابی پس از بحران» یا همان DRP تعریف کرد. Disaster Recovery Plan همان برنامه‌ی منسجمی است که به کسب‌وکارها کمک می‌کند تا از راهکار Disaster Recovery استفاده کنند.

 در ادامه مهم‌ترین گام‌های استفاده از DRP در سازوکار راهکار Disaster Recovery آروان‌کلاد خواهد آمد:

 گام اول: آمادگی ذهنی کسب‌وکار و ذی‌نفعان مهم

آموزش و آگاهی‌رسانی، نخستین گام برای کسب‌وکارها در آغاز استفاده از راهکار DRaaS است؛ به این ترتیب،  آن‌ها -فارغ از نوع صنعت و اندازه‌شان- باید مطمین شوند که همه‌ی کارکنان از نقش خود در برنامه DRP آگاه هستند. این مساله تا آن‌جا مهم است که اختلال‌های عملیاتی و مالی را کاهش می‌دهد؛ هرچه این آگاهی بیش‌تر باشد، احتمال اختلال‌ها کم‌تر و درنهایت به حفظ اعتبار و اعتماد به کسب‌وکارها کمک می‌کند.

گام دوم: آگاهی نسبت به نیازهای کسب‌وکار در DRaaS

کسب‌وکارها در گام دوم این برنامه، باید نسبت به نیازهای‌شان در استفاده از راهکار «بازیابی پس از بحران» شفاف باشند. به این معنا که بدانند به‌طور دقیق از Disaster Recovery چه می‌خواهد؟ پس این گام، دو سوی کلی دارد: یک سو؛ نقش یک شرکت ارایه‌دهنده‌ی محصولات ابری و در سوی دیگر؛ نقش کسب‌وکارهایی که می‌خواهند از DRaaS استفاده کنند:

• کسب‌وکارهای ارایه‌دهنده‌ی خدمات ابری مانند آروان‌کلاد، مسوولیت پایداری زیرساخت‌های فیزیکی و نرم‌افزاری ابر را در این زنجیره به‌عهده دارند. به‌علاوه، مواردی مانند سلامت دیتاسنترها، پایداری شبکه، تامین برق و امنیت فیزیکی تجهیزات را هم در تعهدات‌شان تعریف می‌کنند.

• کسب‌وکارها هم برای بهره‌مندی از خدمات DRaaS باید نوعی معماری مقاوم برای برنامه‌های خود بر بستر زیرساخت ابری را تهیه کنند؛ مواردی مانند پشتیبان‌گیری منظم، انتخاب استراتژی DR مناسب برای هر سرویس و آزمون دوره‌ای از آن‌ها. به‌علاوه، این کسب‌وکارها باید به دو پرسش مهم هم پاسخ دهند: برای بازیابی داده‌ها تا چه میزان محدودیت زمانی دارند و تا کجا حاضرند که ریسک از دست دادن اطلاعات را بپذیرند؟ این دو هدف، هزینه‌ و پیچیدگی برنامه‌ریزی و استراتژی‌ DR کسب‌وکارشان را تعیین می‌کند.

یک نمونه از نوع انتخاب استراتژی‌های DRaaS در این جدول آمده است:

درباره‌ی تصمیم‌گیری این مساله (DRP) باید در نظر داشت که هرچه RPO و RTO سخت‌گیرانه‌تر (یعنی نزدیک‌تر به صفر) باشند، استراتژی کسب‌وکار پیچیده‌تر و هزینه‌ی پیاده‌سازی و نگهداری آن نیازمند هزینه‌ی بیش‌تری خواهد بود.

گام سوم: نوشتن گام‌به‌گام نقشه‌ی DR کسب‌وکار

۱-تعیین اهمیت نقش کسب‌وکار: پیش از طراحی و تصمیم‌گیری درباره‌ی برنامه‌ی DR کسب‌وکارتان باید نقشه‌ای تاثیر کسب‌وکار (Business Impact Analysis) سازمان‌تان داشته‌ باشید؛ یعنی به این نکته پاسخ داده باشید که کدام‌یک از فرآیندها برای کسب‌وکارتان حیاتی‌ترین است؟ برای نمونه، فرآیند تراکنش‌ها، جزو ویژگی‌های حیاتی یک کسب‌وکار مالی و بانکی به‌شمار می‌آید و این کسب‌وکارها نمی‌توانند ریسک توقف ثانیه‌ای این نوع خدمات‌شان را بپذیرند.

۲-اولویت‌بندی سرویس‌های کسب‌وکار: سرویس‌هایی که برای کسب‌وکارتان بیش‌ترین اهمیت را دارد در سه بخش «حیاتی»، «مهم» و «غیرضروری» دسته‌بندی و برای هر کدام از آن‌ها یک هدف واقع‌بینانه از  RTO و RPO مشخص کنید. در ادامه، نوعی راهنمایی از شیوه‌ی اولویت‌بندی محصولات خواهد آمد:

• حیاتی (Tier ۱): محصول/سرویسی که نباید حتا یک دقیقه قطع شود. (مانند درگاه پرداخت برای کسب‌وکارهای مالی و بانکی).

• مهم (Tier ۲): محصول یا سرویسی که قطع شدنش ایرادی ندارد، اما باید در طول نیم‌ساعت به چرخه‌ی ارایه‌ی خدمت بازگردد. (مانند پنل مدیریت درون‌ سازمان).

• غیرضروری (Tier ۳): محصول یا سرویسی که وصل شدن آن می‌تواند با تاخیر چند هفته‌ای باشد. (مانند سامانه‌ی آرشیو سازمانی).

سپس محصولات‌تان را براساس شاخص RPO و RTO تقسیم‌بندی کنید. همان‌طور که بالاتر درباره‌ی تعریف این دو شاخص توضیح داده شده بود، باید در نظر بگیرید که می‌خواهید کدام محصول‌تان با چه تاخیر و میزان احتمالیِ از دست رفتن داده‌ها همراه باشد؟ یا کدام محصول بدون از دست رفتن داده‌ها عمل کند؟

هم‌چنین پس از اولویت‌بندی بالا، نوع پیاده‌سازی بر اساس سرویس را هم تعیین کنید:

• برنامه‌های بدون حالت Stateless: این برنامه‌ها هیچ اطلاعاتی از Session کاربر را نگه نمی‌دارند جابه‌جایی ترافیک برای‌شان بسیار آسان است (مانند یک ماشین حساب ساده).
• برنامه‌های با حالت Stateful: این برنامه‌ها اطلاعات کاربر را ذخیره می‌کنند (مانند سبد خرید کاربر). برای این برنامه‌ها باید راهی برای کپی کردن یا اشتراک‌گذاری اطلاعات سبد خرید بین دو دیتاسنتر تعریف شود  (مانند یک حافظه‌ی Cache توزیع‌شده).
• پایگاه‌های داده  Databases: این بخش همیشه پیچیده‌ترین است. باید تصمیم بگیرید:
  • همگام‌سازی هم‌زمان (Synchronous): یعنی RPO صفر است اما ممکن است سایت کمی کند شود.
  • همگام‌سازی ناهم‌زمان (Asynchronous): یعنی سایت سریع کار می‌کند، اما ممکن است داده‌های چند ثانیه اخیر از دست بروند.

۳- انتخاب معماری DRaaS برای هر محصول: درنهایت هم یکی از معماری‌های DRaaS با توجه به استراتژی مناسب براساس هدف‌های RTO/RPO محصولا‌ت‌تان را انتخاب کنید:

راهنمای نوشتن برنامه‌ی DRaaS در آروان‌کلاد

• آیا سرویس‌های کلیدی ما شناسایی و اولویت‌بندی شده‌اند؟
• آیا هدف‌های زمانی (RTO/RPO) برای هر کدام از محصولات تعریف شده است؟
• آیا پشتیبان‌گیری (Backup) به‌شکل منظم و خودکار انجام می‌شود؟
• آیا پشتیبان‌گیری در برابر دسترسی‌های غیرمجاز، رمزنگاری شده‌اند؟
• آیا پشتیبان‌گیری در یک دیتاسنتر به‌‌طور کلی مجزا (یعنی در یک منطقه‌ی جغرافیایی دیگر آروان‌کلاد) نگهداری می‌شوند؟
• آیا پیش از این، فرآیند بازگردانی داده (Restore) را آزمایش کرده‌ایم؟
• آیا یک دفترچه‌ی راهنمای گام‌به‌گام (Runbook) برای تیم‌های فنی در زمان بحران داریم؟
• آیا ابزاری برای تشخیص فوری قطعی (مانیتورینگ) داریم؟ 
• آیا فرآیند سوییچ (Failover) به سایت پشتیبان، تا جای ممکن، خودکار شده است؟
• آیا برنامه‌ی مشخصی برای بازگشت به سایت اصلی (Failback) پس از رفع بحران داریم؟

گام چهارم: نقش آروان‌کلاد در پیاده‌سازی معماری‌ DRaaS

کسب‌وکارها و کاربرانی که می‌خواهند از DRaaS آروان‌کلاد استفاده کنند باید از میان چهار معماری کلی در پیاده‌سازی DRaaS استراتژی مرتبط با اولویت‌هایشان را انتخاب کنند. استراتژی‌های چهارگانه‌ی زیر به‌ترتیب هزینه، سرعت و پیچیدگی مرتب شده‌اند و به شما در انتخاب دقیق‌تر کمک می‌کنند:

استراتژی اول: پشتیبان‌گیری و بازیابی (Backup and Restore)

این استراتژی، ارزان‌ترین روش در انواع راهکارهای DRaaS است و شبیه داشتن یک حافظه External Hard Drives عمل می‌کند. در وضعیت اجرا هم هیچ زیرساخت دومی پیش از این مرحله، روشن نیست. پس در زمان حادثه‌، ابتدا باید سرورها را بسازیم، سپس پشتیبان‌ها را روی آن‌ کپی کنیم.

 این استراتژی برای سرویس‌هایی مناسب است که قطع شدن طولانی برای‌شان مشکل جدی ایجاد نمی‌کند (مانند آرشیو داده‌های قدیمی). به این ترتیب این استراتژی در شاخص‌های RTO / RPO در وضعیت «بسیار طولانی» قرار دارد؛ یعنی زمان بازیابی در این استراتژی، چیزی میان چند ساعت‌ تا چند روز است.

در فرآیند بازیابی (Failover) هم ساختن سرور جدید (از روی اسنپ‌شات)، دانلود داده‌ها (از Object Storage آروان‌کلاد) و درنهایت تغییر آدرس اینترنتی (DNS) به سرور جدید انجام می‌شود.

 استراتژی دوم: پایلوت لایت (Pilot Light)

این استراتژی شبیه داشتن یک کامپیوتر خاموش اما با هارد روشن است. آروان‌کلاد در این نوع استراتژی، در منطقه‌ (Regen) دوم فقط بخش حیاتی (به‌طور معمول دیتابیس‌ها) را روشن نگه می‌دارد و داده‌ها به‌طور مداوم به آن فرستاده می‌شوند. به این ترتیب در این وضعیت، سرورهای دیگر خاموش می‌مانند.

این روش برای برنامه‌های مهم درون‌سازمانی که می‌توانند چند ساعت قطع باشند، مناسب است. هم‌چنین در این استراتژی، وضعیت شاخص‌های RTO / RPO از ده‌ها دقیقه تا چند ساعت تاخیر را ثبت می‌کنند.

فرآیند بازیابی (Failover) در این استراتژی به این شکل است که سرورهای خاموش، روشن می‌شود، قدرت (منابع) سرورها را به بیش‌ترین حالت خودشان رسانده می‌شوند، دیتابیس پشتیبان فعال می‌شود و ترافیک به سمت آن هدایت می‌شود.

 استراتژی سوم: آماده‌باش گرم (Warm Standby - Active/Passive)

این وضعیت شبیه داشتن یک کامپیوتر روشن، اما کم‌مصرف است؛ یعنی یک کپی کامل از سایت کسب‌وکارتان به‌شکل همیشگی اما با منابع کم‌تر (حدود نیمی از ظرفیت) روشن می‌ماند و  داده‌ها به‌شکل Real-Time کپی می‌شوند.

 این وضعیت برای فروشگاه‌های آنلاین یا APIهای مهم که نمی‌توانند بیش‌تر از چند دقیقه قطع باشند، مناسب است. وضعیت این استراتژی در شاخص‌های RTO / RPO از چند دقیقه تا یک ساعت تعریف می‌شود.

به‌علاوه، فرآیند بازیابی Failover هم در این شاخص، به‌شکل خودکار عمل می‌کند؛ یعنی قطعی سرویس از سمت لودبالانسر (Load Balancer) آروان‌کلاد تشخیص و ترافیک به سایت پشتیبان هدایت می‌شود. سپس یک دستور خودکار، منابع سرورهای پشتیبان را به ظرفیت کامل می‌رساند.

 استراتژی چهارم: چندشهری/ چندمنطقه‌ای (Multi-Site - Active/Active)

گران‌ترین و سریع‌ترین روش، شبیه داشتن دو فروشگاه به‌طور کامل یکسان است. در این استراتژی هر فروشگاه به‌طور هم‌زمان به مشتری‌های‌شان سرویس می‌دهند. این استراتژی برای سرویس‌های حیاتی مانند درگاه‌های پرداخت (با قطعی صفر) مناسب است. بنابراین وضعیت شاخص RTO / RPO هم در این استراتژی نزدیک به صفر است.

به‌علاوه، فرآیند بازیابی (Failover) در این استراتژی به‌شکل کامل آنی و نامحسوس عمل می‌کند؛ یعنی اگر یک دیتاسنتر از کار بیافتد، شبکه‌ی توزیع محتوا (CDN) یا لودبالانسر جغرافیایی آروان‌کلاد، همان لحظه کاربران را به دیتاسنتر دیگر هدایت می‌کند و کاربر به‌طور کلی متوجه قطعی نمی‌شود.

خلاصه‌ای از مهم‌ترین شاخص‌های تعیین‌کننده‌ی این استراتژی‌ها در جدول زیر آمده است:

گام پنجم: آزمون، خودکارسازی و مدیریت

پس از تمام این مراحل و برای آن‌که مطمین شویم این برنامه یک راهکار اجرایی است، باید همیشه آن را تمرین کرد:

• آزمون منظم (DR Drills): باید به‌شکل دوره‌ای برای نمونه در هر فصل، فرآیند بازیابی واقعی را شبیه‌سازی کنیم. این کار مانند تمرین فرود اضطراری هواپیما است؛ نقاط ضعف پیدا می‌شود و مطمین خواهید شد که تیم‌تان آماده است.
• خودکارسازی: تا جایی که می‌توانید، همه‌ی مراحل (پشتیبان‌گیری، سوییچ کردن، برگرداندن) را با استفاده از API یا ابزارهای مدیریت زیرساخت (مانند Terraform) خودکار می‌کنیم تا خطای انسانی کاهش یابد و RTO (زمان بازیابی) سریع‌تر شود.
• برنامه‌ی بازگشت به حالت عادی (Failback): بعد از آن‌که بحران اصلی تمام شد، باید با احتیاط به سایت اصلی برگردیم. این فرآیند شامل کپی کردن تمام داده‌های جدیدی است که در سایت پشتیبان، تولید شده است. پس باید این بازگشت به سایت اصلی و سپس هدایت تدریجی ترافیک را در این مرحله تمرین کنیم.

آروان‌کلاد در تمام این مراحل و جزییات مسیر انتخاب اولویت‌ها و استراتژی DRaaS همراه‌تان است تا بتوانید برنامه‌یDRP شخصی‌سازی‌شده‌ی کسب‌وکارتان را بسازید و اجرایی کنید. برای استفاده از راهکار بازیابی پس از بحران آروان‌کلاد به این لینک بروید.