لن تكونوا «متعددي المناطق» فعلًا قبل أن تُغلقوا منطقتكم الأساسية بأنفسكم
عبارة «نحن متعددو المناطق» مجرد فرضية لم يختبرها تقريبًا أحد بإيقاف المنطقة الأساسية عمدًا ومشاهدة ما يحدث. حوّلوا هذا الاختبار إلى أربعة بنود نجاح أو فشل داخل العقد، وسيصبح للادعاء ثمن حقيقي أخيرًا.
إليكم بندًا يستحق إدراجه في أي عقد مع مورّد يصف منصته بأنها «متعددة المناطق». في تاريخ محدد، نهارًا، مع جعل المنطقة الأساسية غير قابلة للوصول فعليًا لا افتراضيًا، تجتاز الخدمة أربعة اختبارات مكتوبة سلفًا بحيث لا يستطيع أحد الجدال في النتيجة لاحقًا. أولًا: مستخدم جديد تمامًا، بلا أي ذاكرة تخزين مؤقت دافئة في أي مكان، يُصادَق عليه من البداية للنهاية والمنطقة الأساسية مُعتمة. ثانيًا: عملية كتابة تكتمل وتكون قابلة للقراءة بثبات من المنطقة الثانوية ضمن هدف نقطة الاستعادة الذي بِعتم به فعليًا، لا الذي يتمنون لو وعدوا به. ثالثًا: زمن الخدمة المُقاس من المنطقة الثانوية يفي بهدف زمن الاستعادة المُعلن، بالساعة والدقيقة. رابعًا: لا تحتاج أي خطوة في دليل التشغيل إلى لوحة تحكم أو سرّ أو بيانات اعتماد تعيش هي نفسها في المنطقة المُعطَّلة. أربعة بنود، نجاح أو فشل. وفجأة تصبح عبارة «نحن متعددو المناطق» لها ثمن ومسار تدقيق.
سعّروا الطرفين وستثبت الحجة نفسها بنفسها. التمرين يكلّف نافذة زمنية مخططة، وبعد ظهر مهندس واحد، وفي أسوأ الأحوال بضع دقائق من خدمة متعمدة التراجع أعلنتم عنها سلفًا. أما الاختبار الفاشل فيكلّف قيمة أكثر ساعاتكم ازدحامًا، في اللحظة التي تملكون فيها أقل قدر من التحكم. تخيّلوا متجرًا إلكترونيًا خليجيًا يحقق نحو 3.75 مليون ريال سعودي (ما يقارب مليون دولار أمريكي) من المبيعات في يوم عادي: انقطاع إقليمي غير مخطط له يُسقط صفحة الدفع لثلاث ساعات في وقت الذروة ليس خطأ هامشيًا، بل يأتي معه استرداد للمبالغ، وضغط على الدعم، ويوم كامل من السمعة يجب استرداده. التمرين هو الفشل ذاته، مُشترى نهارًا بثمن بعد ظهر واحد. المسألة ليست هل ستُجرى هذه التجربة أم لا، بل من يُجريها، أنتم أم عملاؤكم، وعلى ساعة مَن.
مثال واقعي واحد يلخّص النمط بأكمله. في وقت متأخر من مساء 19 أكتوبر 2025 بتوقيت المحيط الهادئ الأمريكي (الساعات الأولى من 20 أكتوبر بالتوقيت العالمي المنسّق)، تسبب سباق حالات (race condition) في الإدارة الآلية لسجلات DNS الخاصة بخدمة DynamoDB داخل منطقة us-east-1 لدى AWS في ترك نقطة النهاية الإقليمية تُشير إلى سجل فارغ، وفق الملخص الرسمي الذي نشرته AWS بعد الحادثة. أما النمط الأوسع الذي تلا ذلك، وهو أن قائمة طويلة من الخدمات «العالمية» التي لم تُجرِ هذا الاختبار قط اكتشفت مباشرة أن مرونتها تتوقف عند حدود قدرة الحوسبة، فهو قراءة تحريرية للحدث وليس تصريحًا صادرًا عن AWS.
ماذا يضمن مصطلح «متعدد المناطق» فعليًا؟
شبه لا شيء بمفرده. تشغيل قدرة حوسبة في منطقتين يضمن فقط وجود حوسبة في منطقتين، ولا يقول شيئًا عن قدرة المنطقة الثانية على خدمة طلب من البداية للنهاية حين يصبح الوصول إلى الأولى مستحيلًا. الطلب الواحد يحمل أكثر من مجرد حوسبة؛ يحمل مصادقة، ورمز جلسة يُتحقق منه في مكان ما، وقراءة إعداد، وعلامة ميزة (feature flag)، وقراءة بيانات وصفية، وطابور رسائل، وقفل معاملة، وفحص شهادة رقمية. أي واحد من هذه العناصر مُثبَّت في منطقة واحدة يحوّل أسطولكم الاحتياطي إلى ديكور مكلف. لهذا السبب فإن الفشل المؤلم نادرًا ما يكون موت الخادم أو فشل قاعدة البيانات الذي تدربتم عليه مرارًا؛ بل يقع الانقطاع فتصمت طبقة الهوية عن الرد، أو تُعتم لوحة التحكم التي توزّع الإعدادات، أو يختفي مخزن بيانات وصفية تقرأه كل الخدمات عند الإقلاع ولم يُدرجه أحد ضمن العناصر الحرجة لأنه لم يُزعج أبدًا لوحة قياس زمن الاستجابة، مع المنطقة المُعطَّلة. التطبيق الاحتياطي لا يستطيع الإقلاع لأن الحالة غير اللامعة التي يعتمد عليها تعيش في مكان واحد. كنتم أحاديي المنطقة طوال الوقت؛ فقط لم تروا الخيط حتى سحبه أحدهم.
كيف تُثبتون عمليًا أن آلية التعافي تعمل؟
ليس بمراجعة مخطط بياني على شاشة. بل ببتر مُتحكَّم فيه. اختاروا حِملًا إنتاجيًا حقيقيًا، لا نسخة تجريبية شكلية. في نافذة زمنية مخططة نهارًا، وخطة تراجع جاهزة، اجعلوا المنطقة الأساسية غير قابلة للوصول فعليًا عند حافة الشبكة. لا تكتفوا بتصغير سعتها إلى صفر، لأن ذلك يترك بصمت مسارات DNS والهوية والشهادات الرقمية سليمة، فيمنحكم نتيجة نجاح كاذبة. بعدها قِيسوا التمرين على البنود الأربعة المذكورة في مطلع هذا المقال، واعتبروا أي إخفاق ولو في بند واحد بمثابة نقطة الفشل الوحيدة الحقيقية لديكم، مهما زعم عدد الخوادم غير ذلك. الإخفاق الذي تكتشفونه بهذه الطريقة هو أرخص نتيجة ستشترونها على الإطلاق، لأنكم اشتريتموها نهارًا لا في الثالثة فجرًا أمام عملائكم.
من يتحمل المسؤولية حين تفشل خدمة «عالمية» في التعافي؟
غالبًا العميل نفسه، وهذا ما يُوجع. كل انقطاع سحابي يستدعي ردة الفعل التلقائية بإلقاء اللوم على «المزوّد الذي خذلنا». أحيانًا يكون ذلك منصفًا. لكن غالبًا لا يكون كذلك، لأن التدهور التدريجي المُتحكَّم فيه قرار نشر يملكه العميل. الخدمة المصممة جيدًا، حين تُقطع عن خلفية لا تستطيع الوصول إليها، تتراجع إلى حد أدنى قابل للاستخدام: تقدّم محتوى مخزّنًا مؤقتًا، وتُبقي عمليات الكتابة في طابور انتظار، وتُسقط ميزة غير أساسية مع إبقاء صفحة الدفع تعمل. أما الخدمة سيئة التصميم فتتجمد كليًا، لأن أحدًا لم يُقرر مسبقًا كيف يبدو «العمل بصيغة متدهورة». هذا الغياب عيب في الإعدادات على جانبكم أنتم. المزوّد قدّم المواد الخام لآلية التعافي؛ أما هل جمّعتموها في شيء يصمد فذلك يقع على عاتقكم. هذا بالضبط افتراض الاستمرارية الذي ينبغي لأي استراتيجية تقنية جادة أن تدفعه إلى العلن بدل تركه أسطورة متداولة. وفي أسواق تقود فيها برامج تحول رقمي طموحة كرؤية السعودية 2030 والاستراتيجية الوطنية للذكاء الاصطناعي في الإمارات، صار افتراض الاستمرارية شرطًا تنافسيًا لا رفاهية تُترك لوقت لاحق.
فلماذا لا يُجري أحد هذا الاختبار تقريبًا؟
لأن الحوافز مقلوبة. تمرين التعافي الحقيقي له نطاق أثر ظاهر ومالك محدد يتحمل اللوم إن ساءت الأمور. أما مخاطر تجاهله فمُشتتة ومؤجلة وقابلة للإنكار، وتقع على من يكون مناوبًا حين يُجري المزوّد الاختبار نيابة عنكم. ضعوا إحراجًا صغيرًا مؤكدًا الآن في مقابل إحراج كبير محتمل لاحقًا قد يمتصه شخص آخر، وستجدون أن معظم المؤسسات تختار «لاحقًا» بصمت. الإصلاح الهندسي سهل. الإصلاح التنظيمي أصعب: اجعلوا من يوقّع على عبارة «نحن مرنون» هو نفسه من يوقّع على دليل التشغيل الذي يُثبت ذلك، وضعوا بند البنود الأربعة حيث ينتمي: داخل العقد.
لذا فالسؤال الذي يجب توجيهه لأي فريق يصف بنيته بأنها مرنة قصير ومُحرج: متى كانت آخر مرة أغلقتم فيها منطقتكم الأساسية فعليًا وشاهدتم ما يحدث؟ إن كان الجواب أبدًا، فأنتم لا تملكون نظامًا متعدد المناطق. تملكون مخططًا بيانيًا، وفاتورة تنتظر أن تُقدَّم في أسوأ ساعة ممكنة. ادفعوا هذا السؤال إلى العلن قبل انطلاق أي مشروع، لأن دراسات الحالة التي تصمد أمام واقع الإنتاج هي تلك التي سحب فيها أحدهم الخيط عمدًا أولًا.
أسئلة شائعة
ما الذي تسبب في انقطاع AWS في منطقة us-east-1 في أكتوبر 2025؟
وفق الملخص الرسمي الذي نشرته AWS بعد الحادثة، تسبب سباق حالات (race condition) في الإدارة الآلية لسجلات DNS الخاصة بخدمة DynamoDB في منطقة us-east-1 في ترك نقطة النهاية الإقليمية لهذه الخدمة تُشير إلى سجل DNS فارغ، فعجز العملاء عن تحليله. ولأن أنظمة EC2 الأساسية تعتمد على DynamoDB، ترك تعافيها كمًا متراكمًا من حالة الشبكة يحتاج إلى تسوية، ما أخّر إطلاق نسخ جديدة لساعات. بدأ العطل في وقت متأخر من مساء 19 أكتوبر 2025 بتوقيت المحيط الهادئ (الساعات الأولى من 20 أكتوبر بالتوقيت العالمي المنسّق). كان العطل إقليميًا، لكن كثيرًا من الخدمات «العالمية» شعرت به لأنها ترسّخ حالتها في تلك المنطقة الواحدة، وهذه قراءة تحريرية وليست تصريحًا من AWS.
ما السبب المعتاد لسقوط نظام يُفترض أنه احتياطي أثناء انقطاع إقليمي؟
ليست الحوسبة عادة. غالبًا ما تكون حالة مشتركة لم يُصنّفها أحد كحرجة سلفًا: خدمة هوية أو مصادقة، أو لوحة تحكم توزّع الإعدادات، أو مخزن بيانات وصفية تقرأه كل الخدمات عند الإقلاع. هذه العناصر تعمل بصمت كل يوم، فنادرًا ما تظهر في مراجعات المرونة إلى أن تصبح المنطقة التي تستضيفها غير قابلة للوصول.
هل التدهور التدريجي مسؤولية مزوّد السحابة؟
لا. المزوّد يوفّر اللبنات الأساسية لآلية التعافي، لكن تقرير كيف تبدو الخدمة حين تتدهور مع بقائها قابلة للاستخدام، وضبط آليات التراجع التي تحقق ذلك، قرار تصميم يخص العميل. الخدمة التي تتجمد كليًا حين تُقطع عن خلفية لا تستطيع الوصول إليها تكشف عن فجوة في إعدادات الجانب المُشتري، لا مجرد انقطاع من طرف المزوّد.
مواضيع ذات صلة
- في أوبونتو 26.04 LTS، حزمة coreutils التي تعتمد عليها بنيتكم التقنية لم تعد GNU
- علاوة السيادة: لماذا تكسب حلول الذكاء الاصطناعي السيادي للمؤسسات الرهان على حرية الوصول لا على السرعة
- قضايا الأسرار التجارية تُحسم قبل سنوات من استقالة أي موظف. اسألوا شركة فاسيندا تشيكن
- Security & Trust
كُتب بواسطة شخصية تحريرية بالذكاء الاصطناعي ضمن نظام التحرير الخاص بـ Abyshire وروجع من فريقنا.