نیاز و دامنه
خدمت، نشانهٔ مسئله، مالک و حدود اختیار را مشخص کنید.
تست سلامت و پایدارسازی شبکه؛ از نیاز واقعی شروع کنیم
تست سلامت برای ارزیابی وضعیت یک خدمت در دامنه و شرایط مشخص است. با عیبیابی یک خطای شناخته‌شده تفاوت دارد، گرچه نتایج آن می‌تواند مسئله‌ای برای بررسی بیشتر پیدا کند. پایدارسازی نیز باید از اقدام و شاهد قابل توضیح تشکیل شود. این مقاله هیچ آزمون فشار، قطع لینک یا تغییر واقعی روی شبکهٔ زنده انجام نمی‌دهد.
شاهد و برنامه
دادهٔ لازم، روش بررسی و مسیر بازگشت را ثبت کنید.
اقدام کنترل‌شده
آزمون مجاز یا تغییر توافق‌شده را با ثبت نتیجه انجام دهید.
تحویل و پیگیری
پذیرش کاربر، محدودیت باقی‌مانده و مسئول پیگیری را تعیین کنید.
دامنه و وضعیت پایه
فهرست محل‌ها، مسیرها، سرویس‌ها و کاربران نمونه را مشخص کنید. بعضی مسیرهای کم‌استفاده ممکن است مهم باشند و در آزمون روزمره دیده نشوند. نسخهٔ تنظیمات و تغییرهای اخیر را ثبت کنید. پیش از شروع معلوم باشد چه چیزی خارج از محدوده است تا گزارش سلامت با ادعای پوشش کامل و بی‌شرط اشتباه نشود.
معیار پذیرش از دید خدمت
عملیات ضروری کاربر را به معیار تبدیل کنید: ورود، دسترسی مجاز و نتیجهٔ درست درخواست نمونه. صرف روشن بودن سوئیچ یا پاسخ میزبان کافی نیست. حدود قابل قبول را با مالک سرویس تعیین کنید، نه بر اساس یک عدد عمومی. Google SRE دربارهٔ آزمون قابلیت اتکا میان آزمون‌های جدا از تولید و بررسی خدمت منتشرشده تفاوت می‌گذارد.
آزمون کم‌خطر و اختیار اجرا
نوع آزمون، منابع درگیر، زمان، مسئول توقف و راه بازگشت را از قبل بنویسید. RFC 6815 استفاده از روش‌های بنچمارک آزمایشگاهی RFC 2544 روی شبکهٔ تولیدی را نامناسب می‌داند. تست حجیم یا تزریق خطا را به صرف وجود ابزار روی شبکهٔ مشترک اجرا نکنید؛ محیط و مجوز باید متناسب باشند.
مسیر عادی و خطاهای تعریف‌شده
در دامنهٔ توافق‌شده، حالت عادی را با مسیر جایگزین و خطای قابل شبیه‌سازی مقایسه کنید. همهٔ سناریوها به قطع واقعی سرویس نیاز ندارند. اگر Failover یا افزونگی ادعا می‌شود، روش پذیرش باید مخصوص همان طراحی باشد. ناتوانی در اجرای یک سناریو را صریح ثبت کنید، نه اینکه آن را ضمنی موفق فرض کنید.
ظرفیت و شرایط نماینده
زمان آرام روز ممکن است وضعیت ساعت شلوغ را نشان ندهد. شرایط بار و کاربران نمونه را با هدف آزمون هماهنگ کنید. ظرفیت باید از پایداری عملکرد واقعی خدمت تفکیک نشود. افزایش بار بدون سقف و معیار توقف، آزمون قابل کنترل نیست؛ اگر آزمایشگاه نماینده ندارید، محدودیت نتیجه را در گزارش بنویسید.
پایدارسازی مرحله‌ای
بر اساس یافته، اقدام کوچک با علت و هدف روشن طراحی کنید. تغییر تنظیمات، به‌روزرسانی یا جایگزینی قطعه باید طبق اختیار و نسخهٔ بازگشت انجام شود. پس از هر اقدام، آزمون مرتبط تکرار شود. چند اصلاح هم‌زمان بدون شاهد می‌تواند هم علت را مخفی کند و هم ارزیابی اثر را دشوار سازد.
ثبت شواهد و پذیرش کاربر
زمان، نسخه، دامنه، ابزار و نتیجهٔ هر بررسی را نگه دارید. موارد ناموفق یا نامعلوم باید کنار موفق‌ها دیده شوند. تأیید مالک خدمت به همان عملیات مورد نیاز مربوط باشد. مستند آزمون با اطلاعات حساس در مسیر عمومی ذخیره نشود؛ خلاصهٔ مدیریتی و شواهد فنی می‌توانند سطح دسترسی متفاوت داشته باشند.
بازآزمون و حدود گزارش سلامت
پس از تغییر شبکه، برنامه یا ظرفیت، آزمون‌های مرتبط را بازبینی کنید. نتیجهٔ یک روز مجوز وعدهٔ نبود اختلال برای همیشه نیست. برنامهٔ پایش و مسئول پیگیری موارد باقی‌مانده را مشخص کنید. هزینه به تعداد محل، دامنهٔ سناریو، محیط آزمایش و زمان مجاز بستگی دارد؛ معیار تحویل باید پیش از اجرا توافق شود.
پایدارسازی و تست سلامت شبکه در ویوان نت
شرح وضعیت، گسترهٔ کاربران و هدف بررسی را آماده کنید تا دامنهٔ خدمت، اختیار اجرا و معیار تحویل قابل تعریف شوند. تعداد کاربران و هدف بررسی را در بخش پشتیبانی ویوان نت توضیح دهید؛ رمز، کلید یا تنظیمات محرمانه را در درخواست معمولی نفرستید.
سناریوی آموزشی: تست سلامت و پایدارسازی شبکه
یک دفتر فرضی پس از تغییر سوئیچ می‌خواهد دسترسی کاربران را تأیید کند. تیم عملیات نمونه، مسیرها و محدودیت آزمون را مشخص می‌کند و بررسی کم‌خطر انجام می‌دهد. مسیر خارج از دسترس آزمایشگاه در گزارش نامعلوم می‌ماند. هر اصلاح کوچک با تکرار همان آزمون سنجیده می‌شود و نتیجه فقط برای دامنه و شرایط بررسی‌شده اعلام می‌شود.
این مثال آموزشی است، نه پروژهٔ واقعی یا نتیجهٔ عددی ویوان نت؛ روش اجرا و آزمون باید با بستر و اختیار سازمان هماهنگ شوند.
این راهنما از مجموعهٔ پشتیبانی، مانیتورینگ و عیبیابی ویوان نت است. برای شناخت مجموعه، معرفی ویوان نت را ببینید.
پرسش‌های متداول دربارهٔ پایدارسازی و تست سلامت شبکه
تست سلامت همان عیبیابی است؟
نه؛ تست سلامت وضعیت را در دامنهٔ مشخص میسنجد، عیبیابی دنبال علت مسئلهٔ مشخص میگردد.
یک نتیجهٔ موفق کافی است؟
برای همان سناریو شاهد است، نه تضمین سلامت دائمی تمام شبکه.
می‌توان تست فشار را روی شبکهٔ زنده اجرا کرد؟
بدون طرح، سقف، اختیار و کنترل خطر نه؛ آزمون آزمایشگاهی را عمومی اجرا نکنید.
معیار پذیرش چه باشد؟
عملیات و حدود مورد نیاز خدمت با توافق مالک، نه صرفاً پاسخ تجهیزات.
سناریوی اجرا‌نشده را چه بنویسیم؟
خارج از پوشش یا نامعلوم، با دلیل و قدم بعدی؛ آن را موفق معرفی نکنید.
چه زمانی بازآزمون لازم است؟
پس از تغییر مرتبط در شبکه، برنامه، تجهیزات یا ظرفیت و طبق برنامهٔ بازبینی.
منابع فنی و مطالعهٔ بیشتر
منابع برای مبانی و نمونهٔ روش‌ها هستند؛ انتخاب محصول، ظرفیت و تنظیمات واقعی باید در زمان اجرا و بستر سازمان بررسی شوند.