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

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

• هل خدمتي تعمل الآن؟

• وإذا تعطلّت، كم ستأخذ لتعود؟

هذا المقال ليس عن “كيف لا تتعطل أبدًا” لأن ذلك غير واقعي. هذا المقال عن كيف تبني نظامًا يتحمل العطل، ويستعيد الخدمة بسرعة، ويقلل أثر العطل على المستخدم والسمعة والمبيعات.

المفهوم الأساسي: الاعتمادية ليست ميزة، هي جزء من المنتج

كثير من المشاريع تتعامل مع الاعتمادية كأنها “شيء نضيفه لاحقًا”. الحقيقة أن الاعتمادية هي:

• تجربة مستخدم (هل يثق بك؟)

• تسويق (هل ينصح بك؟)

• مبيعات (هل يكرر الشراء؟)

• تكلفة تشغيل (هل ستدفع ساعات طوارئ كل أسبوع؟)

إذا بنيت منتجًا جميلًا لكنه يتعطل بسهولة، ستدفع الثمن في الدعم والسمعة أكثر من أي شيء آخر.

لماذا تتعطل الأنظمة عادة؟

ليس لأن “السيرفر وقع” فقط. الأعطال غالبًا تأتي من:

• تغييرات في الإعدادات أو الشبكة

• إطلاق نسخة فيها خطأ

• ضغط مفاجئ على جزء واحد

• قاعدة بيانات تخنق النظام بسبب استعلام بطيء

• خدمة خارجية تعطلت (دفع، خرائط، رسائل)

• خطأ في الكاش أو الـDNS أو التوجيه

• تسريب ذاكرة أو استهلاك موارد تدريجي

الدرس: لا تفترض أن العطل “نادر”. افترض أنه سيحدث، وابنِ مسارات تُقلل أثره.

هدفنا الحقيقي: 3 مستويات من الحماية

أي نظام محترف يحتاج أن يحقق 3 أهداف:

1) منع العطل قدر الإمكان

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

2) عزل العطل عند حدوثه

إذا تعطل جزء، لا يسقط كل النظام معه.

3) استعادة الخدمة بسرعة

حتى لو تعطل، يكون عندك خطة ووسائل ترجع بسرعة.

أولا: صمّم النظام بحيث لا يكون “نقطة واحدة للفشل”

مفهوم Single Point of Failure

إذا كان عندك عنصر واحد لو توقف يوقف كل شيء، فأنت تنتظر كارثة:

• سيرفر واحد

• قاعدة بيانات واحدة بدون نسخ

• مزود DNS واحد بدون خطة

• خدمة دفع واحدة بدون بديل

• لوحة تحكم واحدة لا تعمل وقت الطوارئ

ماذا تفعل عمليًا؟

1) تعدد النسخ (Redundancy) حسب حجم المشروع

للمشاريع الصغيرة:

• نسخة احتياطية يومية + اختبار استرجاع شهري

• خادم واحد لكن مع مراقبة قوية وخطة نقل سريع

للمشاريع المتوسطة والكبيرة:

• خادمين على الأقل خلف Load Balancer

• قاعدة بيانات مع Replication أو على خدمة مدارة

• CDN للصور والملفات

• فصل الخدمات الحرجة إن أمكن

2) فصل الخدمات الحرجة عن غيرها

مثال:
لو خدمة البحث تعطلت، لا تجعل الدفع يتعطل معها.
لو صفحة العروض تعطلت، لا توقف صفحة الدفع.

هذا يتحقق عبر عزل المسارات (Modules) أو الخدمات.

ثانيًا: ابنِ “تدهور أنيق” بدل الانهيار الكامل

الفكرة: عند العطل، لا تسقط كل التجربة. اجعل التطبيق يقدم الحد الأدنى.

أمثلة على التدهور الأنيق

متجر إلكتروني

• إذا تعطل نظام التوصيل: اعرض “استلم من الفرع” أو “التوصيل مؤقتًا غير متاح”

• إذا تعطل البحث: اعرض تصنيفات وروابط سريعة

• إذا تعطل توصيات المنتجات: اعرض المنتجات الأكثر مبيعًا

تطبيق طلبات/خدمات

• إذا تعطلت الخرائط: اعرض إدخال عنوان يدوي

• إذا تعطل الدفع الإلكتروني: فعّل الدفع عند الاستلام مؤقتًا

• إذا تعطل تتبع الطلب: اعرض حالة نصية وتحديثات بسيطة

مواقع شركات

• إذا تعطل نموذج التواصل: اعرض أرقام أو بريد مباشر

• إذا تعطل جزء من الصفحة: اعرض نسخة ثابتة بسيطة

لماذا هذا مهم؟

لأن المستخدم لا يحتاج كل المزايا وقت العطل. يحتاج أن يكمل أهم شيء: طلب، تواصل، دفع، أو متابعة.

ثالثًا: لا تسمح لخدمة خارجية أن تسقطك

كثير من الأنظمة تعتمد على طرف ثالث:

• بوابة دفع

• SMS/WhatsApp API

• خرائط

• بريد

• تحليلات

• تسجيل دخول اجتماعي

خطأ شائع

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

الحل: Circuit Breaker + Timeouts + Fallback

1) Timeouts

لا تنتظر 30 ثانية. حدّد مهلة قصيرة.

2) Circuit Breaker

إذا فشل الطرف الثالث مرات متتالية، اقفل الاتصال مؤقتًا بدل أن تخنق نظامك.

