ملخص
- ذكر تقرير ما بعد الحادث الصادر عن Cloudflare بتاريخ 12 يونيو 2025 أن انقطاع الخدمة أثر على Workers KV والمنتجات التابعة له بسبب اضطراب لدى مزود سحابي طرف ثالث. يجب أن تُنسب قائمة المنتجات المتأثرة وشرح التبعية إلى تقرير Cloudflare الخاص.
- سجل حالة المزود الأولي مهم، لكنه لا يلغي مسؤولية Cloudflare عن التصميم الداخلي للتبعيات، والتواصل مع العملاء، والتشغيل المنخفض المستوى، والإثبات على أن أعمال تقليل التبعيات المخطط لها قد اكتملت.
- مشكلة المسؤولية هي إعادة توصيل مجالات الفشل المخفية. قد يختار العملاء Cloudflare جزئيًا للتنويع بعيدًا عن مزود آخر، ولكن قد يظل منتج Cloudflare معتمدًا على مكون سحابي تابع لطرف ثالث، ما لم يتم الكشف عن التبعية أو عزلها أو تصميمها للتدهور بأمان.
- Workers KV هي أداة تخزين ابتدائية للمطورين. عندما تتعطل، قد تفشل التطبيقات النهائية وسير عمل الوصول وأدوات الأمان وخدمات الشركات الصغيرة بطرق لم يتمكن العملاء من الاستعداد لها.
- يجب أن يُظهر ملف الإصلاح الموثوق به رسم خرائط التبعيات، ووضوح المنتجات المتأثرة، وجودة إشعار العملاء، وإعادة تصميم التبديل، وسلوك الوضع المنخفض، وتسلسل الاسترداد، واختبارات المرونة، والأدلة اللاحقة على أن الالتزامات المقطوعة في تقرير ما بعد الحادث قد تم الوفاء بها.
التبعيات المخفية تعيد توصيل مجالات الفشل
تقرير ما بعد الحادث الخاص بـ Cloudflare،انقطاع خدمة Cloudflare في 12 يونيو 2025، هو المصدر الرئيسي لخدمات Cloudflare المتأثرة، وشرح تبعية Workers KV، والتزامات المعالجة. توفرصفحة الحالةلـ Cloudflare وسجل الحالةالسياق العام للحوادث. الدرس العام ليس مجرد أن الخدمة قد انقطعت. بل هو أن مزودًا قد يعتبره العملاء طبقة مرونة مستقلة يمكن أن يعتمد هو نفسه على مزود آخر بطريقة تعيد توصيل مجالات الفشل.
هذه إعادة التوصيل هي مشكلة المسؤولية. قد يستخدم العميل Cloudflare للأداء والأمان والحوسبة الطرفية وضوابط الوصول أو خدمات التطوير. قد يستخدم العميل أيضًا مزودًا سحابيًا فائق النطاق في مكان آخر. إذا كان منتج Cloudflare يعتمد داخليًا على نفس المزود، فقد تكون بنية العميل أقل تنوعًا مما يعتقد. يرى العميل مزودين؛ قد يحتوي مسار الفشل على تبعية مشتركة.
هذا لا يعني أن التبعيات الخارجية غير مسؤولة افتراضيًا. تم بناء الخدمات السحابية الحديثة من العديد من المكونات والمزودين والمناطق وواجهات برمجة التطبيقات وأنظمة التخزين وخدمات الهوية والأدوات التشغيلية. السؤال هو ما إذا كانت التبعية مفهومة ومعزولة ومُبلغ عنها ومُصممة للفشل بأمان. التبعية المخفية التي يمكن أن تعطل سير العمل الحرج للعملاء تستحق ملفًا عامًا أقوى من الأدلة.
لذلك يجب قراءة تقرير ما بعد الحادث لـ Cloudflare كدليل من المزود النهائي. يشرح أنظمة Cloudflare الخاصة من وجهة نظر Cloudflare. توفرتحديث حالة Google Cloud حول الاضطراب في 12 يونيووتقرير حادثة Google Cloudالسياق الأولي. يساعد الملف الأولي في شرح الحدث الأوسع، لكنه لا يجيب على جميع أسئلة عملاء Cloudflare. ظلت Cloudflare تسيطر على تصميم تبعية منتجها وتواصلها مع العملاء.
هذا الفصل مهم. إذا اعتُبر المزود الأولي هو القصة بأكملها، تختفي واجبات الاستمرارية الخاصة بـ Cloudflare. إذا تم إلقاء اللوم على Cloudflare كما لو أنها تسببت في الحادث الأولي، فإن هيكل التبعية يُساء فهمه. تقع مسألة المسؤولية بين هذين النقيضين: على ماذا تعتمد Cloudflare، وما الذي فشل عندما فشلت تلك التبعية، وماذا عرف العملاء، وما الذي تغير بعد ذلك؟
Workers KV هي أداة تخزين ابتدائية، وليس تفصيلًا ثانويًا
تصفوثائق Workers KVخدمة تخزين من نوع مفتاح-قيمة يستخدمها المطورون. تُظهروثائق Cloudflare Workersووثائق API تشغيل Workers KVلماذا الخدمة مهمة للتطبيقات المبنية على الحافة. يمكن أن يحتوي KV على تكوينات، وبيانات متعلقة بالجلسات، ومفاتيح الميزات، وبيانات التطبيق، وقواعد الوصول، والبيانات الوصفية المخزنة مؤقتًا، وقيم أخرى قد يعتبرها المطورون عالية التوفر.
عندما تتعطل أداة تخزين ابتدائية، يمكن أن يظهر الفشل بطرق عديدة في النهاية. قد يتم تحميل موقع ويب لكنه يفقد التخصيص. قد تفشل أداة وصول في استرداد حالة السياسة. قد يفتقر منتج أمان إلى بيانات التكوين. قد يكون تطبيق شركة صغيرة غير قادر على خدمة حالة العميل. قد يرى مشغل SaaS أخطاء في عامل يعتمد على KV. قد لا يعرف المستخدم أن KV متورط؛ فهو يرى فقط فشل التطبيق.
هذا هو سبب أهمية الوضوح بشأن المنتجات المتأثرة. يتحكم تقرير ما بعد الحادث لـ Cloudflare في القائمة العامة للخدمات المتأثرة. لا ينبغي لمقال مسؤول أن يستنتج تعطلاً لمنتجات لم تحددها Cloudflare. كما لا ينبغي له معاملة جميع منتجات Cloudflare على أنها متأثرة بنفس القدر. يحتاج العملاء إلى فئات منتجات وتبعيات محددة لتحديد ما إذا كانت بنيتهم الخاصة قد تعرضت للخطر.
تحمل الخدمات الموجهة للمطورين عبء إشعار خاص. قد يكون المطور قد صمم تطبيقًا بافتراض خصائص الخدمة الموثقة من Cloudflare. إذا كشف انقطاع عن تبعية مخفية، فقد يحتاج المطور إلى تعديل البنية، وسلوك التراجع، ومعالجة الأخطاء، والتواصل مع العملاء. يجب أن يوفر تقرير ما بعد الحادث من المزود تفاصيل كافية لمراجعة التصميم دون الكشف عن التفاصيل الداخلية الحساسة التي تخلق مخاطر جديدة.
يُظهر Workers KV أيضًا كيف يمكن لتجريدات المزودين إخفاء تركيز الحالة. قد تبدو واجهة برمجة تطبيقات بسيطة للمفتاح-القيمة بدون خادم وموزعة. لكن التنفيذ الأساسي قد لا يزال يعتمد على أنظمة تحكم معينة، وخدمات بيانات وصفية، ومستويات تخزين، ومزودين خارجيين، أو قرارات تكرار. لا يحتاج العملاء إلى كل أسرار التنفيذ، لكنهم بحاجة إلى معرفة ضمانات الخدمة الهامة عند فشل المزود.
الفشل الأولي لا يلغي مسؤوليات التصميم النهائية
توفر إرشادات الموثوقية من Google Cloud،إطار العمل المعماري: الموثوقية، سياقًا عامًا لتصميم الأنظمة التي تتحمل الأعطال.ركيزة الموثوقية في Well-Architectedمن AWS وإرشادات الموثوقية من Azure Well-Architectedتوضح نفس النقطة المشتركة: التصميم المرن يتطلب فهم التبعيات، وأنماط الفشل، وأهداف الاسترداد، والمقايضات.
هذه الأطر العامة ليست استنتاجات حادثة تتعلق بـ Cloudflare. إنها مفيدة لأنها تحدد سؤال التصميم. إذا قدم مزود خدمة يعتبره العديد من العملاء بنية تحتية، يجب على المزود أن يقرر أي التبعيات مقبولة، وأيها يتطلب عزلاً، وأيها يتطلب تبديلاً، وأيها يمكن أن يتدهور. يختبر فشل طرف ثالث هذه الاختيارات.
تشمل واجبات المزود النهائي رسم خرائط التبعيات، والعزل، وتصميم التراجع، والتواصل حول الحالة، وتسلسل الاسترداد. إذا فشلت خدمة طرف ثالث، يجب أن يعرف المزود النهائي أي المنتجات الداخلية تعتمد عليها، وما هي الأعراض التي ستظهر للعملاء، وما إذا كان وضع القراءة فقط أو الوضع المنخفض ممكنًا، وما إذا كان هناك تبديل، وكيفية إبلاغ العملاء بما تأثر. هذه الواجبات موجودة حتى عندما يكون المزود الأولي هو من تسبب في الاضطراب الأولي.
هذا لا يعني أن كل منتج نهائي يجب أن يكون مستقلاً عن أي تبعية خارجية. سيكون ذلك غير واقعي. بعض التبعيات مقصودة ومبررة اقتصاديًا. مستوى المسؤولية هو التناسب. إذا كانت التبعية يمكن أن تعطل خدمة يستخدمها العملاء للاستمرارية، يجب على المزود تصميم تدهور آمن أو أن يكون صريحًا بشأن الحدود. كلما كانت الخدمة أكثر أهمية، كلما استحق العملاء أدلة أكثر.
تقرير ما بعد الحادث العام لـ Cloudflare قيم لأنه يعترف بالتبعية والتزامات المعالجة. سؤال المتابعة للمسؤولية هو الإنجاز. هل تم الانتهاء من خطوات تقليل التبعيات؟ هل تم اختبار مسارات التبديل؟ هل تم إعادة تصميم المنتجات المتأثرة لتتدهور بشكل أكثر أمانًا؟ هل تلقى العملاء إرشادات معمارية؟ يبدأ تقرير ما بعد الحادث ملف الإصلاح. لا يكمله.
الوضع المنخفض هو وعد للعميل
غالبًا ما يركز تصميم الموثوقية على الاستعادة الكاملة. يحتاج العملاء أيضًا إلى أوضاع منخفضة. قد تستمر خدمة لا يمكنها كتابة البيانات في تقديم القراءات. قد يستمر متجر سياسات لا يمكنه التحديث في تطبيق آخر تكوين صحيح معروف. قد تعيد منصة تطوير لا يمكنها الوصول إلى تبعية أخطاء صريحة بدلاً من المهلات. قد يحدد نظام الحالة بسرعة واجهة برمجة التطبيقات المتأثرة. الوضع المنخفض هو الفرق بين الارتباك الكامل والتقييد المتحكم به.
الفصل من كتاب Google SRE حولالتعامل مع الحمل الزائدذو صلة لأن الحمل الزائد وضغط التبعيات يجبران الأنظمة على تقليل الحمل، والحفاظ على العمل ذي الأولوية، والفشل بشكل متوقع. الفصل حولإدارة الحالة الحرجةذو صلة لأن تبعيات الحالة يصعب نقلها، وتخزينها مؤقتًا، واستعادتها. Workers KV هي خدمة حالة؛ يجب أن يأخذ تصميم الفشل في الاعتبار أنه لا يمكن دائمًا إعادة حساب الحالة على الفور.
بالنسبة للعملاء، يجب أن يكون الوضع المنخفض جزءًا من توقع المنتج. إذا كان KV غير متاح أو متعطل، ماذا يجب أن يفعل التطبيق؟ هل يمكنه تخزين أحدث القيم المعروفة مؤقتًا؟ هل يجب أن يخدم تكوينًا قديمًا؟ هل يجب أن يفشل في وضع الإغلاق لسياسة الأمان؟ هل يجب أن يفشل في وضع الفتح لعرض المحتوى؟ هل يجب على المطور بناء تخزين ثانوي؟ يمكن لـ Cloudflare تقديم وثائق ودروس من الحوادث تساعد العملاء في اتخاذ هذه القرارات.
يتفاعل الوضع المنخفض الداخلي للمزود مع الوضع المنخفض لتطبيق العميل. قد تصمم Cloudflare KV ليتدهور بطريقة معينة. قد يتعامل المطور مع هذا السلوك أو لا. إذا شرح تقرير ما بعد الحادث نمط الفشل بوضوح، يمكن للمطورين تحسين تصميمهم. إذا كان التقرير غامضًا، يجب على كل عميل تخمين ما يجب تغييره.
وبالتالي، فإن مستوى المسؤولية ليس فقط "استعادة أسرع". إنه "جعل الفشل قابلاً للقراءة". الفشل القابل للقراءة له أعراض معروفة، ورسائل حالة، وسلوك خطأ، وإرشادات للعملاء، وتوقعات استرداد. أعطال التبعيات المخفية ضارة جزئيًا لأنها غير قابلة للقراءة حتى يشرحها تقرير ما بعد الحادث.
الشركات الصغيرة والمتوسطة ترث بنية المزود دون رؤيتها
غالبًا ما تستخدم الشركات الصغيرة والمتوسطة البنية التحتية السحابية على وجه التحديد لأنها لا تستطيع بناء الموثوقية العالمية بنفسها. تعتمد على المزودين لإدارة التعقيد. هذا يجعل خطر التبعية المخفية مهمًا بشكل خاص. قد يكون لدى الشركة الكبيرة فرق مخاطر المزودين، ومراجعات معمارية، وتصميم متعدد المزودين. قد يقرأ مطور صغير وثائق المنتج، ويثق في المزود، ويبني.
إذا أثر انقطاع Workers KV على تطبيق شركة صغيرة، فقد لا يكون لديها طبقة تخزين ثانية جاهزة. قد لا تعرف ما إذا كان الفشل ناتجًا عن كودها، أو Cloudflare، أو مزود أولي، أو DNS، أو المصادقة، أو شبكة العميل. قد لا يكون لديها موظفون لتحليل تقرير ما بعد حادث معقد. يصبح حالة المزود والتواصل معه هو استجابة الشركة للحوادث.
NIST SP 800-34 Revision 1،دليل التخطيط للطوارئ للأنظمة الفيدرالية للمعلومات، هو مصدر عام للاستمرارية، لكن درسه الأساسي ينطبق: تحتاج المنظمات إلى تخطيط للطوارئ لاضطرابات النظام. بالنسبة للشركات الصغيرة والمتوسطة، يمكن أن تجعل إرشادات المزود هذا التخطيط ممكنًا. يجب على مزودي الخدمات السحابية تقديم نماذج عملية: استراتيجية التخزين المؤقت، اعتبارات متعددة المناطق، تصدير البيانات، إدارة الفشل، الاشتراك في الحالة، وطرق الاختبار.
NIST SP 800-160 Volume 2 Revision 1،تطوير أنظمة مرنة إلكترونيًا، يعرف المرونة بأنها القدرة على التوقع والمقاومة والاسترداد والتكيف. انقطاع التبعية المخفية هو اختبار للمرونة لأنه يتساءل عما إذا كان النظام يمكنه التكيف عندما يفشل مزود تحت المزود. تعتمد مرونة العميل على شفافية المزود.
توفرمورد مرونة البنية التحتية الحيويةمن CISA إطارًا عامًا للتبعيات النظامية. حتى عندما لا تكون خدمة التطوير في حد ذاتها بنية تحتية حيوية لكل عميل، فإن النموذج مهم: قد تعتمد العديد من الخدمات الصغيرة على نفس مجال الفشل المخفي. يمكن أن ينتشر الانقطاع عبر شركات لم تكن تعلم أنها تشارك التبعية.
التواصل حول الحالة يجب أن يفصل طبقات المنتجات
يجب أن يكون التواصل حول الحالة في مزود متعدد المنتجات متدرجًا. العميل الذي يستخدم CDN الأساسي، والأمان، والعاملين، وKV، والوصول، والصفحات، أو خدمات أخرى يحتاج إلى معرفة أي طبقة متأثرة. إذا كانت لغة الحالة واسعة جدًا، يشعر العملاء غير المتأثرين بالذعر. إذا كانت ضيقة جدًا، يفوت العملاء المتأثرون الاتصال. إذا كانت تسمي فقط المزود الأولي، قد لا يفهم العملاء أي منتجات Cloudflare متأثرة.
توفر صفحة حالة Cloudflare وسجلها سياق قناة الحالة. يوفر تقرير ما بعد الحادث الشرح الأعمق. يجب أن يتوافق الاثنان. يجب أن تحدد تحديثات الحالة المنتجات المتأثرة، وأعراض العميل، وتقدم التخفيف، وما إذا كان الاسترداد جزئيًا أم كاملاً. يجب أن يشرح تقرير ما بعد الحادث السبب الجذري، وهيكل التبعية، والجدول الزمني، والتأثير، والتزامات الإصلاح. يحتاج العملاء إلى الإصدارات في الوقت الفعلي والمراجعة.
التمييز بين منتجات CDN/الأمان الأساسية والمنتجات التي حددتها Cloudflare على أنها متأثرة مهم. Cloudflare منصة واسعة. لا ينبغي تفسير فشل Workers KV تلقائيًا على أنه فشل لكل خدمة Cloudflare. على العكس، العملاء الذين يستخدمون منتجًا تابعًا لا ينبغي عليهم استنتاج التأثير من إشعار منصة عام. دقة طبقة المنتج هي فحص ثقة.
يساعد التواصل الجيد حول الحالة أيضًا العملاء في كتابة إشعاراتهم الخاصة. قد يحتاج مشغل SaaS المبني على Cloudflare إلى شرح تدهور الخدمة لعملائه. يمكنه فعل ذلك بدقة أكبر إذا قدمت Cloudflare معلومات محددة حول المنتجات المتأثرة والجدول الزمني. إذا كانت حالة Cloudflare غامضة، تصبح الإشعارات النهائية غامضة أيضًا. ينتشر عدم اليقين.
يجب أن يتناول تقرير ما بعد الحادث العام أيضًا اكتشاف العميل. ما الأخطاء التي كان سيراها العملاء؟ أي واجهات برمجة تطبيقات أو منتجات تعطلت؟ ما السجلات التي يمكن للعملاء استخدامها لتأكيد التأثير؟ هل تأثرت متانة البيانات أو اتساقها، أم التوفر بشكل أساسي؟ إذا لم يتمكن الملف العام من الإجابة على جميع الأسئلة، فيجب أن يقول أين يمكن للعملاء البحث عن مزيد من التفاصيل.
يجب أن تكون خرائط التبعيات موجهة للعملاء بشكل محكوم
لا يمكن للمزودين نشر كل خريطة تبعية داخلية. سيخلق ذلك مخاطر أمنية وتنافسية. لكن يمكنهم نشر معلومات تبعية محكومة تساعد العملاء في تقييم مجالات الفشل. على سبيل المثال، يمكن لمنتج توثيق ما إذا كان يعتمد على مناطق سحابية خارجية، وما إذا كان التكرار متعدد المناطق موجودًا، وما أنماط الفشل التي يجب على العملاء التخطيط لها، وما أهداف مستوى الخدمة التي تستبعد أعطال المزود الأولي.
هذه ليست مجرد شروط قانونية. إنها معلومات معمارية. العميل الذي يصمم من أجل المرونة يحتاج إلى معرفة ما إذا كان اختيار Cloudflare بالإضافة إلى مزود سحابي آخر ينوع حقًا مخاطرة معينة. إذا كان Cloudflare Workers KV يعتمد على مزود طرف ثالث في مسار ذي صلة، يجب على العملاء فهم الآثار المعمارية على مستوى مفيد. وإلا، فقد يبني العملاء عن غير قصد بنى مترابطة.
يمكن تحديد أولويات شفافية التبعية. يمكن للوثائق العامة وصف البنية العامة وأنماط الفشل. يمكن لوثائق الثقة للمؤسسات تقديم مزيد من التفاصيل تحت ضوابط مناسبة. يمكن لصفحات الحالة الكشف عن تبعيات محددة للحادثة عندما تصبح ذات صلة. يمكن لتقارير ما بعد الحادث شرح ما تغير دون كشف التفاصيل الداخلية الحساسة. الهدف هو معلومات كافية لتصميم العميل، وليس رسمًا تخطيطيًا داخليًا كاملاً.
حادثة يونيو 2025 قيمة لأنها جعلت التبعية مرئية بعد وقوعها. سؤال الإصلاح هو ما إذا كانت التبعية أصبحت مرئية بشكل كافٍ قبل الحدث التالي. لا ينبغي للعملاء أن يحتاجوا إلى انقطاع لمعرفة أن مزودين مرتبطان في نموذج الفشل الخاص بهم. يجب على المزود جعل خيارات التبعية الهامة قابلة للقراءة مسبقًا.
الشكوك المتبقية ومسألة المسؤولية
يترك الملف العام عدة شكوك. لا يقدم التأثير الكامل لكل عميل لتعطل Workers KV. لا يكشف كامل تصميم التبعية الداخلي لـ Cloudflare قبل الحادثة. لا يتحقق بشكل مستقل من أن كل التزام بتقليل التبعية قد تم الوفاء به. لا يثبت ما إذا كان كل عميل لديه معلومات معمارية كافية قبل الانقطاع لتقييم مجالات الفشل المشتركة.
هذه الشكوك لا تجعل المسؤولية مستحيلة. إنها تحدد ما يجب على العملاء والمراقبين البحث عنه بعد ذلك. سيطرت Cloudflare على تصميم تبعية Workers KV، والتواصل حول المنتجات المتأثرة، وسلوك الوضع المنخفض، وتسلسل الاسترداد، والتزامات الإصلاح. سيطر Google Cloud على اضطرابه الأولي وتقارير الحالة الخاصة به. سيطر العملاء على سلوك التراجع لتطبيقهم فقط بالقدر الذي كان فيه سلوك المنتج ونموذج التبعية مرئيًا.
سؤال المسؤولية هو ما إذا كان الانقطاع قد قلل من خطر التبعية المخفية في المستقبل. هل قامت Cloudflare بتخطيط التبعية بوضوح؟ هل أزالت أو عزلت مسار الفشل؟ هل حسنت التبديل؟ هل حدثت وثائق العملاء؟ هل اختبرت التصميم الجديد في ظروف فشل أولي؟ هل شرحت ما يجب على العملاء فعله بشكل مختلف؟ هل أظهرت سجلات الحالة اللاحقة سلوكًا محسنًا؟
يجب أن تستند الإجابة على الأدلة. البيان بأن المرونة قد تحسنت مفيد فقط إذا كان بإمكان العملاء رؤية أي فئة من المرونة قد تغيرت. هل تحسن توفر القراءة؟ هل تحسن توفر الكتابة؟ هل انخفضت تبعية المنتج؟ هل انخفض وقت الاسترداد؟ هل أصبح الوضع المنخفض أكثر أمانًا؟ هل أصبح التواصل حول الحالة أسرع؟ هذه أسئلة قابلة للقياس.
الدرس النهائي هو التنوع مع الدليل
غالبًا ما ينوع عملاء الخدمات السحابية عن طريق اختيار مزودين متعددين. تعمل هذه الاستراتيجية فقط إذا كانت التبعيات الداخلية للمزودين لا تعيد توصيل نفس مجال الفشل بصمت. تذكرنا حادثة Cloudflare في يونيو 2025 بأن التنوع يجب أن يكون مثبتًا وليس مفترضًا. قد يرى العميل Cloudflare و Google Cloud كخيارين منفصلين؛ قد تظل التبعية الداخلية تربطهما لمسار منتج معين.
هذا لا يعني أنه يجب على العملاء الشك في جميع التجريدات. التجريدات هي ما يجعل الخدمات السحابية قابلة للاستخدام. هذا يعني أنه يجب على المزودين أن يكونوا واضحين بشأن خصائص المرونة للتجريدات التي يبيعونها. إذا كانت الخدمة موزعة عالميًا، يجب على العملاء فهم الأجزاء الموزعة عالميًا وتلك التي تعتمد على أنظمة أضيق. إذا كانت الخدمة تستخدم بنية تحتية خارجية، يجب على العملاء فهم ما إذا كانت هذه التبعية يمكن أن تعطلهم.
بالنسبة لـ Cloudflare، فإن مستوى المسؤولية بعد الانقطاع ليس الكمال. إنه دليل التعلم: رسم خرائط تبعية أوضح، وأوضاع منخفضة أكثر أمانًا، وتقليل التبعية حيث وعد، وتبديل أقوى، وخصوصية حالة أفضل، وإرشادات للعملاء تساعد المطورين على تصميم تطبيقات مرنة. بالنسبة للعملاء، الدرس هو أن يسألوا ليس فقط "أي مزود أستخدم؟" بل "ما مجالات الفشل التي يشاركها مزودي؟"
ينتمي الانقطاع إلى سلسلة عن المخاطر والمساءلة لأنه يكشف عن مخاطر سحابية حديثة خفية. يمكن للمزودين بيع المرونة بينما يعتمدون على مزودين آخرين. يمكن أن يكون هذا معقولاً، لكن يجب أن يكون محكومًا. الاستمرارية ليست مجرد مسألة أرقام التوفر. إنها مسألة أي التبعيات ستفشل معًا وإثبات أن الفشل التالي سيكون أصغر.
بنية العميل يمكن أن تكون خاطئة لأسباب عقلانية
يمكن للعملاء اتخاذ خيارات تصميم عقلانية بناءً على المعلومات المتاحة ومع ذلك يساء فهم مجال الفشل. قد يضع المطور منطق التطبيق على Cloudflare Workers، ويستخدم Workers KV للتكوين أو الحالة، ويستضيف خدمات أخرى على Google Cloud لأنه يبدو أنه يوزع المخاطر. إذا كان Workers KV يعتمد على مسار Google Cloud لعملية حرجة، فقد تكون البنية أكثر ترابطًا مما أراده المطور. الخطأ ليس غباءً. إنه نقص معلومات عن التبعية.
لهذا السبب وثائق المزود مهمة. غالبًا ما تركز صفحات المنتج على الأداء والحجم وسهولة الاستخدام والتوفر العالمي. يحتاج العملاء أيضًا إلى معلومات عن مجال الفشل. ما المكونات المكررة؟ ما التبعيات الخارجية؟ ما التبعيات في مسار القراءة والكتابة والتحكم والاسترداد؟ ما المنتجات المصممة لخدمة البيانات القديمة أثناء الاضطراب؟ أيها تتطلب وصولاً مباشرًا إلى تبعية المزود؟
لا تحتاج الإجابة إلى كشف كل تفصيل داخلي. لا يحتاج العملاء إلى أسماء جداول قاعدة بيانات أو رسومات شبكة خاصة. يحتاجون إلى فئات ذات صلة بالتصميم. إذا كانت الخدمة ذات تبعية سحابية خارجية يمكن أن تعطل التوفر، يمكن التعبير عن هذه الحقيقة على مستوى محكوم. إذا تمت إزالة هذه التبعية أو تقليلها بعد حادثة، يمكن للمزود أن يقول أي فئة من التبعية تغيرت.
يجب بعد ذلك دمج هذه الحقائق في مراجعات البنية للعميل. قد تقرر شركة تستخدم KV لمفاتيح الميزات أن القراءات القديمة مقبولة. قد يقرر منتج أمان يستخدم KV للسياسة أن سلوك الإغلاق عند الفشل أكثر أمانًا. قد يقرر تطبيق استهلاكي تخزين محتوى غير حساس مؤقتًا في مكان آخر. قد تتطلب خدمة منظمة مزودًا ثانيًا أو وضع طوارئ محلي. تسمح معلومات التبعية الجيدة لعملاء مختلفين باتخاذ خيارات مختلفة.
بدون هذه المعلومات، يرث جميع العملاء المفاجأة نفسها. هذه هي مشكلة المسؤولية في مجال الفشل في الخدمات السحابية: المزود لديه الخريطة، لكن العميل يتحمل جزءًا من تكلفة الانقطاع.
لغة مستويات الخدمة يجب أن تتوافق مع واقع التبعيات
يمكن لأهداف مستوى الخدمة وصفحات الحالة إخفاء حدود التبعية عن غير قصد. قد يعلن منتج عن التوفر، لكن السؤال الحقيقي للعميل هو التوفر تحت أي أنماط فشل. هل يفترض الالتزام أن البنية التحتية الخاصة للمزود سليمة؟ هل يستبعد الأعطال السحابية الأولية؟ هل يشمل المنتجات التابعة؟ هل يميز بين عمليات القراءة والكتابة؟ هل ينطبق عالميًا أم إقليميًا؟ هل يغطي وظائف مستوى التحكم بالإضافة إلى الوصول إلى البيانات؟
حادثة يونيو 2025 تجعل هذا السؤال عمليًا. العميل الذي يقيم Workers KV قد يهتم أقل بتوفر مجرد وأكثر بما يحدث عندما تفشل تبعية: هل يمكن للتطبيق قراءة المفاتيح الموجودة، كتابة قيم جديدة، سرد المفاتيح، مصادقة استدعاءات API، نشر عوامل جديدة، أو خدمة تكوين قديم؟ لا يمكن لنسبة توفر واحدة الإجابة على كل هذا.
يجب أن تعكس صفحات الحالة هذه الدقة. أثناء الحادثة، قد يكون "الأداء المنخفض" غامضًا جدًا للمطورين الذين يحتاجون إلى معرفة ما إذا كانت عمليات الكتابة تفشل، والقراءات قديمة، والتكرار متأخر، أو المنتجات التابعة معطلة. قد لا يعرف المزود كل التفاصيل على الفور، لكن تقدم الحالة يجب أن يقلل من عدم اليقين مع وصول الحقائق. يجب أن يغلق تقرير ما بعد الحادث الحلقة بعد ذلك.
هذه ليست مجرد مشكلة تجربة عميل. إنها تشكل استجابة الحوادث. إذا علم العميل أن عمليات الكتابة معطلة لكن القراءات آمنة، يمكنه تجميد تغييرات التكوين مؤقتًا. إذا علم أن قراءات السياسة قد تفشل، يمكنه تفعيل التراجع. إذا علم فقط أن المنتج منخفض، قد يتخذ إجراءات أوسع وأكثر إزعاجًا. التواصل الدقيق من المزود يقلل من ردود الفعل المفرطة في النهاية.
لذلك يجب اختبار لغة مستويات الخدمة ضد الحوادث. هل قالت صفحة الحالة للعملاء ما يحتاجون؟ هل توافقت لغة SLA أو SLO مع الفشل؟ هل فهم العملاء ما إذا كانت الحادثة تحتسب ضمن الالتزامات؟ هل شرحت وثائق المنتج كيفية التصميم لنمط الفشل؟ إذا لم يكن الأمر كذلك، فإن وعد الموثوقية من المزود أقل قابلية للاستخدام مما يبدو.
موقع البيانات وتبعية المزود هما سؤالان مختلفان
غالبًا ما يفكر العملاء في موقع البيانات من حيث مكان تخزينها أو معالجتها. تبعية خارجية مخفية تثير سؤالًا ذا صلة لكن مختلفًا: ما علاقات المزودين المشاركة في تشغيل الخدمة؟ قد تخزن الخدمة البيانات في مكان واحد، وتعالج الطلبات على الحافة، ومع ذلك تعتمد على مزود آخر لوظيفة تحكم، أو تخزين أساسي، أو طبقة تنسيق، أو مكون تشغيلي. يمكن أن تكون التبعية للاستمرارية حتى لو لم تغير وضع إقامة البيانات الرسمي للعميل.
يجب أن يكون هذا التمييز واضحًا في وثائق العميل. إذا كانت الخدمة لديها ضمانات موقع بيانات إقليمي، يجب أن يعرف العملاء ما إذا كانت هذه الضمانات تتناول تبعيات التوفر. قد يمتثل العميل لمتطلبات موقع البيانات ومع ذلك يكون لديه تبعية استمرارية لمزود آخر. على العكس، قد لا تعني تبعية تشغيلية خارجية أن بيانات العميل قد تعرضت لذلك المزود. لا ينبغي أن تكون الفئات غامضة.
في حادثة Cloudflare، لا ينبغي للمقال استنتاج نقل بيانات العميل إلى ما وراء الملف المصدر. سؤال المسؤولية هو الاستمرارية ورؤية التبعيات، وليس ادعاءات غير مدعومة بنقل البيانات. لكن العملاء الذين لديهم مخاوف سيادة البيانات قد يظلون يسألون ما إذا كانت التبعيات المخفية تؤثر على تحليل المخاطر الخاص بهم. يجب أن يكون المزودون مستعدين للإجابة بعبارات دقيقة: أي البيانات، أي البيانات الوصفية، أي إشارات التحكم، أي المناطق، أي المزودين، أي أنماط الفشل.
الدقة تحمي كلا الطرفين. تمنع العملاء من افتراض تعرض البيانات حيث لا تدعم الأدلة سوى تعطل التوفر. تمنع أيضًا المزودين من رفض الأسئلة المشروعة حول التبعية كما لو كانت مجرد سوء فهم للخصوصية. الاستمرارية والخصوصية والموقع والمرونة تتداخل، لكنها ليست متطابقة.
أفضل وثائق العملاء ستفصل هذه الأبعاد. إقامة البيانات تصف أين يتم تخزين بيانات العميل أو معالجتها. التبعية التشغيلية تصف أي الأنظمة يجب أن تعمل لكي تعمل الخدمة. تبعية مستوى التحكم تصف أي الخدمات تدير التكوين أو التنسيق. تبعية مجال الفشل تصف أي الأعطال الخارجية يمكن أن تعطل المنتج. يحتاج العملاء إلى المشاهدات الأربعة لبنية جادة.
تسلسل الاسترداد هو إشارة عامة للموثوقية
يجب أن تشرح تقارير ما بعد الحادث ليس فقط لماذا بدأ الانقطاع، بل كيف تم تسلسل الاسترداد. أي التبعيات كان يجب أن تعود أولاً؟ أي المنتجات استعادت أولاً؟ هل تمكن العملاء من خدمة القراءات قبل الكتابات؟ هل تمت استعادة المنتجات التابعة بعد Workers KV، أم أن بعضها تطلب إصلاحات إضافية؟ هل تم تحديث رسائل الحالة بنفس ترتيب الاسترداد الفني؟ يخبر تسلسل الاسترداد العملاء كيف يفهم المزود رسم التبعيات الخاص به.
بالنسبة لمزود واسع، يكشف تسلسل الاسترداد أيضًا عن تحديد الأولويات. بعض المنتجات تدعم ضوابط الأمان، وبعضها تطبيقات التطوير، وبعضها وصول العميل، وبعضها العمليات الداخلية. أثناء تعطل متعدد المنتجات، يجب على القيادة أن تقرر أي منتج يستعيد أولاً وكيفية التواصل حول الاستعادة الجزئية. لا ينبغي للعملاء أن يضطروا إلى تخمين ما إذا كان منتجهم ينتظر شرطًا مسبقًا مخفيًا.
لا يحتاج تقرير ما بعد الحادث العام إلى كل دقيقة داخلية. يجب أن يعطي تسلسلًا كافيًا لإظهار السببية والتعلم. إذا كان تعطل Workers KV قد أثر على المنتجات التابعة، يجب أن يشرح التقرير هذه العلاقة. إذا عادت التبعية الخارجية قبل أن تتعافى جميع منتجات Cloudflare، يجب أن يشرح التقرير لماذا كانت هناك حاجة لاستعادة داخلية إضافية. إذا نفذت Cloudflare حلولاً بديلة أثناء الحادثة، يجب أن يعرف العملاء ما حمت هذه الحلول وما لم تحم.
يدعم تسلسل الاسترداد أيضًا تخطيط العميل. إذا كان تطبيق العميل يعتمد على KV ومنتج Cloudflare آخر، فإن معرفة أي منهما يستعيد أولاً يساعد في تصميم التراجع. إذا تعافت الكتابات لاحقًا من القراءات، قد يقرر العميل وضع التحديثات في قائمة انتظار. إذا كان استرداد مستوى التحكم متأخرًا عن استرداد مستوى البيانات، قد يتجنب العميل إجراء تغييرات أثناء الحادثة. هذه نتائج تصميم عملية تنبع من تسلسل شفاف.
أقوى ملف إصلاح سيختبر التسلسل لاحقًا. أثناء تمرين يوم اللعبة، هل يمكن لـ Cloudflare محاكاة فشل تبعية أولي وإظهار أن المنتجات التابعة تتعافى بشكل أسرع أو تتدهور بشكل أكثر أمانًا؟ هل يمكن لتحديثات الحالة تحديد طبقة الفشل في وقت مبكر؟ هل يمكن للعملاء رؤية أعراض أوضح؟ ستكون أدلة مثل هذه الاختبارات أكثر إقناعًا من وعد بالتحسين.
التزامات تقرير ما بعد الحادث تحتاج إلى إغلاق لاحق
تقرير ما بعد الحادث قيم لأنه يحول الحادثة إلى التزامات عامة. كما يخلق دين مسؤولية. عندما يقول المزود إنه سيقلل التبعية، ويحسن التبديل، ويعيد تصميم بنية، أو يغير المراقبة، يجب أن يتمكن العملاء لاحقًا من رؤية ما إذا كان هذا العمل قد اكتمل. وإلا، تصبح تقارير ما بعد الحادث كتابة طموحة بدلاً من ملفات إصلاح.
يمكن أن يكون الإغلاق عامًا دون أن يكون متهورًا. يمكن للمزود نشر ملاحظة متابعة تشير إلى أنه تمت إزالة تبعية من مسار حرج، وأن اختبارات التبديل تمر الآن، وأن أتمتة صفحة الحالة قد تحسنت، أو أن وثائق العملاء قد تم تحديثها. يمكنه وصف فئة التحكم دون كشف التفاصيل الداخلية. بالنسبة لعملاء المؤسسات، يمكن مشاركة مزيد من التفاصيل عبر قنوات الثقة. المفتاح هو تجنب ترك الالتزامات مفتوحة.
يجب على العملاء أيضًا تتبع هذه الالتزامات. يمكن لفرق مخاطر المزودين تسجيل إجراءات ما بعد الحادث وطلب أدلة الإغلاق أثناء المراجعات. يمكن للمطورين مراقبة تحديثات الوثائق. يمكن لفرق الأمان اختبار التراجع الخاص بهم بعد إصلاح المزود. يمكن لفرق المشتريات تضمين شفافية التبعية في مناقشات التجديد. تقرير ما بعد الحادث ليس مجرد مادة للقراءة؛ إنه مصدر لمهام مخاطر المزود.
انقطاع Cloudflare هو مثال جيد لأن الملف المصدر يتضمن التزامات معالجة. لا ينبغي للمقال أن يدعي أن هذه الالتزامات كاملة بدون دليل. يجب أن يحدد الإنجاز على أنه الخطوة التالية للمسؤولية. هذا يحافظ على عدالة الملف العام: الاعتراف بشفافية المزود ومطالبة دليل الإصلاح.
هذا المعيار يساعد المزودين أيضًا. الإغلاق العام يبني الثقة. إذا نشر المزود تقارير ما بعد الحادث فقط في خضم الانقطاع لكنه لا يغلق الحلقة أبدًا، قد يفترض العملاء أن العمل قد اختفى. ملف إنجاز موجز يظهر أن تعلم الحادثة قد نجا بعد استعادة الخدمة.
يجب أن تفترض أدلة تشغيل العميل فشل مزود المزود
تعامل العديد من أدلة تشغيل العميل فشل المزود كصندوق واحد. إذا فشلت Cloudflare، افعل هذا. إذا فشل Google Cloud، افعل ذلك. يشير ملف يونيو 2025 إلى نموذج أكثر واقعية: قد يفشل منتج من مزود لأن مزودًا تحته يفشل. لذلك يجب أن يسأل دليل تشغيل العميل كيف يستجيب عندما تتداخل تبعيات المزودين.
الخطوة الأولى هي الجرد. أي التطبيقات تعتمد على Workers KV؟ أي البيانات أو التكوينات تخزنها؟ ماذا يحدث إذا فشلت القراءات؟ ماذا يحدث إذا فشلت الكتابات؟ أي الخدمات المرئية للمستخدم تعتمد على هذه التطبيقات؟ أي العملاء أو الفرق الداخلية يجب إخطارهم؟ أي قيم التراجع آمنة؟ أي التغييرات يجب إيقافها؟ بدون هذا الجرد، يكتشف العملاء التبعية في نفس اللحظة التي يحاولون فيها الاستجابة.
الخطوة الثانية هي نمط الفشل. هل يمكن للتطبيق خدمة محتوى قديم؟ هل يمكنه تخزين التكوين محليًا مؤقتًا؟ هل يمكنه وضع الكتابات في قائمة انتظار؟ هل يمكنه الفشل في وضع الإغلاق لقرارات الأمان؟ هل يمكنه عرض صفحة صيانة بدلاً من مهلة؟ هل يمكنه التبديل إلى تخزين آخر للبيانات غير الحرجة؟ كل إجابة تعتمد على غرض التطبيق. لا ينبغي لسياسة أمان أن تفشل في وضع الفتح باستخفاف؛ قد تستطيع لافتة تسويقية خدمة محتوى قديم.
الخطوة الثالثة هي التواصل مع المزود. يجب على العملاء الاشتراك في صفحات الحالة ذات الصلة، وتحديد سبل التصعيد إلى فريق الحساب، ومعرفة أين تظهر تقارير ما بعد الحادث. أثناء الحادثة، يجب على فرق العميل رسم خريطة لحالة المزود على تأثير خدمتهم الخاصة والتواصل مع النهائي. خصوصية المزود تسهل ذلك، لكن العملاء لا يزالون بحاجة إلى رسم الخرائط الخاص بهم.
الخطوة الرابعة هي التمرين. يمكن للعميل محاكاة فشل قراءة KV، أو كتابة، أو زمن استجابة، أو بيانات قديمة، أو عدم يقين في الحالة. يمكن أن يكشف التمرين أن كود التطبيق يفترض أن KV متاح دائمًا، أو أن رسائل الخطأ غير مفيدة، أو أن فرق الدعم لا تعرف أي تبعية مزود متورطة. هذا الاكتشاف أقل تكلفة أثناء الاختبار منه أثناء انقطاع مزود حقيقي.
السحابة المتعددة ليست تلقائيًا متعددة مجالات الفشل
غالبًا ما يعتبر سوق السحابة السحابة المتعددة مرونة. تظهر حادثة Cloudflare لماذا تحتاج هذه العبارة إلى دليل. يمكن للسحابة المتعددة تقليل بعض المخاطر وزيادة أخرى. يمكن أن تنوع قفل المزود، والتعرض الإقليمي، ورفع السعر، أو الفشل الخاص بالخدمة. قد لا تنوع إذا كان منتج مزود يعتمد على مزود آخر في مسار مخفي، أو إذا كانت الهوية مركزية، أو إذا كان DNS مشتركًا، أو إذا كانت المراقبة مستضافة بشكل فردي، أو إذا لم يتمكن الموظفون من تشغيل التراجع.
لذلك يجب على العملاء وصف مجالات الفشل الدقيقة التي يريدون فصلها. هل يريدون الاستقلال عن منطقة سحابية؟ عن فشل مستوى تحكم المزود؟ عن خدمة تخزين؟ عن مزود هوية؟ عن مزود DNS؟ عن شبكة حافة؟ عن أداة فوترة أو نشر؟ تعتمد البنية الصحيحة على مجال الفشل. عدد المزودين ليس بنية بحد ذاتها.
يمكن للمزودين دعم ذلك من خلال وصف تبعياتهم على المستوى الذي يحتاجه العملاء. إذا كان منتج يعتمد على سحابة خارجية لمكون، قد لا يزال ذلك مقبولاً. لكن العملاء الذين يستخدمون هذا المنتج كطبقة تنويع يجب أن يعرفوا ذلك. لا يحتاج المزود إلى وعد باستقلال مطلق؛ يجب عليه تجنب سوء فهم العميل العرضي.
وبالتالي، فإن حادثة يونيو 2025 هي دعوة تدقيق مفيدة. يجب على العملاء مراجعة أين يعتقدون أن لديهم تنوعًا والسؤال عن الدليل الذي يدعم هذا الاعتقاد. يجب على المزودين مراجعة أين يفترض العملاء على الأرجح الاستقلال وتحديد ما إذا كانت الوثائق يجب أن توضح. المرونة تكون أقوى عندما يكون كلا الطرفين صريحين بشأن التبعية التي يتم تنويعها.
يجب أن يبقى توزيع المسؤولية متوازنًا
سيكون من غير العدل معاملة Cloudflare كما لو أنها تسببت في كل تفصيل في الانقطاع الأولي. سيكون أيضًا غير مكتمل معاملة الانقطاع الأولي على أنه قصة المسؤولية الوحيدة. الرؤية المتوازنة توزع الواجبات حسب السيطرة. امتلكت Google Cloud اضطراب خدمتها وملف الحالة الخاص بها. امتلكت Cloudflare تصميم منتجاتها التي تعتمد على تلك الخدمة، وإشعاراتها للعملاء، واستردادها، والتزاماتها بالإصلاح. امتلك العملاء خيارات التراجع الخاصة بتطبيقهم، لكن فقط ضمن حدود المعلومات المتاحة.
هذا التوزيع مهم لأن حوادث السحابة الحديثة غالبًا ما تكون متسلسلة. يعتمد مزود دفع على مزود سحابي. يعتمد مزود SaaS على مزود هوية. يعتمد مزود أمان على خدمة تخزين. تعتمد منصة تطوير على طبقة تنسيق خارجية. عندما يفشل المكون الأولي، يمكن أن يكون المزودون النهائيون ضحايا وفاعلين مسؤولين في نفس الوقت. لم يتسببوا في الفشل الأولي، لكنهم صمموا مسار التبعية.
يجب أن تكون المسؤولية العامة ناضجة بما يكفي لتحمل كلا الحقيقتين. قصص اللوم فقط تثبط الشفافية. قصص العذر فقط تخفي واجبات الإصلاح. السؤال المفيد هو ما كان يمكن لكل طرف فعله بشكل معقول قبل الحادثة وأثناءها وبعدها. هل تواصل المزود الأولي؟ هل عزل المزود النهائي؟ هل خطط العميل؟ هل تحسن كل طرف بعد ذلك؟
تقرير ما بعد الحادث لـ Cloudflare يساعد بجعل التبعية علنية. الخطوة التالية لبناء الثقة هي إثبات أن التبعية تم تقليلها أو عزلها أو جعلها أكثر أمانًا. هكذا تصبح الحادثة المتسلسلة سلسلة أقصر في المرة القادمة.
المعيار التشغيلي النهائي
المعيار النهائي للاستمرارية الخارجية داخل المزود يتكون من خمسة أجزاء. أولاً، معرفة خريطة التبعيات جيدًا بما يكفي للتنبؤ بأعراض العميل. ثانيًا، تصميم المنتجات الحرجة لتتدهور بأمان عندما تفشل تبعية خارجية. ثالثًا، التواصل بوضوح حول طبقات المنتجات المتأثرة أثناء الحادثة. رابعًا، نشر تقرير ما بعد الحادث يميز بين السبب الأولي وخيارات التصميم النهائية. خامسًا، إغلاق الحلقة حول الإصلاحات الموعودة بأدلة لاحقة.
هذا المعيار صعب لأن مزودي الخدمات السحابية يبيعون البساطة على أنظمة معقدة. يُسمح للعملاء بالاعتماد على هذه البساطة، لكن لا ينبغي للمزودين أن يدعوا البساطة تخفي المخاطر. عندما تصبح التبعية المخفية مرئية من خلال انقطاع، لدى المزود فرصة لتحسين كل من البنية والثقة.
ملف يونيو 2025 لـ Cloudflare حول Workers KV ينتمي إلى هذه السلسلة لأنه يظهر الشكل الحديث لمسؤولية البنية التحتية. لم يكن مجال الفشل مجرد خادم أو منطقة. بل كان علاقة بين مزودين داخل منتج مزود آخر. هذا هو نوع المخاطرة التي يواجهها العملاء بشكل متزايد ولا يمكنهم تقييمها بدون مساعدة.
السؤال الدائم ليس ما إذا كان المزودون يمكنهم استخدام مزودين آخرين. سيفعلون. السؤال هو ما إذا كانت التبعية محكومة، ومُفصح عنها بما يكفي للتصميم، ومُختبرة للفشل، ومُصلحة بعد كسرها. تعتمد الاستمرارية الآن على هذا الصدق.