تست شبکه سرور مجازی ایران با Ping، Traceroute و MTR؛ تشخیص Packet Loss
تست شبکه سرور مجازی ایران را از خود سرویس شروع کنید برای تست شبکه سرور مجازی ایران، اول مشخص کنید کدام سرویس و کدام کاربران مشکل دارند. سپس از یک شبکهٔ دیگر همان درخواست را تکرار کنید. اگر مقصد به Ping جواب می‌دهد ولی وب‌سایت باز نمی‌شود، پورت و پاسخ وب را جداگانه بررسی کنید. اگر فقط یک مسیریاب م...
تست شبکه سرور مجازی ایران را از خود سرویس شروع کنید
برای تست شبکه سرور مجازی ایران، اول مشخص کنید کدام سرویس و کدام کاربران مشکل دارند. سپس از یک شبکهٔ دیگر همان درخواست را تکرار کنید. اگر مقصد به Ping جواب می‌دهد ولی وب‌سایت باز نمی‌شود، پورت و پاسخ وب را جداگانه بررسی کنید. اگر فقط یک مسیریاب میانی در MTR بخشی از پاسخ‌ها را نمی‌فرستد و مقصد در همان گزارش پاسخ پایدار دارد، آن ردیف به‌تنهایی دلیل خرابی نیست. زمانی گزارش قابل پیگیری می‌شود که نشانهٔ انتهایی، زمان دقیق و شرایط بازتولید را کنار هم ثبت کنید.
فرض کنید فروشگاه برای چند مشتری در ساعات عصر دیر باز می‌شود. «پینگ سرور بالاست» توضیح کافی برای تصمیم دربارهٔ ارتقا یا جابه‌جایی نیست. ممکن است درخواست در DNS متوقف شده باشد، اتصال TCP دیر برقرار شود، مذاکرهٔ TLS زمان ببرد یا برنامه پس از دریافت درخواست منتظر دیتابیس بماند. این وضعیت‌ها از دید کاربر شبیه‌اند ولی با مشاهده‌های متفاوتی تشخیص داده می‌شوند. در این مقاله یک آزمون کوتاه از دید مشتری می‌سازیم و با Ping، Traceroute و MTR آن را تکمیل می‌کنیم. هدف این است که بتوانید برای خودتان یا پشتیبانی گزارشی تهیه کنید که به اقدام مشخص منجر شود.
فهرست مطالب
- تعریف معیار و سناریوی تست
- اندازه‌گیری با Ping
- خواندن Traceroute
- تفسیر MTR و افت بسته
- آزمون کاربردی سرویس
- گزارش به پشتیبانی و چک‌لیست خرید
- پرسش‌های متداول
تعریف معیار و سناریوی تست
از چه چیزی اندازه می‌گیریم؟
تأخیر رفت و برگشت، فاصلهٔ ارسال درخواست آزمایشی تا دریافت پاسخ آن است. این زمان دو جهت مسیر و زمان پاسخ‌دهی مقصد را شامل می‌شود. از همین عدد نمی‌توانید تأخیر رفت را مستقل از برگشت مشخص کنید. افت بسته در گزارش یک ابزار آزمایشی هم نسبت درخواست‌هایی است که پاسخ مورد انتظارشان در همان آزمون دریافت نشده است. برای نتیجه‌گیری دربارهٔ کیفیت سرویس، نوع درخواست، تعداد نمونه و زمان انتظار را ثبت کنید. اگر مقصد به یک نوع درخواست پاسخ نمی‌دهد، از یک تست کاربردی که با رفتار کاربران مطابقت دارد استفاده کنید.
Jitter یا نوسان تأخیر در کاربرد عملی به تغییر زمان رسیدن یا زمان پاسخ در طول نمونه‌برداری اشاره دارد. تعریف دقیق به شیوهٔ اندازه‌گیری وابسته است. برای یک گزارش عمومی کافی است توضیح دهید میانگین، دامنهٔ تغییر یا انحراف معیار RTT را از کدام ابزار برداشته‌اید. اختلاف بالا میان پاسخ‌های عادی و کند، حتی وقتی میانگین قابل قبول است، برای بعضی کارها مهم است. تماس تعاملی و بازی به نوسان واکنش متفاوتی نسبت به دانلود یک فایل بزرگ دارند. هنگام خرید، معیار را از نیاز برنامه استخراج کنید و نتایج گروه کاربران هدف را جدا نگه دارید.
نقشهٔ تست را قبل از جمع‌آوری خروجی بنویسید
برای یک بررسی کوچک، یک مبدأ تحت تأثیر، یک مبدأ مقایسه و یک مقصد عمومی مجاز انتخاب کنید. مشخص کنید هر مبدأ با کدام اپراتور وصل است و آیا در زمان تست VPN یا پراکسی فعال دارد. سپس بازهٔ زمانی، نام دامنه، IP مقصد و پروتکل را بنویسید. از ساعت‌های قابل مقایسه استفاده کنید. اگر مشتری ساعت را با منطقهٔ زمانی دیگری گزارش می‌دهد، ابتدا آن را تبدیل کنید. این یادداشت کمک می‌کند خروجی‌های افراد مختلف را اشتباهی به یک رخداد منتسب نکنید.
اگر مشکل فقط روی وای‌فای یک دفتر دیده می‌شود، یک آزمون کنترل از همان دفتر با اتصال سیمی انجام دهید. اگر کل دفتر تحت تأثیر است، یک کاربر از اپراتوری دیگر همان نشانی را آزمایش کند. در صورت امکان، درخواست سرویس را در کنار تست شبکه اجرا کنید. تفاوت نتیجه بین دو مبدأ فرضیه‌ای دربارهٔ محل مشکل می‌سازد و دادهٔ کافی برای نسبت دادن قطعی خطا به یک شرکت فراهم نمی‌کند. تیم پشتیبانی می‌تواند با سنجش از سمت دیگر و بررسی رخدادهای خودش دامنهٔ مشکل را محدود کند.
| هدف | دادهٔ لازم | نمونهٔ مقایسه |
|---|---|---|
| سنجش دسترسی | پاسخ پورت و درخواست واقعی | همان URL از دو اپراتور |
| بررسی تأخیر | RTT و بازهٔ نمونه‌برداری | زمان سالم و زمان اختلال |
| تفسیر افت | تعداد نمونه و نتیجهٔ مقصد | یک نوع پروب روی دو مسیر |
| یافتن اثر عملی | خطا و مدت پاسخ برنامه | لاگ برنامه در همان دقیقه |
فرق مسئلهٔ شبکه با ازدحام منابع سرور
وقتی سیستم‌عامل برای پردازش زمان کافی ندارد، درخواست شبکه ممکن است دیر پاسخ بگیرد. وقتی برنامه منتظر دیسک یا پایگاه داده است، مرورگر هم کندی حس می‌کند. برای همین اگر پایش خود سرور در دسترس است، در بازهٔ مشکل مصرف پردازنده، صف کارها و لاگ برنامه را هم ببینید. یک شاهد شبکه و یک شاهد از داخل سرویس انتخاب کنید. اگر پاسخ Ping پایدار است و فقط زمان پاسخ برنامه بیشتر شده، از بررسی زمان پردازش درخواست شروع کنید. اگر برقراری اتصال هم هم‌زمان کند شده، مسیر و محدودیت‌های نقطهٔ ورود ارزش بررسی بیشتری پیدا می‌کنند.
اندازه‌گیری با Ping
یک تست کوتاه از مبدأ تحت تأثیر
Ping برای گرفتن تصویری اولیه از دسترسی و RTT مناسب است. آن را در حد نمونه‌برداری معمول و روی مقصدی اجرا کنید که اجازهٔ آزمون آن را دارید. در نمونهٔ لینوکس، گزینهٔ شمارش مانع اجرای بی‌پایان می‌شود. در ویندوز همان هدف با گزینهٔ شمارش متفاوت انجام می‌شود. مقصد نمونه را با نام یا IP سرویس خودتان جایگزین کنید. نتیجه را در یک شبکهٔ سالم هم با شرایط مشابه بگیرید. برای مقایسه، تعداد نمونه، مبدأ، زمان، IP و نسخهٔ آدرس را ثابت نگه دارید.
ping -c 20 example.com
ping -n 20 example.com [Windows]خلاصهٔ Ping را کامل بخوانید. تعداد ارسال، تعداد دریافت و نسبت افت را در کنار حداقل، میانگین و بیشینه ببینید. یک افزایش لحظه‌ای در بیشینه برای تصمیم خرید یا جابه‌جایی کافی نیست. اگر کاربر در یک بازهٔ تکرارشونده اختلال دارد، نمونه را در همان بازه تکرار کنید. نمونهٔ ساعت خلوت را برای خط پایه نگه دارید. اگر در هر دو بازه یک نتیجه به دست آمد ولی برنامه فقط در ساعت خاص مشکل دارد، رخدادهای برنامه و ظرفیت سرویس را در اولویت بگذارید.
وقتی Ping جواب نمی‌دهد اما سرویس باز است
برخی دستگاه‌ها یا سیاست‌های شبکه به درخواست ICMP Echo پاسخ نمی‌دهند یا تعداد پاسخ‌ها را محدود می‌کنند. در این حالت عدم پاسخ به Ping در کنار باز شدن موفق سرویس به شما می‌گوید روش تست برای سنجش دسترسی آن سرویس کافی نیست. اگر سایت عمومی است، از یک درخواست HTTPS معمول و مجاز استفاده کنید. اگر موضوع یک سرویس دیگر است، از همان پروتکل و مقصد مورد انتظار آن سرویس استفاده کنید. گاهی آزمایش یک پورت تصادفی گزارش را مبهم می‌کند چون پورت مورد آزمایش از ابتدا قرار نبوده باز باشد.
وقتی میانگین خوب است اما کاربر همچنان کندی حس می‌کند
میانگین می‌تواند چند پاسخ بسیار کند را پنهان کند. مثلاً اگر ده‌ها پاسخ در یک محدودهٔ ثابت باشند و چند پاسخ نزدیک به پایان زمان انتظار برسند، خلاصه ممکن است همچنان قابل قبول به نظر برسد. برای همین نمونه‌های منفرد و بازهٔ تغییر را نگه دارید. از کاربر بپرسید کندی در همهٔ درخواست‌ها رخ می‌دهد یا چند بار در دقیقه. اگر زمان‌های جهش با همان گزارش‌ها هم‌خوان است، یک آزمون پروتکل واقعی در همان بازه بگیرید. بهتر است نوع و زمان هر درخواست مشخص باشد تا بتوانید کندی مسیر را از پردازش برنامه جدا کنید.
زمان پایان مهلت و اندازهٔ نمونه
در یک آزمون کوتاه با تعداد نمونهٔ کم، یک پاسخ گمشده درصد بزرگی می‌سازد. نتیجه را با تعداد نمونه گزارش کنید تا خواننده بتواند شدت مشاهده را بفهمد. زمان انتظار ابزار هم روی شمارش اثر دارد. یک پاسخ دیررس ممکن است در تستی ثبت شود و در تست دیگری با مهلت کوتاه‌تر از دست برود. ابتدا روش را ثابت کنید، بعد آزمایش را چند بار در فاصلهٔ منطقی تکرار کنید. اگر شبکهٔ کاربر در زمان تست تغییر می‌کند یا کاربر جابه‌جا می‌شود، مبدأ جدید را جدا ثبت کنید.
خواندن Traceroute
هر ردیف چه چیزی را نشان می‌دهد؟
Traceroute برای پیدا کردن گام‌های قابل مشاهدهٔ مسیر از پروب‌هایی با حد عبور تدریجی استفاده می‌کند. یک دستگاه میانی ممکن است پس از پایان آن حد، پیام مرتبط ارسال کند. زمان نشان‌داده‌شده برای هر گام از مبدأ تا پاسخ همان گام و برگشت آن است. بنابراین اختلاف سادهٔ زمان دو ردیف به شما تأخیر قطعی لینک میان آن‌ها را نمی‌دهد. مسیر برگشت پیام می‌تواند متفاوت باشد و اولویت پاسخ خود مسیریاب هم ممکن است با اولویت عبور بسته‌های کاربر فرق داشته باشد.
در لینوکس و ویندوز ابزارها و روش پیش‌فرض می‌توانند متفاوت باشند. خروجی را همراه فرمان دقیق نگه دارید تا معلوم باشد چه نوع تستی اجرا شده است. در یک مقایسهٔ درست، ابتدا به مقصد و تداوم الگو نگاه کنید. ردیفی که پاسخ نمی‌دهد ممکن است ترافیک را عبور دهد. اگر گام‌های بعدی و مقصد همچنان پاسخ می‌دهند، عبور از بخش قابل مشاهدهٔ مسیر در همان آزمون اتفاق افتاده است. برای تحلیل، نشانه‌های انتهایی و وضعیت سرویس کاربردی را روی همان گزارش یادداشت کنید.
traceroute -n example.com
tracert -d example.com [Windows]چرا بعضی گام‌ها چند نشانی یا ستاره دارند؟
در یک مسیر متوازن، پروب‌های مختلف ممکن است از مسیرهای هم‌ارز متفاوت عبور کنند. یک گام می‌تواند بیش از یک نشانی نشان دهد. ستاره هم یعنی برای همان پروب در مهلت ابزار پاسخ ثبت نشده است. بعضی دستگاه‌ها پاسخ تشخیصی نمی‌فرستند و بعضی در زمان فشار تعداد پاسخ‌ها را محدود می‌کنند. اگر مقصد پاسخ دارد، آن گام را جداگانه به‌عنوان محل قطعی معرفی نکنید. برای بررسی، بازهٔ زمانی و نتیجهٔ نهایی را ثبت کنید و از یک مبدأ دیگر همان مقصد را بسنجید.
مقایسهٔ مسیر در زمان سالم و زمان اختلال
دو خروجی را کنار هم بگذارید و ببینید اولین تفاوت پایدار کجاست. تغییر مسیر بدون افت کیفیت می‌تواند طبیعی باشد. تغییر مسیر همراه با مشکل انتهایی ارزش ثبت بیشتری دارد. اگر ابزار در هر بار ترتیب متفاوتی نشان می‌دهد، چند نمونهٔ محدود از همان مبدأ بگیرید و الگوی غالب را ثبت کنید. اگر سرویس پشت یک سامانهٔ توزیع محتواست، ابتدا بررسی کنید هر دو آزمون واقعاً به همان نشانی رسیده‌اند. در غیر این صورت تفاوت مسیر ممکن است نتیجهٔ تغییر مقصد باشد.
ثبت IP نهایی و نسخهٔ آدرس
نام دامنه ممکن است چند پاسخ IPv4 یا IPv6 داشته باشد. دو مشتری گاهی یک نام را باز می‌کنند اما به مسیرهای متفاوتی می‌رسند. IP مشاهده‌شده در آزمون را کنار نام دامنه بنویسید. اگر قرار است دو نتیجه مقایسه شود، مشخص کنید هر دو از یک خانوادهٔ آدرس استفاده کرده‌اند یا گزارش‌ها جداگانه به عنوان IPv4 و IPv6 نگهداری می‌شوند. اگر مشکل فقط در یکی از این دو مسیر دیده می‌شود، این نکته را در عنوان تیکت بیاورید.
چه زمانی یک مقایسه را معتبر بدانیم؟
وقتی نام سرویس، IP مقصد، نوع پروب، مبدأ و بازهٔ زمانی مشخص است، می‌توان تغییر مشاهده‌شده را بهتر تفسیر کرد. یک نمونه از مسیر سالم و یک نمونه از مسیر مشکل‌دار به‌تنهایی نتیجهٔ قطعی نمی‌سازند، اما با تکرار کنترل‌شده و شاهد کاربردی، الگو روشن‌تر می‌شود. وضعیت درخواست واقعی را هم در همان بازه ثبت کنید. در زمان تحویل گزارش، مشخص کنید کدام مقایسه با شرایط یکسان انجام شده و کدام خروجی صرفاً برای زمینه آمده است.
تفسیر MTR و افت بسته
اول ردیف مقصد را بخوانید
MTR نمونه‌برداری تکراری را با مشاهدهٔ گام‌های مسیر ترکیب می‌کند. گزارش را از مقصد شروع کنید و تعداد ارسال، درصد افت و تغییرات زمان پاسخ را ببینید. سپس به عقب برگردید و بررسی کنید آیا الگوی نامعمول از گامی شروع شده و در گام‌های بعدی هم ادامه دارد. اگر فقط یک ردیف افت زیادی دارد ولی مقصد و گام‌های بعدی سالم‌اند، آن ردیف نشانهٔ کافی برای افت ترافیک عبوری نیست. ممکن است دستگاه به بخشی از درخواست‌های تشخیصی خودش پاسخ ندهد.
«a router might limit the number of ICMP replies that it emits» — راهنمای AWS دربارهٔ تفسیر MTR
mtr -n -r -c 50 example.com
mtr -n -r -c 50 --tcp -P 443 example.comادامه یافتن افت تا مقصد چه معنایی دارد؟
اگر الگوی افت از جایی شروع می‌شود و در مقصد هم دیده می‌شود، شواهد مربوط به اثر انتهایی قوی‌تر است. با این حال از یک گزارش نمی‌توان مالک دقیق پیوند یا جهت رخداد را قطعی تعیین کرد. بسته‌ها و پاسخ‌هایشان ممکن است مسیرهای متفاوتی داشته باشند. همچنین مقصد ممکن است خودش سیاست محدودسازی داشته باشد. برای بررسی کاربردی، همان زمان یک درخواست به سرویس واقعی بگیرید و نتیجه را از مبدأ دوم مقایسه کنید. اگر امکان تست مجاز از سمت مقصد وجود دارد، یک گزارش برگشت به مبدأ قابل دسترس هم اطلاعات بیشتری فراهم می‌کند.
| الگوی مشاهده‌شده | برداشت قابل دفاع | اقدام بعدی |
|---|---|---|
| یک گام میانی افت دارد و مقصد سالم است | همان گام همهٔ پروب‌ها را پاسخ نداده است | نتیجهٔ سرویس را بررسی کنید |
| افت تا مقصد ادامه دارد | احتمال اثر انتهایی وجود دارد | آزمون سرویس و مبدأ دوم را اضافه کنید |
| مقصد پاسخ ICMP ندارد ولی HTTPS موفق است | ICMP برای دسترسی وب معیار کافی نیست | HTTPS و TCP مجاز را بسنجید |
| میانگین ثابت است اما بیشینه جهش دارد | پاسخ‌های دیررس پراکنده‌اند | زمان رخداد و تعداد نمونه را مقایسه کنید |
| چند مبدأ هم‌زمان مشکل دارند | احتمال یک بخش مشترک وجود دارد | لاگ برنامه و وضعیت مقصد را تطبیق دهید |
چه وقت پروب TCP مناسب‌تر است؟
اگر سرویس شما روی HTTPS است و سیاست شبکه به ICMP پاسخ نمی‌دهد، در نسخه‌های مناسب MTR می‌توانید نمونهٔ TCP را روی پورت سرویس خودتان اجرا کنید. نتیجه همچنان یک پروب تشخیصی است و رفتار درخواست کامل HTTP را نشان نمی‌دهد. نسخه و گزینه‌های ابزار را پیش از اجرا ببینید، چون ممکن است پیاده‌سازی یا دسترسی در محیط فرق کند. استفاده از نمونهٔ محدود و پورت شناخته‌شده به خوانایی گزارش کمک می‌کند. نتیجهٔ TCP را با Ping ادغام نکنید مگر اینکه نوع هر نمونه روشن باشد.
مثال عددی با ردیف میانی و مقصد سالم
تصور کنید از ۵۰ پروب، یک گام میانی ۲۵ پاسخ داده است ولی مقصد هر ۵۰ پاسخ را ثبت کرده و صفحهٔ آزمایشی هم در همان بازه باز می‌شود. این مشاهده نشان می‌دهد گام میانی به بخشی از درخواست‌های خودش جواب نداده است. از همین داده نمی‌توان گفت نیمی از درخواست‌های کاربران از بین می‌رود. اگر کاربر همچنان کندی گزارش می‌کند، آزمون را بر اساس سرویس واقعی ادامه دهید. در تیکت هم هر دو عدد و وضعیت درخواست واقعی را بنویسید تا ردیف میانی جدا از زمینه خوانده نشود.
مثال عددی با مشکل انتهایی
در نمونه‌ای دیگر، هم مقصد چند پاسخ را از دست می‌دهد و هم درخواست‌های وب در همان بازه با خطای اتصال روبه‌رو می‌شوند. از یک مبدأ دیگر همان نشانی بدون خطا باز می‌شود. این وضعیت به شما یک مسیر بررسی می‌دهد. زمان، اپراتور، نشانی واقعی و پروتکل را ثبت کنید و نتیجهٔ دو مبدأ را کنار هم بدهید. اگر مشکل از مسیر یک اپراتور دیده می‌شود، پشتیبانی با نمونهٔ دقیق می‌تواند شواهد مسیر و وضعیت مقصد را بررسی کند. تغییر فوری پلن بر اساس یکی از خروجی‌ها ممکن است علامت را دست‌نخورده بگذارد.
خروجی طولانی همیشه گزارش بهتر نمی‌سازد
برای شروع یک گزارش محدود بگیرید و همان بازه را با رخداد مشتری هماهنگ کنید. گزارش چند ساعت نمونه‌برداری اگر زمان شروع و پایان اختلال در آن نامشخص باشد، تفسیر سخت‌تری دارد. در رخداد متناوب، چند نمونهٔ کوتاه در بازه‌های مشخص می‌توانند بهتر نشان دهند چه زمانی وضع تغییر کرده است. برای هر فایل نامی بگذارید که مبدأ و ساعت را روشن کند. در فرایند داخلی، نتیجهٔ خام را نگه دارید تا اگر پشتیبانی درخواست کرد جزئیات در دسترس باشد.
آزمون کاربردی سرویس
مراحل پاسخ وب را جداگانه اندازه بگیرید
یک صفحهٔ سبک از سایت خود انتخاب کنید که باز شدنش نیاز به نشست کاربر نداشته باشد. درخواست را با نام واقعی دامنه بفرستید تا DNS، نام میزبان و گواهی TLS همان مسیر معمول را طی کنند. سپس زمان پیدا کردن نشانی، زمان برقراری اتصال، زمان تکمیل TLS و زمان دریافت نخستین بایت را ثبت کنید. مقادیر curl از شروع درخواست محاسبه می‌شوند و برخی مراحل در مقدار نهایی جمع شده‌اند. برای تخمین زمان یک مرحله، مقدار پایان آن را با پایان مرحلهٔ قبلی مقایسه کنید. قبل از مقایسه ببینید اتصال جدید برقرار شده، تغییر مسیر رخ داده یا درخواست دیگری در همان اجرای ابزار وجود داشته است.
curl -sS -o /dev/null --max-time 15 -w 'status=%{http_code} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n' https://example.com/اگر هدف شما سنجش سرور اصلی است ولی سرویس از کش عمومی پاسخ می‌دهد، مشخص کنید نتیجه مربوط به کدام مسیر است. درخواست موفق به یک صفحهٔ کش‌شده می‌تواند دسترسی کاربر به همان صفحه را تأیید کند و دربارهٔ درخواست‌های پویا اطلاعات محدودی بدهد. برای آزمون پویا یک صفحهٔ عمومی و سبک انتخاب کنید که رفتار آن را می‌شناسید. مسیرهای مدیریتی و عملیات تغییر داده برای این آزمون مناسب نیستند. نوع پاسخ، کد HTTP و نام مسیر را در گزارش بنویسید. اگر دو درخواست به دو مسیر متفاوت می‌روند، زمان‌های آن‌ها را با برچسب جدا نگه دارید.
نمونهٔ DNS کند و اتصال عادی
یک مشتری می‌گوید نخستین بار باز شدن سایت کند است و پس از آن صفحات سریع‌تر می‌آیند. اگر در چند اجرای مستقل زمان جست‌وجوی نام بالاست و پس از دریافت نشانی، TCP و TLS در محدودهٔ معمول همان مشتری تمام می‌شوند، بررسی DNS منطقی است. نام و پاسخ IPv4 یا IPv6 مشاهده‌شده را یادداشت کنید. از مبدأ دوم همین دامنه را بررسی کنید و به تفاوت پاسخ یا مدت جست‌وجو توجه کنید. تغییر عمومی DNS در این مرحله هنوز تصمیم قطعی نیست. ابتدا با فرد مسئول دامنه یا پشتیبانی دربارهٔ رفتار مشاهده‌شده و نتیجهٔ آزمون مقایسه صحبت کنید.
نمونهٔ اتصال عادی و پاسخ دیرهنگام برنامه
فرض کنید تأخیر Ping در هر دو زمان مشابه است و اتصال و TLS هم تفاوت چشمگیری ندارند. با این حال دریافت نخستین بایت فقط برای جست‌وجوی داخلی فروشگاه دیر می‌شود. در این حالت ثبت زمان درخواست و مسیر صفحه به تیم برنامه کمک می‌کند لاگ و زمان دیتابیس را در همان بازه ببیند. اگر فقط یک عملیات طول می‌کشد، بررسی آن عملیات از تکرار آزمون مسیر مفیدتر است. اگر همهٔ مسیرها و حتی صفحهٔ سبک با همان الگو دیر پاسخ می‌دهند، دامنهٔ بررسی گسترده‌تر می‌شود. زمان نخستین بایت می‌تواند علاوه بر پردازش برنامه از عوامل دیگری هم تأثیر بگیرد و به‌تنهایی علت را تعیین نمی‌کند.
نمونهٔ کد خطای وب با مسیر پاسخ‌گو
وقتی مرورگر یک پاسخ ۵۰۳ دریافت می‌کند، دست‌کم یک مؤلفهٔ وب در مسیر پاسخی داده است. همان کد را همراه با زمان، URL و شناسهٔ درخواست در صورت وجود ثبت کنید. بررسی کنید پاسخ را سامانهٔ واسط داده یا برنامهٔ اصلی. برای تکرار آزمون، تعداد کمی درخواست با فاصلهٔ مناسب کافی است. در رخداد واقعی، تکرار سریع روی یک سرویس درگیر می‌تواند نتایج را تغییر دهد. اگر پاسخ خطا فقط برای یکی از مشتریان رخ می‌دهد، مبدأ و زمان را جدا ثبت کنید تا بتوان اثر سیاست دسترسی یا مسیر واسط را بررسی کرد.
سرعت دانلود، پینگ و سقف ترافیک را جدا نگه دارید
تأخیر رفت و برگشت و سرعت انتقال فایل دو شاخص متفاوت‌اند. زمان رسیدن پاسخ کوچک دربارهٔ ظرفیت انتقال یک فایل بزرگ حکم قطعی نمی‌دهد. برای مقایسهٔ دانلود از فایل نمونهٔ مجاز، حجم مشخص و همان شرایط آزمون استفاده کنید. بار انتقال را با نیاز واقعی پروژه تطبیق دهید و سقف ترافیک یا نرخ انتقال را از شرایط سرویس بخوانید. اگر یک کار دانلود بزرگ با افزایش زمان پاسخ بقیهٔ درخواست‌ها هم‌زمان شده، هر دو رخداد را با زمان مشخص گزارش کنید. توضیح نحوهٔ محاسبه و پایش ترافیک سرور مجازی برای بررسی حجم مصرفی مکمل این آزمون است.
دو مبدأ، دو نتیجه و یک تصمیم قابل دفاع
فرض کنید کاربران یک اپراتور هنگام ارسال فرم سفارش چند بار با پایان مهلت روبه‌رو می‌شوند. در مبدأ اول از سه آزمون سبک، یکی در برقراری اتصال کند است. در مبدأ دوم هر سه درخواست در بازهٔ عادی پاسخ می‌گیرند. این داده برای جمع‌بندی مسیر یا نسبت دادن مشکل به یک مالک کافی نیست، اما نشان می‌دهد مشکل عمومی در همهٔ مبدأها بازتولید نشده است. اگر تیم برنامه لاگ دریافت درخواست‌ها را دارد، بررسی کند آیا درخواست‌های ناموفق به برنامه رسیده‌اند. نتیجهٔ این تطبیق دامنهٔ پیگیری را مشخص‌تر می‌کند.
در بررسی بعدی مسیر مقایسه را عوض نکنید مگر اینکه تغییر را در گزارش بیاورید. انتقال از اینترنت ثابت به موبایل، تغییر VPN یا جابه‌جایی به یک صفحهٔ دیگر ممکن است چند عامل را یکجا تغییر دهد. بهتر است ابتدا تنها یک عامل را عوض کنید و شاهد حاصل را ثبت کنید. برای مثال همان دستگاه و همان نشانی را یک بار از اتصال ثابت و یک بار از اتصال موبایل آزمایش کنید. اگر نتایج فرق دارند، یک کاربر دوم از همان اپراتور نمونه بدهد تا معلوم شود وضعیت منحصر به همان اتصال است یا در چند مبدأ دیده می‌شود.
گزارش به پشتیبانی و چک‌لیست خرید
گزارش را با اثر کاربر شروع کنید
در خط اول بگویید چه چیزی برای کاربر از کار افتاده است. مثلاً بنویسید بخشی از کاربران هنگام باز کردن صفحهٔ ورود با پایان مهلت اتصال مواجه شده‌اند. در خط بعد زمان شروع و بازهٔ اندازه‌گیری را با منطقهٔ زمانی ذکر کنید. سپس اپراتور مبدأ، دامنه، IP نهایی، نسخهٔ آدرس و نوع تست را بنویسید. گزارش‌های Ping یا MTR را به‌عنوان پیوست اضافه کنید و در متن تیکت نتیجهٔ ردیف مقصد را خلاصه کنید. نام و نوع پروب را نگه دارید تا پشتیبانی بتواند آزمایش هم‌ارز انجام دهد.
اگر فقط یک بار نتیجه گرفتید، در گزارش بگویید یک نمونه است. اگر سه نمونه دارید، زمان و نتیجهٔ هر سه را جدا بنویسید. حتی یک نمونهٔ سالم در کنار نمونهٔ ناموفق برای رخداد متناوب مفید است. پیام نمونه می‌تواند چنین باشد: از ساعت ۱۸:۱۰ تا ۱۸:۲۰ تهران، درخواست HTTPS از یک اپراتور در دو نوبت به پایان مهلت رسید. از مبدأ دوم همان نام دامنه باز شد. IP مقصد و نتیجهٔ پروب TCP در پیوست آمده است. لطفاً وضعیت مقصد و مسیر مرتبط در این بازه بررسی شود. قبل از ارسال، کوکی، توکن و محتوای محرمانه را از خروجی بردارید.
چه چیزی در پیگیری بعدی ثبت شود؟
وقتی پشتیبانی یک اقدام انجام می‌دهد، زمان دقیق و آنچه باید دوباره آزموده شود را یادداشت کنید. نتیجهٔ پس از تغییر را با روش پیشین بگیرید. اگر پیش از تغییر فقط یک مبدأ مشکل داشت، آزمون را از همان مبدأ تکرار کنید. در گزارش بنویسید آیا کاربر توانسته همان عمل را دوباره انجام دهد. اگر مسیر تغییر کرده ولی نتیجهٔ کاربر بهبود نیافته، این دو مشاهده را کنار هم ثبت کنید. هدف بستن رخداد با یک معیار روشن است. برای پروژه‌های حساس، آخرین نتیجهٔ سالم را در برگهٔ رخداد نگه دارید تا بعداً بتوان تفاوت زمان‌ها را مرور کرد.
چک‌لیست خرید بر اساس تجربهٔ کاربران
پیش از خرید مشخص کنید بیشتر کاربران از چه منطقه و اپراتورهایی وصل می‌شوند. برای تیمی که نرم‌افزار داخلی دارد، اینترنت دفتر و اتصال دورکار اهمیت دارند. برای فروشگاه، گروه کاربران واقعی را در نظر بگیرید. از ارائه‌دهنده دربارهٔ امکان آزمون مجاز روی مقصد نمونه، اطلاعات مسیر و شیوهٔ گزارش اختلال سؤال کنید. اگر مقصد نمونه با سرویس نهایی فرق دارد، بپرسید در چه چیزهایی نمایندهٔ سرویس است. نمونهٔ آزمایشی را با همان پروتکل معمول کاربران بسنجید تا تصمیم به عدد Ping محدود نشود.
جدولی برای نیازهای سرویس خود تهیه کنید. بازهٔ کاری، عملیات مهم، شاخص مقایسه و روش ثبت نتیجه را بنویسید. برای یک پنل مدیریتی، باز شدن صفحه و مدت ورود ممکن است مهم باشد. برای برنامهٔ تعاملی، تداوم اتصال و دامنهٔ نوسان اهمیت بیشتری دارد. یک آزمون را در ساعت پرترافیک و دیگری را در ساعت آرام تکرار کنید. اگر یک مورد نامعمول دیدید، قبل از خرید نتیجه را بازتولید کنید یا از پشتیبانی توضیح بخواهید. شرایط شبکه در طول زمان تغییر می‌کند و هیچ نمونهٔ کوتاهی نمایندهٔ همهٔ کاربران در تمام ساعات نیست.
| نیاز | پرسش پیش از خرید | شواهد مورد انتظار |
|---|---|---|
| کاربران چند اپراتور | مقصد نمونهٔ مجاز برای مقایسه کدام است؟ | پاسخ ثبت‌شده از دو شبکه |
| سرویس وب حساس | آزمون اتصال و HTTPS از کجا انجام شود؟ | نتیجهٔ مقصد و زمان پاسخ صفحه |
| پشتیبانی رخداد | چه اطلاعاتی در تیکت لازم است؟ | فهرست داده‌ها و کانال پیگیری |
| افت متناوب | چگونه بازهٔ اختلال بررسی می‌شود؟ | نمونهٔ سالم و ناموفق با زمان مشخص |
برای تطبیق نیازتان با سرویس، از صفحهٔ سرور مجازی ایران وطن هاست شروع کنید و سؤال‌های جدول را با شرایط اعلام‌شده بررسی کنید. کاربردهای سرور مجازی ایران برای کسب‌وکارها به انتخاب سناریوی آزمایش کمک می‌کند. اگر شواهد به مصرف پردازنده مربوط‌اند، راهنمای بررسی CPU Steal مسیر بررسی داخل سرور را توضیح می‌دهد. برای دیدن دستهٔ کلی سرویس‌ها هم می‌توانید صفحهٔ سرور مجازی را بررسی کنید.
نمونهٔ دفتر کار با اینترنت ثابت و پشتیبان موبایل
در یک دفتر فرضی، نرم‌افزار حسابداری در ساعت مشخصی برای بعضی همکاران دیر باز می‌شود. برای آزمون، یک رایانه را انتخاب کنید و پیش از تعویض اتصال، نشانی مقصد و یک عمل سبک مانند باز کردن صفحهٔ ورود را ثابت نگه دارید. ابتدا نتیجه را در اتصال معمول دفتر ثبت کنید. سپس در همان فاصلهٔ زمانی، از اینترنت موبایل با همان رایانه و همان نشانی استفاده کنید. اگر نتیجه متفاوت است، بررسی کنید آیا VPN، فیلتر سازمانی یا پاسخ DNS در دو اتصال فرق دارد. در گزارش مشخص کنید که تغییر اتصال ممکن است بیش از یک عامل را تغییر داده باشد.
اگر همکار دیگری از همان اینترنت دفتر مشکل را بازتولید می‌کند، زمان و نتیجهٔ آن را کنار گزارش اول قرار دهید. اگر فقط همان رایانه مشکل دارد، تنظیمات دستگاه، پروکسی و سیاست‌های مرورگر هم ارزش بررسی دارند. پیش از نتیجه‌گیری دربارهٔ سرور، ببینید کاربران دیگر می‌توانند همان عمل را در زمان مشابه انجام دهند. یک آزمون موفق در موبایل در کنار مشکل دفتر اطلاعات مفید می‌دهد، اما معلوم نمی‌کند کدام دستگاه در تمام مسیر علت است. تیم شبکه یا میزبان با دیدن دو نمونه می‌تواند بررسی خود را دقیق‌تر شروع کند.
چگونه نتیجهٔ ساعات شلوغ را با خط پایه مقایسه کنیم؟
اگر فقط در ساعت‌های عصر گزارش دریافت می‌کنید، یک نمونه در بازهٔ مشکل و یک نمونه در بازهٔ سالم بگیرید. تعداد درخواست‌ها، مقصد و نوع ابزار را یکسان نگه دارید. در خط پایه نتیجهٔ صفحهٔ عمومی و نتیجهٔ یک مسیر پویا را جداگانه بنویسید. اگر هر دو در ساعت شلوغ دیر می‌شوند، از مبدأ دوم همان سناریو را امتحان کنید. اگر فقط صفحهٔ پویا مشکل دارد، داده‌های برنامه و درخواست‌های هم‌زمان را در همان بازه بررسی کنید. این ترتیب از آن جلوگیری می‌کند که یک نتیجهٔ عادی به دلیل تفاوت روش آزمون به عنوان تغییر شبکه تفسیر شود.
هنگام جمع‌بندی بهتر است چند مشاهده را با جمله‌های دقیق ثبت کنید. بنویسید در چه بازه‌ای، از کدام شبکه و برای کدام درخواست اختلال رخ داده است. بعد نتیجهٔ مقصد و اثر روی کاربران را اضافه کنید. اگر بعضی نتایج با فرضیهٔ اولیه سازگار نیستند، آن‌ها را حذف نکنید. یک نمونهٔ سالم در میان چند نمونهٔ ناموفق ممکن است ماهیت متناوب رخداد را نشان دهد. در پایان مشخص کنید پیگیری بعدی نیازمند گزارش مسیر از مبدأ دیگری است یا باید زمان پردازش داخل برنامه اندازه‌گیری شود.
تحویل نتیجهٔ آزمون خرید به تیم فنی
اگر پیش از سفارش چند سرویس را بررسی کرده‌اید، مقایسه را با یک جدول ساده به تیم تحویل دهید. در هر ردیف فقط شرایطی را بنویسید که واقعاً سنجیده شده است. اگر یک مقصد به ICMP جواب نمی‌دهد ولی سرویس نمونه از HTTPS باز است، هر دو نتیجه را جدا بیاورید. اگر ساعت آزمون یکی از مقصدها با ساعت بقیه فرق دارد، همان تفاوت را ذکر کنید. از پشتیبانی دربارهٔ دسترسی به مقصد نمونه و ارتباط آن با سرویس نهایی بپرسید. نتیجهٔ این کار به تیم اجازه می‌دهد بعد از تحویل هم همان آزمون را تکرار کند.
در روز تحویل، IP مقصد واقعی و مسیر عمومی را ثبت کنید. اگر سرویس از چند نشانی استفاده می‌کند، برای هر خانوادهٔ آدرس معیار مربوط را جدا بنویسید. سپس یک درخواست پایه به سرویس اجرا کنید و زمان و نتیجه را ثبت کنید. دادهٔ این روز نقطهٔ شروع خوبی برای پیگیری است، به شرط اینکه به‌عنوان مشاهدهٔ همان زمان نگهداری شود. اگر در هفته‌های بعد کاربران از اپراتور دیگری اضافه شدند، آن مبدأ را به فهرست بررسی اضافه کنید. فرایند ساده‌ای که تیم بتواند تکرار کند، از مقایسهٔ پیچیده‌ای که فقط یک‌بار انجام می‌شود عملی‌تر است.
یک فرم کوتاه برای ثبت شواهد
برای اینکه داده‌ها در پیام‌های پراکنده گم نشوند، در پروندهٔ رخداد این موارد را ثبت کنید: نشانی مقصد، زمان تهران، مبدأ اتصال، عمل کاربر، نتیجهٔ HTTP یا اتصال، و نتیجهٔ مقصد در آزمون تشخیصی. اگر گزارش فایل پیوست دارد، نام فایل باید بازه و مبدأ را مشخص کند. به‌جای نوشتن درصد بدون زمینه، تعداد پروب و تعداد پاسخ را نیز بیاورید. اطلاعات خصوصی مشتری را فقط در کانال مورد تأیید تیم نگه دارید. با همین فرم کوتاه، نفر بعدی می‌تواند همان عمل را بازتولید کند و ببیند نتیجه تغییر کرده است یا خیر.
پرسش‌های متداول
آیا افت در یک گام میانی به معنی خرابی شبکه است؟
وقتی گام‌های بعدی و مقصد به پروب‌ها پاسخ می‌دهند، گزارش همان گام نشان می‌دهد بخشی از پروب‌های ارسالی به آن پاسخ نگرفته‌اند. برای تصمیم عملی نتیجهٔ انتهایی و رفتار سرویس را ببینید. اگر در مقصد هم افت دارید و همان زمان اتصال برنامه ناموفق است، نمونهٔ مبدأ دوم و جزئیات زمان رخداد را به بررسی اضافه کنید.
چرا با Ping موفق، سایت هنوز کند است؟
Ping نوع دیگری از درخواست را اندازه می‌گیرد و مراحل DNS، اتصال وب، TLS و پردازش برنامه را به‌صورت کامل نمی‌سنجد. یک درخواست HTTPS معمول و سبک انجام دهید و زمان مراحل را ثبت کنید. اگر کندی فقط در یک مسیر پویا تکرار می‌شود، بررسی لاگ برنامه برای همان مسیر کمک می‌کند علت محتمل را محدود کنید.
چند نمونه برای گزارش لازم است؟
تعداد ثابت برای همهٔ رخدادها وجود ندارد. برای شروع از نمونهٔ محدود و قابل تکرار استفاده کنید. تعداد ارسال و زمان آزمون را همراه درصد افت بنویسید. در اختلال متناوب، چند نمونهٔ کوتاه در بازه‌های زمان‌دار و یک خط پایه در زمان سالم، زمینهٔ بهتری برای تحلیل فراهم می‌کنند.
وقتی مقصد به ICMP پاسخ نمی‌دهد چه کنیم؟
اگر سرویس وب فعال است، پاسخ HTTPS یا یک پروب TCP مجاز روی پورت شناخته‌شده را بررسی کنید. نوع آزمون را در گزارش مشخص کنید. نتیجهٔ موفق یک درخواست وب نشان می‌دهد همان مسیر برای همان درخواست کار کرده است و عدم پاسخ ICMP باید بر اساس سیاست مقصد تفسیر شود.
آیا از اختلاف دو ردیف Traceroute می‌توان زمان یک لینک را حساب کرد؟
هر ردیف زمان رفت و برگشت بین مبدأ و دستگاه پاسخ‌دهنده را نشان می‌دهد. مسیر برگشت و رفتار پاسخ‌دهی دستگاه‌ها می‌تواند متفاوت باشد. برای برآورد عملی به نتیجهٔ مقصد و الگوی تکرارشونده نگاه کنید. اگر برای تشخیص فنی به اندازه‌گیری یک پیوند نیاز دارید، اندازه‌گیری مناسب از دو سمت آن لازم است.
نتیجهٔ خوب از یک اپراتور برای همهٔ کاربران کافی است؟
هر اپراتور می‌تواند مسیر متفاوتی داشته باشد. اگر کاربران شما در چند شبکه‌اند، از مبدأهای نماینده نمونه بگیرید. در هر نمونه IP مقصد و نوع پروتکل را ثبت کنید. یک نتیجهٔ خوب را به همان مبدأ و بازه محدود کنید و برای تصمیم خرید نمونه‌های دیگر را با همان روش بررسی کنید.
جمع‌بندی
تست شبکه سرور مجازی ایران وقتی به تصمیم می‌رسد که نتیجهٔ مقصد را در کنار رفتار واقعی سرویس بخوانید. Ping برای شروع سریع است، Traceroute گام‌های قابل مشاهده را نشان می‌دهد و MTR با تکرار نمونه‌ها کمک می‌کند الگو را ببینید. برای اختلال متناوب، یک مبدأ دوم، زمان دقیق و یک آزمون کاربردی اضافه کنید. اگر در حال انتخاب سرویس هستید، همین سناریو را برای کاربران هدف خود تعریف کنید و با مشاهدهٔ سرویس سرور مجازی ایران دربارهٔ امکان آزمون و مسیر پیگیری از پشتیبانی سؤال کنید.
منابع فنی راهنمای MTR، راهنمای AWS برای تفسیر MTR و RFC 1812.
ثبت دیدگاه