هناك نوع من أعطال الكمبيوتر واللابتوب يجعلك تشك في نفسك قبل أن تشك في الجهاز.
تستخدم جهازك بشكل طبيعي، وفجأة يتجمد. الشاشة تتوقف. البرنامج لا يستجيب. الصوت يتقطع. الإنترنت يختفي. أو يصبح الجهاز بطيئًا بطريقة غريبة.
ثم تنتظر قليلًا...
يعود كل شيء طبيعيًا.
تحاول البحث عن المشكلة، لكن عندما تبدأ الفحص لا تجد شيئًا. الجهاز يعمل، والبرامج تفتح، ودرجات الحرارة تبدو عادية، ولا توجد رسالة واضحة تخبرك بما حدث.
ثم بعد يوم أو يومين، يعود العطل مرة أخرى.
 |
| العطل الذي يظهر ويختفي.. كيف تمسك به متلبسًا؟ |
وهنا تبدأ الجملة الشهيرة:
"الجهاز كان خربان قبل شوي، والحين ما فيه شيء!"
لكن الحقيقة أن الجهاز لم يصلح نفسه.
أنت فقط فقدت لحظة وقوع الجريمة.
العطل المتقطع لا يعني أن المشكلة وهمية، بل يعني أن هناك شرطًا معينًا يجعلها تظهر، ثم يختفي هذا الشرط قبل أن تبدأ التحقيق. ولذلك فإن التعامل معه يحتاج إلى طريقة مختلفة عن التعامل مع العطل الدائم.
لا تبحث فقط عن القطعة التالفة.
ابحث عن الظروف التي تجعل العطل يظهر.
وفي هذا المقال سنبني طريقة عملية تساعدك على "الإمساك" بالعطل وهو يحدث، بدل انتظار أن يختفي ثم محاولة تخمين سببه.
لماذا العطل المتقطع أصعب من العطل الدائم؟
العطل الدائم يعطيك هدفًا واضحًا.
إذا كان الجهاز لا يقلع، تستطيع اختبار الطاقة والذاكرة والتخزين والشاشة وغيرها.
أما العطل المتقطع فهو يتحرك.
يظهر عندما تكون الظروف مناسبة له، ثم يختفي عندما تتغير هذه الظروف.
تخيل مثلًا أن جهازك يتجمد بعد تشغيل لعبة لمدة 40 دقيقة.
عندما تعيد تشغيله، يعود طبيعيًا.
إذا بدأت التشخيص بعد إعادة التشغيل، ستجد:
المعالج يعمل.
الذاكرة طبيعية.
القرص يعمل.
اللعبة تعمل.
كل شيء يبدو سليمًا.
لكن المشكلة لم تختفِ فعليًا؛ أنت فقط أعدت الجهاز إلى حالة مختلفة.
وهنا يجب أن تغير طريقة تفكيرك.
بدلًا من:
"ما القطعة التالفة؟"
اسأل:
"ما الذي كان يحدث قبل أن يتعطل الجهاز مباشرة؟"
العطل المتقطع يترك آثارًا أكثر مما تتوقع
حتى عندما يختفي العطل، غالبًا ما يترك خلفه بعض الأدلة.
قد تجدها في:
سجل الأحداث في ويندوز.
استهلاك المعالج والذاكرة.
نشاط وحدة التخزين.
درجات الحرارة.
توقيت الأخطاء.
رسائل البرامج.
إعادة تشغيل أحد التعريفات.
تغير تردد المعالج أو بطاقة الرسوميات.
المشكلة أن معظم المستخدمين لا يسجلون هذه المعلومات وقت حدوث العطل.
ينتظرون حتى يعود الجهاز طبيعيًا، ثم يبدأون الفحص.
وهذا يشبه مراقبة حادث مروري بعد إزالة السيارات من الطريق.
ستجد الطريق مفتوحًا، لكنك فقدت أهم لحظة.
الخطوة الأولى: لا تعيد تشغيل الجهاز فورًا
إذا كان الجهاز لا يزال يستجيب جزئيًا، لا تضغط زر إعادة التشغيل مباشرة.
هذه أهم قاعدة في الإمساك بالعطل المتقطع.
إذا تجمد برنامج معين، انتظر قليلًا.
إذا أصبح الجهاز بطيئًا، افتح Task Manager بالضغط على:
Ctrl + Shift + Esc
وحاول معرفة ما الذي يحدث الآن.
راقب:
CPU لمعرفة استهلاك المعالج.
Memory لمعرفة ضغط ذاكرة RAM.
Disk لمعرفة نشاط وحدة التخزين.
GPU لمعرفة نشاط بطاقة الرسوميات.
ثم راقب العمليات التي تظهر في أعلى القائمة.
لا تبحث فقط عن أعلى رقم.
ابحث عن التغير المفاجئ.
إذا كان CPU عند 20% ثم ارتفع إلى 95% في اللحظة التي بدأ فيها الجهاز بالتجمد، فهذه معلومة.
إذا بقي CPU منخفضًا بينما Disk عند 100%، فهذه معلومة مختلفة.
وإذا كانت الذاكرة شبه ممتلئة قبل التجمّد، فهذه معلومة ثالثة.
لا تنتظر حتى يصل المؤشر إلى 100%
من أكثر الأخطاء شيوعًا أن المستخدم يعتقد أن العطل لا علاقة له بالمكون إلا إذا وصل استخدامه إلى 100%.
وهذا غير صحيح.
قد يكون لديك اختناق في مسار معين بينما الاستخدام الإجمالي يبدو منخفضًا.
مثلًا، يمكن لتطبيق أن يعتمد بشدة على نواة معينة من المعالج، بينما يظهر إجمالي استخدام CPU أقل من 100%.
وقد يتأثر الأداء بسبب زمن الوصول إلى التخزين حتى لو لم تكن كل موارد الجهاز ممتلئة.
لذلك لا تسأل فقط:
"كم النسبة؟"
بل اسأل:
"ما الذي تغير في اللحظة التي تغير فيها سلوك الجهاز؟"
هذه نقطة مهمة جدًا في تشخيص الأعطال المتقطعة.
الخطوة الثانية: استخدم التوقيت كسلاح
إذا كنت تريد الإمساك بالعطل، فأنت تحتاج إلى معرفة متى يظهر.
ابدأ بكتابة سجل صغير.
مثال:
الجهاز يعمل طبيعيًا → بعد 15 دقيقة يبدأ البطء.
بعد 25 دقيقة تبدأ المروحة بالارتفاع.
بعد 30 دقيقة يتجمد البرنامج.
بعد 35 دقيقة يعود الجهاز طبيعيًا.
قد يبدو هذا مجرد وصف، لكنه يمكن أن يكون مفتاح المشكلة.
إذا تكرر السيناريو عدة مرات، فقد تجد أن العطل لا يحدث "عشوائيًا" كما كنت تعتقد.
ربما يظهر عندما يصل الجهاز إلى درجة حرارة معينة.
أو عندما تمتلئ الذاكرة.
أو عندما تبدأ عملية في الخلفية.
أو عندما يصل البرنامج إلى مرحلة محددة.
العشوائية أحيانًا تكون نمطًا لم نكتشفه بعد.
الخطوة الثالثة: حاول إعادة إنتاج العطل
هذه أهم مرحلة.
إذا تمكنت من جعل العطل يحدث تحت ظروف متقاربة، فقد انتقلت من التخمين إلى الاختبار.
لنفترض أن الجهاز يتجمد أثناء تشغيل برنامج معين.
لا تستخدم الجهاز بشكل عشوائي طوال اليوم.
بدلًا من ذلك، حاول تكرار نفس السيناريو:
افتح البرنامج.
نفذ نفس المهمة.
راقب الوقت.
راقب الحرارة.
راقب استهلاك الموارد.
ثم كرر التجربة.
إذا حدث العطل مرة أخرى في ظروف مشابهة، أصبح لديك شيء مهم جدًا: قابلية لإعادة الإنتاج.
وكلما استطعت إعادة إنتاج المشكلة بصورة أقرب، أصبح تحديد السبب أسهل.
الخطوة الرابعة: غيّر متغيرًا واحدًا فقط
هنا يقع كثير من المستخدمين في خطأ قاتل أثناء التشخيص.
الجهاز يتجمد، فيقومون في اليوم نفسه بـ:
تحديث ويندوز.
تحديث تعريف كرت الشاشة.
حذف برامج.
تنظيف الجهاز.
تغيير إعدادات الطاقة.
إعادة تثبيت البرنامج.
ثم يقولون:
"انحلت المشكلة."
لكن هل تعرف أي خطوة أصلحتها؟
لا.
لذلك استخدم قاعدة One Change at a Time، أي تغيير متغير واحد في كل مرة.
إذا كنت تشك في برنامج معين، اختبر بدونه.
إذا كنت تشك في تعريف، اختبر إصدارًا مختلفًا.
إذا كنت تشك في وضع الطاقة، غيّر إعداد الطاقة فقط.
ثم أعد الاختبار.
بهذه الطريقة، كل نتيجة تصبح دليلًا.
الخطوة الخامسة: اصطد العطل باستخدام الحرارة
إذا كان العطل يظهر بعد فترة من الاستخدام، فالحرارة يجب أن تكون ضمن أول الأشياء التي تراقبها.
لاحظ الفرق بين:
الجهاز وهو بارد.
الجهاز بعد 10 دقائق.
الجهاز بعد 30 دقيقة.
الجهاز في اللحظة التي تبدأ فيها المشكلة.
إذا وجدت ارتباطًا متكررًا بين ارتفاع الحرارة وظهور العطل، فهذا دليل قوي.
لكن لا تقع في الخطأ المعاكس أيضًا.
لا تقل:
"الجهاز ساخن، إذن الحرارة هي السبب."
الحرارة قد تكون نتيجة للحمل المرتفع وليس سبب العطل.
مثلًا، قد يبدأ برنامج معين بتحميل المعالج بقوة بسبب مشكلة برمجية، فترتفع الحرارة بعد ذلك.
إذن نحتاج إلى معرفة ما الذي حدث أولًا.
وهنا يأتي دور التوقيت.
الخطوة السادسة: راقب التردد وليس الحرارة فقط
قد ترى درجة حرارة مرتفعة، لكن الأهم أحيانًا هو معرفة ماذا فعل المكون عندما ارتفعت الحرارة.
المعالج أو بطاقة الرسوميات قد يخفضان التردد لحماية نفسيهما، وهي عملية تعرف باسم Thermal Throttling أو الخنق الحراري.
إذا كان التردد مرتفعًا في بداية المهمة ثم ينخفض بشكل واضح عندما ترتفع الحرارة، وبعد ذلك يظهر التقطيع أو التجمد، أصبحت لديك علاقة أقوى بين الأحداث.
وهذا أكثر فائدة من قول:
"الجهاز حار."
أنت الآن تملك تسلسلًا:
حمل مرتفع → حرارة ترتفع → تردد ينخفض → الأداء يتراجع → العطل يظهر.
هذا هو نوع الأدلة الذي تبحث عنه.
الخطوة السابعة: اصطد ضغط الذاكرة
أحيانًا يكون العطل مرتبطًا بذاكرة RAM.
راقب Memory في Task Manager قبل المشكلة وأثناءها.
إذا كانت الذاكرة تقترب من الامتلاء، راقب ما يحدث بعدها.
هل يبدأ النظام في استخدام التخزين بصورة أكبر؟
هل تتباطأ التطبيقات؟
هل يصبح الانتقال بينها بطيئًا؟
هل يبدأ المتصفح أو أحد البرامج في استهلاك الذاكرة بصورة غير طبيعية؟
إذا أغلقت برنامجًا معينًا وعاد الجهاز طبيعيًا مباشرة، فقد حصلت على دليل مهم.
لكن مرة أخرى، لا تعتبر ذلك إثباتًا نهائيًا أن RAM تالفة.
قد تكون السعة غير كافية، أو قد يكون هناك برنامج يستهلك الذاكرة بصورة غير طبيعية.
الخطوة الثامنة: راقب وحدة التخزين عندما يحدث البطء
إذا كان الجهاز يتوقف لثوانٍ ثم يعود، لا تنسَ Disk.
راقب:
Disk Usage.
والعملية التي تستخدم وحدة التخزين.
إذا حدث التجميد في اللحظة التي يبدأ فيها برنامج معين بقراءة أو كتابة كمية كبيرة من البيانات، فقد يكون التخزين جزءًا من القصة.
لكن لا تستبدل SSD لمجرد رؤية استخدام 100%.
الاستخدام المرتفع ليس تشخيصًا.
يجب أن تعرف:
ما العملية التي تستخدمه؟
هل هناك أخطاء؟
هل يتكرر السلوك؟
هل تظهر مشاكل أخرى مثل اختفاء القرص أو فشل القراءة والكتابة؟
هنا يصبح الحكم أكثر دقة.
الخطوة التاسعة: تحقق من سجل الأحداث بعد العطل مباشرة
إذا اختفى العطل، لا تفترض أن آثاره اختفت معه.
استخدم Event Viewer، أو عارض الأحداث، وابحث عن الأحداث المسجلة في الفترة نفسها.
ركز على التوقيت.
إذا كان الجهاز تجمد الساعة 8:42 مساءً، فلا تبدأ بقراءة كل سجلات اليوم.
ابحث حول الساعة 8:42.
هل ظهرت أخطاء؟
هل حدثت مشكلة في تعريف؟
هل توقفت خدمة؟
هل سجل النظام خطأ متعلقًا بمكون معين؟
لا تبحث عن رسالة سحرية.
أنت تجمع قرائن.
إذا تكرر نفس النوع من الأخطاء مع كل عطل، يصبح أكثر أهمية.
الخطوة العاشرة: استخدم Reliability Monitor
هناك أداة مفيدة في ويندوز تسمى Reliability Monitor، أو "مراقب الموثوقية".
وهي تعرض لك خطًا زمنيًا مبسطًا للاستقرار والأعطال.
قد تجد فيها:
تعطل برنامج.
تعطل ويندوز.
تحديثًا.
خطأ في تطبيق.
أو حدثًا مهمًا وقع في نفس الفترة.
ميزة هذه الأداة أنها تجعل الأحداث أسهل في الربط زمنيًا.
إذا كنت تعاني من مشكلة تظهر وتختفي، فإن التسلسل الزمني مهم جدًا.
الخطوة الحادية عشرة: اسأل هل المشكلة مرتبطة بالشاحن؟
في اللابتوب، قم بمقارنة السلوك بين:
البطارية فقط
و
الشاحن متصل
إذا كانت المشكلة تظهر فقط أثناء أحد الوضعين، فقد يكون هناك ارتباط بإدارة الطاقة أو الترددات أو الحرارة أو مصدر الطاقة.
لكن لا تستخدم هذه الطريقة إذا لاحظت سخونة غير طبيعية أو تلفًا واضحًا في الشاحن أو البطارية.
الهدف هنا ليس تعريض الجهاز للخطر، وإنما ملاحظة اختلاف سلوكه في ظروف تشغيل مختلفة وآمنة.
الخطوة الثانية عشرة: افصل الأجهزة الخارجية
قد يكون جهازك سليمًا، لكن أحد الملحقات يتسبب في المشكلة.
إذا كانت لديك أجهزة كثيرة متصلة، افصل غير الضروري منها:
USB.
أقراص خارجية.
محولات.
شاشات إضافية.
أجهزة صوت.
وأي ملحقات أخرى.
ثم اختبر.
إذا اختفت المشكلة، أعد توصيل الأجهزة واحدًا تلو الآخر.
هذه الطريقة تسمى عمليًا Isolation، أي عزل المتغيرات.
بدل أن تقول:
"كل الأجهزة متصلة والمشكلة اختفت."
ستعرف أن المشكلة تعود تحديدًا عند توصيل جهاز معين.
وهنا يصبح التشخيص أسهل بكثير.
الخطوة الثالثة عشرة: اختبر البرنامج المشبوه وحده
إذا كان العطل يظهر أثناء استخدام تطبيق معين، لا تحكم عليه مباشرة.
اختبر سيناريوهين.
الأول:
تشغيل الجهاز واستخدامه دون التطبيق.
الثاني:
تشغيل الجهاز وتشغيل التطبيق وتنفيذ نفس المهمة.
إذا ظهر الفرق باستمرار، أصبح التطبيق أو البيئة التي يعمل فيها أكثر أهمية في التحقيق.
لكن هناك سؤالًا آخر:
هل التطبيق نفسه هو المشكلة، أم أنه يكشف مشكلة في مكون آخر؟
هذه نقطة مهمة.
برنامج التصميم قد يكشف مشكلة GPU.
اللعبة قد تكشف مشكلة حرارة أو طاقة.
برنامج ضغط الملفات قد يكشف مشكلة تخزين.
تطبيقات كثيرة لا تكون السبب، بل تكون المحفز الذي يضغط على النظام بطريقة تكشف الخلل.
الخطوة الرابعة عشرة: لا تنسَ التعريفات
التعريفات Drivers هي حلقة الاتصال بين نظام التشغيل والمكونات.
إذا حدث خلل في تعريف معين، قد ترى مشكلة تظهر في ظروف محددة فقط.
مثلًا:
الشاشة تتجمد أثناء تشغيل فيديو.
أو بطاقة الرسوميات تتوقف أثناء لعبة.
أو الشبكة تنقطع بعد السكون.
أو الصوت يتوقف ثم يعود.
إذا بدأت المشكلة بعد تحديث تعريف، سجل ذلك.
وإذا اختفت بعد الرجوع إلى إصدار سابق، فهذا دليل قوي، لكنه لا يزال يحتاج إلى اختبار إضافي للتأكد.
الخطوة الخامسة عشرة: اجعل الجهاز يسجل ما يحدث
إذا كان العطل سريعًا جدًا بحيث لا تستطيع مراقبته، فحاول تجهيز أدوات المراقبة قبل وقوعه.
الفكرة ليست تشغيل عشرات الأدوات في وقت واحد، وإنما اختيار ما تحتاج إليه.
يمكنك مراقبة:
الحرارة.
التردد.
CPU.
RAM.
GPU.
Disk.
وأحيانًا سجلات النظام.
ثم ترك الجهاز يعمل حتى تظهر المشكلة.
عندما تقع المشكلة، ستتمكن من الرجوع إلى البيانات ومعرفة ما تغير قبلها.
وهنا يصبح لديك شيء أقوى من الذاكرة البشرية.
سجل زمني.
لماذا لا يكفي أن تقول: "بعد إعادة التشغيل كل شيء طبيعي"؟
لأن إعادة التشغيل تغير عددًا كبيرًا من المتغيرات دفعة واحدة.
عند إعادة التشغيل:
يتم تفريغ كثير من حالات الذاكرة.
تتوقف العمليات.
تُعاد الخدمات.
يُعاد تحميل التعريفات.
تنتهي بعض المهام الخلفية.
تتغير درجة الحرارة.
ويبدأ النظام من حالة مختلفة.
لذلك إذا اختفت المشكلة بعد Restart، فهذا لا يخبرك بالضرورة بالسبب.
إنه يخبرك فقط أن إعادة تهيئة النظام أزالت الحالة التي كانت موجودة وقت العطل.
وهذا فرق كبير.
كيف تعرف أنك اقتربت من السبب؟
أنت تقترب عندما تستطيع وصف المشكلة بهذه الطريقة:
"العطل يحدث فقط بعد تشغيل البرنامج X لمدة 20 دقيقة، وتبدأ حرارة GPU بالارتفاع، ثم ينخفض تردده، وبعدها تظهر الشاشة السوداء."
هذا وصف ممتاز.
أما:
"الجهاز أحيانًا يعلق."
فهو وصف ضعيف جدًا.
كلما استطعت إضافة شروط، أصبحت دائرة الاحتمالات أصغر.
مثلاً:
يحدث فقط أثناء الألعاب.
أفضل.
يحدث فقط بعد 30 دقيقة من اللعب.
أفضل.
يحدث فقط بعد ارتفاع حرارة GPU.
أفضل.
يحدث فقط مع لعبة معينة.
أفضل.
يحدث فقط مع تعريف معين.
الآن بدأت تمسك بالخيط.
اختبار A/B قد يكشف الحقيقة
من الطرق العملية المفيدة مقارنة حالتين.
لنقل أنك تشك في وضع الطاقة.
اختبر:
الحالة A: وضع الطاقة الحالي.
الحالة B: وضع طاقة مختلف.
ثم استخدم نفس البرنامج ونفس المهمة تقريبًا.
إذا ظهر العطل في A ولم يظهر في B، فقد حصلت على دليل.
لكن لا تغير خمسة أشياء بين التجربتين.
كلما كان الاختلاف بين الاختبارين واحدًا فقط، كانت النتيجة أقوى.
هذه هي فكرة A/B Testing، أي مقارنة حالتين مع تغيير متغير واحد قدر الإمكان.
ماذا لو لم تستطع إعادة إنتاج العطل؟
هذا طبيعي جدًا.
بعض الأعطال المتقطعة لا تظهر بسهولة.
في هذه الحالة لا تحاول إجبار المشكلة على الظهور بطريقة عشوائية.
بدلًا من ذلك، استمر في جمع الأدلة.
سجل كل مرة تظهر فيها المشكلة.
بعد عدة مرات، ابحث عن القاسم المشترك.
ربما تكتشف أن جميع الحالات حدثت:
بعد فترة طويلة من التشغيل.
أثناء استخدام البطارية.
مع برنامج معين.
بعد الاستيقاظ من السكون.
عندما تكون الذاكرة مرتفعة.
أو عندما تكون الحرارة مرتفعة.
حتى لو لم تستطع إعادة المشكلة في المختبر، قد تتمكن من تحديد ظروفها.
وهذا في حد ذاته تقدم كبير.
متى تبدأ التفكير في العتاد؟
بعد استبعاد المسارات البرمجية الأساسية، ابدأ بالنظر إلى المكونات.
خصوصًا إذا ظهرت علامات مثل:
إعادة تشغيل مفاجئة.
شاشة سوداء متكررة.
اختفاء وحدة تخزين.
أخطاء ذاكرة متكررة.
تجمّد تحت حمل معين.
ارتفاع حرارة غير طبيعي.
مشكلة تظهر خارج ويندوز أيضًا.
أو فشل في اختبارات العتاد.
هنا يمكن أن يصبح فحص RAM أو SSD أو GPU أو نظام التبريد أو الطاقة منطقيًا.
لكن حتى هنا، لا تستبدل القطعة مباشرة.
اختبر الفرضية أولًا إن أمكن.
لا تستخدم التنظيف كتشخيص
من أكثر الأشياء التي تحدث في الأعطال المتقطعة:
الجهاز يتجمد → المستخدم يفتحه → ينظفه → يعيد تركيب القطع → المشكلة تختفي.
فيعتقد أن الغبار كان السبب.
ربما.
لكن ربما أدى فتح الجهاز إلى إعادة تركيب مكون أو تحريك كابل أو تغيير وضع اتصال.
وقد تكون المشكلة اختفت بالصدفة.
إذا كان هدفك معرفة السبب، يجب أن تفرق بين:
"المشكلة اختفت"
و
"عرفت لماذا اختفت."
الأولى نتيجة.
الثانية تشخيص.
أقوى سلاح: إعادة إنتاج المشكلة بعد الإصلاح
إذا غيرت شيئًا وتعتقد أنه حل المشكلة، لا تتوقف عند أول يوم جيد.
حاول تشغيل نفس السيناريو الذي كان يسبب العطل.
إذا كان الجهاز يتجمد بعد 40 دقيقة من تشغيل لعبة، اختبر اللعبة لمدة أطول.
إذا كان البرنامج يتوقف أثناء تصدير الفيديو، نفذ عملية تصدير مشابهة.
إذا كانت المشكلة تظهر بعد العودة من السكون، كرر عملية السكون والاستيقاظ.
الهدف هو التأكد من أن الظرف الذي كان يكشف العطل لم يعد يكشفه.
متى تقول: أمسكت به متلبسًا؟
يمكنك اعتبار نفسك اقتربت جدًا من السبب عندما تتوافر لديك أربعة أشياء:
الظرف: تعرف متى يظهر العطل.
المحفز: تعرف ما الذي يسبقه.
الدليل: لديك قياس أو سجل أو رسالة خطأ تدعم الفرضية.
إعادة الإنتاج: تستطيع جعل المشكلة تظهر مرة أخرى في ظروف مشابهة.
مثال قوي:
تشغيل لعبة معينة → بعد 25 دقيقة → ارتفاع حرارة GPU → انخفاض التردد → الشاشة تتجمد → يظهر خطأ متعلق بالتعريف → تكرر السيناريو مرتين.
هنا أنت لا تتعامل مع "جهاز غريب".
أنت أمام سلسلة أحداث يمكن اختبارها.
خطة سريعة للإمساك بالعطل المتقطع
إذا أردت تطبيق كل ما سبق بطريقة عملية، استخدم هذا التسلسل:
1. لا تعيد التشغيل مباشرة
حاول فحص الجهاز أثناء المشكلة.
2. افتح Task Manager
راقب CPU وRAM وDisk وGPU.
3. سجل الوقت
متى بدأ العطل ومتى انتهى؟
4. سجل المهمة
ماذا كنت تفعل قبل المشكلة؟
5. راقب الحرارة والتردد
خصوصًا أثناء الحمل.
6. افحص Event Viewer
ابحث حول توقيت المشكلة.
7. افحص Reliability Monitor
ابحث عن تعطل التطبيقات والنظام.
8. كرر السيناريو
حاول إعادة إنتاج المشكلة.
9. غيّر شيئًا واحدًا فقط
ثم اختبر من جديد.
10. افتح الجهاز فقط عندما تشير الأدلة إلى العتاد
عندها يصبح التفكيك خطوة تشخيصية وليس تخمينًا.
الخلاصة: لا تطارد العطل.. اجعله يكشف نفسه
العطل الذي يظهر ويختفي ليس عدوًا مستحيلًا.
هو فقط عطل لا يظهر طوال الوقت.
وإذا تعاملت معه بطريقة عشوائية، سيبدو لك وكأنه شبح: يظهر عندما لا تكون مستعدًا، ويختفي عندما تبدأ الفحص.
لكن إذا غيرت أسلوبك، يصبح الأمر مختلفًا.
لا تنتظر بعد العطل.
راقب العطل أثناء حدوثه.
لا تسأل فقط عن القطعة.
اسأل عن الظروف.
لا تعتمد على الذاكرة.
سجل التوقيت والأرقام.
لا تغير كل شيء.
غيّر متغيرًا واحدًا في كل مرة.
ولا تعتبر عودة الجهاز للعمل دليلًا على أن المشكلة انتهت.
قد يكون الجهاز عاد طبيعيًا لأن الحرارة انخفضت، أو الذاكرة تحررت، أو العملية المسببة للمشكلة انتهت، أو التعريف أعاد تشغيل نفسه، أو الحمل انخفض.
المهم أن تعرف لماذا.
وفي النهاية، أقوى طريقة لتشخيص العطل المتقطع هي أن تحول الجملة:
"الجهاز أحيانًا يعلق."
إلى جملة أكثر دقة:
"الجهاز يتجمد عندما يحدث X، بعد Y دقيقة، وتسبق ذلك التغيرات Z."
عند هذه النقطة، لم يعد العطل متلبسًا فقط...
بل أصبح يترك بصماته أمامك.
0 تعليقات