مجله بلاگ
برنامه بازیابی بحران IT؛ راهنمای عملی تداوم سرویس‌های سازمانی
برنامه بازیابی بحران IT سندی عملی برای بازگرداندن سرویس‌های حیاتی پس از رخدادهایی مانند خرابی ذخیره‌ساز، قطع برق طولانی، آتش‌سوزی اتاق سرور، حمله باج‌افزاری، خطای انسانی یا اختلال مرکز داده است. داشتن نسخه پشتیبان شرط لازم است، اما به‌تنهایی تضمین نمی‌کند که سازمان بتواند در زمان قابل قبول فعالیتش را از سر بگیرد.
یک برنامه مؤثر باید مشخص کند کدام سرویس زودتر بازیابی می‌شود، چه کسی تصمیم می‌گیرد، نسخه سالم کجاست، چه زیرساختی برای بازیابی لازم است و موفقیت چگونه سنجیده می‌شود. این راهنما مسیر تدوین و آزمون برنامه را برای شرکت‌های کوچک و متوسط توضیح می‌دهد.
بازیابی بحران با بکاپ چه تفاوتی دارد؟
بکاپ یک نسخه از داده یا تنظیمات است. بازیابی بحران مجموعه‌ای از افراد، فرایندها، زیرساخت‌ها و تصمیم‌هاست که سرویس را پس از حادثه به وضعیت قابل استفاده برمی‌گرداند. ممکن است فایل بکاپ سالم باشد، اما رمز دسترسی، نرم‌افزار سازگار، فضای ذخیره‌سازی، DNS یا مستندات لازم در دسترس نباشد.
در طرح DR باید زنجیره کامل سرویس دیده شود. برای مثال، بازیابی نرم‌افزار مالی فقط به بازگرداندن پایگاه داده محدود نیست؛ Active Directory، DNS، ماشین برنامه، گواهی، مسیر شبکه، لایسنس و دسترسی کاربران نیز باید آماده باشند.
از تحلیل اثر کسب‌وکار شروع کنید
همه سامانه‌ها ارزش و فوریت یکسان ندارند. تحلیل اثر کسب‌وکار یا BIA نشان می‌دهد توقف هر سرویس چه پیامد مالی، قراردادی، عملیاتی و اعتباری دارد. مدیر واحد کسب‌وکار باید در این تصمیم مشارکت کند؛ تیم فناوری اطلاعات به‌تنهایی نمی‌تواند هزینه واقعی توقف فروش، تولید یا پاسخ‌گویی به مشتری را تعیین کند.
- سرویس چه فرایندی را پشتیبانی می‌کند؟
- حداکثر زمان قابل تحمل توقف چقدر است؟
- چه تعداد کاربر یا مشتری تحت تأثیر قرار می‌گیرند؟
- وابستگی‌های فنی و تأمین‌کنندگان کدام‌اند؟
- آیا راهکار دستی موقت وجود دارد؟
- از دست‌رفتن چه مقدار داده قابل قبول است؟
RTO و RPO را واقع‌بینانه تعیین کنید
RTO چیست؟
Recovery Time Objective حداکثر زمان هدف برای بازگرداندن یک سرویس است. اگر RTO سامانه فروش چهار ساعت باشد، معماری، تیم و فرایند باید بتوانند سرویس را حداکثر در این بازه عملیاتی کنند.
RPO چیست؟
Recovery Point Objective بیشترین مقدار قابل قبول از دست‌رفتن داده برحسب زمان است. RPO یک ساعت یعنی نسخه‌ها یا Replication باید طوری باشند که در حادثه بیش از حدود یک ساعت داده از بین نرود.
RTO و RPO بسیار کوتاه هزینه را افزایش می‌دهند. Replication لحظه‌ای، سایت جایگزین آماده و تیم ۲۴ ساعته گران‌تر از بکاپ روزانه‌اند. مقدار هدف باید با اثر کسب‌وکار و بودجه متعادل شود.
سرویس‌ها را اولویت‌بندی کنید
فهرست سرویس‌ها را در چند سطح قرار دهید. سطح اول می‌تواند شامل هویت، DNS، ارتباطات اصلی، سامانه فروش و پایگاه داده حیاتی باشد. سطح دوم سرویس‌هایی هستند که در چند ساعت یا یک روز باید بازگردند. آرشیو، گزارش‌های تاریخی یا محیط آزمایش معمولاً در سطح پایین‌تر قرار می‌گیرند.
ترتیب فنی بازیابی همیشه با ترتیب ظاهری کاربران یکسان نیست. ممکن است قبل از برنامه اصلی لازم باشد ذخیره‌ساز، مجازی‌ساز، Active Directory و DNS فعال شوند. بنابراین Dependency Map بخش اصلی برنامه است.
سناریوهای بحران را تعریف کنید
طرحی که فقط «خرابی سرور» را پوشش دهد کافی نیست. حداقل سناریوهای زیر را بررسی کنید:
- خرابی یک ماشین مجازی یا سیستم‌عامل؛
- خرابی Host، ذخیره‌ساز یا تجهیزات شبکه؛
- قطع برق و ازکارافتادن سرمایش اتاق سرور؛
- حذف تصادفی فایل، ماشین یا حساب؛
- باج‌افزار و آلوده‌شدن بکاپ متصل؛
- خرابی کامل سایت اصلی یا عدم دسترسی به ساختمان؛
- اختلال سرویس ابری یا ارتباط اینترنت؛
- نبود نیروی کلیدی یا از دسترس خارج‌شدن پیمانکار.
برای واکنش امنیتی سریع، برنامه DR را با راهنمای واکنش به باج‌افزار در ۲۴ ساعت اول هماهنگ کنید. بازیابی شتاب‌زده پیش از مهار حادثه می‌تواند محیط سالم را دوباره آلوده کند.
معماری بکاپ برای بازیابی واقعی
نسخه پشتیبان باید چندلایه، مستقل و قابل آزمون باشد. استفاده از اصول قانون ۳-۲-۱ در پشتیبان‌گیری نقطه شروع مناسبی است: حداقل سه نسخه از داده، روی دو نوع رسانه و یک نسخه خارج از سایت. برای مقابله با باج‌افزار، نسخه Immutable یا آفلاین اهمیت ویژه دارد.
بکاپ باید فراتر از فایل‌ها باشد. تنظیمات فایروال و سوئیچ، ماشین‌های مجازی، پایگاه داده، Active Directory، DNS، IP-PBX، گواهی‌ها، کلیدهای رمزنگاری و مستندات عملیاتی را نیز پوشش دهید. دسترسی مدیر بکاپ را از حساب‌های روزمره و دامنه اصلی جدا کنید.
انتخاب راهکار بازیابی
بازیابی در سایت اصلی
برای خرابی محدود مناسب است و هزینه کمتری دارد، اما در حادثه فیزیکی گسترده پاسخ‌گو نیست. قطعات یدکی، ظرفیت ذخیره و دسترسی به نسخه‌های سالم باید مشخص باشند.
سایت سرد، گرم یا داغ
سایت سرد فضا و اتصال پایه دارد و تجهیزات پس از حادثه آماده می‌شوند. سایت گرم بخشی از زیرساخت را آماده نگه می‌دارد. سایت داغ تقریباً هم‌زمان و آماده انتقال بار است. انتخاب میان آن‌ها به RTO، هزینه و حساسیت سرویس بستگی دارد.
بازیابی در ابر
DRaaS یا بازیابی روی زیرساخت ابری می‌تواند نیاز به مرکز داده دوم را کاهش دهد، اما پهنای باند، هزینه انتقال، سازگاری شبکه، امنیت حساب ابری و روش بازگشت به سایت اصلی باید آزمایش شوند.
نقش‌ها و زنجیره تصمیم‌گیری
در زمان بحران نباید تصمیم‌ها وابسته به یک نفر باشند. برنامه باید نقش‌ها را تعریف کند:
- مدیر بحران: فعال‌سازی برنامه و اولویت‌های کسب‌وکار؛
- رهبر فنی: هماهنگی بازیابی زیرساخت و سرویس‌ها؛
- مسئول امنیت: مهار رخداد و تأیید پاک‌بودن محیط؛
- مالک سرویس: آزمون عملکرد و تأیید بازگشت؛
- مسئول ارتباطات: اطلاع‌رسانی داخلی، مشتری و تأمین‌کننده؛
- ثبت‌کننده رخداد: ثبت زمان، تصمیم، تغییر و نتیجه.
اطلاعات تماس باید به‌صورت آفلاین نیز در دسترس باشد. اگر ایمیل سازمانی قطع شده باشد، تیم به کانال ارتباطی جایگزین نیاز دارد.
Runbook بازیابی چه اطلاعاتی داشته باشد؟
Runbook باید آن‌قدر روشن باشد که فرد واجد صلاحیت دیگری نیز بتواند مراحل را اجرا کند. برای هر سرویس این موارد را ثبت کنید:
- مالک فنی و کسب‌وکاری؛
- RTO، RPO و سطح اولویت؛
- سرورها، شبکه و سرویس‌های وابسته؛
- محل بکاپ و روش دریافت امن Credential؛
- ترتیب دقیق Restore و تنظیمات پس از آن؛
- آزمون‌های سلامت و معیار پذیرش؛
- مسیر Rollback و Escalation؛
- روش ثبت شواهد و زمان‌های اجرا.
رمزها و کلیدها را داخل سند عادی ننویسید. سند باید به محل امن نگهداری Credential و روش دسترسی اضطراری اشاره کند.
آزمون برنامه بازیابی بحران
برنامه‌ای که آزمایش نشده فقط یک فرضیه است. آزمون را از Tabletop Exercise آغاز کنید؛ تیم سناریو را روی میز مرور می‌کند و تصمیم‌ها، تماس‌ها و وابستگی‌ها را می‌سنجد. سپس بازیابی یک فایل یا ماشین در محیط ایزوله انجام شود. در سطح بالاتر، Failover سرویس یا قطع کنترل‌شده بخشی از زیرساخت آزموده می‌شود.
هر آزمون باید زمان شروع، زمان دستیابی به نقاط کلیدی، خطاها، اقدام اصلاحی و مالک آن را ثبت کند. دستیابی به RTO فقط زمانی معتبر است که با ساعت و شواهد واقعی اندازه‌گیری شده باشد.
چک‌لیست اجرای برنامه DR
- فهرست سرویس‌ها و مالک آن‌ها کامل است؛
- RTO و RPO با مدیر کسب‌وکار تأیید شده‌اند؛
- نقشه وابستگی‌ها و ترتیب بازیابی وجود دارد؛
- بکاپ مستقل و تغییرناپذیر نگهداری می‌شود؛
- Credential اضطراری امن و قابل دسترس است؛
- ظرفیت شبکه، Compute و Storage مقصد بررسی شده است؛
- Runbookها نسخه‌گذاری و آفلاین نگهداری می‌شوند؛
- کانال ارتباطی جایگزین مشخص است؛
- آزمون دوره‌ای و اقدام اصلاحی زمان‌بندی شده است؛
- فرایند بازگشت از سایت جایگزین مستند است.
مثال عملی: خرابی ذخیره‌ساز شرکت
یک شرکت ۱۲۰ نفره سامانه مالی، فایل و نرم‌افزار فروش را روی یک کلاستر مجازی اجرا می‌کند. خرابی کنترلر ذخیره‌ساز همه ماشین‌ها را متوقف می‌کند. در برنامه DR، ابتدا شبکه مدیریتی و مجازی‌ساز جایگزین آماده می‌شود؛ سپس Domain Controller و DNS، پایگاه داده فروش، سرور برنامه و در مرحله بعد فایل‌سرور بازیابی می‌شوند.
نسخه‌های بکاپ روی مخزن محلی و یک فضای Immutable خارج از سایت قرار دارند. مالک فروش با یک سناریوی واقعی ورود، ثبت سفارش و گزارش‌گیری، سلامت سرویس را تأیید می‌کند. پس از تثبیت، فایل‌سرور با اولویت پایین‌تر بازمی‌گردد. این ترتیب مانع اتلاف زمان برای سرویس کم‌اهمیت در ساعات اول می‌شود.
شاخص‌های سنجش آمادگی
- درصد سرویس‌های دارای RTO و RPO تأییدشده؛
- نرخ موفقیت Jobهای بکاپ؛
- زمان واقعی Restore در آخرین آزمون؛
- درصد Runbookهای بازبینی‌شده در شش ماه اخیر؛
- تعداد وابستگی‌های بدون مالک؛
- سن آخرین آزمون Failover؛
- تعداد اقدام‌های اصلاحی بازمانده از مانور.
این شاخص‌ها را همراه با مانیتورینگ زیرساخت گزارش کنید تا آمادگی بازیابی به یک فعالیت مستمر تبدیل شود.
اشتباه‌های رایج
- اتکا به موفقیت Job بکاپ بدون آزمون Restore؛
- یکسان‌گرفتن اولویت همه سرویس‌ها؛
- نگهداری بکاپ و Credential در همان دامنه آسیب‌دیده؛
- نادیده‌گرفتن DNS، گواهی، لایسنس و مسیر شبکه؛
- نبود نسخه آفلاین Runbook و اطلاعات تماس؛
- تعریف RTO غیرواقعی بدون بودجه و ظرفیت؛
- آزمون فنی بدون حضور مالک کسب‌وکار؛
- نداشتن برنامه بازگشت از محیط موقت به سایت اصلی.
پرسش‌های متداول
هر چند وقت یک‌بار برنامه DR آزمایش شود؟
آزمون بخش‌های حیاتی حداقل فصلی و مانور جامع حداقل سالانه مناسب است. پس از تغییر مهم زیرساخت یا سرویس، Runbook مرتبط باید دوباره آزموده شود.
آیا Snapshot ماشین مجازی بکاپ محسوب می‌شود؟
Snapshot برای تغییر کوتاه‌مدت مفید است، اما معمولاً به همان Storage وابسته است و جایگزین بکاپ مستقل و قابل‌بازیابی نیست.
آیا شرکت کوچک به سایت دوم نیاز دارد؟
الزاماً خیر. با توجه به RTO و بودجه می‌توان از زیرساخت ابری، تجهیزات رزرو، فضای همکار یا بازیابی در سایت اصلی استفاده کرد. تصمیم باید مبتنی بر اثر توقف باشد.
مسئول برنامه بازیابی بحران چه کسی است؟
مالکیت نهایی با مدیریت سازمان است؛ تیم فناوری اطلاعات اجرای فنی را هدایت می‌کند و مالکان سرویس، اولویت و صحت عملکرد را تأیید می‌کنند.
جمع‌بندی
برنامه بازیابی بحران IT زمانی ارزشمند است که اولویت‌های کسب‌وکار را به معماری، بکاپ، نقش‌ها و Runbook قابل اجرا تبدیل کند. RTO و RPO باید واقعی، وابستگی‌ها مستند و بازیابی با شواهد زمانی آزمایش شود.
پس از هر مانور یا حادثه واقعی، جلسه بازنگری برگزار کنید و فرضیات نادرست، تأخیرها و وابستگی‌های کشف‌شده را به اقدام اصلاحی دارای مسئول و موعد تبدیل کنید. برنامه DR باید همراه با تغییر فناوری، نیروی انسانی، قراردادها و نیاز کسب‌وکار به‌روز شود؛ نسخه قدیمی در زمان بحران می‌تواند از نبود برنامه خطرناک‌تر باشد.
نصیر ارتباط می‌تواند ارزیابی ریسک، تدوین BIA، طراحی بکاپ و سایت جایگزین، نگارش Runbook، اجرای مانور و نگهداری دوره‌ای را در قالب پشتیبانی شبکه سازمانی انجام دهد؛ از کاربر و سرویس‌های روزمره تا زیرساخت، سرورها و بازیابی پس از بحران.
