أسبوعٌ هزّ ثقة السحابة: ماذا حدث في أكتوبر 2025؟
في العشرين من أكتوبر 2025 تعرّضت AWS لواحد من أكبر أعطالها خلال العام في منطقة us-east-1 (شمال فرجينيا)؛ إذ تسبّب خلل من نوع «حالة تسابق» (race condition) في نظام DNS الخاص بقاعدة بيانات DynamoDB في سلسلة انهيارات طالت أكثر من 110 خدمات من بينها Lambda وIAM وCloudFormation وCognito. واستمر العطل نحو 15 ساعة وأثّر في أكثر من 4 ملايين مستخدم وما يزيد على 1000 شركة حول العالم.
وبعد تسعة أيام فقط، في 29 أكتوبر، توقّفت خدمات Microsoft Azure نحو 9 ساعات بسبب تغيير غير مقصود في إعدادات خدمة Azure Front Door (نظام موازنة الأحمال وتوزيع المحتوى العالمي)، ما أدّى إلى انقطاعات وفشل في تخصيص الموارد عبر خدمات متعددة. والدرس المشترك واضح: حتى أكبر مزوّدي السحابة يتعطّلون، والاعتماد على منطقة واحدة أو مستوى تحكّم عالمي واحد يحوّلها إلى نقطة فشل وحيدة قاتلة.
تكلفة التوقف: لماذا لم يَعُد التعافي من الكوارث رفاهية
التوقّف مكلف للغاية. تشير تقديرات الصناعة إلى أن متوسط تكلفة توقّف تقنية المعلومات يبلغ نحو 5,600 دولار في الدقيقة، وأن ساعة توقّف واحدة تتجاوز 300 ألف دولار لدى أكثر من 90% من المؤسسات المتوسطة والكبيرة، فيما يبلّغ 41% منها عن خسائر تتراوح بين مليون وخمسة ملايين دولار في الساعة. ومن المتوقّع أن تتجاوز كلفة التوقّف العالمية 400 مليار دولار سنويًا بحلول 2030.
لهذا يتوسّع سوق التعافي من الكوارث السحابية بسرعة؛ إذ تُقدَّر قيمته بنحو 21.8 مليار دولار في 2026 في طريقه إلى نحو 50.5 مليار دولار بحلول 2030. لم يَعُد التعافي من الكوارث بوليصة تأمين تأمل ألّا تستخدمها، بل انضباطًا تشغيليًا. ويُحكَم أي خطة بمؤشّرين أساسيين: زمن التعافي المستهدف (RTO) أي أقصى مدة توقّف مقبولة، ونقطة التعافي المستهدفة (RPO) أي أقصى قدر من البيانات يمكن خسارته. حدِّدهما لكل حِمل عمل قبل اختيار الاستراتيجية.
استراتيجيات التعافي الأربع: من النسخ الاحتياطي إلى Active-Active
تُصنّف AWS والصناعة عمومًا التعافي من الكوارث في طيف من أربع مقاربات تُوازن بين الكلفة وRTO/RPO: أولًا النسخ الاحتياطي والاستعادة (Backup & Restore) وهو الأرخص لكن زمن تعافيه بالساعات؛ ثانيًا الضوء الإرشادي (Pilot Light) حيث تبقى نسخة أساسية جاهزة تُشغَّل عند الحاجة؛ ثالثًا الاستعداد الدافئ (Warm Standby) وهو نسخة مصغّرة عاملة دائمًا تتوسّع عند الكارثة؛ ورابعًا متعدد المواقع النشط (Active/Active) بتكرار كامل وزمن تعافٍ شبه صفري لكن بكلفة تقارب ضِعف كلفة المنطقة الواحدة.
يعتمد الاختيار على حَرَجية حِمل العمل. تستقرّ أغلب المؤسسات على الضوء الإرشادي أو الاستعداد الدافئ كنقطة توازن، وتحتفظ بـ Active/Active للأنظمة التي لا تحتمل أي توقّف. ومن الإرشادات العملية: شغّل نسخًا أصغر في منطقة التعافي ووسّعها وقت التبديل، وأتمتة عملية التبديل بدل الاعتماد على إجراءات يدوية تحت الضغط، واختبر الخطة دوريًا — فخطة تعافٍ غير مُختبَرة مجرّد أمنية لا خطة. وتذكّر أن التوزّع على أكثر من منطقة لدى المزوّد نفسه يساعد، لكنّ فشل مستوى التحكّم العالمي قد يطالك رغم ذلك، وهنا تبرز قيمة تعدّد المزوّدين للأنظمة الأشدّ حَرَجية.
التعافي من الكوارث في سياق المملكة ورؤية 2030
لطالما تعارض الصمود مع توطين البيانات لدى المؤسسات السعودية؛ فالحفاظ على البيانات داخل المملكة مع الرغبة في تكرار جغرافي كان صعبًا. لكنّ المشهد يتغيّر: منطقة Google Cloud في الدمام، ومنطقة أوراكل الثانية في الرياض (مع سحابة ذكاء اصطناعي سيادية)، ومنطقة Azure السعودية بثلاث مناطق توافر مستقلة (المتوقّعة في الربع الأخير من 2026)، كلها تجعل التعافي من الكوارث متعدّد مناطق التوافر بل ومتعدّد المناطق ممكنًا داخل المملكة دون إرسال البيانات خارجها.
وتُعزّز المتطلبات التنظيمية هذا التوجّه: تتوقّع ضوابط الهيئة الوطنية للأمن السيبراني وأطر مؤسسة النقد (ساما) وجود خطط استمرارية أعمال وتعافٍ من الكوارث للأنظمة الحرجة، ويضيف نظام حماية البيانات الشخصية (PDPL) اعتبارات توطين البيانات. خلاصة 2026: صمّم لمواجهة الفشل من اليوم الأول — حدِّد RTO/RPO لكل نظام، ووزّع على مناطق التوافر (والمناطق حيث يُبرّر ذلك)، وأتمتة واختبر التبديل، واستفد من المناطق السحابية الجديدة داخل المملكة للتوفيق بين الصمود والسيادة الرقمية.
