الخلاصة

  • وقع انقطاع أكتوبر 2021 بعد بدء صيانة مخططة لتعزيز الحماية من هجمات حجب الخدمة، إلا أن المصادر لا تنسب الانقطاع نفسه إلى هجوم DDoS؛ فالتهديد كان دافعاً للتغيير، لا السبب التشغيلي للانقطاع.
  • قالت OVHcloud إن أمراً يتعلق بإعادة التوزيع من BGP إلى OSPF أدخل جدول الإنترنت بأكمله إلى بروتوكول التوجيه الداخلي، فامتلأ جدول OSPF وارتفع استهلاك الذاكرة والمعالج وتعطل توجيه IPv4، بينما ظل IPv6 قابلاً للوصول.
  • كانت هناك ضوابط اعتماد معلنة، تشمل مجلس التغييرات وخطة التنفيذ ومراجعة النظراء؛ لذا تتركز المساءلة على التحقق الدلالي، وحدود نطاق الضرر، ومراقبة الحالة الحية، وفعالية التراجع، لا على ادعاء أن التغيير لم يخضع للمراجعة.
  • كانت الاستعادة مرحلية: ظهرت مشكلة الإعداد قرابة 09:20 بتوقيت وسط أوروبا، وأُطفئ جهاز التوجيه المتضرر عند 10:18، وبدأت أولى الخدمات بالعودة عند 10:20، ثم أعلنت نهاية الأزمة التقنية عند 10:57.
  • تثبت الأدلة إخفاقاً واسع الأثر في قابلية الوصول عبر التوجيه، لكنها لا تثبت عدداً دقيقاً للعملاء أو الخدمات المتضررة، ولا فقدان بيانات أو حريقاً أو تدميراً مادياً، ولا خسارة مالية كلية، ولا أن النسخ واللصق كان السبب الجذري النهائي.

الدافع الأمني ليس سبب الانقطاع

في 13 أكتوبر 2021 بدأت OVHcloud تغييراً مخططاً في بنية التوجيه الإنتاجية. وكان الهدف المعلن تقوية الحماية من هجمات حجب الخدمة في فترة ازدادت فيها شدة الهجمات. يفسر ذلك سبب اختيار نافذة الصيانة، لكنه لا يغيّر السلسلة السببية التي عرضتها الشركة لاحقاً: أمر إعداد، وإعادة توزيع بين بروتوكولين، وتضخم في حالة التوجيه، وضغط على موارد مستوى التحكّم، وفشل في التقارب والتراجع.

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

كما أن كلمة «صيانة» لا تجعل الخطر روتينياً. التغيير في نقطة تعيد توزيع المسارات بين BGP وOSPF يمس العلاقة بين رؤية الإنترنت الخارجية وحالة الوصول الداخلية. والخطأ في هذا الحد لا يبقى بالضرورة محصوراً في سطر إعداد واحد؛ فقد يضيف عدداً ضخماً من المسارات إلى مجال داخلي لم يُصمم لاستيعابها، ويجبر أجهزة أخرى على معالجة تحديثات وتقارب متكرر، ويستهلك الموارد المطلوبة لإصلاح الحالة نفسها.

من أمر واحد إلى اختناق في مستوى التحكّم

وفق رواية OVHcloud، لم يفسر جهاز توجيه أمراً على النحو الصحيح. وكان الأمر يتصل بإعادة توزيع المسارات من BGP إلى OSPF. النتيجة المعلنة كانت إدخال جدول توجيه الإنترنت بأكمله إلى بروتوكول البوابة الداخلية. امتلأ جدول OSPF، وتعرّضت ذاكرة جهاز التوجيه ومعالجه لضغط شديد، وظهرت حلقة تقارب بين BGP وOSPF جعلت توجيه IPv4 غير قابل للتشغيل.

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

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

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

المراجعة كانت موجودة، لكن الإثبات التشغيلي لم يمنع النتيجة

قالت OVHcloud إن التغيير أُعد عبر مجلس استشاري للتغييرات، وخطة تنفيذ، ومراجعة من النظراء. يجب الحفاظ على هذا الواقع كما هو. لا تدعم الأدلة رواية أن مهندساً نفذ عملاً مرتجلاً بلا إشراف. وفي الوقت نفسه، لم تمنع هذه الآليات جدول الإنترنت من الوصول إلى النظام الداخلي، ولم تجعل التراجع البرمجي فعالاً عند الحاجة.

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

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

