راینو

در پایان این درس باید بتوانی

Baseline عملیاتی را از پایه توضیح بدهی
Health Metrics و Threshold را در یک سناریوی واقعی تحلیل کنی
Backup Configuration و Software Metadata را با روش کنترل‌شده پیاده‌سازی کنی
Config Diff و Change Evidence را با Evidence بررسی کنی
Troubleshooting با Known-Good State را مرحله‌به‌مرحله عیب‌یابی کنی

Baseline عملیاتی

Baseline Snapshot یک عدد تصادفی نیست؛ Trend و Range عادی در ساعات مختلف است. Interface Error تقریباً صفر، CPU متوسط، Peak Bandwidth و تعداد Neighbor/Route نمونه‌هایی هستند که باید در طول زمان شناخته شوند. Baseline هر Device Role می‌تواند متفاوت باشد.

برای فهم این مفهوم باید مرز آن با فناوری‌های مجاور روشن باشد. در شبکه واقعی، یک علامت مشابه می‌تواند از چند لایه ایجاد شود؛ بنابراین تعریف دقیق باعث می‌شود از تغییر Configuration نامرتبط جلوگیری شود.

Baseline set

Baseline: CPU, memory, interface errors, utilization, neighbors, route count

برای Baseline سلامت، Backup Configuration و Change Evidence، فهم Baseline عملیاتی باید همراه با مرزبندی دقیق انجام شود. قبل از هر تصمیم، مشخص کن این مفهوم در کدام لایه یا بخش از مسیر قرار دارد، چه Stateی ایجاد می‌کند و چه چیزی خارج از مسئولیت آن است. بسیاری از خطاهای عملی از اینجا شروع می‌شوند که یک علامت مشترک به فناوری اشتباه نسبت داده می‌شود. اگر بتوانی بگویی «این بخش دقیقاً چه چیزی را ثابت می‌کند و چه چیزی را ثابت نمی‌کند»، هنگام Incident به‌جای حدس زدن، Failure Domain را کوچک می‌کنی. در محیط واقعی همیشه فناوری مجاور، مسیر برگشت و Policyهای بین راه را هم در ذهن نگه دار.

Health Metrics و Threshold

Threshold باید از Baseline و Capacity Requirement بیاید. CPU 70 درصد شاید روی یک Platform عادی و روی دیگری خطر باشد. Alert بدون Context Noise می‌سازد. Health Dashboard باید Metric، Duration و Correlation را در نظر بگیرد.

جریان را از دید Packet یا State دنبال کن، نه فقط از دید Command. هر مرحله باید Input، تصمیم و Output مشخص داشته باشد و بتوانی بگویی شکست در آن مرحله چه علامتی تولید می‌کند.

Threshold design

Metric + duration + context -> actionable alert

برای تحلیل عملی Health Metrics و Threshold یک Flow Card کوچک بساز: Source، Destination، Protocol یا Service، Interface/VLAN/Prefix مرتبط و Timestamp. سپس Packet یا State را از یک Boundary به Boundary بعدی دنبال کن. این روش در Baseline سلامت، Backup Configuration و Change Evidence کمک می‌کند تفاوت میان Configuration موجود و رفتار واقعی شبکه دیده شود. اگر یک مرحله سالم است، همان مرحله را دوباره تغییر نده؛ Boundary بعدی را آزمایش کن. اگر مرحله‌ای شکست می‌خورد، خروجی و Counter همان نقطه را ثبت کن. این عادت ساده باعث می‌شود Troubleshooting حتی در شبکه‌ای با چند Switch، Router، Security Policy و Server قابل تکرار و قابل توضیح باشد.

Backup Configuration و Software Metadata

Backup فقط copy running-config startup-config نیست. باید نسخه Configuration خارج Device، Software Image/Version، License/Inventory و روش Restore شناخته شود. انتقال امن فایل با SCP/SFTP در فصل ۱۲ پوشش داده شد. Backup بدون Test Restore اعتماد کامل نمی‌دهد.

Configuration باید بعد از Baseline و با Scope مشخص انجام شود. نمونه دستور برای Lab است و Syntax یا Capability دقیق می‌تواند با Platform و IOS XE Release تفاوت داشته باشد؛ Contextual Help و مستندات همان Device مرجع نهایی‌اند.

Backup metadata

show running-config
show version
show inventory

پیاده‌سازی Backup Configuration و Software Metadata در شبکه شرکت باید به سه فاز 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 سازمان سازگار بماند.

Config Diff و Change Evidence

Config Diff قبل/بعد Change کمک می‌کند Scope واقعی را ببینیم. در IOS XE قابلیت archive یا ابزار خارجی می‌تواند Difference را نشان دهد. Ticket باید Intent، Commands/Automation Job، Pre-check و Post-check را نگه دارد.

Verification یعنی مقایسه State عملیاتی با Intent. وجود خط Configuration فقط Desired State را نشان می‌دهد؛ Counter، Table، Log یا Test End-to-End ثابت می‌کند Feature واقعاً چگونه کار می‌کند.

Config diff

show archive config differences nvram:startup-config system:running-config

