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