Network Troubleshooting Methodology - The Systematic Approach

أيضا متوفر في:

منهجية تشخيص المشاكل في الشبكة: النهج المنهجي

لماذا مسائل المنهجية

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

الحل: A systematic, scientific approach to troubleshooting that uses evidence, not assumptions, to identify root causes.

The Cost of Haphazard Troubleshooting: الوقت الضائع، تصحيح غير صحيح أن القناع المشاكل الحقيقية، تحديد الأصابع بين الفرق، وتجربة المستعمل المتدهورة.

مقدمة: المنهجية العلمية المطبقة على الربط الشبكي

إن التشويش على الشبكات هو أساساً ممارسة في الطريقة العلمية:

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

وتوفر هذه المادة إطاراً منظماً للكشف عن اضطرابات الشبكات التي تحول دون حدوث عقبات مشتركة مثل:

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

الأسئلة الخمسة الرئيسية

قبل التخلّص من التشخيصات التقنية، أجيبوا على هذه الأسئلة الحاسمة الخمسة لتضييق نطاق تحقيقاتكم:

السؤال 1: ما الذي تغير مؤخراً؟

تغيرات الإتحاد؟ معدات جديدة؟ تحديثات البرمجيات؟ تعديلات في علم الطبول؟

سجلات إدارة التغيير
استعراض الالتزامات الأخيرة في نظم إدارة التشكيلات
أسأل: "هل كان يعمل بالأمس؟"

السؤال 2: من المصاب؟

مستعمل واحد؟ مبنى واحد؟ الجميع؟ تطبيق محدد فقط؟

جهاز واحد: من المحتمل أن تكون قضية محلية (NIC، كابل، تشكيلة)
شبكة فرعية واحدة: Gateway, DHCP, or shift issue
الجميع: البنية التحتية الأساسية، أو نظام المعلومات الإدارية المتكامل، أو مسألة واسعة النطاق
تطبيق محدد: خادم التطبيقات، قاعدة الجدار الناري، أو DNS

↓

السؤال 3: هل هو ثابت أم متقطع؟

يحدث دائما؟ فقط خلال ساعات معينة؟ حوادث عشوائية؟

ثابت: الفشل الحاد (القطع الممكن، التشويش، الخدمة)
أساس التوقيت: الازدحام خلال ساعات العمل والعمليات المقررة
Intermittent/Random: عدم التطابق، فشل الأجهزة، وصلة متقطعة

↓

السؤال 4: هل يمكنك استنساخه؟

هل يمكن أن تشعل المشكلة على الطلب؟

نعم: أسهل بكثير للتشخيص (يُمكن أن يُختبر الافتراضات)
لا: وضع نظام للرصد/التسجيل وإنتظار التكرار

↓

السؤال 5: ماذا يرى الجانب الآخر؟

تحقق من كل من نهاية الاتصال

منظور العملاء ضد منظور الخادم
التعبئة في المصدر ضد الوجهة
مسارات قياسية؟ مسارات مختلفة للإرسال ضد

The OSI Model-Based Diagnostic Approach

ويوفر نموذج التفتيش الموقعي إطاراً منظماً لحل المشاكل. العمل من لاير 1 (الفيزياء) إلى الأعلى، أو من لاير 7 (التطبيق) إلى الأسفل، حسب الأعراض.

النهج القائم على أساس القاع (Layer 1 ) Layer 7)

عند استخدام: فقدان التوصيل الكامل، لا ضوء للوصل، أو أعراض طبقات مادية

1 :

(كابل) متصل؟ أربط الأضواء؟ نظيفة؟
الأوامر: show interfaces.. ethtool eth0
البحث عن: أخطاء في اتفاقية حقوق الطفل، التصادم، الاصطدامات المتأخرة، الجرذان، العملاق

↓

Layer 2: Data Link

صحيح (فلان)؟ المرفأ مُمكّن؟ حجب STP؟
الأوامر: show mac address-table.. show spanning-tree
ابحثوا عن ازدهار ماك, تغيرات في علم الطبقة العليا

↓

Layer 3: Network

أيمكن لبوابة (بينغ)؟ منضدة متحركة صحيح؟
الأوامر: ping.. traceroute.. show ip route
البحث عن:

↓

Layer 4: Transport

