با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
یک کاربر یا چند کاربر یا همه را مشخص کن
اول مشخص کن محدوده یک کاربر، یک دستگاه، یک بخش یا کل شرکت است؛ همین پاسخ بسیاری از فرضیهها را حذف میکند و نشان میدهد از Client شروع کنی یا از سرویس مشترک در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: در رخداد پیچیده، لایهها را جدا کن و یک نقطه سالم مرجع پیدا کن؛ مقایسه Client سالم و مشکلدار، Port سالم و مشکلدار یا زمان قبل و بعد از Change میتواند تفاوت معنیدار را آشکار کند؛ وقتی علت پیدا شد، Workaround و Root Cause را از هم جدا ثبت کن و بعد از Fix سرویس را از دید کاربر و Monitoring تأیید کن نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که عیبیابی حرفهای یعنی مسئله را کوچک کنی نه اینکه تعداد تغییرها را زیاد کنی؛ Scope، Timeline، Recent Change و Evidence چهار ستون اولیهاند؛ سپس هر Test باید یک فرضیه را تأیید یا رد کند و نتیجه ثبت شود؛ اگر یک Test اطلاعات جدیدی نمیدهد، صرف تکرار آن ارزش تشخیصی ندارد برای کامل شدن تصویر این موضوع، در این درس تمرکز روی روش فکر کردن در رخداد واقعی است؛ به جای آزمونهای تصادفی باید Scope، Timeline، Recent Change و Evidence را مشخص کنی و هر تست را برای تأیید یا رد یک فرضیه انجام بدهی؛ هدف فقط رسیدن به Fix نیست، بلکه باید بتوانی علت، نتیجه تستها، Validation و اقدام پیشگیرانه را توضیح و مستند کنی
Location و VLAN و نرمافزار را مقایسه کن
VLAN یک Broadcast Domain منطقی جدا روی زیرساخت Switch میسازد؛ کاربران دو VLAN برای ارتباط به Routing نیاز دارند VLAN امنیت کامل نیست؛ Policy بین VLANها هم مهم است VLAN یک Broadcast Domain منطقی ایجاد میکند و به سازمان اجازه میدهد جداسازی شبکه را مستقل از محل فیزیکی کاربران انجام دهد؛ Access Port معمولاً ترافیک یک VLAN را برای End Device حمل میکند و Trunk چند VLAN را با Tag ۸۰۲.۱Q بین تجهیزات منتقل میکند؛ برای عیبیابی باید VLAN ID در دو سر لینک، وضعیت Tag و Untag، Native VLAN در صورت استفاده و عضویت پورتها با طراحی شبکه مقایسه شوند برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که در رخداد پیچیده، لایهها را جدا کن و یک نقطه سالم مرجع پیدا کن؛ مقایسه Client سالم و مشکلدار، Port سالم و مشکلدار یا زمان قبل و بعد از Change میتواند تفاوت معنیدار را آشکار کند؛ وقتی علت پیدا شد، Workaround و Root Cause را از هم جدا ثبت کن و بعد از Fix سرویس را از دید کاربر و Monitoring تأیید کن
اثر کسبوکار را بفهم
اثر میزان اثر رخداد یا تغییر روی کاربران و فرایند کسبوکار است؛ تعداد کاربر تنها معیار نیست؛ اهمیت سرویس و وجود راه جایگزین هم مهم است اثر را با احساس فوریت فرد گزارشدهنده یکی ندان اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، در رخداد پیچیده، لایهها را جدا کن و یک نقطه سالم مرجع پیدا کن؛ مقایسه Client سالم و مشکلدار، Port سالم و مشکلدار یا زمان قبل و بعد از Change میتواند تفاوت معنیدار را آشکار کند؛ وقتی علت پیدا شد، Workaround و Root Cause را از هم جدا ثبت کن و بعد از Fix سرویس را از دید کاربر و Monitoring تأیید کن در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که عیبیابی حرفهای یعنی مسئله را کوچک کنی نه اینکه تعداد تغییرها را زیاد کنی؛ Scope، Timeline، Recent Change و Evidence چهار ستون اولیهاند؛ سپس هر Test باید یک فرضیه را تأیید یا رد کند و نتیجه ثبت شود؛ اگر یک Test اطلاعات جدیدی نمیدهد، صرف تکرار آن ارزش تشخیصی ندارد
محدوده درست از تغییر بخش سالم جلوگیری میکند
محدوده مشکل مشخص میکند چند کاربر، دستگاه، شبکه یا سرویس تحت تأثیر هستند؛ مقایسه یک نمونه سالم و خراب سریعترین راه کوچک کردن محدوده است قبل از دانستن محدوده سراغ تغییر سراسری نرو Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمانبندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود میتواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگیها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفهای است در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که عیبیابی حرفهای یعنی مسئله را کوچک کنی نه اینکه تعداد تغییرها را زیاد کنی؛ Scope، Timeline، Recent Change و Evidence چهار ستون اولیهاند؛ سپس هر Test باید یک فرضیه را تأیید یا رد کند و نتیجه ثبت شود؛ اگر یک Test اطلاعات جدیدی نمیدهد، صرف تکرار آن ارزش تشخیصی ندارد
نمونه سالم برای مقایسه مفید است
نمونه سالم یک Reference سریع میدهد؛ اختلاف IP، Version، Policy یا رفتار بین سالم و خراب معمولاً دامنه علت را کوچک میکند، به شرطی که دو نمونه واقعاً قابل مقایسه باشند برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، عیبیابی حرفهای یعنی مسئله را کوچک کنی نه اینکه تعداد تغییرها را زیاد کنی؛ Scope، Timeline، Recent Change و Evidence چهار ستون اولیهاند؛ سپس هر Test باید یک فرضیه را تأیید یا رد کند و نتیجه ثبت شود؛ اگر یک Test اطلاعات جدیدی نمیدهد، صرف تکرار آن ارزش تشخیصی ندارد اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، در رخداد پیچیده، لایهها را جدا کن و یک نقطه سالم مرجع پیدا کن؛ مقایسه Client سالم و مشکلدار، Port سالم و مشکلدار یا زمان قبل و بعد از Change میتواند تفاوت معنیدار را آشکار کند؛ وقتی علت پیدا شد، Workaround و Root Cause را از هم جدا ثبت کن و بعد از Fix سرویس را از دید کاربر و Monitoring تأیید کن برای کامل شدن تصویر این موضوع، در این درس تمرکز روی روش فکر کردن در رخداد واقعی است؛ به جای آزمونهای تصادفی باید Scope، Timeline، Recent Change و Evidence را مشخص کنی و هر تست را برای تأیید یا رد یک فرضیه انجام بدهی؛ هدف فقط رسیدن به Fix نیست، بلکه باید بتوانی علت، نتیجه تستها، Validation و اقدام پیشگیرانه را توضیح و مستند کنی
فرض کن در یک رخداد عیبیابی واقعی مشکلی گزارش شده و احتمال میدهی به تعیین محدوده و اثر مربوط باشد. قبل از تغییر، وضعیت فعلی را با ابزارهای شبکه، Logها و مقایسه قبل و بعد بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- تغییر دادن تنظیمات مرتبط با تعیین محدوده و اثر قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره تعیین محدوده و اثر فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با تعیین محدوده و اثر، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با ابزارهای شبکه، Logها و مقایسه قبل و بعد وضعیت مرتبط با تعیین محدوده و اثر را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با تعیین محدوده و اثر بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- یک کاربر یا چند کاربر یا همه را مشخص کن
- Location و VLAN و نرمافزار را مقایسه کن
- اثر کسبوکار را بفهم
- محدوده درست از تغییر بخش سالم جلوگیری میکند
- نمونه سالم برای مقایسه مفید است
- قبل از تغییر، محدوده مشکل را مشخص کن و از کمخطرترین تست شروع کن
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
چرا باید یک کاربر یا چند کاربر یا همه را مشخص کنی و از کجا میفهمی نتیجه درست است؟
اول مشخص کن محدوده یک کاربر، یک دستگاه، یک بخش یا کل شرکت است. همین پاسخ بسیاری از فرضیهها را حذف میکند و نشان میدهد از Client شروع کنی یا از سرویس مشترک
چرا باید Location و VLAN و نرمافزار را مقایسه کنی و از کجا میفهمی نتیجه درست است؟
VLAN یک Broadcast Domain منطقی جدا روی زیرساخت Switch میسازد؛ کاربران دو VLAN برای ارتباط به Routing نیاز دارند
این نکته را با یک مثال توضیح بده: اثر کسبوکار را بفهم. بعد بگو در عمل چطور آن را بررسی میکنی.
اثر میزان اثر رخداد یا تغییر روی کاربران و فرایند کسبوکار است؛ تعداد کاربر تنها معیار نیست؛ اهمیت سرویس و وجود راه جایگزین هم مهم است
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
