سيناريوهات استكشاف أخطاء Linux والشبكات

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

السيناريو 1: حمل عالٍ، CPU منخفض

المقابل: "متوسط الحمل 100 لكن استخدام CPU فقط 10%. ماذا يحدث؟"

نهجك:

# الخطوة 1: تأكد من الأعراض
uptime                    # تحقق من متوسط الحمل
top -b -n1 | head -20     # استخدام CPU

# الخطوة 2: تحقق من انتظار I/O
vmstat 1 5                # انظر عمود 'wa' (انتظار I/O)
iostat -x 1 5             # تفاصيل I/O القرص

# الخطوة 3: حدد المسبب
iotop                     # أي العمليات تقوم بـ I/O
lsof +D /mount/point      # الملفات المستخدمة على تخزين بطيء

# الخطوة 4: تحقق من صحة القرص
dmesg | grep -i error     # أخطاء القرص في سجل النواة
smartctl -a /dev/sda      # صحة قرص SMART

الأسباب الجذرية: قرص فاشل، مشاكل NFS، أقفال قاعدة البيانات، تبديل مفرط

---

السيناريو 2: انتهاء وقت اتصال SSH

المقابل: "لا تستطيع SSH إلى خادم. أرشدني خلال التصحيح."

نهجك:

# الخطوة 1: الاتصال الأساسي
ping server.example.com          # قابل للوصول بـ ICMP؟
traceroute server.example.com    # أين يفشل؟

# الخطوة 2: حل DNS
dig server.example.com           # هل DNS يحل؟
dig @8.8.8.8 server.example.com  # جرب DNS بديل

# الخطوة 3: اتصال المنفذ
nc -zv server.example.com 22     # هل المنفذ 22 مفتوح؟
telnet server.example.com 22     # هل يمكننا الاتصال؟

# الخطوة 4: تحقق من مضيف آخر
# إذا فشل ما سبق، جرب من شبكة مختلفة
# يستبعد مشاكل جانب العميل

# الخطوة 5: إذا كان لديك وصول للكونسول
systemctl status sshd            # هل SSH يعمل؟
ss -tlnp | grep 22               # يستمع على المنفذ 22؟
journalctl -u sshd               # سجلات SSH
iptables -L -n                   # الجدار الناري يحظر؟
cat /etc/hosts.deny              # TCP wrappers؟

الأسباب الشائعة: قواعد الجدار الناري، خدمة SSH متوقفة، ACLs الشبكة، مجموعات الأمان (السحابة)

---

السيناريو 3: تطبيق يعمل ببطء

المقابل: "المستخدمون يبلغون أن تطبيق الويب بطيء. من أين تبدأ؟"

نهجك المنظم (طريقة USE):

المورد	الاستخدام	التشبع	الأخطاء
CPU	top، mpstat	متوسط الحمل	dmesg
الذاكرة	free -h	استخدام التبديل	OOM في السجلات
القرص	iostat	انتظار I/O	smartctl
الشبكة	sar -n DEV	الإسقاطات/الأخطاء	أخطاء الواجهة

# فحص صحة سريع
top -b -n1 | head -20
free -h
iostat -x 1 3
ss -s

# خاص بالتطبيق
curl -w "@curl-format.txt" -o /dev/null -s http://localhost/
# يقيس DNS، الاتصال، TTFB، الوقت الكلي

# تحقق من سجلات التطبيق
tail -f /var/log/app/error.log
journalctl -u myapp -f

# مشاكل اتصال قاعدة البيانات؟
mysql -e "SHOW PROCESSLIST"
# أو
psql -c "SELECT * FROM pg_stat_activity"

---

السيناريو 4: طوارئ مساحة القرص

المقابل: "القرص عند 99%. الإنتاج متوقف. ماذا تفعل؟"

نهجك (بسرعة!):

# الخطوة 1: ابحث عن أكبر المجلدات (سريع)
du -sh /* 2>/dev/null | sort -rh | head -10

# الخطوة 2: ابحث عن الملفات الكبيرة
find /var -type f -size +100M -exec ls -lh {} \; 2>/dev/null

# الخطوة 3: تحقق من الملفات المحذوفة لا تزال مفتوحة
lsof +L1 | head -20

# الخطوة 4: مكاسب سريعة آمنة
# اقطع (لا تحذف) السجلات الكبيرة
> /var/log/large-log-file.log

# امسح ذاكرة الحزم المؤقتة
# Debian/Ubuntu
apt-get clean
# RHEL/CentOS
yum clean all

# احذف النوى القديمة (بحذر!)
# تحقق من النواة الحالية أولاً
uname -r

# الخطوة 5: على المدى الطويل
# أعد تدوير السجلات
# أضف تنبيهات مراقبة عند 80%
# فكر في LVM للمرونة

---

السيناريو 5: فقدان حزم الشبكة

المقابل: "المستخدمون يشتكون من اتصال متقطع. كيف تحقق؟"

# الخطوة 1: قس فقدان الحزم
ping -c 100 target.com
# انظر نسبة فقدان الحزم

# الخطوة 2: المراقبة المستمرة
mtr target.com
# يُظهر الفقدان في كل قفزة

# الخطوة 3: تحقق من أخطاء الواجهة
ip -s link show eth0
# انظر أخطاء RX/TX، الإسقاطات

# الخطوة 4: تحقق من عدم تطابق duplex
ethtool eth0
# Full duplex يجب أن يطابق إعداد السويتش

# الخطوة 5: التقط الحزم للتحليل
tcpdump -i eth0 -w capture.pcap host target.com
# حلل بـ Wireshark

# الخطوة 6: تحقق من تشبع الشبكة
sar -n DEV 1 10
# انظر rxkB/s، txkB/s مقابل سعة الواجهة

---

إطار استكشاف الأخطاء

استخدم دائماً نهجاً منظماً:

1. اجمع المعلومات
   - ما الذي تغير مؤخراً؟
   - متى بدأ؟
   - من المتأثر؟

2. شكّل فرضية
   - بناءً على الأعراض، ما الأكثر احتمالاً؟
   - رتب حسب الاحتمالية

3. اختبر الفرضية
   - شغّل أوامر التشخيص
   - تحقق من السجلات
   - تحقق من الافتراضات

4. نفّذ الإصلاح
   - ابدأ بتغييرات قابلة للعكس
   - وثّق ما غيرته

5. تحقق وراقب
   - تأكد من حل المشكلة
   - أعد المراقبة لاكتشاف التكرار

نصيحة احترافية: دائماً تحدث بصوت عالٍ عن عملية تفكيرك في المقابلات. المقابلون يريدون رؤية كيف تفكر، وليس فقط الإجابة النهائية.

لقد أتقنت أساسيات Linux والشبكات. الوحدة التالية: CI/CD والبنية التحتية كرمز—الأدوات التي تحدد DevOps الحديث. :::