- تعریف Symptom و Scope را از پایه توضیح بدهی
- Baseline و Timeline را در یک سناریوی واقعی تحلیل کنی
- Hypothesis و Test قابل رد را با روش کنترلشده پیادهسازی کنی
- Change Control و Minimum Change را با Evidence بررسی کنی
- Verification، Root Cause و Documentation را مرحلهبهمرحله عیبیابی کنی
تعریف Symptom و Scope
گزارش «شبکه کند است» اطلاعات کافی ندارد. باید بدانی چه User/Service/Site، چه زمان، چه Protocol و چه Patternی متاثر است. Scope با مقایسه User سالم/خراب، VLAN، Site و Destination کوچک میشود. Symptom باید قابل تکرار یا حداقل با Timestamp قابل Correlation باشد.
برای فهم این مفهوم باید مرز آن با فناوریهای مجاور روشن باشد. در شبکه واقعی، یک علامت مشابه میتواند از چند لایه ایجاد شود؛ بنابراین تعریف دقیق باعث میشود از تغییر Configuration نامرتبط جلوگیری شود.
MethodSymptom -> scope -> baseline -> hypothesis -> test -> evidence -> fix -> verifyبرای روش علمی Troubleshooting: Scope، Evidence و Hypothesis، فهم تعریف Symptom و Scope باید همراه با مرزبندی دقیق انجام شود. قبل از هر تصمیم، مشخص کن این مفهوم در کدام لایه یا بخش از مسیر قرار دارد، چه Stateی ایجاد میکند و چه چیزی خارج از مسئولیت آن است. بسیاری از خطاهای عملی از اینجا شروع میشوند که یک علامت مشترک به فناوری اشتباه نسبت داده میشود. اگر بتوانی بگویی «این بخش دقیقاً چه چیزی را ثابت میکند و چه چیزی را ثابت نمیکند»، هنگام Incident بهجای حدس زدن، Failure Domain را کوچک میکنی. در محیط واقعی همیشه فناوری مجاور، مسیر برگشت و Policyهای بین راه را هم در ذهن نگه دار.
Baseline و Timeline
Baseline وضعیت سالم را نشان میدهد و Timeline ترتیب رخدادها را. Last Known Good، آخرین Change، Alert و Logهای همزمان را کنار هم بگذار. بدون Timeline ممکن است یک Log قدیمی را Root Cause Incident جدید فرض کنی.
جریان را از دید Packet یا State دنبال کن، نه فقط از دید Command. هر مرحله باید Input، تصمیم و Output مشخص داشته باشد و بتوانی بگویی شکست در آن مرحله چه علامتی تولید میکند.
TimelineLast known good | change | alert | log | user reportبرای تحلیل عملی Baseline و Timeline یک Flow Card کوچک بساز: Source، Destination، Protocol یا Service، Interface/VLAN/Prefix مرتبط و Timestamp. سپس Packet یا State را از یک Boundary به Boundary بعدی دنبال کن. این روش در روش علمی Troubleshooting: Scope، Evidence و Hypothesis کمک میکند تفاوت میان Configuration موجود و رفتار واقعی شبکه دیده شود. اگر یک مرحله سالم است، همان مرحله را دوباره تغییر نده؛ Boundary بعدی را آزمایش کن. اگر مرحلهای شکست میخورد، خروجی و Counter همان نقطه را ثبت کن. این عادت ساده باعث میشود Troubleshooting حتی در شبکهای با چند Switch، Router، Security Policy و Server قابل تکرار و قابل توضیح باشد.
Hypothesis و Test قابل رد
Hypothesis باید جملهای باشد که بتوانی ردش کنی: «Default Route Edge حذف شده، چون همه شبکههای داخلی سالماند اما همه مقصدهای بیرونی Fail میشوند». Test باید Expected Result داشته باشد. اگر Result مخالف بود، Hypothesis رد و مرحله بعد انتخاب میشود.
Configuration باید بعد از Baseline و با Scope مشخص انجام شود. نمونه دستور برای Lab است و Syntax یا Capability دقیق میتواند با Platform و IOS XE Release تفاوت داشته باشد؛ Contextual Help و مستندات همان Device مرجع نهاییاند.
Scientific testHypothesis + expected result + actual result -> accept/rejectپیادهسازی Hypothesis و Test قابل رد در شبکه شرکت باید به سه فاز Pre-check، Change و Post-check تقسیم شود. در Pre-check وضعیت فعلی، Dependencyها و مسیر مدیریت را ذخیره کن؛ در Change فقط Scope لازم را تغییر بده؛ در Post-check هم State فنی و هم سرویس کاربر را Verify کن. برای Changeهایی که ممکن است Access مدیریت، Routing یا Security را تحت تأثیر قرار دهند، Rollback را قبل از اجرای دستور بنویس و مسیر Recovery را مشخص کن. هدف این نیست که Configuration فقط از نظر Syntax پذیرفته شود؛ Desired State باید با Design، مستندات، Address Plan و Security Policy سازمان سازگار بماند.
Change Control و Minimum Change
قبل از Change Evidence را حفظ کن. کوچکترین تغییر لازم را انتخاب و Rollback مشخص کن. Reload، Clear State یا Disable Security Feature ابزارهای پرImpact هستند و نباید جای Diagnosis را بگیرند.
Verification یعنی مقایسه State عملیاتی با Intent. وجود خط Configuration فقط Desired State را نشان میدهد؛ Counter، Table، Log یا Test End-to-End ثابت میکند Feature واقعاً چگونه کار میکند.
Change controlMinimum change + rollback + maintenance windowدر Verification مربوط به Change Control و Minimum Change، خروجی Command را بهصورت «Expected در برابر Actual» بخوان. وجود یک Line در Running Configuration فقط Intent را نشان میدهد؛ Table، Neighbor State، Counter، Log یا Test End-to-End نشان میدهد Feature واقعاً چه میکند. اگر Counter وجود دارد، مقدار مطلق را تنها معیار نگذار؛ قبل و بعد از Test به Delta توجه کن. اگر Log وجود دارد، Timestamp و Source را با Flow آزمایشی تطبیق بده. در روش علمی Troubleshooting: Scope، Evidence و Hypothesis بهتر است حداقل یک Positive Test و، هرجا Security مطرح است، یک Negative Test نیز داشته باشی تا هم Availability و هم Policy درست اثبات شوند.
Verification، Root Cause و Documentation
پس از Fix همان Test اولیه را تکرار، Monitoring و Negative Test Security را بررسی و Root Cause را ثبت کن. Root Cause با Trigger فرق دارد؛ مثلاً Trigger یک Change ACL و Root Cause نبود Test خودکار قبل از Deploy میتواند باشد.
در Troubleshooting ابتدا Scope و Flow را ثبت کن، سپس کمهزینهترین Test را اجرا کن که یک فرضیه را تأیید یا رد میکند. قبل از Clear، Reload یا Disable کردن Feature، Evidence را جمع کن تا Root Cause از بین نرود.
ClosureRoot cause | trigger | impact | fix | preventionمسیر Troubleshooting Verification، Root Cause و Documentation را با کمهزینهترین Test شروع کن که بیشترین اطلاعات را میدهد. ابتدا Scope و آخرین وضعیت سالم را مشخص کن، سپس نزدیکترین Boundary سالم به کاربر یا Source را پیدا کن و قدمبهقدم جلو برو. هر Test باید یک Hypothesis را رد یا تأیید کند؛ اگر نتیجه فرضیه را رد کرد، همان Configuration را بیدلیل دستکاری نکن. قبل از Reload، Clear State یا Disable کردن Feature، Evidence را ذخیره کن چون این عملیات میتوانند سرنخ Root Cause را پاک کنند. بعد از Fix نیز تست اولیه را تکرار و Preventive Action را در Documentation ثبت کن.
کاربران سه VLAN اینترنت ندارند. آخرین Change روی Edge NAT بوده است. Default Route سالم اما NAT ACL فقط VLAN قدیمی را Match میکند. Hypothesis با Counter ACL تأیید، فقط ACE لازم اضافه و Test اولیه تکرار میشود. Reload Router هیچوقت لازم نشد.
اشتباههای رایج و علت آنها
- تغییر روش علمی Troubleshooting: Scope، Evidence و Hypothesis بدون Baseline و Scope مشخص
- قضاوت درباره روش علمی Troubleshooting: Scope، Evidence و Hypothesis فقط از روی وجود Configuration
- نادیده گرفتن Dependencyها و مسیر واقعی Packet/State
- انجام Clear/Disable گسترده قبل از جمعآوری Evidence
تمرین عملی
- یک Diagram یا State Flow برای روش علمی Troubleshooting: Scope، Evidence و Hypothesis رسم کن
- نمونه Configuration/Policy روش علمی Troubleshooting: Scope، Evidence و Hypothesis را در Lab بررسی کن
- خروجی Verification را قبل و بعد از یک Test مقایسه کن
- یک Failure عمدی بساز و Root Cause را با Runbook پیدا کن
نکتههایی که باید با خودت ببری
- گزارش «شبکه کند است» اطلاعات کافی ندارد
- Baseline وضعیت سالم را نشان میدهد و Timeline ترتیب رخدادها را
- Hypothesis باید جملهای باشد که بتوانی ردش کنی: «Default Route Edge حذف شده، چون همه شبکههای داخلی سالماند اما همه مقصدهای بیرونی Fail میشوند»
- قبل از Change Evidence را حفظ کن
- پس از Fix همان Test اولیه را تکرار، Monitoring و Negative Test Security را بررسی و Root Cause را ثبت کن
خودسنجی
تعریف Symptom و Scope چه مسئلهای را حل یا توضیح میدهد؟
گزارش «شبکه کند است» اطلاعات کافی ندارد.
در Baseline و Timeline مهمترین State یا جریان چیست؟
Baseline وضعیت سالم را نشان میدهد و Timeline ترتیب رخدادها را.
قبل از Hypothesis و Test قابل رد چه کاری ضروری است؟
Baseline، Scope و Rollback مشخص شود.
اصل کلیدی Verification، Root Cause و Documentation چیست؟
هر Test باید یک فرضیه را با Evidence تأیید یا رد کند.
منابع مرجع این درس
برای ذخیره پیشرفت وارد حساب شو
حساب کاربری برای آزمون و ثبت مرحلهها استفاده میشود
