Escalation صحیح و جمع‌آوری Show Output برای مهندس ارشد

show version مدل/نسخه/Uptime را می‌دهد

Escalation خوب یعنی نفر بعد مجبور نباشد از صفر شروع کند. باید Problem Statement، Scope، زمان، Topology، تغییرات اخیر و خروجی‌های مرتبط مثل show version، show interfaces، show ip route و show logging را با توضیح کوتاه تحویل بدهی.

Dump کردن هزار خط Output بدون Context کمکی نمی‌کند. خروجی باید به سؤال Incident ربط داشته باشد و اطلاعات حساس قبل از ارسال مدیریت شود.

show version مدل/نسخه/Uptime را می‌دهد. show interfaces وضعیت و Counter.

show ip route مسیرها

show ip route مسیرها. show logging Eventهای زمانی را نشان می‌دهد.

show running-config می‌تواند Secret/اطلاعات حساس داشته باشد و نباید بی‌محابا ارسال شود. Timestamp و NTP برای تطبیق Log مهم‌اند. Tech-support Bundle حجیم است و باید طبق دستور سطح بالاتر/Support Vendor گرفته شود.

Escalation «من بلد نیستم» نیست

Escalation «من بلد نیستم» نیست؛ انتقال کنترل‌شده مسئله با شواهد است. هرچه داده تمیزتر باشد، Resolution سریع‌تر می‌شود.

Escalation باید قابل ادامه باشد. Output کمتر ولی مرتبط بهتر از Dump نامرتب است. اطلاعات حساس باید محافظت شود.

Output قبل از Change

از Output قبل از Change شروع کن. بعد زمان دقیق Incident. اگر تا اینجا چیزی غیرعادی ندیدی، Device/Interface ID. در آخر نتیجه Testهای انجام‌شده و منفی.

نتیجه «Output قبل از Change» و «زمان دقیق Incident» را کنار هم بگذار. اگر هر دو طبیعی بودند، «Device/Interface ID» کمک می‌کند محدوده مشکل کوچک‌تر شود. «نتیجه Testهای انجام‌شده و منفی» را زمانی انجام بده که بررسی‌های قبلی جواب روشنی نداده‌اند.

Uplink هر روز 14:00 قطع می‌شود

Uplink هر روز ۱۴:۰۰ قطع می‌شود. Ticket شامل فقط «Switch مشکل دارد» است. اگر Counter، Log، زمان دقیق، Interface و Change History نباشد تیم ارشد دوباره همه چیز را از اول می‌پرسد.

ترتیب منطقی بررسی همین وضعیت می‌تواند این باشد: Output قبل از Change → زمان دقیق Incident → Device/Interface ID → نتیجه Testهای انجام‌شده و منفی. این ترتیب را با نتیجه واقعی هر مرحله جلو ببر؛ اگر یکی از بررسی‌ها علت را روشن کرد، سراغ تغییرهای بی‌ربط نرو.

برای یک Uplink intermittent یک بسته Escalation یک‌صفحه‌ای بساز: Summary

برای یک Uplink intermittent یک بسته Escalation یک‌صفحه‌ای بساز: Summary، Impact، Timeline، Topology، سه Output کلیدی و کاری که نباید تکرار شود.

قبل از ایجاد خطا «Output قبل از Change» را در حالت سالم ثبت کن. بعد از ایجاد یک خطای کنترل‌شده، همان مورد و در پایان «نتیجه Testهای انجام‌شده و منفی» را دوباره بررسی کن. تفاوت قبل و بعد باید در گزارش تمرین مشخص باشد.

ارسال Running-config کامل با Secret

ارسال Running-config کامل با Secret. گرفتن debug سنگین بدون هماهنگی. Escalate کردن بدون Scope و Test.

CCST باید بداند چه شواهدی جمع کند. TAC Case پیچیده و Debug تخصصی با راهنمای مهندس ارشد انجام می‌شود.

Escalation باید قابل ادامه باشد

Escalation باید قابل ادامه باشد. Output کمتر ولی مرتبط بهتر از Dump نامرتب است. اطلاعات حساس باید محافظت شود.

برای Uplink Error کدام Output مستقیم‌تر است؟ show interfaces همان Port همراه Counter و Status. آیا همیشه باید running-config کامل را ارسال کرد؟ خیر؛ ممکن است اطلاعات حساس داشته باشد و فقط بخش لازم طبق Policy ارسال می‌شود.

Escalation خوب یعنی نفر بعدی مجبور نباشد بررسی را از صفر شروع کند

Escalation خوب یعنی نفر بعدی مجبور نباشد بررسی را از صفر شروع کند. زمان دقیق مشکل، Device و Interface درگیر، محدوده کاربران، آخرین تغییر، خروجی دستورهای مرتبط و نتیجه بررسی‌هایی که انجام شده‌اند را کنار Ticket بگذار. جمله «Uplink مشکل دارد» برای ادامه کار کافی نیست.

خروجی‌های Cisco را هدفمند جمع کن؛ مثلاً وضعیت Interface، Counterها، Route مرتبط یا Neighborها. لازم نیست هزاران خط نامرتبط بفرستی. قبل از ارسال Config یا Show Output هم اطلاعات حساس مثل Password، Secret، Community یا Public IPهای محرمانه را طبق سیاست سازمان مدیریت کن.

اگر مشکل intermittent است، زمان رخداد اهمیت بیشتری پیدا می‌کند. Counter قبل و بعد، Log همان دقیقه و وضعیت سمت مقابل را ثبت کن. چنین اطلاعاتی به مهندس ارشد اجازه می‌دهد Eventهای دو Device را با هم تطبیق بدهد و صرفاً از روی حدس تصمیم نگیرد.