ايش يصير لو سيرفرك توقف؟ دليل الطوارئ

عندما يتوقف السيرفر: الدقائق الأولى تحدد كل شيء

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

كل دقيقة توقف تكلّف أموالاً حقيقية. المتوسط العالمي لتكلفة التوقف: 5,600 دولار في الدقيقة للشركات المتوسطة. حتى لو شركتك أصغر، الأثر ملموس: عملاء يخسرون الثقة، طلبات تضيع، سمعة تتضرر.

خطة الاستجابة: 5 مراحل

المرحلة 1: الاكتشاف (0-2 دقيقة)

لا تنتظر أن يُخبرك العميل. نظام المراقبة يجب أن يكتشف التوقف قبل أي شخص:

• مراقبة HTTP كل 30 ثانية (Uptime Robot، Hetrixtools، أو حل مخصص)
• تنبيهات فورية عبر SMS وبريد إلكتروني
• صفحة حالة خدمة عامة تتحدث تلقائياً

المرحلة 2: التشخيص (2-10 دقائق)

اتصل بالسيرفر وحدد المشكلة:

# هل السيرفر يستجيب أصلاً؟
ping server-ip

# هل SSH يعمل؟
ssh -o ConnectTimeout=5 user@server-ip

# إذا دخلت — تحقق من الموارد
top -bn1 | head -20
df -h
free -m
dmesg | tail -50

العَرَض	السبب المحتمل	الإجراء الفوري
لا استجابة للـ ping	عطل شبكة أو هاردوير	تواصل مع مركز البيانات
SSH يعمل لكن الموقع لا	خدمة ويب متوقفة	أعد تشغيل nginx/Apache
استهلاك CPU 100%	عملية خارجة عن السيطرة	حدد العملية واقتلها
القرص ممتلئ 100%	نفاد المساحة	احذف logs قديمة أو وسّع القرص
الذاكرة ممتلئة	تسرب ذاكرة أو حمل زائد	أعد تشغيل الخدمة المسببة

المرحلة 3: الاحتواء (10-30 دقيقة)

إذا لم تستطع حل المشكلة فوراً، احتوها:

1. فعّل صفحة صيانة: أفضل من رسالة خطأ عامة
2. أعلم العملاء: رسالة واضحة عبر البريد أو صفحة الحالة
3. وثّق كل خطوة: ستحتاجها للتحليل لاحقاً
4. لا تجرّب حلولاً عشوائية: كل تغيير بدون فهم قد يزيد المشكلة

المرحلة 4: الحل

بحسب نوع المشكلة:

عطل البرمجيات

# إعادة تشغيل خدمة الويب
systemctl restart nginx
systemctl restart php-fpm

# إعادة تشغيل قاعدة البيانات
systemctl restart mysql

# مراجعة logs الأخطاء
tail -100 /var/log/nginx/error.log
tail -100 /var/log/mysql/error.log

نفاد المساحة

# أكبر الملفات
du -sh /var/log/* | sort -rh | head -10

# تنظيف logs
journalctl --vacuum-size=100M
find /var/log -name "*.gz" -mtime +30 -delete

مشكلة أداء

# أعلى العمليات استهلاكاً
ps aux --sort=-%mem | head -10
ps aux --sort=-%cpu | head -10

# اتصالات قاعدة البيانات
mysqladmin -u root processlist

المرحلة 5: التعافي والتوثيق

بعد حل المشكلة:

1. تأكد من عمل كل الخدمات
2. راجع logs للتأكد من عدم وجود أخطاء متبقية
3. حدّث صفحة الحالة
4. أرسل إشعار للعملاء بعودة الخدمة
5. اكتب تقرير Post-Mortem خلال 24 ساعة

قالب تقرير Post-Mortem

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

أدوات أساسية يجب تجهيزها مسبقاً

الأداة	الغرض	أمثلة
مراقبة خارجية	اكتشاف التوقف	Uptime Robot، Hetrixtools
وصول طوارئ	الدخول عند عطل SSH	KVM/IPMI، لوحة تحكم مركز البيانات
صفحة حالة	إعلام العملاء	Instatus، Cachet
قنوات تنبيه	إشعار الفريق	SMS، WhatsApp
نسخ احتياطي	استعادة البيانات	نسخ يومي مُختبر

الوقاية خير من العلاج

90% من حالات التوقف يمكن منعها:

• مراقبة الموارد بشكل مستمر (CPU، ذاكرة، قرص)
• تنبيهات عند 80% استهلاك (قبل الوصول لـ 100%)
• تحديثات أمان منتظمة
• نسخ احتياطي يومي مُختبر
• اختيار مزود استضافة موثوق بـ SLA واضحة

كلاود يقدم SLA بنسبة 99.99% مع مراكز بيانات Tier III في الرياض. لكن حتى مع أعلى مستوى SLA، خطة الطوارئ الخاصة بك ضرورية. المزود يحمي البنية التحتية، وأنت تحمي تطبيقك.

---

ابدأ الآن

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