شرح الفصل العاشر من Network Plus بالعربية: استكشاف أخطاء الشبكة وإصلاحها (Network Trobleshooting)

Safely LocK
0

 الفصل العاشر: Network Trobleshooting


الجزء الأول: #1


العنوان: Troubleshooting Steps and Procedures



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

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

خطوات وإجراءات استكشاف الأخطاء وإصلاحها (Troubleshooting Steps and Procedures):

بغض النظر عن المشكلة، فإن استكشاف الأخطاء وإصلاحها الفعال للشبكة يتبع بعض الخطوات المحددة، وتوفر هذه الخطوات إطارًا لإجراء عملية استكشاف الأخطاء وإصلاحها، وعند اتباعها، يمكن أن تقلل من الوقت اللازم لعزل المشكلة وإصلاحها، وتناقش الأقسام التالية خطوات وإجراءات استكشاف الأخطاء وإصلاحها الشائعة كما حددتها أهداف  compTIA Network Plus:
 
  •  تحديد المشكلة:
  • جمع المعلومات.
  • استجواب المستخدمين.
  • تحديد الأعراض.
  •  تحديد ما إذا كان هناك أي تغيير.
  •  تكرار المشكلة، إذا أمكن.
  • معالجة المشاكل المتعددة بشكل فردي.

  •  إقامة نظرية حول السبب المحتمل
  •    استجواب الواضح.
  •  النظر في مناهج متعددة:
    •  نموذج OSI من الأعلى للأسفل/من الأسفل للأعلى.
    • التقسيم والتغلب.

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

نصيحة أختبار:
يجب أن تتوقع أسئلة تطلب منك تحديد خطوات منهجية استكشاف الأخطاء وإصلاحها بالترتيب الدقيق.
 
تحديد المشكلة (Identify the Problem):

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

يجب أن تحصل على أكبر قدر ممكن من المعلومات حول المشكلة، ويمكنك جمع المعلومات من ثلاثة مصادر رئيسية: الكمبيوتر (على شكل سجلات ورسائل خطأ)، مستخدم الكمبيوتر الذي يعاني من المشكلة، وملاحظاتك الخاصة.

بعد أن تقوم بتسجيل الأعراض، يمكنك البدء في تحديد بعض الأسباب المحتملة لتلك الأعراض.\

نصيحة أختبار:
لا تحتاج إلى معرفة مكان تخزين رسائل الخطأ في نظام التشغيل. تحتاج فقط إلى معرفة أن عملية استكشاف الأخطاء تتطلب منك قراءة سجلات الأخطاء التي يتم إنشاؤها بواسطة النظام.

 تحديد الأعراض (Identify Symptoms):
 
بعض مشاكل الكمبيوتر تكون معزولة لمستخدم واحد في موقع واحد؛ والبعض الآخر يؤثر على عدة آلاف من المستخدمين في مواقع متعددة، ويعد تحديد المنطقة المتأثرة جزءًا هامًا من عملية استكشاف الأخطاء، وغالبًا ما يملي الاستراتيجيات التي تستخدمها لحل المشكلة.

نصيحة أختبار:
قد يتم تزويدك بوصف سيناريو أو وصف معزز بواسطة مخطط شبكة، وفي كلتا الحالتين، يجب عليك قراءة وصف المشكلة بعناية، خطوة بخطوة، وفي معظم الحالات، يكون الجواب الصحيح منطقيًا تمامًا، ويمكن بسهولة تحديد الإجابات الخاطئة.



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

ربما لم تبدأ عملية حل المشكلة في الخادم، ولكن هذا غالباً ما يكون مكان بدايتها. فهم من تأثر بالمشكلة يمكن أن يمنحك أولى الدلائل على مكان وجود المشكلة. على سبيل المثال، تغيير نطاق بروتوكول تكوين المضيف الديناميكي (DHCP) أو استنفاد النطاق من قبل مسؤول جديد قد يؤثر على عدة مستخدمين، بينما يمكن أن يؤثر تلاعب مستخدم بإعدادات TCP/IP لجهاز كمبيوتر واحد فقط على هذا الشخص.
 
 تحديد ما إذا كان هناك أي تغيير (Determine Whether Anything Has Changed):

سواء كانت هناك مشكلة في وصول محطة العمل إلى قاعدة بيانات أو شبكة كاملة، فقد كانت تعمل في وقت ما، على الرغم من أن العديد من الأشخاص يدعون أن جهاز الكمبيوتر "توقف فجأة عن العمل"، فإن ذلك غير محتمل، الأكثر احتمالاً هو أن التغييرات في النظام أو الشبكة تسببت في المشكلة، ابحث عن التطبيقات المثبتة حديثًا، التصحيحات أو التحديثات المطبقة، الأجهزة الجديدة، نقل الكمبيوتر المادي، أو اسم المستخدم وكلمة المرور الجديدة، يعد تحديد أي تغييرات حديثة في النظام غالبًا هو الاتجاه الصحيح لعزل المشكلة واستكشاف الأخطاء وإصلاحها. 
تكرار المشكلة إذا أمكن (Duplicate the Problem if Possible):

