الملخص

  • وصف تقرير Cloudflare العام بعد الحادث ليوم 17 يوليو 2020 تغيير تكوين الشبكة في أتلانتا، ونافذة انقطاع رئيسية مدتها 27 دقيقة، وسقوط حوالي نصف حركة المرور في الذروة، وتأثير عالمي على العملاء جعل ضوابط هندسة حركة المرور الداخلية مشكلة توفر للعملاء.
  • سؤال المساءلة هو من الذي يتحكم في اختبار قواعد التوجيه، والنشر المرحلي، وتفضيل المسار، وضمانات الحد الأقصى للبادئة، وسلوك الأمان في العمود الفقري، ورسائل حالة العملاء، وسرعة التراجع، والدليل على أن سلامة النشر تغيرت بعد الحادث.
  • القضية ليست انقطاعًا سحابيًا عامًا. إنها قضية مرونة الشبكة لأن خدمات Cloudflare الطرفية، DNS، الأمان، توصيل التطبيقات، وتوجيه حركة المرور هي جزء من مجموعة الخدمة العامة واستمرارية الأعمال للمؤسسات الأخرى.
  • تتعامل هذه المقالة مع تقرير Cloudflare بعد الحادث كحساب حادث من طرف أول وتستخدم BGP، المرونة، SRE، NIST، CISA، ومصادر الحالة كسياق، وليس كدليل على جهاز التوجيه الخاص.
  • الدرس الدائم هو أن التغيير المرحلي للشبكة يجب أن يثبت، لا أن يعد فقط: يجب على المزود أن يظهر كيف يتم اختبار قاعدة توجيه واحدة، والحد منها، ومراقبتها، وتراجعها، ومنعها من التحول إلى انقطاع مشترك للعملاء.

لماذا تنتمي هذه القضية إلى ملف المخاطر والمساءلة

جعلت Cloudflare نشر قواعد التوجيه اختبارًا لمساءلة مرونة الشبكة لأن حادث 17 يوليو 2020 كشف سمة أساسية للاعتماد الحديث على السحابة: قرار هندسة حركة المرور الداخلي للمزود يمكن أن يصبح حدث توفر عام للعملاء الذين لم يروا التغيير أبدًا. ذكر حساب الحادث لـ Cloudflare على source: blog.cloudflare.com أن تغيير تكوين في أتلانتا تسبب في فقدان حركة مرور العمود الفقري، مع تشغيل الحادث الرئيسي من 21:12 UTC إلى 21:39 UTC وتأثير كبير على حركة المرور. هذا الحساب العام يعطي عمودًا واقعيًا واضحًا لطرح أسئلة المساءلة دون اختراع سجلات جهاز التوجيه الخاصة.

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

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

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

خلفية BGP من مركز التعلم Cloudflare على source: cloudflare.com، RFC 4271 على source: rfc-editor.org، و NIST SP 800-189 على source: csrc.nist.gov مفيدة لأنها تؤطر التوجيه بين النطاقات وتبادل حركة المرور المرن. ليست نتائج حول أجهزة التوجيه في يوليو 2020. إنها تساعد القراء على فهم لماذا التفضيلات المحلية، إعلانات المسار، توجيه حركة المرور، والعمود الفقري للمزود هي أسطح سيطرة وليست سباكة مجردة.

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

فشل قاعدة التوجيه يصبح انقطاع العميل عندما تكون الحافة بنية تحتية مشتركة

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

وثائق خدمة Cloudflare الخاصة على source: developers.cloudflare.com و source: developers.cloudflare.com تظهر مدى اتساع سطح السيطرة المواجه للعميل. وثائق Workers على source: developers.cloudflare.com ومعلومات التوصيل البيني للشبكة على source: cloudflare.com تظهر أن Cloudflare ليست مجرد مخزن موقع ويب مؤقت. إنها منصة حافة، بيئة تشغيل للمطورين، ومشارك في التوصيل البيني. تلك الصفحات ليست دليل حادث. إنها تشرح لماذا يعتمد العملاء بشكل معقول على إدارة التغيير الشبكي الداخلي لـ Cloudflare.

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

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

مواد Google SRE حول التعامل مع الحمل الزائد على source: sre.google وإدارة الحالة الحرجة على source: sre.google هي سياق مفيد لأنها تؤطر كيف تفشل الأنظمة الموزعة تحت الحمل، التغذية الراجعة، ومشاكل إدارة الحالة. حادث Cloudflare كان حدث تحكم شبكي، وليس حالة Google SRE. لكن مفردات SRE تساعد في طرح الأسئلة الصحيحة: ما الإشارة التي تمت مراقبتها، ما العتبة التي كانت مهمة، ما الاستجابة التلقائية الموجودة، ما القرار البشري المطلوب، وكيف تم التحقق من الإصلاح.

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

النشر المرحلي هو ضابط مساءلة، وليس مجرد تحسين هندسي

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

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

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