هل يمكن أن نقيم اتصالاً بـ(تي سي) ؟ الجدار الناري يغلق الميناء؟
الأوامر: telnet host port.. netstat -anحزمة
ابحثوا عن إعادة إرسال TCP، صفر من النوافذ، حزمة RST

↓

Layer 5-7: Session/Presentation/Application

هل حلّت هذه القضية؟ طلب الرد؟ التوثيق يعمل؟
الأوامر: nslookup.. dig.. curl -v
البحث عن: إخفاقات نظم الأمن الوطني، وأخطاء التطبيقات، والمسائل المتعلقة بالتوقيت

النهج القائم على النقاط الرئيسية (الخط 7 ) لاير 1)

عند استخدام: المشاكل الخاصة بالتطبيقات حيثما توجد وسائل الاتصال الأساسية

مثال: "أنا يُمْكِنُ أَنْ أُشوّفَ الإنترنتَ، لَكنِّي لا أَستطيعُ أَنْ أَصِلَ إلى موقعِ الشركةِ SharePoint."

ابدأي في (لايير 7) حلّت إدارة الأمن الوطني لتصحيح IP؟) ولم تعمل إلا إذا لزم الأمر.

هل هو (لاير 1) أو 2 أو 3؟

استخدام هذه الشجرة التشخيصية السريعة لتحديد أي طبقة تفشل:

هَلْ يُمْكِنُ أَنْ تَرْفعَ الشبحَ المحلي (127.0.0.1)؟

لا

المشكلة: نظام التشغيل/مسألة البرمجيات

TCP/IP stack not functioning. تحقق من خدمات الـ (إس) و إعادة تركيب محركات الشبكة

نعم

هل يمكنك ربط عنوانك الشخصي؟

↓ NO

المشكلة: لاير 1/2 - الشبكة المحلية

مُعَوَّل، سائق خاطئ، كابل غير مُسجَّل. تحقق: ip link show أو مدير جهاز

↓ YES

هل يمكنك أن تغلق البوابة؟

↓ NO

المشكلة: لاير 1/2 - الشبكة المحلية

شيك: السلك الفيزيائي، تحويل مركز الميناء، انتداب شبكة VLAN، طاولة البحث والتطوير

↓ YES

هل يمكنك أن تضغط على مضيف عن بعد بواسطة عنوان IP؟

↓ NO

المشكلة: لاير 3

دق طاولة، قواعد الجدار الناري الاستخدام traceroute العثور على مكان توقف الحزم

↓ YES

هل يمكنك حل الـ "دي إن إس" ؟

↓ NO

Problem: DNS Configuration

التحقق: أماكن الخواديم التابعة لدائرة الأمن الوطني، وتوافر خواديم إدارة الأمن الوطني، ووقف الجدار الناري

↓ YES

هل يمكنك الوصول إلى مرفأ الطلبات (ميناء مضيف)

↓ NO

المشكلة: الجدار الناري/القفل المرفئي

التحقق: قواعد الجدار الناري، مجموعات الأمن، خدمة الاستماع إلى الميناء

↓ YES

الشبكة جيدة

وتتمثل المشكلة في الطلب نفسه، أو التوثيق، أو تشكيلة التطبيق

تقنيات العزل

عندما يكون لديك فرضية حول السبب الجذري، استخدام هذه تقنيات العزلة لتأكيد أو رفضه:

1 - يستعاض عن العناصر بشكل منهجي

تيب: تغيير متغير واحد في كل مرة إذا قمت بمسح كل من الكابل وميناء التبديل لن تعرف أيهما أصلحه

