دیتاسنتر دوم داریم و باید بدانیم هنگام بحران چه چیزی به آن منتقل می‌شود

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

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

سایت دوم با سرویس دوم تفاوت دارد

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

به همین دلیل، برنامه بازیابی باید واحد آن را «سرویس کسب‌وکاری» در نظر بگیرد. هر سرویس مجموعه‌ای از برنامه، داده، زیرساخت و فرایند انسانی است. وقتی این مجموعه به‌طور کامل در مقصد تعریف شود، تیم می‌تواند ظرفیت و ترتیب لازم را محاسبه کند.

مدیر بحران باید بداند کدام صف زودتر حرکت می‌کند

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

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

RTO و RPO را از زبان کسب‌وکار بپرسیم

RTO می‌گوید یک خدمت حداکثر چه مدت می‌تواند متوقف بماند. RPO نشان می‌دهد سازمان حداکثر چه مقدار از داده‌های جدید را می‌تواند از دست بدهد. این دو عدد را نباید تیم زیرساخت به‌تنهایی انتخاب کند. مالک سرویس باید اثر هر بازه را توضیح دهد و مدیریت هزینه رسیدن به آن را بپذیرد.

اگر واحد مالی توقف دو ساعته را غیرقابل قبول می‌داند، طرحی که بازیابی آن هشت ساعت طول می‌کشد پاسخ‌گو نیست. اگر از دست‌رفتن پانزده دقیقه تراکنش قابل قبول نیست، Replication روزانه کافی نخواهد بود. عددهای آرمانی نیز بی‌هزینه نیستند؛ هر کاهش در RTO یا RPO ممکن است ظرفیت، ارتباط، مجوز و عملیات بیشتری بخواهد.

نقشه وابستگی‌ها مسیر حرکت را می‌سازد

تیم برنامه مالی را در مقصد روشن می‌کند، اما ورود کاربران شکست می‌خورد. سرویس هویت در سایت اصلی مانده است. پس از انتقال هویت، نام دامنه داخلی پاسخ نمی‌دهد. این زنجیره نشان می‌دهد ترتیب بازیابی باید بر پایه وابستگی باشد، نه صرفاً اهمیت ظاهری ماشین‌ها.

برای هر خدمت، ورودی‌ها و خروجی‌ها ثبت می‌شوند: هویت، DNS، NTP، پایگاه داده، صف پیام، فایل مشترک، API بیرونی، گواهی، فایروال و ابزار مانیتورینگ. سپس وابستگی‌های مشترک مشخص می‌شوند. معمولاً چند سرویس پایه وجود دارند که باید پیش از بیشتر سامانه‌ها فعال شوند.

داده مقصد باید قابل استفاده باشد

داشتن Replica یا بکاپ به معنی آماده‌بودن داده نیست. باید معلوم باشد آخرین نقطه سالم کدام است، آیا Replication خطا یا آلودگی را نیز منتقل کرده و چگونه سازگاری پایگاه داده تأیید می‌شود. در حمله باج‌افزاری، انتقال خودکار تغییرات می‌تواند نسخه مقصد را هم آسیب‌پذیر کند.

طرح بازیابی باید میان سناریوی خرابی فیزیکی، خطای نرم‌افزاری و حمله سایبری تفاوت بگذارد. در خرابی سخت‌افزار شاید جدیدترین Replica مناسب باشد؛ در آلودگی باید به نقطه سالم قدیمی‌تر بازگشت. نگهداری نسخه‌های Immutable و مسیر بررسی سلامت، انتخاب را در بحران ممکن می‌کند.

شبکه فقط یک لینک بین دو ساختمان نیست

کاربر باید بتواند سرویس بازیابی‌شده را پیدا کند و به آن برسد. تغییر Route، DNS، Load Balancer، آدرس‌ها و قواعد فایروال باید طراحی و تمرین شود. اگر مقصد در آزمون فقط از شبکه مدیریت دیده شود، موفقیت فنی با تجربه واقعی کاربران فاصله دارد.

ظرفیت ارتباط نیز اهمیت دارد. لینک ممکن است برای Replication روزانه کافی باشد اما هنگام انتقال انبوه داده یا استفاده کاربران در بحران اشباع شود. سناریوی ظرفیت باید هم ترافیک بازیابی و هم ترافیک بهره‌برداری را بسنجد. مسیر جایگزین برای ارتباطات حیاتی نیز باید آزموده شود.

هویت و دسترسی اضطراری را پیشاپیش آماده کنیم

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

نقش‌ها در مقصد نیز باید از پیش تعریف شوند. دسترسی گسترده موقت ممکن است برای سرعت وسوسه‌کننده باشد، اما دامنه خطا و سوءاستفاده را بالا می‌برد. تفکیک مسئولیت، ثبت فعالیت و مسیر تأیید تغییر باید حتی در وضعیت بحران حفظ شود، با فرایندی کوتاه و مشخص.