كان ينبغي أن يملك التغيير مظروفاً واضحاً: زيادة قصوى متوقعة في عدد المسارات، وعائلات بادئات محددة، وعدم حدوث نمو غير متوقع في قاعدة OSPF، وحدود مستقلة تمنع التغذية الراجعة، ومجموعة فحوص خارجية لقابلية الوصول. وإذا تجاوزت الحالة ذلك المظروف، يجب أن يتوقف التقدم قبل انتظار بلاغات العملاء.

تسلسل زمني لا يجوز اختزاله في رقم واحد

يضع السجل التفصيلي بداية التغيير عند 09:05 بتوقيت وسط أوروبا. وعند 09:18 جرى عزل BGP وتنفيذ تعديلات في الإعداد. ظهرت مشكلة إعداد الشبكة عند 09:20، وكُشف تدهور أداء جهاز التوجيه وصُعّد عند 09:21. وبحلول 09:30 كان التراجع قد فشل واتُّخذ قرار العزل المادي.

عند 10:18 أُطفئ جهاز التوجيه المتضرر. وعند 10:20 بدأت أولى الخدمات بالعودة بعد تقارب الشبكة، ثم اعتبرت OVHcloud الأزمة التقنية منتهية عند 10:57. كما وُجد تحديث تشغيلي سابق في اليوم نفسه استخدم توقيتين أكثر تقريباً: 09:12 للتدخل و10:15 للعزل. وللدقة، تمثل الرواية التفصيلية اللاحقة الأساس الأقوى، فيما يظل الملخص المبكر شاهداً على تطور الاتصال أثناء الحدث.

لا ينبغي تحويل هذه المراحل إلى مدة واحدة غير مشروطة. بدأت مشكلة قابلية الوصول عبر IPv4 قرابة 09:20، ولم تعد كل الخدمات في اللحظة نفسها، وبدأت أولى الخدمات بالعودة عند 10:20، واستمرت عملية الاستقرار حتى 10:57. قول إن «الخدمة عادت بعد ساعة» يصف أول عودة، لا نهاية الأزمة التقنية. وقول إن الانقطاع استمر حتى 10:57 يوحي خطأً بأن كل خدمة ظلت غائبة تماماً حتى ذلك الوقت.

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

تعطل IPv4 وبقاء IPv6 قابلاً للوصول

حافظت المصادر على حد تقني مهم: أصبح توجيه IPv4 غير قابل للتشغيل، بينما ظل IPv6 قابلاً للوصول. لا يعني ذلك أن كل خدمة تعتمد IPv6 عملت بلا عيب، ولا أن كل مسار IPv4 فشل بالطريقة نفسها. لكنه يمنع وصف الحادثة بأنها اختفاء كامل وغير مميز لكل اتصال.

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

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

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

أثر واسع بلا إجمالي مختلق

وصفت OVHcloud اضطراباً امتد عبر شبكتها وعدم قدرتها على معالجة حركة IPv4 بصورة صحيحة لمواقعها. ورصدت وسائل إعلام مستقلة تعذر الوصول إلى مواقع العملاء وخوادمهم وإلى موقع الشركة ومعلومات الحالة. وذكرت Numerama آلاف المواقع المتأثرة وقدمت أمثلة فرنسية عامة وتجارية.

تثبت هذه المشاهدات أثراً مادياً واسعاً على الوصول. لكنها لا تشكل جرداً مدققاً. لا توفر المصادر عدداً نهائياً للعملاء أو الخدمات أو أجهزة التوجيه أو البلدان أو المعاملات المتضررة، ولا حصيلة موحدة للخسائر. كلمة «آلاف» وصف منسوب إلى تقرير، وليست بديلاً عن سجل أثر متصالح مع بيانات العملاء.

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

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

فشل التراجع، ونجح العزل في استعادة السيطرة

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

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

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

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

ما لا يحسمه السجل

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

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

كذلك لا تثبت المصادر فقدان بيانات، أو حريقاً، أو تدميراً مادياً، أو إجمالي خسارة مالية، أو عدداً دقيقاً للمتضررين. ولا تثبت أن هجوماً لحجب الخدمة تسبب في الانقطاع، ولا أن التغيير غاب عنه مجلس التغييرات أو خطة التنفيذ أو مراجعة النظراء.

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

المصادر