در Verification مربوط به Config Diff و Change Evidence، خروجی Command را به‌صورت «Expected در برابر Actual» بخوان. وجود یک Line در Running Configuration فقط Intent را نشان می‌دهد؛ Table، Neighbor State، Counter، Log یا Test End-to-End نشان می‌دهد Feature واقعاً چه می‌کند. اگر Counter وجود دارد، مقدار مطلق را تنها معیار نگذار؛ قبل و بعد از Test به Delta توجه کن. اگر Log وجود دارد، Timestamp و Source را با Flow آزمایشی تطبیق بده. در Baseline سلامت، Backup Configuration و Change Evidence بهتر است حداقل یک Positive Test و، هرجا Security مطرح است، یک Negative Test نیز داشته باشی تا هم Availability و هم Policy درست اثبات شوند.

Troubleshooting با Known-Good State

هنگام Incident State فعلی را با Known-Good Baseline مقایسه کن: آیا Error Counter ناگهان بالا رفته؟ OSPF Neighbor Count کم شده؟ Config نسبت به Template Drift دارد؟ این مقایسه Hypothesis را سریع‌تر از نگاه منفرد به یک Output می‌سازد.

در Troubleshooting ابتدا Scope و Flow را ثبت کن، سپس کم‌هزینه‌ترین Test را اجرا کن که یک فرضیه را تأیید یا رد می‌کند. قبل از Clear، Reload یا Disable کردن Feature، Evidence را جمع کن تا Root Cause از بین نرود.

Troubleshooting model

Current state <-> baseline/template -> identify abnormal delta

مسیر Troubleshooting Troubleshooting با Known-Good State را با کم‌هزینه‌ترین Test شروع کن که بیشترین اطلاعات را می‌دهد. ابتدا Scope و آخرین وضعیت سالم را مشخص کن، سپس نزدیک‌ترین Boundary سالم به کاربر یا Source را پیدا کن و قدم‌به‌قدم جلو برو. هر Test باید یک Hypothesis را رد یا تأیید کند؛ اگر نتیجه فرضیه را رد کرد، همان Configuration را بی‌دلیل دست‌کاری نکن. قبل از Reload، Clear State یا Disable کردن Feature، Evidence را ذخیره کن چون این عملیات می‌توانند سرنخ Root Cause را پاک کنند. بعد از Fix نیز تست اولیه را تکرار و Preventive Action را در Documentation ثبت کن.

سناریوی عملی

یک Uplink روزانه Peak 80% دارد و Alert روی ۷۰% تنظیم شده؛ تیم هر روز Noise می‌گیرد. Baseline نشان می‌دهد ۸۰% برای ۱۰ دقیقه عادی است اما Error Counter صفر می‌ماند. Threshold با Duration و Capacity Plan اصلاح می‌شود تا Alert معنی‌دار شود.

اشتباهات رایج

اشتباه‌های رایج و علت آن‌ها

تغییر Baseline سلامت، Backup Configuration و Change Evidence بدون Baseline و Scope مشخص
قضاوت درباره Baseline سلامت، Backup Configuration و Change Evidence فقط از روی وجود Configuration
نادیده گرفتن Dependencyها و مسیر واقعی Packet/State
انجام Clear/Disable گسترده قبل از جمع‌آوری Evidence

تمرین عملی

یک Diagram یا State Flow برای Baseline سلامت، Backup Configuration و Change Evidence رسم کن
نمونه Configuration/Policy Baseline سلامت، Backup Configuration و Change Evidence را در Lab بررسی کن
خروجی Verification را قبل و بعد از یک Test مقایسه کن
یک Failure عمدی بساز و Root Cause را با Runbook پیدا کن

نکته‌هایی که باید با خودت ببری

Baseline Snapshot یک عدد تصادفی نیست؛ Trend و Range عادی در ساعات مختلف است
Threshold باید از Baseline و Capacity Requirement بیاید
Backup فقط copy running-config startup-config نیست
Config Diff قبل/بعد Change کمک می‌کند Scope واقعی را ببینیم
هنگام Incident State فعلی را با Known-Good Baseline مقایسه کن: آیا Error Counter ناگهان بالا رفته؟ OSPF Neighbor Count کم شده؟ Config نسبت به Template Drift دارد؟ این مقایسه Hypothesis را سریع‌تر از نگاه منفرد به یک Output می‌سازد

خودسنجی

Baseline عملیاتی چه مسئله‌ای را حل یا توضیح می‌دهد؟

Baseline Snapshot یک عدد تصادفی نیست؛ Trend و Range عادی در ساعات مختلف است.

در Health Metrics و Threshold مهم‌ترین State یا جریان چیست؟

Threshold باید از Baseline و Capacity Requirement بیاید.

قبل از Backup Configuration و Software Metadata چه کاری ضروری است؟

Baseline، Scope و Rollback مشخص شود.

اصل کلیدی Troubleshooting با Known-Good State چیست؟

هر Test باید یک فرضیه را با Evidence تأیید یا رد کند.

منابع رسمی

منابع مرجع این درس

مطالعه همیشه آزاد است

برای ذخیره پیشرفت وارد حساب شو

حساب کاربری برای آزمون و ثبت مرحله‌ها استفاده می‌شود

ورود یا ثبت‌نام

بازگشت به صفحه دوره CCNA