NIST SP 800-34 Rev. 1 على source: csrc.nist.gov و NIST SP 800-160 Vol. 2 Rev. 1 على source: csrc.nist.gov مفيدة هنا لأنها تحدد مفاهيم التخطيط للطوارئ والمرونة الإلكترونية. ليست أدلة توجيه. إنها تساعد في ترجمة هندسة الشبكة إلى واجبات مرونة: التوقع، التحمل، التعافي، التكيف، والتحقق. يجب أن يظهر تحليل ما بعد الحادث للمزود ليس فقط التعافي من حادث واحد، ولكن تكييف نظام النشر الذي سمح بالحادث.

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

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

سرعة التراجع تكون مرئية فقط عندما يكون الجدول الزمني دقيقًا

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

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

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

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

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

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

التوصيل البيني، النقل، وتصميم العمود الفقري جزء من ثقة العميل

حادث Cloudflare في يوليو 2020 يجلس على الحدود بين هندسة العمود الفقري الداخلي والنظام البيئي الأوسع للإنترنت. نادرًا ما يفحص العملاء تفاصيل التوصيل البيني والنقل، لكن هذه التفاصيل تشكل قابلية الوصول. PeeringDB على source: peeringdb.com يعطي سياقًا عامًا للنظام البيئي للتوصيل البيني. RIPE RIS على source: ris.ripe.net و RouteViews على source: routeviews.org يظهران أن مراقبة التوجيه العامة موجودة، حتى لو لم تستطع كشف كل قرار خاص بالمزود. إجراءات مشغلي MANRS على source: manrs.org و RFC 7908 على source: rfc-editor.org توفر مفردات تسرب المسار وأمن التوجيه ذات الصلة بالأحداث المجاورة.

لا يجب الخلط بين حادث يوليو 2020 وتسرب المسار في يونيو 2019 الذي حللته Cloudflare على source: blog.cloudflare.com. في 2019، كانت Cloudflare مزودًا متأثرًا يشرح تسرب مسار يشمل شبكات أخرى. في 2020، وصف تحليل ما بعد الحادث لـ Cloudflare مشكلة تكوين شبكة داخلية. الفرق مهم لأن خريطة المساءلة تختلف. لتسرب المسار، يمكن أن يشمل الإصلاح التحقق من الأصل، التصفية، مسؤولية مزود النقل، وأعراف النظام البيئي. لانقطاع قاعدة التوجيه الداخلي، يركز الإصلاح بشكل أكبر على إدارة التغيير للمزود، الاختبار، التفضيل المحلي، ضمانات الحد الأقصى للبادئة، ونصف قطر انفجار التحكم في حركة المرور.

نشرت Cloudflare مواد RPKI وأمن التوجيه مثل source: blog.cloudflare.com و source: blog.cloudflare.com. تلك المصادر تظهر الدعوة العامة لـ Cloudflare والمفردات التقنية حول أمن المسار. لا تثبت تلقائيًا إصلاح يوليو 2020. تساعد القراء على فهم لماذا يجب الحكم على المزود الذي يشارك بعمق في أمن التوجيه من خلال انضباط التغيير الشبكي القابل للتحقق بالإضافة إلى التعليم العام.

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

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

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

استمرارية العميل تعتمد على إثبات المزود، وليس ثقة المزود

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

نموذج 10-K لعام 2020 لـ Cloudflare على SEC source يوفر سياق مخاطر الأعمال للشركة، بينما مواد الثقة والامتثال لـ Cloudflare على source: cloudflare.com توفر سياق ضمان حاضر. إيداعات المستثمرين وصفحات الثقة ليست دليل إصلاح الحادث. تظهر أن التوفر، الأمان، وثقة العملاء مادية لنموذج الأعمال. هذا يجعل مساءلة الحوادث المفصلة عقلانية تجاريًا، وليس فقط مرغوبة أخلاقيًا.

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

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

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

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

الأدلة السلبية جزء من تحليل ما بعد الحادث المفيد للشبكة

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

الهدف هو منع العملاء من القيام بعمل مكلف في مسار مخاطر خاطئ.

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

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

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

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

يجب أن تتضمن دفاتر تشغيل العميل قرارات انقطاع حافة المزود

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

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

ينطبق نفس المنطق على DNS الثانوي وتصميمات multi-CDN. التكرار يمكن أن يقلل الاعتماد، لكنه يضيف تعقيد التكوين ويمكن أن يخلق مسارات فشل جديدة. إذا كان المزود الثانوي لا يعكس قواعد الأمان، سلوك التخزين المؤقت، تكوين TLS، مصادقة الأصل، والتسجيل، فقد يكون مسار تجاوز الفشل أقل أمانًا من الانقطاع. مساءلة المزود واستمرارية العميل يتفاعلان. يجب على Cloudflare جعل ضوابطها قوية؛ يجب على العملاء تحديد الخدمات التي تبرر تكلفة وتعقيد الاحتياطي المستقل.

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

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

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

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

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

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

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

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

الدرس الدائم هو جعل سلامة تغيير الشبكة قابلة للملاحظة

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

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

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

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

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

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