ظرفیت سایت دوم باید با هدف آن هماهنگ باشد

برخی سازمان‌ها مقصدی هم‌اندازه محیط اصلی می‌سازند؛ برخی فقط ظرفیت خدمات حیاتی را نگه می‌دارند. هیچ‌کدام ذاتاً درست یا غلط نیست. انتخاب به RTO، بودجه، مدت بحران و امکان کاهش موقت سطح خدمت بستگی دارد. مسئله زمانی ایجاد می‌شود که ظرفیت کوچک است ولی انتظار بازیابی کامل وجود دارد.

می‌توان برای هر موج، CPU، حافظه، Storage، IOPS و پهنای باند را برآورد کرد و حاشیه‌ای برای خطا یا رشد در نظر گرفت. اگر قرار است سرویس‌های غیرحیاتی خاموش بمانند، این تصمیم باید به مالکان آن‌ها اعلام شود. سایت دوم نباید وعده‌ای مبهم برای «همه‌چیز» باشد.

ترتیب بازیابی را به Runbook تبدیل کنیم

دانش شفاهی در روز حادثه قابل اتکا نیست. Runbook باید آغازگر رخداد، مسئول اعلام Disaster، مراحل فنی، نقطه‌های تأیید کسب‌وکار، معیار توقف و مسیر بازگشت را بنویسد. هر مرحله باید آن‌قدر روشن باشد که تیم شیفت دیگر نیز بتواند آن را اجرا کند.

Runbook فهرست طولانی دستورها نیست. تصمیم‌ها را نیز ثبت می‌کند: چه زمانی از Replica استفاده کنیم، چه زمانی بکاپ پاک انتخاب شود، کدام سرویس موقتاً با ظرفیت کمتر بالا بیاید و چه کسی ارتباط با مدیران را بر عهده دارد. اطلاعات تماس و دسترسی‌ها باید جداگانه و امن نگهداری شوند.

اعلام بحران یک تصمیم مدیریتی است

انتقال سرویس می‌تواند هزینه، ریسک و پیامد ارتباطی داشته باشد. چه کسی مجاز است وضعیت Disaster را اعلام کند؟ اگر مدیر اصلی در دسترس نبود، جانشین چه کسی است؟ تأخیر در پاسخ این پرسش می‌تواند زمان بازیابی را بیشتر از خود عملیات فنی کند.

طرح خوب یک ماتریس تصمیم دارد. شدت حادثه، زمان برآوردشده تعمیر، سلامت داده و اثر کسب‌وکار ورودی‌های تصمیم‌اند. تیم فنی اطلاعات را ارائه می‌کند و مسئول تعیین‌شده تصمیم را ثبت می‌کند. این سازوکار از تغییرهای متناقض در میانه بحران جلوگیری می‌کند.

آزمون باید فراتر از روشن شدن ماشین باشد

در آزمون‌های ساده، تیم یک ماشین را در مقصد روشن می‌کند و نتیجه را موفق می‌داند. آزمون واقعی باید ورود کاربر، اجرای تراکنش اصلی، ثبت داده، تهیه بکاپ، مانیتورینگ و دسترسی واحد پشتیبانی را بررسی کند. مالک سرویس باید نتیجه عملیاتی را تأیید کند.

سناریو نیز باید محدودیت داشته باشد: سایت اصلی در دسترس نیست، یک عضو کلیدی تیم حضور ندارد یا آخرین Replica مشکوک است. این محدودیت‌ها ضعف طرح را پیش از حادثه آشکار می‌کنند. آزمون قرار نیست نمایش بی‌نقص باشد؛ ابزار یادگیری و اصلاح است.

بازگشت به سایت اصلی بخش فراموش‌شده طرح است

پس از چند ساعت یا چند روز، سایت اصلی آماده می‌شود. داده جدید در مقصد تولید شده و کاربران به مسیر تازه عادت کرده‌اند. بازگشت بدون طرح می‌تواند دوباره قطعی یا از دست‌رفتن داده ایجاد کند. Failback باید مانند Failover طراحی شود.

همگام‌سازی معکوس، پنجره تغییر، تأیید داده و اطلاع‌رسانی به کاربران مراحل اصلی‌اند. همچنین باید روشن باشد آیا سرویس فوراً برمی‌گردد یا تا زمان پایدارشدن کامل در مقصد می‌ماند. تصمیم عجولانه برای بازگشت، ارزش بازیابی موفق را از بین می‌برد.

ارتباطات بحران باید هم‌زمان پیش برود

کاربران و مدیران به زمان و وضعیت قابل اعتماد نیاز دارند. اگر تیم فنی مشغول بازیابی است و هیچ‌کس پیام نمی‌دهد، شایعه و درخواست‌های تکراری فشار را بیشتر می‌کنند. یک مسئول ارتباطات باید بازه به‌روزرسانی و مخاطبان را از قبل بداند.

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

