ويندوز سيرفر للمحترفين #13: فن استكشاف الأعطال ومنهجية REACT

🧭 قبل أن نبدأ

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

🔧 الفصل الثالث عشر: استكشاف أعطال الخادم (Server Troubleshooting)

📐 ما هي منهجية استكشاف الأعطال؟

مجموعة عمليات وإجراءات وأفضل ممارسات تحدد خطوات العمل، وما يُنفَّذ في كل خطوة، وطريقة التوثيق. وهناك نهجان:

• نهج منظومي (Systematic): ينظر إلى النظام كاملًا.
• نهج محدد (Specific): لكل فئة من المشكلات.

مثال على النهج المحدد لبطاقة شبكة لا تعمل، من الأسفل إلى الأعلى:

1. هل البطاقة مركّبة فعليًا بشكل صحيح؟
2. هل اكتشفها نظام التشغيل؟
3. هل التعريف مثبت بشكل صحيح؟
4. هل إعدادات البروتوكول (TCP/IP) صحيحة؟

ويمكن السير بالترتيب المعاكس، من الإعدادات نزولًا إلى العتاد.

💡 التعريف الذي يغيّر طريقة تفكيرك

"Troubleshooting is the process of discovering the unknown cause and solution for a known problem." — "استكشاف الأعطال هو عملية اكتشاف السبب المجهول والحل المجهول لمشكلة معروفة."

فإذا كنت تعرف الحل مسبقًا، فأنت لا تستكشف، بل تُصلح فقط.

⚡ منهجية REACT

طوّرها الكاتب حين كان يعمل في مكتب المساعدة (Help Desk)، لأنه كان ينسى خطوات مهمة تكلفه دقائق أو ساعات، إضافة إلى الضغط النفسي. ويقول إنه يصل دائمًا إلى حل بنهاية هذه المراحل؛ أحيانًا يكون الحل إعادة تثبيت كاملة، لكنه غالبًا يجد حلًا أبسط.

R → Research     (البحث)
E → Engage       (إشراك المستخدم)
A → Adjust       (التعديل)
C → Configure    (الضبط وفق المعايير)
T → Take Note    (التوثيق)

المراحل الثلاث الأولى هدفها حل المشكلة، والمرحلتان الأخيرتان هدفهما الاستقرار على المدى الطويل.

🔎 R: البحث

يروي الكاتب قصة من عام 1997: قاعدة بيانات Access 95 تُظهر خطأ "A device attached to the system is not functioning". كلمة "device" جعلته يفكر في العتاد، فقضى ساعتين يفحص الأجهزة دون جدوى، وعاد إلى بيته محبطًا. في اليوم التالي بحث في MSDN، فوجد أن الخطأ قد ينتج عن ملف VBRUN300.DLL تالف. استنتج من ذلك أن أي DLL تالف قد يسبب الخطأ نفسه، فأعاد تثبيت Access، واختفت المشكلة.

والقاعدة التي خرج بها:

"My new standard is, research at least fifteen minutes before moving to the Adjust stage with any new problem that requires troubleshooting." — "قاعدتي الجديدة: ابحث خمس عشرة دقيقة على الأقل قبل الانتقال إلى مرحلة التعديل في أي مشكلة جديدة."

مصادر البحث: وثائقك الداخلية، وTechNet، وMSDN، وEventID.net لتفسير معرّفات الأحداث، والبحث عن رسالة الخطأ في Google وموقع المصنّع.

🗣️ E: إشراك المستخدم

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

"...will usually cause people to become defensive and fail to get you any valuable information." — "...يجعل الناس عادةً في موقف دفاعي، فلا تحصل منهم على أي معلومة مفيدة."

أسئلة أخرى مفيدة: متى بدأت المشكلة؟ هل حدثت من قبل؟ هل يعاني منها آخرون؟ متى عمل الشيء آخر مرة؟ هل الجهاز موصول بالكهرباء؟ والكاتب يضيف في النص: "(بجدية!)".

وقد تتنقل بين البحث وإشراك المستخدم عدة مرات قبل أن تبدأ التعديل.

🔩 A: التعديل

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

"This is why I look at problems as stepping stones to a better future; solving this network or computer problem today will make me more capable of solving other problems tomorrow." — "لهذا أنظر إلى المشكلات كدرجات سلّم نحو مستقبل أفضل؛ فحل مشكلة اليوم يجعلني أقدر على حل مشكلات الغد."

📏 C: الضبط

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

📝 T: التوثيق

وثّق على الأقل: المشكلة ورسائل الخطأ، والسبب باختصار، والحل بخطواته، والمبادئ التي تعلمتها. وإن لم يكن لدى مؤسستك نظام تذاكر (Trouble Tickets)، فأنشئ قاعدة بيانات بسيطة خاصة بك قابلة للبحث.

🧅 استكشاف الأعطال عبر نموذج OSI

اصعد أو انزل عبر الطبقات السبع، وتحقق من كل طبقة على حدة. (ويُضاف أحيانًا مزاحًا "الطبقة 8" أي المستخدم.)

