الخلل الخفي في Fastly ومسؤولية حافة CDN المركزة

ملخص

• تقول Fastly أن نشرًا برمجيًا بدأ في 12 مايو 2021 أدخل خللاً خفيًا. في 8 يونيو، قام أحد العملاء بتغيير تكوين صحيح يحتوي على الظروف غير العادية التي نشطته. تسبب الفشل الناتج في عودة 85% من شبكة Fastly إلى الأخطاء. كشفت Fastly عن الاضطراب في غضون دقيقة واحدة وأعادت 95% من الشبكة إلى التشغيل الطبيعي في غضون 49 دقيقة.
• لم يتم تحديد الحادث علنًا على أنه تسرب لـ BGP أو فشل في الندية أو نقص في العبور أو هجوم إلكتروني أو إجراء عميل غير صالح. وجدت الملاحظات المستقلة أخطاء في التطبيق بينما كانت طبقة الشبكة تبدو طبيعية. هذا التمييز مهم: يمكن لشبكة CDN أن تتمتع بتنوع مادي وحمولة واسع لكنها تظل مرتبطة من خلال البرمجيات المشتركة ودلالات التهيئة وأنظمة النشر وعناصر التحكم في الاستعادة.
• النتائج بالنسبة للعملاء اعتمدت على الهندسة والاستعداد التشغيلي. كان لدى GOV.UK شبكة CDN ثانوية متاحة باستمرار وعملية تحويل موثقة، لكن انتشار DNS والمقايضات في وضع التدهور استهلكت وقتًا. كان لدى GitLab اعتماد جزئي فقط لخدمته الرئيسية، لكن اعتماد حزمة خارجية أعاق خط الأنابيب العادي الذي أراد المهندسون استخدامه لتجاوز CDN الفاشل.
• لذا فإن المساءلة تقع على جانبي حدود الخدمة دون أن تكون متساوية. سيطرت Fastly على كود المنصة والاختبار واحتواء النشر وعزل الفشل العالمي واستعادة المزود. سيطر العملاء على رسم خرائط الاعتماد والتسليم البديل وسعة الأصل وجاهزية DNS والشهادات وأدوات الاستعادة وتحمل تأثير الأعمال. يجب على مجالس الإدارة والجهات التنظيمية أن تطلب أدلة مختبرة من كلا المجالين، لا أن تقبل نسبة توفر عالية أو عقد مزود ثانٍ كدليل على المرونة.

تغيير صحيح واحد، مجال فشل عالمي واحد

في الساعة 09:47 بالتوقيت العالمي الموحد في 8 يونيو 2021، بدأ جزء كبير من الويب العام في إرجاع أخطاء. كانت مواقع الأخبار وخدمات التجارة ومنصات المطورين وخدمات البث والموقع المركزي للحكومة البريطانية من بين الضحايا المرئيين. بدا الحدث، من الخارج، وكأنه فشل العديد من المؤسسات غير المرتبطة في وقت واحد. من حيث البنية التحتية، كانت مرتبطة: تقاربت طلبات تلك الخدمات على شبكة توصيل المحتوى الخاصة بـ Fastly.

يقدم ملخص Fastly لانقطاع 8 يونيو السرد السببي المركزي. نشر برمجي بدأ في 12 مايو أدخل خللاً. بقي كامنًا حتى دفع أحد العملاء تغيير تكوين صحيح تحت الظروف المحددة المطلوبة لتفعيله. تقول Fastly أن 85% من شبكتها عادت بعد ذلك بأخطاء. حددت المراقبة الاضطراب العالمي في الساعة 09:48، بعد دقيقة واحدة من البداية. تبع أول تحديث عام للحالة في الساعة 09:58. حدد المهندسون تكوين العميل في الساعة 10:27، بدأ التعافي في الساعة 10:36، وكان 95% من الشبكة يعمل بشكل طبيعي في غضون 49 دقيقة من البداية. أشارت Fastly إلى تخفيف الحادث في الساعة 12:35 وحله في الساعة 12:44، ثم بدأت نشر الإصلاح الدائم للخلل في الساعة 17:25.

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

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

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

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

الخط الزمني يفصل بين الخطر الكامن والاضطراب النشط

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

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

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

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

كان هذا فشل تطبيق، وليس انهيار توجيه

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

