با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
CPU بالا و MAC Flap نشانهاند
پردازنده دستورهای سیستمعامل و برنامهها را اجرا میکند و زمان پردازش را بین کارها تقسیم میکند؛ در Task Manager فقط درصد لحظهای را نبین؛ نام Process، مدت درگیری و الگوی تکرار را هم بررسی کن CPU صددرصد برای چند ثانیه میتواند طبیعی باشد؛ مشکل وقتی مهم میشود که ماندگار باشد یا پاسخگویی سیستم را مختل کند MAC Address شناسه لایه محلی Interface است و Switch از آن برای یادگیری محل دستگاه استفاده میکند؛ MAC Table کمک میکند بفهمی یک دستگاه از کدام Port دیده میشود MAC با IP نقش یکسان ندارد و معمولاً Route بین شبکهها بر اساس IP است در مستندات معماری پردازنده، هسته واحد فیزیکی اجرای دستورهاست و رشته مسیر منطقی اجرای کارها را نشان میدهد؛ فرکانس فقط یکی از عوامل کارایی است و معماری پردازنده، تعداد هستهها، اندازه و سطح Cache، نوع بار کاری و محدودیتهای توان و دما نیز روی نتیجه اثر میگذارند؛ در عیبیابی نباید صرفاً از روی درصد مصرف CPU نتیجه گرفت که پردازنده خراب یا ضعیف است، بلکه باید Process مصرفکننده، مدت زمان مصرف، دمای سیستم و رفتار برنامه در همان بازه بررسی شود
Portهای جدید را بررسی کن
Port عدد منطقی داخل TCP یا UDP است که سرویس مقصد را مشخص میکند؛ برای تست سرویس باید IP مقصد، پروتکل و Port را با هم بدانیم Port فیزیکی Switch با Port نرمافزاری TCP/UDP یکی نیست در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که سناریوی واقعی را مثل یک رخداد زنده مدیریت کن: ابتدا دامنه اثر و سرویس حیاتی را مشخص کن، سپس شواهد جمع کن و از تغییرهای پرخطر دوری کن؛ اگر چند نشانه همزمان وجود دارند، ممکن است یک علت مشترک مانند DNS، Uplink، Storage یا Identity پشت آنها باشد؛ وابستگی سرویسها را روی کاغذ یا Diagram دنبال کن اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، در سناریوهای چندلایه، ترتیب آزمون اهمیت دارد؛ ابتدا تستی را انتخاب کن که با کمترین ریسک بیشترین اطلاعات را بدهد و اگر فرضیه رد شد مسیر بعدی را انتخاب کن؛ ارتباط با کاربران و ثبت Timeline هم بخشی از مدیریت رخداد است چون بعداً برای تحلیل علت، گزارش مدیریتی و جلوگیری از تکرار استفاده میشود
STP Status را ببین
STP برای جلوگیری از Loop لایه دو مسیرهای اضافی را محاسبه و بعضی Portها را Block میکند؛ تغییر Topology یا Portهای Blocking را هنگام اختلال بررسی کن خاموش کردن STP برای رفع موقت میتواند Broadcast Storm ایجاد کند Spanning Tree برای جلوگیری از Loop در شبکههای لایه دوم طراحی شده است؛ Switchها با تبادل اطلاعات کنترلی توپولوژی را میشناسند و بعضی مسیرهای افزونه را تا زمانی که لازم نباشند در حالت Forwarding قرار نمیدهند؛ وقتی مشکل Broadcast Storm یا قطع و وصل متناوب دیده میشود، وضعیت STP، نقش پورتها، تغییرات توپولوژی و کابلهای موازی باید بررسی شوند و حذف تصادفی یک مسیر بدون شناخت توپولوژی میتواند افزونگی شبکه را از بین ببرد نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که سناریوی واقعی را مثل یک رخداد زنده مدیریت کن: ابتدا دامنه اثر و سرویس حیاتی را مشخص کن، سپس شواهد جمع کن و از تغییرهای پرخطر دوری کن؛ اگر چند نشانه همزمان وجود دارند، ممکن است یک علت مشترک مانند DNS، Uplink، Storage یا Identity پشت آنها باشد؛ وابستگی سرویسها را روی کاغذ یا Diagram دنبال کن
کابل مشکوک را کنترلشده جدا کن
در Broadcast Storm اگر Loop فیزیکی محتمل است Link مشکوک را با شناخت Topology و اثر آن کنترلشده جدا کن؛ قطع کور Uplink میتواند بخش بیشتری را بخواباند در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: سناریوی واقعی را مثل یک رخداد زنده مدیریت کن: ابتدا دامنه اثر و سرویس حیاتی را مشخص کن، سپس شواهد جمع کن و از تغییرهای پرخطر دوری کن؛ اگر چند نشانه همزمان وجود دارند، ممکن است یک علت مشترک مانند DNS، Uplink، Storage یا Identity پشت آنها باشد؛ وابستگی سرویسها را روی کاغذ یا Diagram دنبال کن برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، در سناریوهای چندلایه، ترتیب آزمون اهمیت دارد؛ ابتدا تستی را انتخاب کن که با کمترین ریسک بیشترین اطلاعات را بدهد و اگر فرضیه رد شد مسیر بعدی را انتخاب کن؛ ارتباط با کاربران و ثبت Timeline هم بخشی از مدیریت رخداد است چون بعداً برای تحلیل علت، گزارش مدیریتی و جلوگیری از تکرار استفاده میشود برای کامل شدن تصویر این موضوع، در این درس تمرکز روی روش فکر کردن در رخداد واقعی است؛ به جای آزمونهای تصادفی باید Scope، Timeline، Recent Change و Evidence را مشخص کنی و هر تست را برای تأیید یا رد یک فرضیه انجام بدهی؛ هدف فقط رسیدن به Fix نیست، بلکه باید بتوانی علت، نتیجه تستها، Validation و اقدام پیشگیرانه را توضیح و مستند کنی
بعد تثبیت Protection را اصلاح کن
بعد از توقف Storm فقط کابل را کنار نگذار؛ STP، BPDU Guard یا طراحی Port را اصلاح کن تا همان خطا دوباره کل شبکه را تحت تأثیر قرار ندهد در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: سناریوی واقعی را مثل یک رخداد زنده مدیریت کن: ابتدا دامنه اثر و سرویس حیاتی را مشخص کن، سپس شواهد جمع کن و از تغییرهای پرخطر دوری کن؛ اگر چند نشانه همزمان وجود دارند، ممکن است یک علت مشترک مانند DNS، Uplink، Storage یا Identity پشت آنها باشد؛ وابستگی سرویسها را روی کاغذ یا Diagram دنبال کن برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، در سناریوهای چندلایه، ترتیب آزمون اهمیت دارد؛ ابتدا تستی را انتخاب کن که با کمترین ریسک بیشترین اطلاعات را بدهد و اگر فرضیه رد شد مسیر بعدی را انتخاب کن؛ ارتباط با کاربران و ثبت Timeline هم بخشی از مدیریت رخداد است چون بعداً برای تحلیل علت، گزارش مدیریتی و جلوگیری از تکرار استفاده میشود برای کامل شدن تصویر این موضوع، در این درس تمرکز روی روش فکر کردن در رخداد واقعی است؛ به جای آزمونهای تصادفی باید Scope، Timeline، Recent Change و Evidence را مشخص کنی و هر تست را برای تأیید یا رد یک فرضیه انجام بدهی؛ هدف فقط رسیدن به Fix نیست، بلکه باید بتوانی علت، نتیجه تستها، Validation و اقدام پیشگیرانه را توضیح و مستند کنی
فرض کن در سناریوی واقعی شرکت مشکلی گزارش شده و احتمال میدهی به سناریو: Loop و Broadcast Storm مربوط باشد. قبل از تغییر، وضعیت فعلی را با ابزارهای مرتبط با همان سناریو و مستندات شرکت بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- تغییر دادن تنظیمات مرتبط با سناریو: Loop و Broadcast Storm قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره سناریو: Loop و Broadcast Storm فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با سناریو: Loop و Broadcast Storm، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با ابزارهای مرتبط با همان سناریو و مستندات شرکت وضعیت مرتبط با سناریو: Loop و Broadcast Storm را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با سناریو: Loop و Broadcast Storm بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- CPU بالا و MAC Flap نشانهاند
- Portهای جدید را بررسی کن
- STP Status را ببین
- کابل مشکوک را کنترلشده جدا کن
- بعد تثبیت Protection را اصلاح کن
- در هر مرحله فقط یک تغییر کنترلشده انجام بده تا اثر آن قابل تشخیص باشد
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: CPU بالا و MAC Flap نشانهاند. بعد بگو در عمل چطور آن را بررسی میکنی.
پردازنده دستورهای سیستمعامل و برنامهها را اجرا میکند و زمان پردازش را بین کارها تقسیم میکند؛ در Task Manager فقط درصد لحظهای را نبین؛ نام Process، مدت درگیری و الگوی تکرار را هم بررسی کن
چرا باید Portهای جدید را بررسی کنی و از کجا میفهمی نتیجه درست است؟
Port عدد منطقی داخل TCP یا UDP است که سرویس مقصد را مشخص میکند؛ برای تست سرویس باید IP مقصد، پروتکل و Port را با هم بدانیم
چرا باید STP Status را ببینی و از کجا میفهمی نتیجه درست است؟
STP برای جلوگیری از Loop لایه دو مسیرهای اضافی را محاسبه و بعضی Portها را Block میکند؛ تغییر Topology یا Portهای Blocking را هنگام اختلال بررسی کن
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
