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

ملخص

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

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

في الساعة 09:47 UTC من 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 الخاص يقبل أنه كان يجب توقع الشرط.

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

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

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

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

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

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

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

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

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

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

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

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

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

• قد يستخدم العميل CDN واحدًا للوثيقة الجذرية وكل كائن أساسي.
• قد يستخدم العميل عدة CDNs لكنه يترك سكريبتًا أو خطًا أو صورة أو API أو شهادة أو مسار إعادة توجيه حاسمًا على مزود واحد.
• قد يشترك اثنان من CDNs المستقلين ظاهريًا في سحابة أصلية، أو مزود 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 و Registry و Pages، مما يظهر قيمة فصل مسارات الخدمة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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