الخلاصة

  • تقول Azure إن قيداً مؤقتاً على تحديثات أنظمة تشغيل البوابات انتهى، فعادت تحديثات كثيرة خلال وقت قصير. وكان تغيير سابق قد زاد أيضاً زمن معالجة عمليات الإعداد.
  • أثّر الحمل المشترك في عمليات إدارة عدة خدمات شبكية عبر مناطق متعددة. وفي بعض بوابات ExpressRoute تقدّم تحديث النسخة الاحتياطية التالية قبل اكتمال استعادة الإعدادات والمسارات.

أسهل وصف لانقطاع سحابي هو أن تحديثاً تسبب فيه. لكن مراجعة Azure لحدث 30 سبتمبر و1 أكتوبر تصف تفاعلاً أهم. فقد أوقف قيد مؤقت تحديثات نظام التشغيل لمجموعة من البوابات. وعندما انتهى القيد، استؤنف عدد كبير من التحديثات خلال فترة وجيزة. وفي الوقت ذاته، أطال تغيير منشور سابقاً زمن معالجة عمليات الإعداد في مستوى تحكم شبكي إقليمي مشترك. ازدادت الطلبات في اللحظة التي صار فيها إنجاز كل طلب أبطأ.

هذا ليس دليلاً على أن تحديثاً معيباً واحداً يفسر الحادث كله. تصف Microsoft زيادة في إعادة التشغيل وطلبات استرجاع الإعدادات تزامنت مع خدمة أبطأ؛ ولم تحمِ آليات الحد من المعدل وحماية الحمل القائمة المعالجة الحرجة بما يكفي. تحركت موجة التحديثات منطقةً تلو أخرى، ولذلك اختلفت أوقات التأثر. تسمي Azure خدمات منها ExpressRoute Gateway وApplication Gateway وAzure Firewall وBastion وVirtual WAN وVPN Gateway، في مناطق من الأمريكتين وأوروبا وآسيا والمحيط الهادئ وأفريقيا والشرق الأوسط. ولا تقدم المراجعة العامة حصراً لتأثير الحادث على كل عميل.

عطل في الإدارة قطع بعض الاتصالات أيضاً

تعلّق كثير من التأثير بعمليات الإدارة. لكن بعض بوابات ExpressRoute فقدت مؤقتاً اتصالها بالشبكات المحلية المرتبطة بها. وتقول Azure إن النسخة التي أعيد تشغيلها أثناء التحديث ربما وُسمت بأنها سليمة قبل استعادة إعداداتها وحالة التوجيه. عندئذ انتقل التحديث إلى النسخة الاحتياطية الأخرى. وإذا تعذر على النسختين استرجاع إعدادات المسارات المطلوبة، انقطع الاتصال.

بعد نحو 30 دقيقة من محاولات استرجاع الإعدادات غير الناجحة، طبقت البوابات المتأثرة آخر إعداد سليم محفوظ محلياً. هذه مدة المحاولات التي تصفها Microsoft، وليست ادعاءً بأن انقطاع كل عميل استمر 30 دقيقة. بدأ الحادث الإجمالي عند 20:30 بالتوقيت العالمي في 30 سبتمبر، وخُففت آخر موجة عند 02:15 في 1 أكتوبر. وتوضح Azure أن مدة الحادث العامة لا تساوي مدة تأثر كل عميل أو مورد.

ويبين التسلسل الزمني لماذا لم تكفِ إضافة السعة. رُصد تدهور ExpressRoute عند 20:43، ثم تدهور أوسع في مستوى التحكم عند 20:58. قدم إيقاف التحديثات الإضافية عند 21:45 وتحويل الحركة راحة مؤقتة، ولم تحسم محاولات إضافة الموارد المشكلة. وعند 23:55 ربط المحققون بطء معالجة الإعدادات بتراجع في الأداء. بدأ التراجع عن التغيير في منطقة واحدة عند 01:15 في 1 أكتوبر، وتحققت Microsoft من النتيجة قبل التوسع. وانتهى التأثير عند اكتمال التراجع في المناطق المتأثرة عند 02:15.

نافذة الصيانة لا تشرح كيفية تصريف التحديثات المؤجلة

تقول وثائق Azure إن تحديثات البوابات قد تشمل ترقيعات برمجية وتحديثات لمكونات الشبكة وإخراج أجهزة من الخدمة. ويمكن للعملاء اختيار نوافذ صيانة لبعض البوابات؛ وهذا يضبط التوقيت لكنه لا يثبت كيفية تصريف التحديثات المؤجلة بعد انتهاء التعليق. وتذكر مراجعة Microsoft تحسين الاستئناف المتدرج، وفحوصاً تؤكد استعادة الإعدادات والمسارات قبل تحديث النسخة الاحتياطية التالية، ومعالجة قيود التوسع، وتحسين الحد من المعدل وإسقاط الحمل. هذه إجراءات ومواعيد تقديرية منشورة، وليست تحققاً مستقلاً من اكتمالها جميعاً.

توصي إرشادات Microsoft للنشر الآمن بالتوسع التدريجي والتحقق من الصحة قبل كل مرحلة وإيقاف النشر عند ظهور مشكلة. والسؤال التشغيلي هنا أدق: هل تعني «سليمة» أن العملية أعيد تشغيلها، أم أن الإعدادات والمسارات اللازمة للخدمة استُرجعت وتحققت؟ لا تساعد الازدواجية إذا كانت النسخة التالية ترث الاعتماد نفسه على مستوى تحكم لم يتعافَ بعد.

وتقول Microsoft إن العملاء لم يكن بوسعهم منع هذا الحادث المحدد أو تقليل أثره. ويمكنهم مع ذلك حصر أحمال العمل التي تعتمد على كل بوابة، ومراقبة مسار البيانات لديها منفصلاً عن عمليات الإدارة، وضبط تنبيهات Service Health. تحسن هذه الخطوات الرصد والاستجابة، لكنها لا تحول خطة استعادة المزوّد إلى ضمان يتحكم فيه العميل.

المصادر: مراجعة Azure للحادث 7Q30-010؛ بوابات الشبكة الافتراضية لـExpressRoute؛ صيانة البوابات التي يتحكم فيها العميل؛ ممارسات النشر الآمن. إطار تحريري فقط: Heng Lu، الملاحظة 20.