زیرساخت مجازیسازی محل اجرای بخش بزرگی از سرویسهای سازمان است. سامانههای مالی، اتوماسیون اداری، بانکهای اطلاعاتی، نرمافزارهای داخلی و سرویسهای ارتباطی ممکن است همگی روی همین بستر قرار گرفته باشند. اختلال در این زیرساخت، برخلاف خرابی یک سیستم منفرد، میتواند چندین بخش سازمان را همزمان متوقف کند.
این قسمت از رادیو آوید به مدیریت بحران زیرساخت مجازیسازی اختصاص دارد. در فایل صوتی این قسمت، تجربههایی درباره تفکیک ترافیک شبکه، مستندسازی ریسکها، افزونگی تجهیزات، پشتیبانگیری، Replication و مدیریت تیم در زمان حادثه مطرح شده است. پیشنهاد میکنیم ابتدا فایل صوتی را بشنوید. نسخه متنی و دستهبندیشده مطالب نیز در ادامه در دسترس شما قرار دارد.
کیفیت واکنش سازمان در روز بحران، به تصمیمهایی بستگی دارد که پیش از حادثه گرفته شدهاند.
زیرساخت مجازیسازی، قلب عملیاتی سازمان
نگاه سازمان به زیرساخت مجازیسازی باید با نگاه آن به یک نرمافزار یا تجهیز مستقل متفاوت باشد. بسیاری از سرویسهای سازمان در این نقطه به هم میرسند و به منابع پردازشی، شبکه و ذخیرهسازی مشترک وابسته میشوند.
تمرکز سرویسها مزایای زیادی دارد، اما دامنه اثر خرابی را نیز افزایش میدهد. از دسترس خارجشدن یک میزبان، ذخیرهساز یا مسیر شبکه ممکن است چند ماشین مجازی را بهصورت همزمان متوقف کند. به همین دلیل، طراحی این زیرساخت باید بر پایه پایداری، امنیت و امکان بازیابی انجام شود.
مدیریت بحران زیرساخت مجازیسازی مجموعه اقداماتی است که سازمان برای کاهش احتمال اختلال، محدودکردن خسارت و بازگرداندن سرویسها انجام میدهد. این اقدامات از مرحله طراحی آغاز میشوند و تا بررسی حادثه پس از بازیابی ادامه دارند.
برای آشنایی بیشتر با اجزای این بستر، مطلب معماری PVM تصویری روشنتر از ساختار یک سامانه مجازیسازی ارائه میکند.
تفکیک ترافیک شبکه در زیرساخت مجازی
در یک زیرساخت مجازیسازی، همه ترافیکها هدف و حساسیت یکسانی ندارند. مسیر مدیریت میزبانها با ترافیک ماشینهای مجازی متفاوت است. بکاپ، Replication، ارتباط با ذخیرهساز و مهاجرت ماشینهای مجازی نیز هرکدام الگوی ترافیکی خاص خود را دارند.
عبور همه این ترافیکها از یک مسیر مشترک، پایش و عیبیابی را دشوار میکند. در این وضعیت، تیم فنی بهسادگی نمیتواند تشخیص دهد افزایش مصرف شبکه مربوط به کاربران، بکاپ، ذخیرهسازی یا یک رفتار غیرعادی است.
مسیرهای اصلی شبکه مجازیسازی معمولاً شامل موارد زیر هستند:
- مسیر مدیریت میزبانها و پلتفرم مجازیسازی
- ترافیک ماشینهای مجازی و ارتباط آنها با کاربران
- ترافیک بکاپ و انتقال نسخههای پشتیبان
- ترافیک Replication میان میزبانها یا سایتها
- ارتباط با ذخیرهسازهای تحت شبکه
- مسیر مهاجرت ماشینهای مجازی میان سرورها
در طراحی مطلوب، هرکدام از این ترافیکها مسیر کنترلشده خود را دارند. اگر تعداد رابطهای فیزیکی یا ظرفیت تجهیزات محدود باشد، حداقل باید ترافیک مدیریت، ترافیک ماشینهای مجازی و ترافیک بکاپ و Replication از یکدیگر جدا شوند.
نتیجه عملی تفکیک مسیرهای شبکه
تفکیک ترافیک، دسترسی به درگاههای مدیریتی را محدود میکند و امکان اعمال سیاستهای امنیتی متفاوت را فراهم میسازد. همچنین ترافیک سنگین بکاپ یا Replication کمتر بر عملکرد ماشینهای مجازی اثر میگذارد.
این جداسازی در زمان حادثه نیز به کار تیم فنی سرعت میدهد. وقتی هر نوع ترافیک مسیر مشخصی داشته باشد، منشأ مصرف غیرعادی یا اختلال شبکه سریعتر پیدا میشود و تیم میتواند دامنه مشکل را دقیقتر بررسی کند.
مستندسازی، بخشی از آمادگی برای بحران
یکی از نکات اصلی این قسمت رادیو آوید، ثبت مکتوب وضعیت زیرساخت است. مدیر فناوری اطلاعات باید وضعیت موجود، ضعفها، نیازهای اصلاحی و پیامدهای ادامه شرایط فعلی را بهصورت رسمی در اختیار مدیران سازمان قرار دهد.
یک گزارش فنی که فقط در واحد فناوری اطلاعات باقی بماند، لزوماً به تصمیم مدیریتی منجر نمیشود. ریسکها باید به زبان روشن نوشته و در اتوماسیون اداری، صورتجلسه کمیته یا گزارش رسمی ثبت شوند. این مستند مشخص میکند کدام خطرها شناسایی شدهاند و اجرای کدام اقدامات به بودجه یا تصمیم مدیران نیاز دارد.
مستند وضعیت زیرساخت بهتر است این اطلاعات را در بر بگیرد:
- فهرست سرویسها و ماشینهای مجازی مهم
- وابستگی سرویسها به میزبان، شبکه و ذخیرهساز
- نقاط ضعف و مؤلفههای فاقد افزونگی
- وضعیت نسخههای پشتیبان و Replication
- اولویت اقدامات اصلاحی
- تجهیزات، بودجه و نیروی انسانی موردنیاز
- مسئولیت افراد و پیمانکاران در زمان حادثه
هدف این مستندسازی، انتقال مسئولیت به دیگران نیست. مدیران باید پیش از حادثه بدانند زیرساخت سازمان چه محدودیتهایی دارد و تأخیر در رفع هر ضعف چه پیامدی ایجاد میکند.
افزونگی تجهیزات از مرحله طراحی آغاز میشود
زیرساختی که دقیقاً بهاندازه مصرف روزانه ظرفیت دارد، هنگام خرابی فضای مانور کمی خواهد داشت. اگر یکی از میزبانها از مدار خارج شود، میزبانهای باقیمانده باید توان اجرای ماشینهای مجازی مهم را داشته باشند.
افزونگی فقط به تعداد سرورها مربوط نیست. کارتهای شبکه، سوئیچها، منابع تغذیه، مسیرهای ارتباطی، کنترلرهای ذخیرهساز و محل نگهداری نسخههای پشتیبان نیز باید بررسی شوند. خرابی هر مؤلفهای که جایگزین ندارد، ممکن است کل فرایند بازیابی را متوقف کند.
تجهیز اضافه زمانی ارزش دارد که آماده استفاده باشد. پیکربندی، سازگاری و سلامت آن باید پیش از بحران آزمایش شود. وجود یک سرور خاموش یا لینک جایگزین، بدون آزمون عملی، تضمینی برای ادامه سرویس نیست.
نقش پشتیبانی فنی در روز حادثه
در شرایط عادی، بسیاری از مشکلات با دانش تیم داخلی حل میشوند. هنگام بحران، دسترسی به تیم پشتیبان محصول یا پیمانکار متخصص میتواند زمان تشخیص و بازیابی را کاهش دهد.
استفاده از نرمافزارهای دارای مجوز معتبر و پشتیبانی مشخص باعث میشود تیم سازمان در زمان حادثه تنها نماند. هنگام انتخاب محصول یا پیمانکار باید شیوه پاسخگویی در شرایط اضطراری، دسترسی به بهروزرسانیها، کیفیت مستندات و تجربه تیم فنی بررسی شود.
قیمت خرید تنها بخشی از هزینه زیرساخت است. محصولی که در زمان خرابی پشتیبانی قابل اتکا ندارد، ممکن است هزینه توقف طولانیتری به سازمان تحمیل کند.
بکاپ و Replication، دو ابزار با وظایف متفاوت
بکاپ و Replication هر دو در بازیابی زیرساخت نقش دارند، اما جای یکدیگر را نمیگیرند. بکاپ نسخهای از اطلاعات یا ماشین مجازی را برای بازیابی در آینده نگه میدارد. Replication یک نسخه دوم از ماشین مجازی را روی میزبان یا محل دیگری قرار میدهد تا راهاندازی مجدد سرویس سریعتر انجام شود.
اگر دادهای حذف یا آلوده شود، همان تغییر ممکن است به نسخه Replication نیز منتقل شود. نسخههای پشتیبان مستقل و تاریخچهدار برای بازیابی اطلاعات پیش از خرابی لازم هستند. در مقابل، Replication میتواند زمان بازگرداندن ماشین مجازی را کاهش دهد.
سازمان باید هر دو فرایند را آزمایش کند. موفقبودن عملیات کپی یا نمایش وضعیت سبز در نرمافزار، اثبات نمیکند که ماشین مجازی در زمان حادثه بدون مشکل اجرا خواهد شد.
مطلب دستورالعمل پشتیبانگیری از اطلاعات و مدیریت نسخهها نکات بیشتری درباره طراحی و کنترل نسخههای پشتیبان ارائه میدهد. برای بررسی Replication و پایداری سرویس نیز میتوانید مطلب پایداری سرویس در VDI را مطالعه کنید.
سایت بازیابی متناسب با اندازه سازمان
راهکار بازیابی لازم نیست برای همه سازمانها شکل یکسانی داشته باشد. یک مجموعه کوچک ممکن است از یک میزبان جایگزین در محل دیگری استفاده کند. سازمان بزرگتر میتواند سایت بحران مجهز با فاصله جغرافیایی بیشتر داشته باشد.
اندازه راهکار باید با اهمیت سرویسها و توان سازمان متناسب باشد. نکته اصلی این است که نسخه دوم در دسترس باشد، روش راهاندازی آن مستند شده باشد و اعضای تیم بدانند در زمان حادثه چه کاری باید انجام دهند.
تجربه آوید از بازیابی زیرساخت یک سازمان در مطلب دیتاسنتر ریکاوری و بازیابی اطلاعات منتشر شده است. این تجربه نشان میدهد آمادگی قبلی چگونه بر زمان بازگشت سرویس اثر میگذارد.
اولویتهای تیم فنی هنگام بحران
زمانی که اختلال رخ میدهد، فشار زیادی بر واحد فناوری اطلاعات وارد میشود. مدیران و کاربران پاسخ میخواهند و همزمان تیم فنی باید منشأ مشکل را پیدا کند. در چنین شرایطی، حفظ تمرکز اهمیت زیادی دارد.
جستوجوی مقصر در میانه حادثه، زمان و انرژی تیم را میگیرد. ابتدا باید دامنه مشکل مشخص شود، از گسترش آسیب جلوگیری شود و سرویسهای مهم بهترتیب اولویت بازگردند. بررسی کوتاهیها و مسئولیتها بعد از تثبیت وضعیت انجام میشود.
ترتیب مناسب واکنش به حادثه شامل این مراحل است:
- تشخیص محدوده اختلال و سرویسهای آسیبدیده
- جلوگیری از گسترش مشکل
- تعیین مسئول هماهنگی و تقسیم وظایف
- بازیابی سرویسها بر اساس اولویت سازمان
- ثبت اقدامات و تصمیمهای گرفتهشده
- بررسی علت حادثه پس از بازگشت شرایط عادی
حفظ آرامش به معنی کوچکشمردن حادثه نیست. تصمیمهای عجولانه میتوانند دامنه آسیب را بیشتر کنند. تیم باید بر اساس اطلاعات موجود و سناریوی از پیش تعیینشده عمل کند.
مدیریت روابط انسانی در کنار مسائل فنی
بحران فقط تجهیزات و نرمافزارها را درگیر نمیکند. فشار روانی میتواند رابطه میان کارشناسان، مدیران و پیمانکاران را نیز تحت تأثیر قرار دهد. اختلاف و سرزنش در این مرحله، مشارکت افراد را کاهش میدهد.
مدیر بحران باید فضای همکاری را حفظ کند، مسئولیتها را روشن نگه دارد و از چند مسیر موازی برای صدور دستور جلوگیری کند. گزارشهای کوتاه و منظم نیز مانع انتشار اطلاعات ناقص در سازمان میشوند.
تیم داخلی و پیمانکاران بخشی از ظرفیت بازیابی سازمان هستند. مدیریت درست ارتباط میان این افراد، گاهی بهاندازه انتخاب ابزار فنی بر نتیجه حادثه اثر دارد.
تبدیل حادثه به درس اجرایی
هیچ زیرساختی بهطور کامل از خطا مصون نیست. حتی سازمانهایی که تجهیزات و نیروی متخصص دارند ممکن است بر اثر کمبود ظرفیت، خطای پیکربندی یا نقص در پایش با توقف سرویس روبهرو شوند.
سازمان یادگیرنده پس از بازگشت سرویس، حادثه را رها نمیکند. علت فنی، ضعف فرایند، تأخیرهای رخداده و مشکلات ارتباطی باید ثبت شوند. سپس برای هر اصلاح، مسئول و زمان اجرا تعیین شود.
این بررسی باید به پرسشهای مشخص پاسخ دهد:
- اولین نشانه اختلال چه بود و چه زمانی دیده شد؟
- کدام بخش از زیرساخت نقطه شکست بود؟
- کدام مرحله بازیابی بیشترین زمان را گرفت؟
- چه مستند، دسترسی یا تجهیزی در دسترس نبود؟
- برای جلوگیری از تکرار حادثه چه اقدامی لازم است؟
اگر خروجی جلسه فقط یک گزارش باشد، احتمال تکرار مشکل کاهش پیدا نمیکند. درس حادثه زمانی به بهبود زیرساخت منجر میشود که به اقدام اجرایی تبدیل شود.
چکلیست آمادگی زیرساخت مجازیسازی
- سرویسها و ماشینهای مجازی مهم شناسایی شدهاند.
- ترتیب بازیابی سرویسها به تأیید مدیران رسیده است.
- ترافیک مدیریت از شبکه عمومی کاربران جدا شده است.
- مسیرهای بکاپ و Replication ظرفیت کافی دارند.
- میزبانها و تجهیزات شبکه از ظرفیت جایگزین برخوردارند.
- نسخههای پشتیبان در مقصدی مستقل نگهداری میشوند.
- بازیابی نسخههای پشتیبان بهصورت عملی آزمایش شده است.
- روش راهاندازی نسخه Replication مستند شده است.
- اطلاعات تماس تیم داخلی و پیمانکاران بهروز است.
- دسترسیهای اضطراری بهشکل امن نگهداری میشوند.
- مسئول هماهنگی و اطلاعرسانی در بحران مشخص است.
- نتیجه هر حادثه به برنامه اصلاحی تبدیل میشود.
جمعبندی
مدیریت بحران زیرساخت مجازیسازی پیش از وقوع حادثه آغاز میشود. تفکیک ترافیک شبکه، ثبت ریسکها، تأمین افزونگی، نگهداری نسخههای پشتیبان و آزمایش بازیابی، زیرساخت را برای شرایط دشوار آماده میکنند.
در زمان حادثه، تیم باید بر مهار مشکل و بازگرداندن سرویسها تمرکز کند. حفظ آرامش، تقسیم وظایف و مدیریت ارتباط میان افراد، از تصمیمهای شتابزده جلوگیری میکند. پس از حادثه نیز علتها و ضعفها باید به اقدام اصلاحی تبدیل شوند.
برای شنیدن توضیحات کامل و تجربههای مطرحشده، فایل صوتی این قسمت از رادیو آوید را بشنوید. مطالب تدابیر امنیتی زیرساخت مجازیسازی در شرایط بحرانی و امنیت سایبری در شرایط بحرانی نیز اطلاعات تکمیلی این موضوع را در اختیار شما قرار میدهند.
پرسشهای متداول
اولین اقدام پس از اختلال زیرساخت مجازیسازی چیست؟
ابتدا دامنه اختلال و سرویسهای آسیبدیده را مشخص کنید. پس از مهار مشکل، سرویسها باید بر اساس اولویت از پیش تعیینشده بازیابی شوند. بررسی مسئولیتها به بعد از تثبیت شرایط موکول میشود.
آیا Replication جایگزین بکاپ است؟
خیر. Replication برای راهاندازی سریعتر نسخه دوم ماشین مجازی به کار میرود، اما حذف یا آلودگی داده ممکن است به آن منتقل شود. نسخه پشتیبان مستقل برای بازگشت به وضعیت سالم لازم است.
تفکیک ترافیک شبکه چه کمکی به امنیت میکند؟
تفکیک مسیرها، دسترسی به بخش مدیریتی را محدود میکند و تشخیص ترافیک غیرعادی را سادهتر میسازد. همچنین مصرف بالای بکاپ و Replication کمتر بر سرویسهای عملیاتی اثر میگذارد.
سازمان کوچک چگونه برای بازیابی آماده شود؟
یک سازمان کوچک میتواند ماشینهای مهم را روی میزبان جایگزین یا در محل دیگری نگهداری کند. اندازه راهکار مهم نیست؛ امکان راهاندازی، مستندبودن مراحل و آزمایش دورهای آن اهمیت دارد.