شاخص‌های آمادگی را گزارش کنیم

درصد سرویس‌های دارای RTO و RPO مصوب، پوشش نقشه وابستگی، زمان آخرین آزمون، فاصله نتیجه واقعی با هدف و تعداد اقدام‌های اصلاحی باز شاخص‌های قابل استفاده‌اند. گزارش «سایت دوم فعال است» برای هیئت‌مدیره اطلاعات تصمیم‌ساز فراهم نمی‌کند.

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

نقش راگا در ارزیابی محل دوم

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

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

حالت حداقلی کسب‌وکار را تعریف کنیم

در یک بحران طولانی، ممکن است سازمان نتواند همه قابلیت‌های عادی را در مقصد ارائه کند. مالک سرویس باید مشخص کند حداقل عملیات قابل قبول چیست. سامانه مالی شاید ابتدا فقط ثبت تراکنش‌های ضروری را فعال کند و گزارش‌های تحلیلی را به بعد بسپارد. مرکز تماس نیز ممکن است با تعداد کاربر محدود آغاز شود.

این حالت حداقلی ظرفیت و ترتیب بازیابی را واقعی‌تر می‌کند. رابط‌های غیراساسی، Jobهای سنگین و گزارش‌های دوره‌ای موقتاً متوقف می‌شوند. فهرست محدودیت‌ها باید به کاربران اعلام و زمان بازگشت به حالت کامل تعیین شود. کاهش خدمت تصمیم مدیریت است، نه نتیجه ناخواسته کمبود منابع.

تأمین‌کنندگان بیرونی را وارد سناریو کنیم

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

در آزمون میزگرد، یکی از وابستگی‌های بیرونی را نیز در دسترس فرض نکنید. تیم بررسی می‌کند آیا مسیر جایگزین، Cache، کار دستی یا اطلاع‌رسانی به مشتری وجود دارد. این تمرین مرز واقعی تداوم سازمان را نشان می‌دهد.

اسناد و ابزارهای طرح را خارج از سایت اصلی نگه داریم

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

نسخه‌ها باید با تغییر معماری به‌روزرسانی شوند. در ابتدای هر آزمون، تیم می‌تواند از روی اسناد شروع کند و موارد قدیمی را ثبت نماید. سندی که یک سال استفاده نشده، احتمالاً با واقعیت فاصله دارد.

پس از هر آزمون مالک اصلاح تعیین کنیم

فهرست ضعف بدون مالک به نتیجه تبدیل نمی‌شود. هر یافته باید شدت، اقدام، مسئول، بودجه احتمالی و تاریخ هدف داشته باشد. مواردی که به تصمیم مدیریت نیاز دارند جدا شوند. آزمون بعدی باید بسته‌شدن اقدامات مهم را تأیید کند.

یک گزارش کوتاه برای مدیران می‌تواند هدف، زمان واقعی، شکاف اصلی و تصمیم لازم را نشان دهد. جزئیات فرمان‌ها در پیوست فنی باقی می‌مانند. این گزارش سرمایه‌گذاری را به ضعف مشاهده‌شده متصل می‌کند.

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

نتیجه دوباره آزموده می‌شود.

تصمیم بعد از حادثه فرضی

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

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

چک‌لیست تصمیم‌گیری

• سرویس‌های حیاتی و وابستگی‌های آن‌ها مشخص شوند.
• RTO و RPO با مالک کسب‌وکار توافق شوند.
• بازیابی واقعی و ارتباطات بحران آزموده شوند.
• نتیجه آزمون به اقدام اصلاحی دارای مسئول و موعد تبدیل شود.

سؤالات متداول

داشتن بکاپ برای تداوم کسب‌وکار کافی است؟

خیر. نسخه پشتیبان باید محافظت شود و بازیابی آن در زمان و مقیاس موردنیاز آزموده شود.

RTO و RPO چه کاربردی دارند؟

RTO زمان قابل‌تحمل تا بازگشت سرویس و RPO مقدار قابل‌تحمل ازدست‌رفتن داده را مشخص می‌کند.

مانور بازیابی چه خروجی‌ای باید داشته باشد؟

زمان واقعی، شکاف‌ها، مسئول اصلاح، موعد اقدام و تصمیم مدیریتی باید ثبت شوند.

منابع

[۱] NIST — راهنمای برنامه‌ریزی تداوم و بازیابی سامانه‌های اطلاعاتی مشاهده منبع

[۲] CISA — راهنمای برنامه‌ریزی تداوم کسب‌وکار مشاهده منبع

مطالب مرتبط در سایت راگا

برای تکمیل این مسیر، راهکارهای بکاپ و بازیابی اطلاعات راگا و مقاله «داده‌های قدیمی هم هزینه دارند و باید درباره نگهداری آن‌ها تصمیم گرفت» را ببینید.