سناریو آشناست: کاربران یک شعبه میگویند سامانه ERP «کند شده»، تیم شبکه روی Router و WAN Link خطای واضحی نمیبیند و تیم سرور هم CPU و Memory را عادی گزارش میکند. مشکل ممکن است نه در مبدأ باشد و نه در مقصد؛ یک Hop میانی، مسیر ISP یا تغییر Route میتواند Latency را بالا برده باشد. در چنین شرایطی، Network Path Analysis در OpManager کمک میکند مسیر ارتباط را بهجای یک عدد کلی، Hop به Hop ببینید.
هدف این مقاله تشخیص محل اختلال در مسیر بین کاربر، شعبه، شبکه WAN، ISP و دیتاسنتر است؛ نه تکرار مانیتورینگ SD-WAN یا صرفاً اندازهگیری Availability دستگاهها.
چرا Up بودن دو Endpoint به معنی سالم بودن مسیر نیست؟
ممکن است Router شعبه و Server مقصد هر دو Up باشند، اما بستهها در مسیر با Latency، Packet Loss یا Route غیرمنتظره روبهرو شوند. مانیتورینگ صرف Endpointها این بخش میانی را کامل نشان نمیدهد. Path Analysis دیدی میدهد که کدام Hopها در مسیر حضور دارند و تغییر رفتار از کجا شروع میشود.
| نشانه | برداشت اولیه | بررسی مناسب |
|---|---|---|
| Latency بالا فقط در یک شعبه | مسیر WAN/ISP محتمل است | Path و RTT شعبه تا مقصد |
| Packet Loss بعد از یک Hop مشخص | مسیر یا تجهیز میانی نیاز به بررسی دارد | مقایسه Hopهای قبل و بعد |
| تغییر ناگهانی Path | Routing یا Provider تغییر کرده است | Baseline مسیر و Change Review |
| Endpointها سالماند ولی کاربر کندی دارد | Blind Spot بین دو سمت وجود دارد | Network Path Analysis |
Network Path Analysis چه اطلاعاتی به تیم عملیات میدهد؟
در طراحی درست، تیم NOC باید بتواند مسیر بین Source و Destination را مشاهده و تغییرات آن را با زمان وقوع Incident مقایسه کند. اطلاعاتی مانند Hop، Response Time و تغییر مسیر باعث میشود Troubleshooting از حدسزدن به یک فرآیند مبتنی بر شواهد نزدیک شود.
سناریو: کندی ERP فقط در شعبه اصفهان
فرض کنید ERP در دیتاسنتر تهران است. شعبه شیراز مشکلی ندارد، اما کاربران اصفهان از کندی شکایت دارند. بررسی پیشنهادی:
- Availability Router و WAN Interface شعبه را کنترل کنید.
- Latency مسیر شعبه اصفهان تا ERP را با شعبه سالم مقایسه کنید.
- Hopهایی را که فقط در مسیر اصفهان دیده میشوند مشخص کنید.
- زمان آغاز افزایش Response Time را با Change، Provider Maintenance یا Route Change مقایسه کنید.
- اگر مشکل خارج از شبکه سازمان است، Evidence قابل ارائه به ISP جمع کنید.
Path Analysis با WAN RTT چه تفاوتی دارد؟
WAN RTT بیشتر به کیفیت رفتوبرگشت ارتباط بین دو نقطه توجه میکند؛ Path Analysis به این سؤال پاسخ میدهد که «این رفتوبرگشت از چه مسیر و Hopهایی عبور میکند؟». این دو مکمل یکدیگرند. وقتی RTT بد شده است، Path Analysis میتواند محل محتمل تغییر را محدود کند.
Cisco IP SLA کجا وارد طراحی میشود؟
در شبکههایی که Cisco IP SLA استفاده میشود، Probeهای فعال میتوانند سنجشهایی مانند Response Time، Jitter یا Packet Loss را از دید مشخصی انجام دهند. OpManager قابلیتهای مرتبط با WAN RTT و Cisco IP SLA را برای پایش کیفیت ارتباط ارائه میکند. انتخاب Test باید بر اساس نوع سرویس، تجهیزات و توپولوژی انجام شود.
Baseline مسیر؛ تغییر مسیر همیشه Incident نیست
شبکههای Dynamic Routing ممکن است بهدلایل طبیعی مسیر را تغییر دهند. بنابراین صرف مشاهده یک Path متفاوت کافی نیست. باید Baseline داشته باشید: مسیر معمول، محدوده طبیعی RTT و زمانهای Maintenance. ارزش Monitoring زمانی ایجاد میشود که تغییر «معنادار» از رفتار عادی جدا شود.
Path Analysis و Root Cause Analysis
اگر Root Cause Analysis فقط با «سرور کند بود» یا «اینترنت مشکل داشت» بسته شود، دانش عملیاتی ایجاد نمیشود. Path Evidence میتواند در Problem Record ثبت شود و مشخص کند اختلال از Interface داخلی، لینک WAN، Provider یا مسیر دیتاسنتر ناشی بوده است.
برای طراحی RCA در لایه Monitoring، مقاله Root Cause Analysis در OpManager میتواند مکمل این موضوع باشد.
اتصال Alarm به ServiceDesk Plus
وقتی اختلال مسیر از Threshold عبور میکند، بهتر است Alarm به فرآیند Incident متصل شود تا Owner، SLA و Timeline مشخص داشته باشد. اگر Ticketهای شبکه نیز خودکار وارد میز خدمت میشوند، راهنمای Ticket Routing در ServiceDesk Plus نشان میدهد چگونه Assignment و SLA را ساختارمند کنید.
برای مطالب تخصصی ServiceDesk Plus نیز servicedeskplus.ir در دسترس است.
KPIهای مناسب برای مانیتورینگ Path
- میانگین و صدکهای RTT در مسیرهای کلیدی؛
- تعداد تغییرات Path خارج از Maintenance Window؛
- تعداد Incidentهای مرتبط با WAN/ISP؛
- میانگین زمان تشخیص Hop یا Segment مشکلدار؛
- تعداد رخدادهای Packet Loss یا Jitter خارج از Baseline.
Runbook عملی برای NOC
| مرحله | اقدام | خروجی |
|---|---|---|
| ۱ | تأیید Scope کاربران متاثر | شعبه/سرویس مشخص |
| ۲ | بررسی Device و Interface Health | حذف خرابی محلی واضح |
| ۳ | مقایسه Path و RTT با Baseline | Hop یا Segment مشکوک |
| ۴ | Correlation با Change/ISP | فرضیه قابل آزمون |
| ۵ | ثبت Evidence در Incident/Problem | RCA قابل پیگیری |
نکات کلیدی
- Up بودن Source و Destination سلامت مسیر بین آنها را تضمین نمیکند.
- Path Analysis برای پیدا کردن Segment یا Hop مشکوک مکمل WAN RTT است.
- Baseline مانع تبدیل هر Route Change به Alert کاذب میشود.
- Evidence مسیر برای Escalation به ISP و Problem Management ارزش عملی دارد.
- Monitoring باید به Incident Workflow متصل شود، نه اینکه در داشبورد متوقف بماند.
منابع
- ManageEngine OpManager — Network Path Analysis
- ManageEngine OpManager — WAN RTT Monitoring
- ManageEngine OpManager — Cisco IP SLA Monitoring
سخن پایانی
وقتی کاربران از کندی سرویس شکایت میکنند، فقط مانیتورکردن سرور و Router کافی نیست. Network Path Analysis در OpManager فاصله بین این دو نقطه را قابل مشاهده میکند و به تیم NOC کمک میدهد سریعتر مشخص کند مشکل در شبکه داخلی، WAN، Provider یا مسیر دیتاسنتر قرار دارد.
مدانت خدمات استعلام و خرید لایسنس OpManager، طراحی معماری Monitoring، نصب، Migration، تنظیم Threshold، Integration با ServiceDesk Plus، آموزش و پشتیبانی ارائه میکند. برای بررسی راهکار میتوانید صفحه OpManager Plus در مدانت و همچنین چکلیست خرید لایسنس ManageEngine را ببینید.
