- Detect و Scope را از پایه توضیح بدهی
- Stabilize و حفظ Evidence را در یک سناریوی واقعی تحلیل کنی
- Diagnosis و Hypothesis را با روش کنترلشده پیادهسازی کنی
- Remediation و Verification را با Evidence بررسی کنی
- Post-Incident Documentation و Prevention را مرحلهبهمرحله عیبیابی کنی
Detect و Scope
Detect ممکن است از Monitoring Alert، Ticket کاربر یا Log باشد. Scope باید مشخص کند چه User/Service/Site/Protocol و از چه زمانی متاثر است. Severity Incident از Business Impact میآید، نه صرفاً از جذابیت فنی مشکل.
برای فهم این مفهوم باید مرز آن با فناوریهای مجاور روشن باشد. در شبکه واقعی، یک علامت مشابه میتواند از چند لایه ایجاد شود؛ بنابراین تعریف دقیق باعث میشود از تغییر Configuration نامرتبط جلوگیری شود.
Incident workflowDetect -> Scope -> Stabilize -> Evidence -> Hypothesis -> Test -> Fix -> Verify -> Documentبرای Incident Workflow، از Detect تا Documentation، فهم Detect و Scope باید همراه با مرزبندی دقیق انجام شود. قبل از هر تصمیم، مشخص کن این مفهوم در کدام لایه یا بخش از مسیر قرار دارد، چه Stateی ایجاد میکند و چه چیزی خارج از مسئولیت آن است. بسیاری از خطاهای عملی از اینجا شروع میشوند که یک علامت مشترک به فناوری اشتباه نسبت داده میشود. اگر بتوانی بگویی «این بخش دقیقاً چه چیزی را ثابت میکند و چه چیزی را ثابت نمیکند»، هنگام Incident بهجای حدس زدن، Failure Domain را کوچک میکنی. در محیط واقعی همیشه فناوری مجاور، مسیر برگشت و Policyهای بین راه را هم در ذهن نگه دار.
Stabilize و حفظ Evidence
اگر Impact شدید است، Stabilization موقت مثل Failover یا Isolation ممکن است قبل از Root Cause کامل لازم باشد. با این حال Evidence حیاتی مثل Log، Counter و Running State را تا حد امکان قبل از Reset جمع کن. Reload میتواند Symptom را موقتاً حذف و Root Cause را پنهان کند.
جریان را از دید Packet یا State دنبال کن، نه فقط از دید Command. هر مرحله باید Input، تصمیم و Output مشخص داشته باشد و بتوانی بگویی شکست در آن مرحله چه علامتی تولید میکند.
Evidence preservationPreserve logs/counters before reload or clearبرای تحلیل عملی Stabilize و حفظ Evidence یک Flow Card کوچک بساز: Source، Destination، Protocol یا Service، Interface/VLAN/Prefix مرتبط و Timestamp. سپس Packet یا State را از یک Boundary به Boundary بعدی دنبال کن. این روش در Incident Workflow، از Detect تا Documentation کمک میکند تفاوت میان Configuration موجود و رفتار واقعی شبکه دیده شود. اگر یک مرحله سالم است، همان مرحله را دوباره تغییر نده؛ Boundary بعدی را آزمایش کن. اگر مرحلهای شکست میخورد، خروجی و Counter همان نقطه را ثبت کن. این عادت ساده باعث میشود Troubleshooting حتی در شبکهای با چند Switch، Router، Security Policy و Server قابل تکرار و قابل توضیح باشد.
Diagnosis و Hypothesis
Hypothesis باید قابل تست باشد. بهجای «احتمالاً شبکه است» بگو «Default Route روی Edge حذف شده؛ چون همه VLANها IP داخلی دارند ولی هیچ Destination خارجی Reach نمیشود». سپس با show ip route این فرضیه را تست کن. اگر رد شد، فرضیه بعدی را انتخاب کن.
Configuration باید بعد از Baseline و با Scope مشخص انجام شود. نمونه دستور برای Lab است و Syntax یا Capability دقیق میتواند با Platform و IOS XE Release تفاوت داشته باشد؛ Contextual Help و مستندات همان Device مرجع نهاییاند.
Diagnostic recordHypothesis + test + expected result + actual resultپیادهسازی Diagnosis و Hypothesis در شبکه شرکت باید به سه فاز 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 سازمان سازگار بماند.
Remediation و Verification
Remediation باید کوچکترین Change لازم برای Root Cause اثباتشده باشد. بعد از Fix همان Test اولیه، Monitoring و Negative Test Security را اجرا کن. Recovery User بدون Recovery Monitoring کامل نیست.
Verification یعنی مقایسه State عملیاتی با Intent. وجود خط Configuration فقط Desired State را نشان میدهد؛ Counter، Table، Log یا Test End-to-End ثابت میکند Feature واقعاً چگونه کار میکند.
VerificationFix -> repeat original test -> monitor -> negative testدر Verification مربوط به Remediation و Verification، خروجی Command را بهصورت «Expected در برابر Actual» بخوان. وجود یک Line در Running Configuration فقط Intent را نشان میدهد؛ Table، Neighbor State، Counter، Log یا Test End-to-End نشان میدهد Feature واقعاً چه میکند. اگر Counter وجود دارد، مقدار مطلق را تنها معیار نگذار؛ قبل و بعد از Test به Delta توجه کن. اگر Log وجود دارد، Timestamp و Source را با Flow آزمایشی تطبیق بده. در Incident Workflow، از Detect تا Documentation بهتر است حداقل یک Positive Test و، هرجا Security مطرح است، یک Negative Test نیز داشته باشی تا هم Availability و هم Policy درست اثبات شوند.
Post-Incident Documentation و Prevention
Post-Incident شامل Timeline، Root Cause، Trigger، Impact، Fix، What Went Well/Failed و Preventive Action است. اگر Monitoring دیر متوجه شد، Alert بهتر کن؛ اگر Template Drift بود، Automation/Review را اصلاح کن. هدف کاهش احتمال و Impact تکرار است.
در Troubleshooting ابتدا Scope و Flow را ثبت کن، سپس کمهزینهترین Test را اجرا کن که یک فرضیه را تأیید یا رد میکند. قبل از Clear، Reload یا Disable کردن Feature، Evidence را جمع کن تا Root Cause از بین نرود.
Post-incident recordTimeline | root cause | trigger | impact | fix | preventive actionمسیر Troubleshooting Post-Incident Documentation و Prevention را با کمهزینهترین Test شروع کن که بیشترین اطلاعات را میدهد. ابتدا Scope و آخرین وضعیت سالم را مشخص کن، سپس نزدیکترین Boundary سالم به کاربر یا Source را پیدا کن و قدمبهقدم جلو برو. هر Test باید یک Hypothesis را رد یا تأیید کند؛ اگر نتیجه فرضیه را رد کرد، همان Configuration را بیدلیل دستکاری نکن. قبل از Reload، Clear State یا Disable کردن Feature، Evidence را ذخیره کن چون این عملیات میتوانند سرنخ Root Cause را پاک کنند. بعد از Fix نیز تست اولیه را تکرار و Preventive Action را در Documentation ثبت کن.
یک تغییر ACL ساعت 10:05 دسترسی ERP را قطع میکند. Alert 10:06، Scope همه شعب، Config Diff تغییر ACL را نشان میدهد. Rollback همان ACE سرویس را برمیگرداند، Test ERP و Monitoring سبز میشوند و Preventive Action شامل Automated ACL Test قبل از Deploy میشود.
اشتباههای رایج و علت آنها
- تغییر Incident Workflow، از Detect تا Documentation بدون Baseline و Scope مشخص
- قضاوت درباره Incident Workflow، از Detect تا Documentation فقط از روی وجود Configuration
- نادیده گرفتن Dependencyها و مسیر واقعی Packet/State
- انجام Clear/Disable گسترده قبل از جمعآوری Evidence
تمرین عملی
- یک Diagram یا State Flow برای Incident Workflow، از Detect تا Documentation رسم کن
- نمونه Configuration/Policy Incident Workflow، از Detect تا Documentation را در Lab بررسی کن
- خروجی Verification را قبل و بعد از یک Test مقایسه کن
- یک Failure عمدی بساز و Root Cause را با Runbook پیدا کن
نکتههایی که باید با خودت ببری
- Detect ممکن است از Monitoring Alert، Ticket کاربر یا Log باشد
- اگر Impact شدید است، Stabilization موقت مثل Failover یا Isolation ممکن است قبل از Root Cause کامل لازم باشد
- Hypothesis باید قابل تست باشد
- Remediation باید کوچکترین Change لازم برای Root Cause اثباتشده باشد
- Post-Incident شامل Timeline، Root Cause، Trigger، Impact، Fix، What Went Well/Failed و Preventive Action است
خودسنجی
Detect و Scope چه مسئلهای را حل یا توضیح میدهد؟
Detect ممکن است از Monitoring Alert، Ticket کاربر یا Log باشد.
در Stabilize و حفظ Evidence مهمترین State یا جریان چیست؟
اگر Impact شدید است، Stabilization موقت مثل Failover یا Isolation ممکن است قبل از Root Cause کامل لازم باشد.
قبل از Diagnosis و Hypothesis چه کاری ضروری است؟
Baseline، Scope و Rollback مشخص شود.
اصل کلیدی Post-Incident Documentation و Prevention چیست؟
هر Test باید یک فرضیه را با Evidence تأیید یا رد کند.
منابع مرجع این درس
برای ذخیره پیشرفت وارد حساب شو
حساب کاربری برای آزمون و ثبت مرحلهها استفاده میشود
