با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
نشانه با علت اصلی فرق دارد
نشانه با علت اصلی فرق دارد علت اصلی، علت زیربنایی است که با حذف یا کنترل آن احتمال تکرار رخداد کم میشود؛ نشانه رفعشده را با علت اصلی یکی ندان گاهی چند علت و عامل کمککننده وجود دارد روش عیبیابی قابل اتکا از تعیین دامنه مشکل شروع میشود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویسها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیهها از کمریسکترین تستها بررسی شوند؛ تغییر چند عامل همزمان تشخیص علت را دشوار میکند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که در رخداد پیچیده، لایهها را جدا کن و یک نقطه سالم مرجع پیدا کن؛ مقایسه Client سالم و مشکلدار، Port سالم و مشکلدار یا زمان قبل و بعد از Change میتواند تفاوت معنیدار را آشکار کند؛ وقتی علت پیدا شد، Workaround و Root Cause را از هم جدا ثبت کن و بعد از Fix سرویس را از دید کاربر و Monitoring تأیید کن
حدس باید فرضیه باشد
حدس باید فرضیه باشد فرضیه یک علت احتمالی قابل تست است که از شواهد ساخته میشود؛ تستی انتخاب کن که بتواند فرضیه را رد یا تأیید کند فرضیه را با حقیقت قطعی اشتباه نکن روش عیبیابی قابل اتکا از تعیین دامنه مشکل شروع میشود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویسها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیهها از کمریسکترین تستها بررسی شوند؛ تغییر چند عامل همزمان تشخیص علت را دشوار میکند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: در رخداد پیچیده، لایهها را جدا کن و یک نقطه سالم مرجع پیدا کن؛ مقایسه Client سالم و مشکلدار، Port سالم و مشکلدار یا زمان قبل و بعد از Change میتواند تفاوت معنیدار را آشکار کند؛ وقتی علت پیدا شد، Workaround و Root Cause را از هم جدا ثبت کن و بعد از Fix سرویس را از دید کاربر و Monitoring تأیید کن
شواهد تصمیم را تأیید میکند
شواهد داده قابل مشاهده مانند پیام خطا، Log، نتیجه تست، وضعیت Port یا تنظیمات فعلی هستند؛ هر فرضیه باید با شواهد تأیید یا رد شود حدس و تجربه شخصی مفیدند اما جای شواهد را نمیگیرند روش عیبیابی قابل اتکا از تعیین دامنه مشکل شروع میشود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویسها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیهها از کمریسکترین تستها بررسی شوند؛ تغییر چند عامل همزمان تشخیص علت را دشوار میکند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: در رخداد پیچیده، لایهها را جدا کن و یک نقطه سالم مرجع پیدا کن؛ مقایسه Client سالم و مشکلدار، Port سالم و مشکلدار یا زمان قبل و بعد از Change میتواند تفاوت معنیدار را آشکار کند؛ وقتی علت پیدا شد، Workaround و Root Cause را از هم جدا ثبت کن و بعد از Fix سرویس را از دید کاربر و Monitoring تأیید کن
تست باید کمخطر باشد
تست باید کمخطر باشد تست خوب باید بیشترین اطلاعات را با کمترین احتمال اختلال بدهد. Ping، مشاهده Log یا مقایسه تنظیمات معمولاً قبل از Restart سرویس حیاتی یا تغییر Firewall قرار میگیرند روش عیبیابی قابل اتکا از تعیین دامنه مشکل شروع میشود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویسها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیهها از کمریسکترین تستها بررسی شوند؛ تغییر چند عامل همزمان تشخیص علت را دشوار میکند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: عیبیابی حرفهای یعنی مسئله را کوچک کنی نه اینکه تعداد تغییرها را زیاد کنی؛ Scope، Timeline، Recent Change و Evidence چهار ستون اولیهاند؛ سپس هر Test باید یک فرضیه را تأیید یا رد کند و نتیجه ثبت شود؛ اگر یک Test اطلاعات جدیدی نمیدهد، صرف تکرار آن ارزش تشخیصی ندارد اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، در رخداد پیچیده، لایهها را جدا کن و یک نقطه سالم مرجع پیدا کن؛ مقایسه Client سالم و مشکلدار، Port سالم و مشکلدار یا زمان قبل و بعد از Change میتواند تفاوت معنیدار را آشکار کند؛ وقتی علت پیدا شد، Workaround و Root Cause را از هم جدا ثبت کن و بعد از Fix سرویس را از دید کاربر و Monitoring تأیید کن
هدف بازگرداندن سرویس پایدار است
عیبیابی فقط پیدا کردن علت جذاب نیست؛ هدف اول بازگرداندن سرویس به وضعیت پایدار و امن است و بعد، برای مشکل مهم یا تکراری، علت اصلی و اقدام پیشگیرانه بررسی میشود روش عیبیابی قابل اتکا از تعیین دامنه مشکل شروع میشود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویسها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیهها از کمریسکترین تستها بررسی شوند؛ تغییر چند عامل همزمان تشخیص علت را دشوار میکند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که عیبیابی حرفهای یعنی مسئله را کوچک کنی نه اینکه تعداد تغییرها را زیاد کنی؛ Scope، Timeline، Recent Change و Evidence چهار ستون اولیهاند؛ سپس هر Test باید یک فرضیه را تأیید یا رد کند و نتیجه ثبت شود؛ اگر یک Test اطلاعات جدیدی نمیدهد، صرف تکرار آن ارزش تشخیصی ندارد برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، در رخداد پیچیده، لایهها را جدا کن و یک نقطه سالم مرجع پیدا کن؛ مقایسه Client سالم و مشکلدار، Port سالم و مشکلدار یا زمان قبل و بعد از Change میتواند تفاوت معنیدار را آشکار کند؛ وقتی علت پیدا شد، Workaround و Root Cause را از هم جدا ثبت کن و بعد از Fix سرویس را از دید کاربر و Monitoring تأیید کن
فرض کن در یک رخداد عیبیابی واقعی مشکلی گزارش شده و احتمال میدهی به ذهنیت عیبیابی؛ نشانه با علت فرق دارد مربوط باشد. قبل از تغییر، وضعیت فعلی را با ابزارهای شبکه، Logها و مقایسه قبل و بعد بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- حدس و تجربه شخصی مفیدند اما جای شواهد را نمیگیرند
- تغییر دادن تنظیمات مرتبط با ذهنیت عیبیابی؛ نشانه با علت فرق دارد قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره ذهنیت عیبیابی؛ نشانه با علت فرق دارد فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با ذهنیت عیبیابی؛ نشانه با علت فرق دارد، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با ابزارهای شبکه، Logها و مقایسه قبل و بعد وضعیت مرتبط با ذهنیت عیبیابی؛ نشانه با علت فرق دارد را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با ذهنیت عیبیابی؛ نشانه با علت فرق دارد بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- نشانه با علت اصلی فرق دارد
- حدس باید فرضیه باشد
- شواهد تصمیم را تأیید میکند
- تست باید کمخطر باشد
- هدف بازگرداندن سرویس پایدار است
- قبل از تغییر، محدوده مشکل را مشخص کن و از کمخطرترین تست شروع کن
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: نشانه با علت اصلی فرق دارد. بعد بگو در عمل چطور آن را بررسی میکنی.
علت اصلی، علت زیربنایی است که با حذف یا کنترل آن احتمال تکرار رخداد کم میشود؛ نشانه رفعشده را با علت اصلی یکی ندان
این نکته را با یک مثال توضیح بده: حدس باید فرضیه باشد. بعد بگو در عمل چطور آن را بررسی میکنی.
فرضیه یک علت احتمالی قابل تست است که از شواهد ساخته میشود؛ تستی انتخاب کن که بتواند فرضیه را رد یا تأیید کند
این نکته را با یک مثال توضیح بده: شواهد تصمیم را تأیید میکند. بعد بگو در عمل چطور آن را بررسی میکنی.
شواهد داده قابل مشاهده مانند پیام خطا، Log، نتیجه تست، وضعیت Port یا تنظیمات فعلی هستند؛ هر فرضیه باید با شواهد تأیید یا رد شود
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
