استقلال زیرساخت پس از قطع ارتباط چگونه سنجیده می‌شود؟
استقلال زیرساخت را با یک آزمون عملی بسنجید. اگر ارتباط با یک سرویس بیرونی قطع شود، تیم فناوری اطلاعات تا چه مدت می‌تواند سرویس‌های ضروری را فعال نگه دارد، تنظیمات را تغییر دهد و در صورت خرابی، زیرساخت را بازیابی کند؟ ممکن است ماشین‌های مجازی در دیتاسنتر سازمان روشن بمانند، اما ورود مدیر همچنان به سامانه‌ای بیرون از سازمان وابسته باشد.
آزمون ابر حاکمیتی اروپایی AWS نمونه‌ای از بررسی این وابستگی‌هاست. برای تیم مجازی‌سازی، معیار آزمون این است که هنگام قطع ارتباط کدام عملیات انجام می‌شود و کدام عملیات تا برقراری دوبارهٔ ارتباط متوقف می‌ماند.
نتیجهٔ آزمون استقلال زیرساخت در ابر اروپایی AWS
AWS در گزارش رسمی ۱ نوامبر ۲۰۲۶ اعلام کرد که در ۲۴ اکتبر ۲۰۲۶، ارتباط ابر حاکمیتی اروپایی خود را برای چند ساعت با دو سامانه قطع کرد. یکی شبکهٔ خصوصی جهانی AWS و دیگری سامانه‌ای برای انتقال محدود و کنترل‌شدهٔ بخشی از داده‌های عملیاتی بود.
در طول آزمون، اینترنت عمومی مسیر جایگزین ترافیکی شد که معمولاً از شبکهٔ خصوصی AWS عبور می‌کرد. طبق گزارش شرکت، دسترس‌پذیری سرویس‌ها در این محیط و ارتباط خصوصی از طریق AWS Direct Connect تحت تأثیر قرار نگرفت. پس از پایان آزمون، ترافیک به مسیر معمول برگشت.
«بارهای کاری به فعالیت ادامه دادند و مشتریان همچنان به داده‌هایشان دسترسی داشتند.»
تفاوت محل نگهداری داده با استقلال زیرساخت
محل داده (Data Residency) مشخص می‌کند داده و نسخه‌های آن کجا نگهداری می‌شوند. استقلال عملیاتی یعنی تیم بتواند هنگام قطع ارتباط بیرونی، زیرساخت را با امکانات در دسترس اداره و بازیابی کند. ممکن است نسخهٔ پشتیبان در دیتاسنتر سازمان باشد، اما کلید رمزگشایی به یک سرویس بیرونی وابسته بماند. برای سنجش این وابستگی، بازیابی را با امکاناتی امتحان کنید که هنگام قطعی در اختیار تیم می‌مانند. مراحل کار در دستورالعمل پشتیبان‌گیری و مدیریت نسخه‌ها آمده است.
جدول زیر پرسش‌های ارزیابی و شواهد لازم را برای هر حوزه نشان می‌دهد:
| موضوع | پرسش ارزیابی | شاهد مورد نیاز |
|---|---|---|
| محل داده | داده و نسخه‌های آن کجا نگهداری می‌شوند؟ | معماری ذخیره‌سازی و مسیر انتقال داده |
| مدیریت زیرساخت | پس از قطع سرویس بیرونی، مدیر می‌تواند وارد سامانه شود و منابع را تغییر دهد؟ | نتیجهٔ ورود با نشست تازه و اجرای یک تغییر مدیریتی |
| پشتیبان‌گیری و بازیابی | فایل، کلید و ابزار لازم برای بازیابی در دسترس‌اند؟ | گزارش بازیابی و بررسی سلامت داده در شرایط آزمون |
| نگهداری و به‌روزرسانی | بسته‌ها، امضاها و مجوزهای لازم از کجا تأمین می‌شوند؟ | نقشهٔ وابستگی و نتیجهٔ آزمون به‌روزرسانی |
AWS در شرح معماری ابر حاکمیتی اروپا به شبکهٔ اختصاصی، ریشهٔ اعتماد اروپایی و سامانهٔ جداگانهٔ مدیریت هویت اشاره می‌کند. در دیتاسنتر سازمان هم بررسی کنید هنگام قطعی، ورود مدیران، صدور گواهی و دسترسی به ابزارهای مدیریت چگونه انجام می‌شود.
آزمون لایهٔ مدیریت پس از قطع ارتباط
ممکن است برنامه‌ها همچنان پاسخ دهند، اما مدیر نتواند ماشین مجازی تازه‌ای بسازد، مجوز کاربری را تغییر دهد یا یک میزبان آسیب‌دیده را جایگزین کند. برای سنجش استقلال زیرساخت، بارهای کاری و لایهٔ مدیریت یا Control Plane را جداگانه آزمایش کنید. رفتار هرکدام به معماری پلتفرم بستگی دارد.
آزمون مدیریت را با یک نشست تازه شروع کنید. نشست قبلی ممکن است تا زمان انقضای توکن برقرار بماند، در حالی که احراز هویت برای ورود تازه از کار افتاده است. پس از ورود، منابع یک ماشین آزمایشی را تغییر دهید و نتیجه را در سوابق سامانه پیدا کنید.
چک‌لیست آزمون استقلال زیرساخت مجازی‌سازی
پیش از آزمون، محدودهٔ اجرا را مشخص کنید. بنویسید کدام ارتباط قطع می‌شود، کدام سرویس باید در دسترس بماند و تیم از چه مسیری وارد پنل مدیریت می‌شود. نخستین اجرا را در محیط آزمایشی یا در بازهٔ مصوب اعمال تغییر انجام دهید. معیار توقف و روش بازگشت به وضعیت عادی را پیش از شروع تعیین کنید.
| حوزه | عملیات آزمایشی | نتیجه‌ای که باید ثبت شود |
|---|---|---|
| هویت و دسترسی | ورود با نشست تازه و تغییر مجوز حساب آزمایشی | وضعیت ورود، اعمال مجوز و وابستگی به سرویس هویت |
| چرخهٔ عمر ماشین مجازی | ایجاد، روشن و خاموش‌کردن ماشین آزمایشی و تغییر منابع آن | عملیات موفق، پیام خطا و زمان انجام هر عملیات |
| کلاستر و میزبان | مهاجرت ماشین مجازی و افزودن میزبان آزمایشی با رعایت پیش‌نیازها | عملیات قابل اجرا و پیش‌نیازهای خارج از محدودهٔ آزمون |
| شبکه | اعمال سیاست شبکه و بررسی نام‌گشایی و همگام‌سازی ساعت | وضعیت DNS و NTP و اثر اختلال هرکدام |
| اسنپ‌شات و پشتیبان‌گیری | گرفتن اسنپ‌شات و اجرای جداگانهٔ بازیابی از نسخهٔ پشتیبان مستقل | سلامت دادهٔ بازیابی‌شده و دسترسی به حساب و کلید لازم |
| دسترس‌پذیری بالا | شبیه‌سازی خرابی میزبان در سناریوی مصوب | رفتار HA، سرویس‌های تحت تأثیر و زمان بازگشت |
| مجوز نرم‌افزار | بررسی رفتار محصول پس از قطع دسترسی به سرور مجوز | مهلت اعتبار و قابلیت‌هایی که در طول آزمون محدود شدند |
| به‌روزرسانی | نصب بستهٔ تأییدشده از مخزن داخلی | دسترسی به بسته و وابستگی‌های آن و امکان تأیید امضا |
| بازیابی لایهٔ مدیریت | بازیابی پنل مدیریت طبق دستورالعمل محصول | زمان بازگشت مدیریت و نیاز به حساب، کلید، ابزار یا پشتیبانی بیرونی |
| پایش و ممیزی | مشاهدهٔ هشدارها و بررسی سوابق تغییرات در زمان قطع ارتباط | تداوم ثبت رویداد و دسترسی تیم عملیات به سوابق |
برای هر ردیف، نتیجه، مدت آزمون و نسخهٔ محصول را ثبت کنید. پس از برقراری دوبارهٔ ارتباط، عملیات معوق، همگام‌سازی و خطاها را بررسی کنید. اگر زیرساخت باید چند روز بدون ارتباط بیرونی کار کند، آزمون را طوری تنظیم کنید که تمدید یا انقضای توکن، گواهی و مجوز نرم‌افزار را هم پوشش دهد.
در نقشهٔ وابستگی زیرساخت چه ثبت کنیم؟
نقشهٔ وابستگی نشان می‌دهد هر جزء از زیرساخت برای انجام کارش به چه سرویسی متکی است. کنار هر سرویس تأمین‌کننده، اثر قطع ارتباط و زمان بروز آن را ثبت کنید. این اطلاعات مشخص می‌کند کدام وابستگی باید زودتر آزمایش شود.
- نام سرویس‌های مصرف‌کننده و تأمین‌کننده و محل استقرارشان را ثبت کنید.
- نوع ارتباط و شرایطی را که سرویس مصرف‌کننده به آن نیاز دارد، بنویسید.
- پیامدهای قطع ارتباط و زمان احتمالی بروز اختلال را در نقشه مشخص کنید.
- مسیر جایگزین و اختیار تیم داخلی برای تغییر تأمین‌کننده را مشخص کنید.
- مسئول نگهداری هر وابستگی و تاریخ آخرین آزمون آن را در نقشه ثبت کنید.
برای مثال، اگر دریافت داده‌های پایش از بیرون قطع شود، ممکن است ماشین‌های مجازی همچنان کار کنند و فقط دید عملیاتی تیم کاهش یابد. اگر سرویس هویت قطع شود، ممکن است ورود مدیران با نشست تازه مختل شود. اولویت آزمون را بر اساس اثری تعیین کنید که هر قطعی بر توان اداره یا بازیابی زیرساخت دارد.
چگونه ادعای تأمین‌کننده دربارهٔ استقلال زیرساخت را بسنجیم؟
محل توسعه محصول و وابستگی عملیاتی آن دو معیار جداگانه‌اند. یک محصول بومی ممکن است برای اعتبارسنجی مجوز یا دریافت به‌روزرسانی به سرویس بیرونی متکی باشد. دربارهٔ یک محصول خارجی هم بررسی کنید کدام اجزای حیاتی را می‌توان در محدودهٔ سازمان مستقر و اداره کرد. از تأمین‌کننده نقشهٔ وابستگی، گزارش آزمون قطع ارتباط و دستورالعمل بازیابی را بخواهید.
گزارش را با نیاز سازمان مقایسه کنید. ببینید چه ارتباطی قطع شده، کدام عملیات برای چه مدتی در دسترس مانده و تیم برای بازیابی به چه حساب، کلید یا ابزار بیرونی نیاز داشته است.
وابستگی‌های زیرساخت هوش مصنوعی محلی
در زیرساخت هوش مصنوعی، یک وظیفهٔ واقعی را از دریافت ورودی تا تحویل خروجی آزمایش کنید. بسته به معماری، درایور GPU، میان‌افزار، مخزن کانتینر و مخزن مدل ممکن است برای راه‌اندازی یا بازیابی سرویس لازم باشند. سرویس هویت و رابط‌های بیرونی را هم در نقشهٔ وابستگی ثبت کنید.
فرض کنید مدل روی سرور سازمان اجرا می‌شود، اما برای تکمیل کار باید از یک رابط بیرونی داده بگیرد. اگر آن رابط قطع شود، ممکن است مدل همچنان پاسخ بدهد و کار در مرحلهٔ دریافت داده متوقف شود. معیار آزمون، تحویل خروجی مورد انتظار در همان شرایط است.
نخستین آزمون استقلال پلتفرم را چگونه اجرا کنیم؟
برای شروع، یک وابستگی حیاتی و یک عملیات روزمره انتخاب کنید. مثلاً ارتباط محیط آزمایشی را با سرویس هویت بیرونی موقتاً قطع کنید. آزمون زمانی موفق است که مدیر از مسیر تعریف‌شده با نشست تازه وارد شود، منابع یک ماشین آزمایشی را تغییر دهد و نتیجه را در سوابق سامانه پیدا کند.
این چارچوب برای ارزیابی استقلال زیرساخت در PVM و سایر پلتفرم‌های مجازی‌سازی قابل استفاده است. کنار هر نتیجه، شرایط اجرا و محدودیت مشاهده‌شده را بنویسید تا مشخص باشد نتیجه برای کدام نسخه، کدام وابستگی و چه مدت قطع ارتباط معتبر است.
