طريقة التشخيص المنظمة
النهج المنهجي
في علوم الحاسوب، وخاصة في السحابة، لا ينبغي أن يكون استكشاف الأخطاء وإصلاحها "تجربة وخطأ" عشوائية. ستوفر لك الطريقة المنظمة الوقت وتجعلك أكثر فعالية.
┌─────────────────────────────────────────────────────────────┐
│ طريقة التشخيص في 5 خطوات │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. العَرَض │
│ └── ما الذي لا يعمل بالضبط؟ │
│ كن دقيقًا! "لا يعمل" ليس عرضًا صالحًا. │
│ │
│ 2. الفَرَضِيَّات │
│ └── ما هي الأسباب المحتملة؟ │
│ قم بإدراجها حسب الاحتمالية. │
│ │
│ 3. الاختبارات │
│ └── كيف تتحقق من كل فرضية؟ │
│ اختبار واحد في كل مرة، بطريقة منهجية. │
│ │
│ 4. التصحيح │
│ └── ما الإجراء الذي يحل المشكلة؟ │
│ تطبيق والتحقق. │
│ │
│ 5. التوثيق │
│ └── تدوين الحل للرجوع إليه في المستقبل. │
│ تحديث دليل التشغيل. │
│ │
└─────────────────────────────────────────────────────────────┘
الخطوة 1: تحديد العَرَض
عرض سيء مقابل عرض جيد
❌ أعراض سيئة (غامضة جدًا) :
• "الخادم لا يعمل"
• "معطل"
• "لدي خطأ"
• "كان يعمل من قبل"
✅ أعراض جيدة (دقيقة) :
• "انتهاء مهلة SSH بعد 30 ثانية إلى IP 52.1.2.3"
• "خطأ 502 Bad Gateway على http://example.com"
• "تتحول المثيل i-xxx إلى terminated بعد 10 ثوانٍ"
• "تعيد صفحة الويب خطأ 500 منذ الساعة 14:30"
أسئلة يجب طرحها
┌─────────────────────────────────────────────────────────────┐
│ أسئلة توضيحية │
├─────────────────────────────────────────────────────────────┤
│ │
│ ماذا ؟ │
│ • ما هي رسالة الخطأ الدقيقة ؟ │
│ • ما هي الوظيفة المتأثرة ؟ │
│ • ما هي الخدمة/المثيل المعني ؟ │
│ │
│ متى ؟ │
│ • متى بدأت المشكلة ؟ │
│ • هل المشكلة ثابتة أم متقطعة ؟ │
│ • هل هناك أنماط (ساعات، أيام) ؟ │
│ │
│ أين ؟ │
│ • ما هي المنطقة/AZ ؟ │
│ • ما هي المثيل/المورد ؟ │
│ • من أين يتم ملاحظة المشكلة ؟ │
│ │
│ من ؟ │
│ • جميع المستخدمين أم بعضهم فقط ؟ │
│ • من بعض الشبكات/IPs ؟ │
│ │
│ تغيير ؟ │
│ • ما الذي تغير مؤخرًا ؟ │
│ • نشر ؟ تكوين ؟ AWS ؟ │
│ │
└─────────────────────────────────────────────────────────────┘
الخطوة 2: صياغة الفَرَضِيَّات
فئات مشاكل EC2
┌─────────────────────────────────────────────────────────────┐
│ فئات المشاكل │
├─────────────────────────────────────────────────────────────┤
│ │
│ 🌐 الشبكة │
│ ├── Security Group تم تكوينه بشكل خاطئ │
│ ├── NACL يحظر │
│ ├── جدول التوجيه غير صحيح │
│ ├── بوابة الإنترنت مفقودة │
│ └── لا يوجد IP عام │
│ │
│ 🔐 الأمان / المصادقة │
│ ├── مفتاح SSH خاطئ │
│ ├── مستخدم خاطئ │
│ ├── أذونات ملف .pem │
│ └── IAM (للمكالمات API) │
│ │
│ 💻 المثيل │
│ ├── المثيل غير قيد التشغيل │
│ ├── فشل فحص الحالة │
│ ├── الخدمة غير مبدوءة (Apache, SSH) │
│ └── القرص ممتلئ │
│ │
│ 📦 التطبيق │
│ ├── تعطل التطبيق │
│ ├── تكوين غير صحيح │
│ ├── تبعية مفقودة │
│ └── منفذ غير صحيح │
│ │
│ ☁️ AWS │
│ ├── انقطاع إقليمي │
│ ├── خدمة متدهورة │
│ └── صيانة │
│ │
└─────────────────────────────────────────────────────────────┘
تحديد أولويات الفَرَضِيَّات
القاعدة الذهبية: من الأبسط إلى الأكثر تعقيدًا
من الأكثر احتمالاً إلى الأقل احتمالاً
مثال لـ "انتهاء مهلة SSH" :
احتمالية عالية (تحقق أولاً)
1. Security Group - منفذ 22 مغلق
2. لا يوجد IP عام
3. المثيل غير قيد التشغيل
احتمالية متوسطة
4. NACL يحظر
5. جدول التوجيه بدون مسار إلى IGW
6. جدار ناري على المثيل
احتمالية منخفضة
7. انقطاع AWS إقليمي
8. خطأ في عميل SSH
الخطوة 3: اختبار الفَرَضِيَّات
اختبارات لمشاكل الشبكة
# 1. التحقق من حالة المثيل
aws ec2 describe-instances --instance-ids i-xxx \
--query 'Reservations[].Instances[].State.Name'
# 2. التحقق من IP العام
aws ec2 describe-instances --instance-ids i-xxx \
--query 'Reservations[].Instances[].PublicIpAddress'
# 3. التحقق من Security Groups
aws ec2 describe-security-groups --group-ids sg-xxx
# 4. اختبار الاتصال بالشبكة (من جهازك)
ping IP_PUBLIQUE # ICMP (إذا كان مسموحًا)
telnet IP_PUBLIQUE 22 # اختبار منفذ SSH
nc -zv IP_PUBLIQUE 22 # بديل لـ telnet
# 5. التحقق من جدول التوجيه للشبكة الفرعية
aws ec2 describe-route-tables --filters "Name=association.subnet-id,Values=subnet-xxx"
اختبارات لمشاكل المثيل
# 1. التحقق من فحوصات الحالة
aws ec2 describe-instance-status --instance-ids i-xxx
# 2. استرجاع سجلات النظام (إذا تم تكوينها)
aws ec2 get-console-output --instance-id i-xxx
# 3. التحقق من مقاييس CloudWatch
aws cloudwatch get-metric-statistics \
--namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-xxx \
--start-time 2024-01-01T00:00:00Z \
--end-time 2024-01-01T01:00:00Z \
--period 300 \
--statistics Average
من المثيل (إذا كان متاحًا)
# التحقق من الخدمات
systemctl status sshd
systemctl status httpd
# التحقق من المنافذ المفتوحة
netstat -tlnp
ss -tlnp
# التحقق من مساحة القرص
df -h
# التحقق من الذاكرة
free -m
# التحقق من السجلات
tail -100 /var/log/messages
tail -100 /var/log/secure
journalctl -xe
الخطوة 4: تطبيق التصحيح
قواعد للتصحيحات
┌─────────────────────────────────────────────────────────────┐
│ قواعد لتطبيق التصحيح │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. تغيير واحد في كل مرة │
│ └── لا تغير 5 أشياء في نفس الوقت! │
│ └── وإلا لن تعرف ما الذي حل المشكلة │
│ │
│ 2. التوثيق قبل التغيير │
│ └── تدوين الحالة الحالية │
│ └── القدرة على التراجع │
│ │
│ 3. اختبار بعد كل تغيير │
│ └── التحقق مما إذا تم حل المشكلة │
│ └── التحقق من عدم إنشاء مشاكل جديدة │
│ │
│ 4. التحقق الكامل │
│ └── الاختبار السريع لا يكفي │
│ └── اختبار جميع حالات الاستخدام المتأثرة │
│ │
└─────────────────────────────────────────────────────────────┘
مثال على تصحيح موثق
المشكلة : انتهاء مهلة SSH إلى المثيل i-0123456789
التشخيص :
- المثيل : قيد التشغيل ✓
- IP العام : 52.1.2.3 ✓
- Security Group : sg-abc123
→ منفذ 22 : مفقود ❌
التصحيح المطبق :
aws ec2 authorize-security-group-ingress \
--group-id sg-abc123 \
--protocol tcp \
--port 22 \
--cidr 0.0.0.0/0
التحقق :
ssh -i ma-cle.pem ec2-user@52.1.2.3
→ اتصال ناجح ✓
التاريخ : 2024-12-18 14:30
الفني : Haythem
الخطوة 5: التوثيق
قالب التوثيق
# الحادثة : [عنوان قصير]
## التاريخ والمدة
- البداية : YYYY-MM-DD HH:MM
- الحل : YYYY-MM-DD HH:MM
- المدة الإجمالية : X ساعات
## العَرَض
[وصف دقيق للمشكلة الملاحظة]
## التأثير
- المستخدمون المتأثرون : X
- الخدمات المتأثرة : [قائمة]
- مستوى الخطورة : حرج/كبير/صغير
## السبب الجذري
[تفسير السبب الأساسي]
## التسلسل الزمني
- HH:MM - اكتشاف المشكلة
- HH:MM - بدء التشخيص
- HH:MM - تحديد السبب
- HH:MM - تطبيق التصحيح
- HH:MM - التحقق والإغلاق
## الحل المطبق
[وصف التصحيح]
## الإجراءات الوقائية
- [ ] إجراء 1 لتجنب تكرار المشكلة
- [ ] إجراء 2
- [ ] تحديث دليل التشغيل
## الدروس المستفادة
[ما تعلمناه من هذه الحادثة]
تمرين عملي
السيناريو
السياق :
لقد قمت بتشغيل مثيل EC2 منذ 5 دقائق.
المثيل في حالة "قيد التشغيل".
تحاول الاتصال عبر SSH.
النتيجة :
$ ssh -i ma-cle.pem ec2-user@52.1.2.3
ssh: connect to host 52.1.2.3 port 22: Connection timed out
طبق طريقة التشخيص!
الإجابة الموجهة
الخطوة 1 : العَرَض
"انتهاء مهلة SSH بعد 30 ثانية إلى 52.1.2.3 منفذ 22
من جهازي (IP: 203.0.113.50)"
الخطوة 2 : الفَرَضِيَّات (حسب الاحتمالية)
1. Security Group - منفذ 22 غير مفتوح أو IP غير مصرح به
2. لا يوجد مسار إلى بوابة الإنترنت
3. NACL يحظر المنفذ 22
4. المثيل لم يبدأ بالكامل بعد
الخطوة 3 : الاختبارات
اختبار 1 : Security Group
→ aws ec2 describe-security-groups --group-ids sg-xxx
→ النتيجة : منفذ 22 مفتوح إلى 10.0.0.0/8 فقط
→ لم يتم السماح لـ IP الخاص بي 203.0.113.50!
الخطوة 4 : التصحيح
aws ec2 authorize-security-group-ingress \
--group-id sg-xxx \
--protocol tcp \
--port 22 \
--cidr 203.0.113.50/32
التحقق :
ssh -i ma-cle.pem ec2-user@52.1.2.3
→ اتصال ناجح!
الخطوة 5 : التوثيق
[املأ القالب أعلاه]
الملخص
| الخطوة | الإجراء | المدة النموذجية |
|---|---|---|
| 1. العَرَض | تحديد بدقة | 2-5 دقائق |
| 2. الفَرَضِيَّات | قائمة حسب الاحتمالية | 5-10 دقائق |
| 3. الاختبارات | التحقق بطريقة منهجية | متغير |
| 4. التصحيح | تغيير واحد في كل مرة | متغير |
| 5. التوثيق | دائمًا التوثيق | 10-15 دقيقة |
اختبار التحقق
- لماذا يجب اختبار فرضية واحدة في كل مرة؟
- ما الفرق بين العَرَض الغامض والدقيق؟
- بماذا تبدأ: الأسباب المحتملة أم غير المحتملة؟
- لماذا توثق حتى الحوادث الصغيرة؟
- ماذا تفعل إذا لم يعمل التصحيح الأول؟
القسم التالي: مختبر: سيناريوهات الأعطال