3) Fallback

قدم بديل: رسالة، خيار دفع آخر، طريقة إدخال مختلفة.

هذه الثلاثية وحدها تنقذك من انهيارات كثيرة.

رابعًا: راقب قبل أن يشتكي العملاء

المراقبة ليست لوحة جميلة فقط. هي إنذار مبكر.

ما الذي يجب مراقبته؟

1) مؤشرات البنية

• CPU, RAM, Disk

• عدد الطلبات في الثانية

• أخطاء 5xx

• زمن الاستجابة

2) مؤشرات التطبيق

• عدد أخطاء تسجيل الدخول

• فشل الدفع

• فشل إنشاء طلب

• زيادة الاستثناءات في logs

3) مؤشرات تجربة المستخدم

• ارتفاع السلال المتروكة

• انخفاض إتمام الشراء

• زيادة وقت التحميل على الموبايل

قاعدة مهمة

راقب “ما يؤلم العميل” لا فقط “ما يؤلم السيرفر”.

خامسًا: نشر آمن يقلل الأعطال

كثير من الأعطال سببها إطلاق نسخة بدون نظام.

استراتيجيات نشر آمنة

1) Blue/Green Deployment

نسختان: واحدة تعمل، واحدة جديدة تُختبر ثم تبديل سريع.

2) Canary Release

أطلق التحديث على نسبة صغيرة من المستخدمين، راقب، ثم وسّع.

3) Feature Flags

شغّل وأطفئ ميزات بدون نشر نسخة جديدة.
ميزة خطيرة؟ اقفلها فورًا بدل أن تسقط النظام كله.

قائمة قبل أي نشر

• هل هناك خطة Rollback؟

• هل تم اختبار السيناريو الأساسي؟

• هل هناك Migration قاعدة بيانات؟ وهل يمكن الرجوع؟

• هل تم قياس الأداء بعد التحديث؟

سادسًا: خطة استعادة الخدمة (Incident Response)

وقت العطل، أسوأ شيء هو الارتباك. تحتاج خطة بسيطة جدًا.

1) أدوار واضحة

• قائد الحادث (Incident Lead)

• مسؤول البنية

• مسؤول التطبيق

• مسؤول التواصل مع العملاء

2) قناة واحدة للطوارئ

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

3) خطوات ثابتة للتعامل

• تأكيد العطل (هل هو عام أم جزئي؟)

• تحديد آخر تغيير تم

• فحص المراقبة والـlogs

• تطبيق rollback أو تعطيل ميزة بFeature Flag

• التحقق من عودة الخدمة

• مراقبة ما بعد العودة

4) صفحة حالة (Status Page)

حتى لو بسيطة. لأنها:

• تقلل ضغط الدعم

• ترفع ثقة العميل

• تمنحك وقتًا للإصلاح بدل الرد على كل شخص

ماذا تكتب للعميل؟

• ما المشكلة بشكل مختصر

• ما التأثير

• ما الإجراء الحالي

• تحديثات زمنية قصيرة

لا تطل. فقط كن واضحًا.

سابعًا: قاعدة البيانات غالبًا هي نقطة الاختناق

كثير من الأعطال تأتي من:

• استعلامات بطيئة

• قفل جداول

• نقص فهارس

• نمو بيانات غير محسوب

حلول عملية

1) فهارس (Indexes) للأعمدة المستخدمة في البحث والترتيب

2) Cache للبيانات المتكررة

3) Pagination بدل تحميل كل البيانات

4) فصل القراءة عن الكتابة عند النمو (Read replicas) إن لزم

5) مراقبة الاستعلامات البطيئة وإصلاح الأعلى تأثيرًا أولًا

ثامنًا: اختبر الأعطال بدل أن تتفاجأ بها

فكرة اختبار العطل ليست معقدة. ابدأ ببساطة:

تمارين بسيطة

• ماذا يحدث إذا تعطل الدفع؟

• ماذا يحدث إذا تعطل SMS؟

• ماذا يحدث إذا قاعدة البيانات بطيئة؟

• ماذا يحدث إذا ارتفع الضغط 10 أضعاف؟

الهدف ليس أن كل شيء يبقى مثاليًا، بل أن تعرف كيف يتصرف النظام، وأن يكون لديك بدائل.

قائمة تحقق لبناء نظام يتحمل الأعطال

هندسة

• لا توجد نقطة واحدة للفشل في العناصر الحرجة

• CDN للملفات

• نسخ احتياطي + اختبار استرجاع

• Timeouts + Circuit breaker للخدمات الخارجية

تشغيل

• مراقبة للأخطاء والزمن والطلبات

• تنبيهات على مؤشرات “تؤلم العميل”

• خطة نشر آمنة + rollback

• Feature flags للميزات الحساسة

طوارئ

• أدوار واضحة

• قناة واحدة للحادث

• Status page بسيطة

• Postmortem بعد كل عطل

كيف تكتب Postmortem بدون لوم؟

بعد عودة الخدمة، أهم خطوة لتحسين النظام هي تحليل السبب الجذري.

ما الذي تكتبه؟

• ماذا حدث؟

• ما السبب؟

• ما الذي ساعدنا؟

• ما الذي أخّرنا؟

• ما الإجراء الذي يمنع تكراره؟

• من المسؤول عن تنفيذ الإجراء ومتى؟

الهدف ليس توبيخ شخص. الهدف تقوية النظام.

خاتمة

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

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