سلك رقائق السوائب بالكابل المعروف
اختبار على مدخل مختلف
(أو مكيّف شبكة الـ (يو إس بي
اختبار من جهاز عمل مختلف
الانتقال إلى مختلف VLAN/subnet

2. Packet Captures at Multiple Points

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

# Capture on client
tcpdump -i eth0 -w client.pcap host server.example.com

# Capture on server
tcpdump -i eth0 -w server.pcap host client.example.com

# Compare:
# - Do packets leave client? (check client.pcap)
# - Do packets arrive at server? (check server.pcap)
# - If yes/no: problem is in the path between
# - If yes/yes but server doesn't respond: server-side issue

3. Loopback Testing

القضاء على المتغيرات الخارجية عن طريق اختبار الربط داخل جهاز واحد:

# Test TCP stack without network
ping 127.0.0.1

# Test application listening locally
telnet localhost 80

# Test loopback on network interface (if supported)
# Some NICs support physical loopback for Layer 1 testing

4 - مقارنات خط الأساس المعروفة الجيدة

Compare formation and behavior against a working system:

# Compare interface settings
diff <(ssh working-switch "show run int gi1/0/1") \
     <(ssh broken-switch "show run int gi1/0/1")

# Compare routing tables
diff <(ssh router1 "show ip route") \
     <(ssh router2 "show ip route")

التوثيق خلال عملية استئصال الشغب

الوثائق الحسنة تمنع التعميم من التزييف حيث تحاول نفس الشيء عدة مرات دون أن تدرك ذلك

نموذج مطاردة المشاكل

Issue ID: TICKET-12345
Date/Time: 2026-02-02 14:30 UTC
Reported By: Jane Smith (jane.smith@company.com)
Affected Users: ~50 users in Building A, 3rd floor
Symptom: Cannot access file server \\fileserver01

Initial Observations:
- Issue started around 14:00 UTC
- Only affects Building A, 3rd floor
- Other buildings can access fileserver01
- Ping to fileserver01 (10.1.50.10) times out from affected users
- Ping to default gateway (10.1.30.1) succeeds

Tests Performed:
1. [14:35] Checked switch port status: gi1/0/15 is UP/UP
2. [14:38] Checked VLAN assignment: Port is in VLAN 30 (correct)
3. [14:42] Checked interface errors: 1,234 CRC errors on gi1/0/15
4. [14:45] Replaced patch cable - still seeing CRC errors
5. [14:50] Moved uplink to different port (gi1/0/16) - errors persist
6. [14:55] Checked fiber cleanliness - dirty connector found

Root Cause:
Dirty fiber connector on uplink between Building A floor switch
and distribution switch causing CRC errors and packet loss

Resolution:
Cleaned fiber connector with proper cleaning kit. CRC errors
dropped to zero. File server access restored.

Verification:
Users confirmed file server accessible. Monitored for 15 minutes
with no errors.

Time to Resolution: 25 minutes

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

دراسات الحالة في العالم الحقيقي

دراسة إفرادية: "الشبكة بطيئة" (في الحقيقة: "إستنشاق النوافذ"

الرمز

وتضاءلت أوقات الاستجابة لتطبيق قاعدة البيانات من 100 متر إلى 5 ثوان. فريق الطلب كان يلوم "ملاءة الشبكة"

الاستهلاك الأولي (الخطأ)

ازدحام الشبكة
WAN link saturated
زجاجة الجدار الناري

عملية التشخيص

اختبار Ping: RTT = 2ms (excellent, rules out Layer 3 latency)
اختبار باندويث 950 Mbps on 1 Gbps link (no congestion)
القبض على الحزمة: Revealed TCP Zero Windowpackets from database server
تفتيش سيرفر: خادم قاعدة البيانات يحصل على عازل = 64 كيلوبايت (للحن)

سبب الروت

وكانت حاجزات قاعات قاعدة البيانات (SOS) صغيرة للغاية بالنسبة لمنتجات التأخير ذات النطاق الترددي العالي (X). نافذة (تي سي) ستملأها وتجبر المرسل على الانتظار

القرار

# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216

الدرس المتعلم

لا تفترض: "سلو" لا يعني دائماً "خطوبة العمل" جمع الأدلة دائماً قبل القفز إلى الاستنتاجات

Case Study 2: Intermittent Connectivity (Actually: Duplex Mismatch)

Symptom

الإتصال بالسيرفر سينخفض عشوائياً خاصة تحت الحمولة في بعض الأحيان عمل جيد، وأحيانا غير مستجيب تماما.

Initial Assumptions (Wrong)

Failing NIC
كابل سيئ
قضية معدات التبديل

Diagnostic Process

التفتيش المشترك: Server NIC = 1000/Full, Switch port = 1000/Half (mismatch)
مضادات الرعب: الاصطدام المكثف يعتمد على مدخل
الاصطدامات المتأخرة: مؤشر سوء الفهم المزدوج

Root Cause

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

Resolution

! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
 speed 1000
 duplex full

Lesson Learned

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

دراسة الحالة 3: "لا يمكن الوصول إلى بعض المواقع الشبكية" (في الحقيقة: MTU/PMTUD Black Hole)

Symptom

ويمكن للمستعملين أن يصفوا بعض المواقع الشبكية (غوغل، ياهو) ولكن ليس مواقع أخرى (موقع مصرفي، بوابة شركات). ونجحت الطلبات الصغيرة المقدمة من شركة HTTP، ووقت صفحات كبيرة.

Initial Assumptions (Wrong)

DNS issue
حواجز إطلاق النار تحجب مواقع محددة
ISP routing problem

Diagnostic Process

قرار لجنة الأمن الوطني: لا بأس في جميع المواقع
اختبار Ping: يمكن أن يربط مواقع "غير قابلة للتواصل"
طلب صغير مقدم من شركة HTTP: تشغيل الصفحات الصغيرة
تحميل كبير: ستال بعد مصافحة TCP
اختبار MTU: ping -M do -s 1472 تنجح ping -M do -s 1473 الفشل
ICMP monitoring: لا "التفاهم مطلوب" (الرمز 3 4)

Root Cause

نفق شبكة (في سي) تقلص من وحدة مكافحة الإرهاب إلى 1400، لكن الجدار الناري كان يحجب رسائل ICMP "Fragmentation Needed" لم يستطع جهاز كشف الحركة إيجاد ثقب أسود حزمة صغيرة، وحزمة كبيرة مع DF قليلا تم قذفها صامتة.

Resolution

! Implemented TCP MSS clamping on router
interface Tunnel0
 ip tcp adjust-mss 1360

! Alternative: Allow ICMP Type 3 Code 4 through firewall
access-list 101 permit icmp any any packet-too-big

Lesson Learned

مسائل الحجم: وفي حالة إخفاق الطلبات الصغيرة ولكن عمليات النقل الكبيرة، يشتبه في وجود قضايا تتعلق بالوحدة/النقل. استعملي التجسس مع (دي.دي) لتختبري طريق (إم.تي)

Case Study 4: VoIP Quality Issues (Actually: QoS Misconfiguration)

Symptom

المكالمات الصوتية كانت مقطعة صوتية و متقطعة Only occurred during business hours (9am-5pm).

Initial Assumptions (Wrong)

عدم كفاية عرض النطاق الترددي
خادم الصوت المزدحم
ISP connection quality

Diagnostic Process

اختبار باندويث: لا يُستخدم سوى 40 في المائة خلال ساعة العمل
تفتيش QoS: الحركة الصوتية المميزة بالرقم EF (46)
التفتيش الموقعي: لم يخصص سوى 5 في المائة من النطاق الترددي (يمكن أن يكون 33 في المائة)
القبض على الحزمة: أحزمة صوت تسقط أثناء الازدحام

Root Cause

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

Resolution

! Corrected QoS policy
policy-map WAN-QOS
 class VOICE
  priority percent 33
 class VIDEO
  bandwidth percent 25
 class CRITICAL-DATA
  bandwidth percent 20
 class class-default
  bandwidth percent 22

Lesson Learned

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

إشارة إلى الرمز

الرمز	Layer	أوامر للهرب	ماذا تبحث عن
لا يوجد ضوء	Layer 1	`show interfaces ethtool eth0`	الحالة: أسفل، لا ناقلات، كابل غير مزروع
خسارة الحزمة	1/2	`show interfaces show interfaces counters errors`	أخطاء لجنة حقوق الطفل، الجرعات، العملاق، التصادم، الاصطدامات المتأخرة
لا أستطيع الدخول	Layer 2	`arp -a show mac address-table show spanning-tree`	No ARP entry, MAC not learned, STP blocking
لا أستطيع الوصول إلى شبكة الأنترنت البعيدة	Layer 3	`traceroute show ip route show ip route summary`	الطريق المفقود، الخطأ التالي
رفض	Layer 4	`telnet host port netstat -an tcpdump`	دائرة لا تستمع، حاوية الحماية، TCP RST
بطء الأداء	Layer 4+	`ping (RTT) iperf3 tcpdump show interfaces`	درجة عالية من الرطوبة، الحد الأقصى للزوارق، إعادة إرسال TCP، صفر من النوافذ
لا يمكن حل اسم المضيف	Layer 7	`nslookup dig cat /etc/resolv.conf`	DNS server unreachable, wrong DNS config, NXDOMAIN
هبوط متقطع	Layer 1/2	`ping -f (flood) show logging show interfaces`	داء دوبليكس غير المطابقة، وفشل الكابلات،
يعمل في بعض الأحيان، لا غيره	متعددة	`Extended ping Packet capture Interface statistics`	Load balancing issue, ECMP asymmetry, state table overflow

متى إلى (إسكاليت)

معرفة متى تتصاعد إلى البائع TAC أو كبار المهندسين. Escalate when:

لقد استنفدت كل المشاكل في طريقتك في قاعدة معرفتك
الإصدار يتطلب الدخول/البعثات التي ليس لديك
المشكلة تتعلق بالبرمجيات البرمجية للبائعين أو عيوب المعدات
أثر الأعمال التجارية حاسم ومراعي للوقت
يتعين على الأفرقة المتعددة أن تتعاون (التطبيق + الشبكة + الخادم)

قبل التصعيد: توثق كل ما حاولت المهندسون بحاجة إلى هذه المعلومات لتجنب تكرار خطواتك. يشمل:

الوصف الكامل للأعراض
الوقت الذي بدأت فيه المسألة
إدارة الأوامر التشخيصية وناتجها
الدعم في مجال التجميع
التعبئة (إذا كان ذلك مناسبا)
ما حاولت بالفعل

بناء قاعدة معارفك الشخصية

فكل جلسة لرد المشاكل هي فرصة للتعلم. بناء قاعدة معارف شخصية:

1. Create a troubleubleshooting Journal

# Example structure
~/troubleshooting-journal/
├── 2026-01-15-duplex-mismatch.md
├── 2026-01-22-mtu-black-hole.md
├── 2026-02-02-tcp-window-exhaustion.md
└── README.md  # Index of all issues

# Each file contains:
# - Symptom
# - Diagnostic steps
# - Root cause
# - Resolution
# - Lessons learned
# - Related tickets/documentation

2. Build a Command Cheat Sheet

تنظيم أوامر مستعملة في كثير من الأحيان من خلال سيناريو مرجعي سريع أثناء عملية فرز المشاكل.

3. Document your Network

رسم بياني لعلم الأرض (Layer 2 and Layer 3)
مخطط وثائق عناوين البرنامج
مهام الشبكة
التكوينات الموحدة (التواريخ)
خطوط الأساس المعروفة (الإحصاءات الداخلية قبل المشاكل)

المقاتلون المشتركون إلى أفويد

تحدث تغييرات عشوائية بدون تشخيص

فتغيير التشكيلات دون فهم المشكلة كثيرا ما يزيد الأمور سوءا أو يخفي المسألة الحقيقية.

افترض ان الشبكة دائما ما تكون مخطئة

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

(سكيب) يوثق متاعبك

سوف تضيع وقتك في تكرار الإختبارات التي قمت بها بالفعل أو لا تستطيع أن تشرح للزملاء ما حاولت

المسائل المتقطعة

وكثيراً ما تكون المشاكل المتقطعة علامات إنذار مبكر على الفشل الوشيك. التحقيق معهم قبل أن يصبحوا حاسمين

ستة أعراض بدلاً من الأسباب الجذرية

إعادة تشغيل جهاز قد يعيد الخدمة، ولكن إذا كنت لا تعرف لماذا تحتاج إلى إعادة التشغيل، المشكلة سوف تتكرر.

Summary: Systematic Problemubleshooting checklist

قبل أن تبدأ

أجيب على الأسئلة الرئيسية الخمسة (ما الذي تغير؟ من المتأثر؟ ثابت أم متقطع؟ قابلة للتكاثر؟ ماذا يرى الجانب الآخر؟
جمع الأعراض الأولية وتقارير المستعملين
التحقق من التغييرات أو الصيانة الأخيرة

√ خلال عملية فرز المشاكل

العمل بطريقة منهجية من خلال طبقات التفتيش الموقعي (الارتفاع التدريجي أو من القمة)
تغيير متغير واحد في وقت الاختبار
توثيق كل اختبار ونتائجه
استعملوا الحزمة لترى سلوك المرور الفعلي
مقارنة بخطوط الأساس المعروفة

القرار

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

خاتمة

مشكلة الشبكة هي العلم والفن The science is following a systematic methodology, using diagnostic tools correctly, and understanding protocols. الفن هو معرفة أي اختبارات تجري أولاً استناداً إلى الأعراض، والاعتراف بأنماط الخبرة، ومعرفة متى تتصاعد.

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

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

آخر تحديث: 2 شباط/فبراير 2026 | Author: Baud9600 Technical Team