• الطبقة 1 (الفيزيائية): الكابلات والموصلات ولوحات التوصيل والبطاقات. جرّب الجهاز المشكوك فيه في جهاز آخر سليم. والكابلات قد تعيش سنوات أو تتلف بسرعة، فتحقق منها دائمًا.
• الطبقة 2 (ربط البيانات): المبدّلات ومنافذها وVLANs وأمان المنافذ، وعنوان MAC للبطاقة.
• الطبقة 3 (الشبكة): التوجيه، مع ثلاثة أوامر أساسية:

ipconfig /all          :: إعدادات IP كاملة (MAC وDNS والبوابة وDHCP...)
ping 192.168.10.1      :: اختبار الاتصال (4 طلبات افتراضيًا)
ping 192.168.10.1 -n 25
arp -a                 :: ذاكرة ARP المؤقتة: ربط IP (طبقة 3) بـ MAC (طبقة 2)

رسالة Destination host unreachable تعني أن الاتصال فشل.

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

⚙️ نموذج العتاد/البرمجيات

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

🩺 العَرَض ← التشخيص ← العلاج

مثل الطب تمامًا: اجمع الأعراض بأسئلة جيدة، ثم شخّص السبب الأرجح، ثم عالج مع تجربة حل واحد في كل مرة.

مثال الكاتب: جهاز لا يتصل بالشبكة ومؤشرات LED مطفأة. استُبدلت البطاقة فلم تُحل المشكلة. جُرّبت البطاقة القديمة في جهاز آخر فعملت. أُعيد تثبيت التعريف فلم تُحل. والسبب النهائي: منفذ التوسعة (Expansion Port) معطوب، فأُرسل الجهاز للمصنّع.

🧠 التفكير المنظومي (Systems Thinking)

لا تلُم ماركة معينة أو نظام تشغيل تلقائيًا، فهناك آلاف لديهم تجربة معاكسة لتجربتك. بدلًا من ذلك اسأل:

• ما الأجهزة بين هذا الجهاز والطرف الذي يحاول الاتصال به؟
• ما الأجهزة الأخرى التي تتصل بالنظام نفسه الآن؟
• ماذا تغيّر في البيئة التي يعمل فيها النظام؟
• هل نُقل الجهاز فعليًا مؤخرًا؟

ITIL: مجموعة وثائق لأفضل ممارسات إدارة تقنية المعلومات، أنشأها مكتب التجارة الحكومية البريطاني. وتفرّق بين مفهومين:

• الحادثة (Incident): حدث خارج العمليات القياسية يوقف الخدمة أو يضعف جودتها.
• المشكلة (Problem): السبب الجذري للحادثة.

وتوصي بأن تعيد الخدمة للعمل أولًا، ثم تبحث عن السبب الجذري لمنع تكرارها.

🧰 أدوات استكشاف الأعطال الأربع

📋 Task Manager

• يُفتح بـ Ctrl+Shift+Esc.
• تبويب Processes يعرض اسم العملية، وPID، والمستخدم، ونسبة المعالج، والذاكرة.
• الأولويات الست: Low، وBelow Normal، وNormal (الافتراضية)، وAbove Normal، وHigh، وRealtime.
• لإنهاء عملية معلّقة: End Process، أو من سطر الأوامر taskkill.

📈 Performance Monitor (perfmon)

يعمل بـ عدادات أداء (Counters) مثل % Processor Time و% User Time. ويفرّق بين وضع المستخدم (User Mode) الذي تعمل فيه التطبيقات بصلاحيات محدودة، ووضع النواة (Kernel Mode) الذي يعمل فيه النظام والتعريفات بصلاحيات كاملة. ويساعدك على تحديد ما إذا كانت المشكلة في المعالج أو الذاكرة أو القرص أو الشبكة.

🔬 Resource Monitor

"مدير المهام وقد كبر". يعرض المعالج والقرص والشبكة والذاكرة بتفصيل أكبر.

perfmon /res      :: Resource Monitor
perfmon /report   :: تقرير تحليلي خلال 60 ثانية
perfmon /rel      :: تقرير الموثوقية: تحديثات وأعطال وتنبيهات عبر الزمن

💡 تقرير الموثوقية مفيد جدًا للمشكلات المتقطعة: يعرض مثلًا متى ثُبّت تعريف جديد ومتى بدأت الانهيارات.

📓 Event Viewer

السجلات الأربعة الرئيسية:

• Application: أحداث التطبيقات والخدمات.
• Security: أحداث التدقيق.
• Setup: أحداث برامج التثبيت (خصوصًا MSI).
• System: أحداث مكوّنات نظام التشغيل.

استخدم Filter Current Log لإظهار Critical وError وWarning فقط، وابحث عن رقم Event ID في EventID.net. ولمركزة السجلات من عدة خوادم في مكان واحد توجد اشتراكات الأحداث (Event Subscriptions)، وتتطلب خدمة WinRM.

💎 اقتباسات هذا الجزء تستحق التوقف عندها

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

🎯 خلاصة الجزء

استكشاف الأعطال يحتاج مهارة تقنية ومنهجية واضحة معًا: REACT، أو نموذج OSI، أو العتاد/البرمجيات، أو العَرَض/التشخيص/العلاج، أو التفكير المنظومي، مع مرجعية ITIL. والأدوات الأساسية: Task Manager وPerformance Monitor وResource Monitor وEvent Viewer.

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