لكل مشكلة سبب، وتحديد سبب المشكلة هو المفتاح لمنع حدوثها مرة أخرى مع هذه الآلة أو غيرها، وإحدى الطرق لمعرفة أنك قد حددت السبب هي القدرة على تكرار المشكلة، يجب أن يكون السبب الوحيد لتكرار المشكلة هو التحقق من أنك قد وجدت السبب بالفعل بحيث يمكنك اتخاذ خطوات للتأكد من أن هذا السبب لا يصبح مشكلة مرة أخرى، كمثال، إذا كان سبب المشكلة هو تصحيح جديد لتطبيق لا يعمل بشكل صحيح مع نظام تشغيل معين، فستحتاج إلى التأكد من أن هذا التوليف من التصحيح والنظام التشغيلي لا يتم تنفيذه مرة أخرى (تشمل الخطوات التي يمكن اتخاذها تحديث نظام التشغيل، تثبيت جزء فقط من التصحيح، وهكذا).
 
التعامل مع أكثر من مشكلة (Approach Multiple Problems Individually):

إحدى أصعب الحالات التي يجب التعامل معها هي وجود أكثر من مشكلة واحدة (محطة عمل معينة لا تقوم بتحميل التطبيق A، لا يمكن الطباعة من التطبيق B، وهكذا)، عندما يكون هذا هو الحال، فإن الطريقة الوحيدة لحل المشاكل هي معالجة كل واحدة منها بشكل فردي، ويجب ترتيب المشاكل حسب الأهمية (استنادًا إلى معايير مثل الضرورة التجارية) وحلها بهذا الترتيب.
 
 إقامة نظرية للسبب المحتمل (Establish a Theory of Probable Cause):
 
نصيحة أختبار:
عند التعامل مع مشكلة، ابدأ باستجواب الواضح، وإذا فشلت تلك المحاولة، فكر في طرق للتعامل مع المشكلة من مناهج متعددة، ويمكن التفكير في استخدام نموذج top-to-bottom أو bottom-to-top (مثل العمل من خلال نموذج OSI) وتوزيع المشكلة على زملائك في العمل لحلها بطريقة divide and conquer.

 اختبار النظرية لتحديد السبب (Test the Theory to Determine the Cause):

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

إذا تم تأكيد النظرية، يجب عليك وضع خطة عمل - قائمة بالخطوات التالية لحل المشكلة، وإذا لم يتم تأكيد النظرية (في المثال المعطى، لم يتم تنزيل أي برنامج جديد ولم يتم تطبيق أي حزمة خدمة)، يجب عليك إقامة نظرية جديدة أو التفكير في تصعيد المشكلة.
 
 إقامة خطة عمل (Establish a Plan of Action):

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

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

مع وجود الخطة، يجب أن تكون جاهزًا لتنفيذ الحل - أي تطبيق التصحيح، واستبدال الأجهزة، توصيل كابل، أو تنفيذ حل آخر، في العالم المثالي، سيكون الحل الأول هو حل المشكلة؛ ومع ذلك، للأسف، هذا ليس دائمًا هو الحال، إذا لم يحل الحل الأول المشكلة، يجب عليك تتبع خطواتك والبدء من جديد.

يجب عليك محاولة حل واحد فقط في كل مرة، وتجربة عدة حلول في وقت واحد يمكن أن تجعل من غير الواضح أي منها أصلح المشكلة.
 
تنفيذ الحل أو التصعيد (Implement the Solution or Escalate):

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

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

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

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

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

لنفترض أنه، كمدير خادم، تلاحظ مشكلة في القرص الصلب في تكوين RAID 1 على خادم Linux، أنت تعرف كيفية استبدال الأقراص في تكوين RAID 1 الفاشل، ولكن ليس لديك خبرة في العمل مع RAID البرمجي على خادم Linux، من المؤكد أن هذه الحالة تتطلب تصعيد المشكلة، وظيفة مدير الخادم في هذه الحالة هي ملاحظة القرص RAID 1 الفاشل وتجنيد المساعدة المناسبة لإصلاح فشل RAID داخل Linux.
 
ملحوظة: 
عندما تواجه مشكلة، تكون مسؤولاً عنها حتى تُحل أو يتم تحويلها لشخص آخر، وبالطبع، يتطلب تحويل المشكلة إلى شخص آخر أن يكون كل من الأطراف على علم بذلك.
 
 التحقق من وظائف النظام بالكامل (Verify Full System Functionality):

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

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

من الضروري التحقق من وظائف النظام بالكامل قبل أن تكون راضيًا عن الحل، بعد الوصول إلى مستوى الرضا هذا، يجب عليك النظر في المشكلة وتحديد ما إذا كانت أي تدابير وقائية يجب تنفيذها لمنع تكرار نفس المشكلة.
 
 توثيق النتائج، الإجراءات، النتائج، والدروس المستفادة (Document Findings, Actions, Outcomes, and Lessons):

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

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

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

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


  •  النتائج: يختار العديد من المسؤولين تضمين معلومات عن النجاحات والإخفاقات، وقد يمنعك توثيق الإخفاقات من اتخاذ نفس الطريق مرة أخرى، ويمكن أن يقلل توثيق الحلول الناجحة من الوقت اللازم لإعادة تشغيل النظام أو الشبكة.

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



النهاية: 
وهنا لقد انتهى الشق الأول من الفصل العاشر ، تستطيع مشاركتنا برأيك ، والأنضمام الى مجتمعنا من هنا.

إرسال تعليق

0تعليقات

إرسال تعليق (0)

#buttons=(موافق!) #days=(20)

يستخدم موقعنا ملفات تعريف الارتباط لتحسين تجربتك. تاكد الان
Ok, Go it!