الخلاصة

  • فتحت Cloudflare سجل الحادث عند 17:56:57 بالتوقيت العالمي وصنفت Tunnel أولاً كانقطاع كبير.
  • أبلغ عدة عملاء عن تدهور الأنفاق أو توقفها بالكامل، بما في ذلك تعذر الوصول إلى الموارد الخاصة.
  • حُددت المشكلة عند 18:28، وبدأت مراقبة الإصلاح عند 18:52، وأُعلن الحل عند 20:44.
  • حصرت الشركة لاحقاً التأثير المعروف في مجموعة فرعية من العملاء وقالت إن خدمات Cloudflare الأخرى لم تتأثر.
  • لم تعلن سبباً نهائياً أو عدداً للعملاء، وطلبت إعادة تشغيل cloudflared إذا استمرت الأعطال.

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

السجل العام لا يساوي مدة التوقف لدى كل مؤسسة

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

استغرق المسار المنشور قرابة ساعتين وثمان وأربعين دقيقة. لكنه لا يحدد مدة انقطاع أي عميل بعينه. لا يذكر السجل البلدان أو إصدارات الموصل أو نسبة الحركة أو التطبيقات التي تعذر الوصول إليها. كما لا يقدم سبباً جذرياً نهائياً.

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

إعادة التشغيل تجعل التعافي مسؤولية مشتركة

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

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

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

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

أربعة تنبيهات في يوم واحد لا تعني سبباً واحداً

يسجل النظام الرسمي في 28 يوليو أيضاً أخطاء في Durable الكيانات بغرب أميركا الشمالية، ومشكلات أداء شبكي في إسطنبول، وزيادة في أخطاء HTTP 530 في فرانكفورت. لكل سجل منتج ومنطقة وساعة ووصف مختلف.

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

القراءة المنضبطة أضيق: كان لخدمة Tunnel فشل خاص في الوصول، وتسلسل إصلاح خاص، وتعليمات إعادة تشغيل خاصة. أما التنبيهات الأخرى فهي سياق منفصل لليوم نفسه.

يجب أن تبدأ المراقبة من جهة المستخدم

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

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

لا تسمح المعلومات العامة بمقارنة تصميمات العملاء أثناء الحادث. لكنها تكفي لإثبات أن التحقق النهائي لا يمكن تفويضه بالكامل إلى مؤشر Cloudflare.

ما الذي ينبغي أن يجيب عنه التقرير اللاحق

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

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

توقف توقيت Cloudflare العام عند 20:44. أما توقيت العميل فلا يتوقف إلا عندما يستجيب المورد الخاص من جديد.

المصادر