تحديد المشكلة وتعريفها

تحديد المشكلة هو الخطوة الأولى، ويمكن القول إنه الأهم. فالتحديد الخاطئ للمشكلة يوجّه كل خطوة لاحقة في الاتجاه الخطأ. والهدف هنا هو صياغة بيان مشكلة واضح ومحدد وموثّق. ونادرًا ما يضيع الوقت الذي يُنفق في فهم المشكلة بدقة، لأنه يوجّه كل الجهود اللاحقة نحو العَرَض الحقيقي بدلًا من تخمين.

ابدؤوا بجمع الحقائق. تحدثوا إلى المستخدمين المتأثرين، وافحصوا لوحات المراقبة والسجلات، وأجروا اختبارات سريعة بأنفسكم. حاولوا معرفة النطاق (مستخدم واحد، أو طابق واحد، أو الموقع بأكمله)، والتوقيت (متى بدأت المشكلة)، والأعراض (بطء، أو انقطاع متقطع، أو توقف كامل). وكلما كانت المعلومات أكثر تحديدًا، كانت نظريتكم أدق.

من الأسئلة الفعالة: "ما الذي تغيّر؟" تبدأ معظم المشكلات مباشرة بعد تغيير ما: أجهزة جديدة، أو تعديل في الإعدادات، أو تحديث للبرامج، أو حدث متعلق بالطاقة. اسألوا المستخدمين وتحققوا من سجلات التغييرات. فإذا كانت الخدمة تعمل بالأمس وفشلت اليوم، فلا بد أن شيئًا ما قد تغيّر، وغالبًا ما يقود اكتشاف ذلك الفرق مباشرة إلى السبب. وتُعد التغييرات الحديثة من أولى المشتبه بهم.

يصف المستخدمون الأعراض بكلماتهم الخاصة، لذا قابلوا المستخدمين بعناية ولطف. اطرحوا أسئلة مفتوحة مثل: "ماذا كنتم تفعلون عندما حدث العطل؟" و"هل تغيّر أي شيء آخر؟" وتجنبوا الأسئلة الموجّهة التي توحي بإجابة خاطئة. انتبهوا إلى أن المستخدمين قد يغفلون بعض التفاصيل أو يصفون الآثار بدلًا من الأسباب. يحوّل الصبر والأسئلة الجيدة الشكوى الغامضة إلى بيانات مفيدة.

يؤدي تحديد النطاق إلى تضييق نطاق البحث بدرجة كبيرة. فإذا كان جهاز واحد فقط متأثرًا، فافحصوا ذلك الجهاز أو كبله. وإذا كانت VLAN كاملة متوقفة، فاشتبهوا في المحوّل أو البوابة. وإذا لم يكن لدى الموقع بأكمله اتصال بالإنترنت، فركّزوا على ارتباط WAN أو مزود خدمة الإنترنت ISP. إن مواءمة حجم المشكلة مع حجم السبب المحتمل توفر وقتًا هائلًا.

حاولوا، متى أمكن، إعادة إنتاج المشكلة بأنفسكم. تؤكد إعادة إنتاج العطل أنه حقيقي، وتكشف الظروف الدقيقة، وتمنحكم اختبارًا يمكن تكراره بعد الإصلاح. فإذا تعذر على المستخدم فتح موقع ويب، فجرّبوا فتحه من جهازكم على الشبكة نفسها. يصعب إعادة إنتاج المشكلات المتقطعة، لكن القيام بذلك لا يقدّر بثمن لتأكيد نجاح العلاج.

تنص CompTIA صراحةً على ضرورة التشكيك في البديهيات. فأسباب كثيرة للانقطاع تكون عادية: كبل غير موصول، أو جهاز متوقف عن التشغيل، أو كلمة مرور منتهية الصلاحية، أو تفعيل مفتاح Caps Lock أثناء تسجيل الدخول. لا تستغرق هذه الفحوص الأولية سوى ثوانٍ، وغالبًا ما تحل المشكلة. إن تخطي الفحوص البسيطة لأنها "لا يمكن أن تكون السبب" طريقة شائعة لإضاعة ساعات في عطل تافه.

غالبًا ما تعلن الأجهزة عن مشكلاتها بنفسها. اقرأوا السجلات بحثًا عن رسائل الخطأ، وراقبوا أضواء ارتباط الواجهة، وراجعوا تنبيهات المراقبة. فقد يشير ضوء أحمر في منفذ محوّل، أو حدث مسجل يفيد بأن "الواجهة متوقفة"، أو رسالة خطأ من DHCP، مباشرةً إلى موضع العطل. ويساعد ما تخبركم به الأجهزة في استكمال ما يبلّغ عنه المستخدم.

فكّروا فيما إذا كنتم تواجهون مشكلة واحدة أم عدة مشكلات. فقد يظهر عطلان غير مرتبطين في الوقت نفسه، ويبدوان كأنهما عَرَض غريب واحد. فإذا لم تنسجم المؤشرات مع سبب واحد، فاسألوا ما إذا كانت مشكلتان متداخلتين. إن فصل المشكلات المتشابكة يمنع الارتباك الناتج عن محاولة تفسير كل شيء بنظرية واحدة مفروضة.

اجمعوا نتائجكم في بيان مشكلة دقيق يوضح من المتأثر، وما الذي يتعطل، ومتى بدأت المشكلة، وأي نمط مرتبط بها. إن عبارة "منذ إعادة تشغيل المحوّل الساعة 9 صباحًا، لا تستطيع جميع الهواتف على VLAN 20 التسجيل" أكثر فائدة بكثير من عبارة "الهواتف معطلة". يشكّل البيان الجيد الأساس الذي تبني عليه بقية المنهجية.

يقود التعريف المتين للمشكلة طبيعيًا إلى نظريات السبب. فإذا بدأت المشكلة بعد تغيير في إعدادات محوّل واحد، وكانت تؤثر فقط في مستخدمي ذلك المحوّل، فستظهر نظريتكم الأولى بوضوح. إن بذل جهد حقيقي في التحديد يجعل وضع النظرية واختبارها والإصلاح أسرع وأكثر دقة بكثير. عرّفوا المشكلة جيدًا، وستسير بقية عملية استكشاف الأخطاء بسلاسة.

اختبروا فهمكم لتحديد المشكلات.

لقد تعلّمتم كيفية تحديد المشكلات وتعريفها. النقاط الأساسية:

• اجمعوا معلومات النطاق والتوقيت والأعراض من المستخدمين والسجلات والاختبارات.
• اسألوا دائمًا: "ما الذي تغيّر؟"
• حدّدوا النطاق لتقدير حجم السبب المحتمل، وأعيدوا إنتاج المشكلة متى أمكن.
• شكّكوا في البديهيات أولًا.
• اكتبوا بيان مشكلة دقيقًا يوجّه كل خطوة لاحقة.