ملاحظة الشبكة المعاصرة من Kentik رأت الحدث يبدأ في الساعة 09:49 UTC وقاست انخفاضًا بنحو 75% في حركة المرور الواردة من Fastly قبل أن تبدأ حركة المرور في العودة في الساعة 10:39. تحليل طبقة بطبقة من Cisco ThousandEyes لاحظ أخطاء خدمة بينما استمرت مسارات الشبكة في العمل ووصف أنماط تعافي مختلفة للعملاء مع تحول حركة المرور بين مزودي التوصيل. تحليل منتج لاحق من ThousandEyes ذكر التمييز مباشرة: ظهرت أخطاء 503 في طبقة التطبيق بينما بدت طبقة الشبكة طبيعية.

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

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

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

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

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

التوزيع والتركيز يمكن أن يتعايشا

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

البحوث المنشورة بعد الحادث تساعد في قياس الإعداد الأوسع دون إثبات حصة Fastly السوقية الدقيقة في ذلك اليوم. دراسة حول تبعيات خدمات الطرف الثالث عبر 50 دولة وجدت اعتمادًا واسعًا على مزودي DNS وCDN وسلطة الشهادات الخارجيين، مع تباين كبير حسب الدولة ومجموعة مزودين مركزة للغاية. دراسة أخرى، نظرة أولى على توحيد مزودي DNS واستضافة الويب، وجدت أن Cloudflare وAmazon وAkamai وFastly وGoogle استضافت مجتمعة حوالي 62% من صفحات الفهرس في أعلى 10,000 Tranco في قياسها ووفرت أغلبية الموارد الخارجية للعديد من المواقع.

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

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

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

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

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

GOV.UK كان لديه نسخة احتياطية وما زال يعاني من انقطاع

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

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

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

هذا ما تبدو عليه المرونة الحقيقية: خيار بتكاليف وتحولات حالة وحكم وتأخير. البديل قلل خطر انقطاع طويل. لم يجعل التحويل فوريًا أو خاليًا من العواقب. كشف الحادث أيضًا عن اعتماد على اتصال المستخدم. صفحة الخطأ 503 العامة من Fastly كانت خارج سيطرة محتوى GOV.UK وكانت دون معايير الخدمة للمعلومات العامة المفيدة.

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

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

GitLab وجد اعتمادًا داخل مسار التعافي

سجل حادثة الإنتاج العام لـ GitLab يظهر هندسة مختلفة وفشلًا مختلفًا. خدم Fastly أصول gitlab.com، لذا كان الموقع الرئيسي متدهورًا بشدة للمستخدمين الذين تفتقر متصفحاتهم إلى JavaScript والصور المخبأة. كان about.gitlab.com، حيث كان Fastly نقطة الدخول الأولى، غير متاح تمامًا. استمرت واجهات API وGit وسجل الحزم والصفحات، مما يظهر قيمة فصل مسارات الخدمة.

في الساعة 10:18 UTC، أعد مهندسو GitLab طلب دمج لاستبدال CDN المستخدم للأصول. لم يتمكنوا من تطبيقه عبر خط الأنابيب العادي لأن صورة في ذلك الخط الأنابيب حاولت تثبيت حزمة من مستودع خارجي تأثر أيضًا بانقطاع Fastly. آلية التعافي المقصودة ورثت نفس الحدث الخارجي من خلال اعتماد لم يكن إعداد CDN الذي كانوا يغيرونه.

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

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

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

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

التعافي يمكن أن يحول كفاءة المخبأ إلى ضغط على الأصل

عادةً ما تحمي CDN الأصل من الكثير من حمل الطلبات. قالت GOV.UK أن ما يقرب من 93% من طلباتها كانت تخدم من المخبأ. توثيق الحماية لـ Fastly يصف النمط العادي: خوادم POP الحافة تخدم الكائنات المخبأة، ودرع مخصص يمكنه دمج الأخطاء قبل أن تصل إلى الأصل. تحسن الهندسة الأداء ويمكن أن تقلل حركة مرور الأصل بشكل حاد.

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

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

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

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

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

متعدد CDN هو نموذج تشغيل، وليس مربع اختيار مشتريات

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

تصميم متعدد CDN قابل للتنفيذ له ثماني خصائص صعبة على الأقل.

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

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

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

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

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

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

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

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

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

استجابة Fastly كانت سريعة، لكن الطمأنينة العامة كانت ضيقة

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

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

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

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

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

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

السجل الاقتصادي جعل الموثوقية قضية حوكمة

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

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

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

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

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

المساءلة مشتركة، لكنها غير مبهمة

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

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

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

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

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

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

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

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

ما يجب أن تطلبه مجالس الإدارة بعد فشل حافة كامن

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

للمزود، يجب أن تجيب الأدلة على أسئلة ملموسة:

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

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

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

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

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

الدرس الدائم هو حول التعافي المستقل

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

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

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

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

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

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