با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
نشانه دقیق را قبل از تعویض قطعه ثبت کن
قبل از تعویض قطعه بنویس مشکل دقیقاً چه زمانی، با چه پیامی و در چه شرایطی رخ میدهد؛ بدون ثبت نشانه ممکن است قطعه سالم را عوض کنی و بعد نتوانی بفهمی تغییر واقعاً مؤثر بوده یا نه روش عیبیابی قابل اتکا از تعیین دامنه مشکل شروع میشود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویسها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیهها از کمریسکترین تستها بررسی شوند؛ تغییر چند عامل همزمان تشخیص علت را دشوار میکند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که مشخصات قطعه باید با مدل دقیق و مستندات سازنده تطبیق داده شود؛ شباهت ظاهری Connector یا Slot همیشه به معنی سازگاری الکتریکی و منطقی نیست؛ در محیط سازمانی علاوه بر کار کردن قطعه، پایداری، Driver معتبر، وضعیت Warranty و امکان جایگزینی نیز اهمیت دارد و نتیجه کار باید در Inventory سیستم ثبت شود
برق و کابل و اتصال فیزیکی را اول بررسی کن
در عیبیابی سختافزار از سادهترین زنجیره شروع کن: برق ورودی، آداپتور یا پاور، کابل، Connector و نشانههای روشن شدن؛ این بررسیها کمخطرند و قبل از تعویض قطعه اطلاعات زیادی میدهند روش عیبیابی قابل اتکا از تعیین دامنه مشکل شروع میشود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویسها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیهها از کمریسکترین تستها بررسی شوند؛ تغییر چند عامل همزمان تشخیص علت را دشوار میکند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: در عیبیابی سختافزار، مشاهده و اندازهگیری باید قبل از تعویض قطعه انجام شود؛ وضعیت Power، کابل، دما، اتصال فیزیکی، تشخیص Firmware و سپس وضعیت Device در سیستمعامل مسیر منطقی بررسی است؛ اگر قطعهای برای تست جایگزین میشود، بهتر است فقط همان متغیر تغییر کند تا معلوم باشد بهبود یا خرابی ناشی از کدام عامل بوده است برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که مشخصات قطعه باید با مدل دقیق و مستندات سازنده تطبیق داده شود؛ شباهت ظاهری Connector یا Slot همیشه به معنی سازگاری الکتریکی و منطقی نیست؛ در محیط سازمانی علاوه بر کار کردن قطعه، پایداری، Driver معتبر، وضعیت Warranty و امکان جایگزینی نیز اهمیت دارد و نتیجه کار باید در Inventory سیستم ثبت شود
در هر مرحله فقط یک متغیر را تغییر بده
وقتی چند چیز را با هم عوض میکنی حتی اگر مشکل حل شود نمیفهمی کدام تغییر مؤثر بوده است؛ یک تغییر، یک آزمایش و یک نتیجه ثبتشده، عیبیابی را قابل تکرار میکند روش عیبیابی قابل اتکا از تعیین دامنه مشکل شروع میشود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویسها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیهها از کمریسکترین تستها بررسی شوند؛ تغییر چند عامل همزمان تشخیص علت را دشوار میکند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که در عیبیابی سختافزار، مشاهده و اندازهگیری باید قبل از تعویض قطعه انجام شود؛ وضعیت Power، کابل، دما، اتصال فیزیکی، تشخیص Firmware و سپس وضعیت Device در سیستمعامل مسیر منطقی بررسی است؛ اگر قطعهای برای تست جایگزین میشود، بهتر است فقط همان متغیر تغییر کند تا معلوم باشد بهبود یا خرابی ناشی از کدام عامل بوده است
تست با قطعه سالم شناختهشده دامنه مشکل را کم میکند
اگر قطعهای سالم و سازگار داری میتوانی آن را کنترلشده جایگزین کنی تا فرضیه را آزمایش کنی. «سالم شناختهشده» یعنی قبلاً کارکرد آن تأیید شده باشد، نه قطعهای که فقط نو به نظر میرسد روش عیبیابی قابل اتکا از تعیین دامنه مشکل شروع میشود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویسها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیهها از کمریسکترین تستها بررسی شوند؛ تغییر چند عامل همزمان تشخیص علت را دشوار میکند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، در عیبیابی سختافزار، مشاهده و اندازهگیری باید قبل از تعویض قطعه انجام شود؛ وضعیت Power، کابل، دما، اتصال فیزیکی، تشخیص Firmware و سپس وضعیت Device در سیستمعامل مسیر منطقی بررسی است؛ اگر قطعهای برای تست جایگزین میشود، بهتر است فقط همان متغیر تغییر کند تا معلوم باشد بهبود یا خرابی ناشی از کدام عامل بوده است
بعد از رفع مشکل پایداری را تست و نتیجه را مستند کن
یک بار روشن شدن سیستم کافی نیست؛ همان کاری را که مشکل ایجاد میکرد چند بار و در مدت مناسب تکرار کن، دما و خطاها را ببین و در پایان قطعه یا تنظیم تغییرکرده و نتیجه آزمایش را ثبت کن روش عیبیابی قابل اتکا از تعیین دامنه مشکل شروع میشود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویسها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیهها از کمریسکترین تستها بررسی شوند؛ تغییر چند عامل همزمان تشخیص علت را دشوار میکند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که در عیبیابی سختافزار، مشاهده و اندازهگیری باید قبل از تعویض قطعه انجام شود؛ وضعیت Power، کابل، دما، اتصال فیزیکی، تشخیص Firmware و سپس وضعیت Device در سیستمعامل مسیر منطقی بررسی است؛ اگر قطعهای برای تست جایگزین میشود، بهتر است فقط همان متغیر تغییر کند تا معلوم باشد بهبود یا خرابی ناشی از کدام عامل بوده است
فرض کن در رایانه کاربر مشکلی گزارش شده و احتمال میدهی به روش استاندارد عیبیابی سختافزار مربوط باشد. قبل از تغییر، وضعیت فعلی را با Task Manager، Device Manager، BIOS/UEFI و ابزار تشخیصی سازنده بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- یک بار روشن شدن سیستم کافی نیست؛ همان کاری را که مشکل ایجاد میکرد چند بار و در مدت مناسب تکرار کن، دما و خطاها را ببین و در پایان قطعه یا تنظیم تغییرکرده و نتیجه آزمایش را ثبت کن
- تغییر دادن تنظیمات مرتبط با روش استاندارد عیبیابی سختافزار قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره روش استاندارد عیبیابی سختافزار فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با روش استاندارد عیبیابی سختافزار، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با Task Manager، Device Manager، BIOS/UEFI و ابزار تشخیصی سازنده وضعیت مرتبط با روش استاندارد عیبیابی سختافزار را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با روش استاندارد عیبیابی سختافزار بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- نشانه دقیق را قبل از تعویض قطعه ثبت کن
- برق و کابل و اتصال فیزیکی را اول بررسی کن
- در هر مرحله فقط یک متغیر را تغییر بده
- تست با قطعه سالم شناختهشده دامنه مشکل را کم میکند
- بعد از رفع مشکل پایداری را تست و نتیجه را مستند کن
- قبل از باز کردن کیس یا جابهجایی قطعه، برق را قطع کن و نکات ESD را رعایت کن
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
چرا باید نشانه دقیق را قبل از تعویض قطعه ثبت کنی و از کجا میفهمی نتیجه درست است؟
قبل از تعویض قطعه بنویس مشکل دقیقاً چه زمانی، با چه پیامی و در چه شرایطی رخ میدهد. بدون ثبت نشانه ممکن است قطعه سالم را عوض کنی و بعد نتوانی بفهمی تغییر واقعاً مؤثر بوده یا نه
چرا باید برق و کابل و اتصال فیزیکی را اول بررسی کنی و از کجا میفهمی نتیجه درست است؟
در عیبیابی سختافزار از سادهترین زنجیره شروع کن: برق ورودی، آداپتور یا پاور، کابل، Connector و نشانههای روشن شدن؛ این بررسیها کمخطرند و قبل از تعویض قطعه اطلاعات زیادی میدهند
چرا باید در هر مرحله فقط یک متغیر را تغییر بدهی و از کجا میفهمی نتیجه درست است؟
وقتی چند چیز را با هم عوض میکنی حتی اگر مشکل حل شود نمیفهمی کدام تغییر مؤثر بوده است. یک تغییر، یک آزمایش و یک نتیجه ثبتشده، عیبیابی را قابل تکرار میکند
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
