سياسة واحدة، كل منطقة: Google Cloud ومساءلة مستوى تحكم عالمي

ملخص

• في 12 يونيو 2025، وصلت حقول فارغة غير مقصودة في سياسة حصص إلى مخازن بيانات التحكم في خدمة Google Cloud الإقليمية بشكل متزامن تقريبًا. لم يتضمن مسار الشيفرة المنشور سابقًا معالجة مناسبة للأخطاء ولا حماية بإشارات الميزات؛ أدت معالجة السياسة إلى تعطل ثنائيات التحكم في الخدمة في كل منطقة. عادت العديد من واجهات برمجة تطبيقات Google Cloud وGoogle Workspace وGoogle Security Operations بأخطاء 503. تمكنت الموارد الحالية للتدفق والبنية التحتية كخدمة إلى حد كبير من الاستمرار في الخدمة، لكن مسارات الإدارة وواجهات برمجة التطبيقات اللازمة لفحص الخدمات أو تعديلها أو توسيع نطاقها أو استعادتها كانت معطلة على نطاق واسع.
• كان الخلل المباشر محدودًا، لكن فشل المساءلة كان معماريًا. كان لدى Google مثيلات خدمات موزعة إقليميًا ونشر تدريجي للثنائيات، ومع ذلك تم تكرار السياسة المسببة عالميًا في غضون ثوانٍ. لذلك تجاوز آلية القتل التعلم الإقليمي الذي كان من المفترض أن يوفره النشر. تسبب الاسترداد بعد ذلك في تأثير قطيع ضد Spanner في المناطق الأكبر لأن المهام المعاد تشغيلها تفتقر إلى التراجع الأسي العشوائي. كما اعتمدت البنية التحتية العامة لصحة الخدمة السحابية على البيئة المتأثرة، مما أخر أول إشعار من Google لمدة ساعة تقريبًا.
• تظهر حوادث سابقة أسبابًا مختلفة ولكن أسئلة متكررة حول الاستقلال المنطقي. في يونيو 2019، ألغت أتمتة الصيانة جدولة مجموعات التحكم في الشبكة في عدة مواقع مادية، وتم سحب مسارات BGP، وتنافست أدوات التشخيص على الشبكة المزدحمة. في فبراير 2021، أدى خطأ كامن تم تشغيله أثناء تغييرات حصص التوصيل البيني إلى حجب برمجة الشبكة العالمية. في مارس 2021، كشفت مسارات غير صالحة عن عيب معروف في البائع، وافتقرت بعض مواقع Cloud Interconnect إلى تنوع كافٍ في بائعي أجهزة التوجيه. هذه ليست عيوب برمجية متكررة واحدة؛ إنها اختبارات متكررة لاحتواء السبب المشترك، وسلطة التغيير، واسترداد الشبكة، والرؤية الصادقة.
• Google مسؤولة عن التحقق من صحة البيانات المكررة عالميًا، وعزل وظائف مستوى التحكم، والحفاظ على سلوك فشل ثابت أو فتح حيثما يكون آمنًا، والحفاظ على اتصالات الحوادث مستقلة، وإثبات اكتمال الإصلاحات الموعودة. لا يمكن للعملاء إصلاح ضوابط المنصة هذه، لكنهم يظلون مسؤولين عن تحديد العمليات التي تعتمد على واجهات برمجة تطبيقات مستوى التحكم، والمراقبة من خارج المزود، واختبار الأوضاع المتدهورة، وشراء تنوع المسار والمزود بدلاً من الاعتماد على الروابط الاسمية. يقلل النشر متعدد المناطق من العديد من المخاطر؛ لكنه لا يهرب، بمفرده، من مستوى سياسة عالمي أو بنية أساسية مشتركة.

كان الانقطاع قرار تحكم تم اتخاذه في كل مكان في وقت واحد

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

يشرح هذا التمييز لماذا كانت حادثة 12 يونيو 2025 في وقت واحد أقل من انقطاع كلي في البنية التحتية وأكثر من مشكلة API عادية. يقول تقرير حوادث التحكم في الخدمة الكامل من Google أن الموارد الحالية للتدفق والبنية التحتية كخدمة لم تتأثر مباشرة بالفشل الأساسي. ومع ذلك، شهدت قائمة طويلة من المنتجات أخطاء API خارجية، بما في ذلك Identity and Access Management وCloud Storage وBigQuery وCloud Run وCloud DNS وCloud Load Balancing وHybrid Connectivity وNetwork Connectivity Center وSpanner ومنتجات المراقبة ووحدة التحكم وخدمات AI متعددة.

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

كانت الآلية واضحة بشكل غير عادي في الحساب العام لـ Google. في 29 مايو، تم إصدار ميزة جديدة للتحكم في الخدمة لفحوصات إضافية لسياسة الحصص منطقة بمنطقة. اكتمل نشر الثنائيات دون كشف الخلل لأن مسار الشيفرة الفاشل تطلب تغيير سياسة لاحق. لم تكن الميزة محمية بعلم يمكن تفعيلها تدريجيًا لمشاريع محددة، ومعالجتها للبيانات غير الصالحة سمحت بقيمة فارغة بتعطيل العملية. في 12 يونيو حوالي الساعة 10:45 صباحًا بتوقيت المحيط الهادئ، تمت كتابة سياسة حصص تحتوي على حقول فارغة غير مقصودة إلى جداول Spanner الإقليمية المستخدمة من قبل التحكم في الخدمة. نظرًا لأن بيانات الحصص كانت مصممة للتحرك عالميًا مع اتساق فوري تقريبًا، ظهرت البيانات عبر المناطق في غضون ثوانٍ.

ثم واجه كل نشر إقليمي للتحكم في الخدمة نفس المدخلات ودخل في حلقة تعطل.

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

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

مشغل قصير أدى إلى استرداد طويل وغير متساوٍ

يحتوي الجدول الزمني لـ Google على قصتين مختلفتين للغاية. كان الكشف والتشخيص سريعين. كان الاسترداد الكامل ليس كذلك.

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

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

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

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

النشر الإقليمي لم يخلق تعلمًا إقليميًا

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

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

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

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

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

الفشل المفتوح هو قرار تجاري وأمني، وليس مجرد شعار

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

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

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

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

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

شارك نظام الحالة في الانقطاع الذي كان من المفترض أن يصفه

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

لم يكن هذا غير مسبوق. خلال انقطاع المصادقة العالمي لـ Google في 14 ديسمبر 2020، يقول تقرير الحادث أن أدوات Cloud Support الداخلية تأثرت، ولم يتمكن العملاء من إنشاء أو عرض حالات الدعم في وحدة التحكم، وتأخرت اتصالات لوحة القيادة حتى بعد انتهاء التأثير الرئيسي. جاء هذا الحدث من إدارة الحصص الآلية التي تقلل السعة لنظام الهوية المركزي. بقيت تكوينات مستوى بيانات الشبكة الحالية قابلة للتشغيل، لكن الخدمات المصادقة، الوصول إلى API، وحدات التحكم، والعديد من الأدوات الداخلية لم تكن كذلك. تختلف الآلية عن 2025؛ القلق المتكرر هو أن الهوية والدعم والمراقبة والاتصالات يمكن أن تشارك المصير مع الخدمات التي من المفترض أن تشخصها.

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

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

لدى العملاء التزام موازٍ. يقول دليل التكامل لـ Personalized Service Health صراحةً أن الخدمة لا يمكنها معرفة ما إذا كان كل منتج حاسمًا لتطبيق معين أو ما إذا كان التطبيق يستمر عندما تفشل تبعية واحدة. يحتاج المشغلون إلى فحوصات رحلة المستخدم الخاصة بهم، ومقاييس التطبيق، وقياس الشبكة، وإنذارات عملية الأعمال. يجب أن يعمل مسار واحد على الأقل خارج Google Cloud ويتم تسليمه إلى قناة حوادث لا تعتمد على هوية Google. حالة المزود هي تأكيد، وليست كاشفًا أول ووحيد.

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

نجت مهام العمل الحالية بشكل أفضل من الإجراءات التي كان من المفترض أن تنقذها

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

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

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

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

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

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

أظهر انقطاع 2019 أن الفصل المادي يمكن أن يشارك حدود أتمتة واحدة

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

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

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

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

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

تنوع التوصيل البيني والعبور يتعلق بالقدر، وليس عدد الدوائر

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

يوضح تقرير حادث البنية الأساسية في 17 مارس 2021 من Google هذا الاختلاف. أدى توصيل أجهزة توجيه جديدة إلى تغيير المسارات التي تستقبلها أدوار معينة لأجهزة التوجيه. كشفت تلك المسارات عن عيب معروف في نموذج جهاز توجيه معين، مما تسبب في فشل عمليات التوجيه. قلل إعادة التوجيه التلقائي من خطر التتابع الأوسع لكنه أنتج فقدان حزمة أثناء التقارب. تسبب تخفيف يدوي في فترة أخرى من الازدحام، وكان لبعض مواقع Cloud Interconnect تأثير ممتد لأن تكرار بائع جهاز التوجيه كان غير كافٍ. تأثرت حركة المرور بين المناطق بعناوين IP الخاصة، وحركة IP العامة، وموازنات التحميل، وأنفاق VPN، والاتصال الخارجي بنسب مختلفة.

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

تقدم نظرة عامة على Cloud Interconnect من Google تكوينات بنسبة 99.9 و99.99 بالمائة وتوضح أن الاتصال الفردي ليس له اتفاقية مستوى خدمة (SLA) لوقت التشغيل. يدعو دليل Partner Interconnect إلى أربع اتصالات VLAN عبر مترو ومجالي توفر حافة للطوبولوجيا الموصى بها بنسبة 99.99٪؛ كما يلاحظ أن قطاع المزود خارج شبكة Google يحتاج إلى ضمانه الخاص. يمكن أن يؤدي استخدام مزودي خدمات متعددين إلى تحسين التوفر، ولكن فقط إذا كانت مساراتهم الأساسية منفصلة بالفعل ولديها سعة كافية أثناء تجاوز الفشل.

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

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

متعدد المناطق هو حماية قوية ضد الفئة الخاطئة من الفشل

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

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

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

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

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

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

حولت Cloudflare حادث مزود واحد إلى درس تبعية لآخر

عبر حدث يونيو 2025 حدودًا مؤسسية بطريقة مفيدة بشكل خاص. يقول تقرير الانقطاع الخاص بـ Cloudflare أن Workers KV يعتمد جزئيًا على مزود سحابي تابع لجهة خارجية. عندما فشلت هذه التبعية، أصبح Workers KV غير متأثر وتأثرت مجموعة واسعة من منتجات Cloudflare التي تستخدمه، بما في ذلك Access وGateway وWARP وTurnstile وImages وStream وأجزاء من لوحة القيادة وخدمات أخرى. لم تكن خدمات CDN والأمان الأساسية لـ Cloudflare معطلة بشكل موحد، لكن التبعية جعلت فشل مستوى التحكم في Google Cloud مرئيًا من خلال المنتجات المباعة تحت اسم مزود آخر.

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

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

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

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

رصيد SLA لا يثبت أن التبعية مقبولة

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

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

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

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

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

قائمة إصلاحات Google ذات مصداقية فقط عندما تصبح دليلاً

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

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

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

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

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

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

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

ما يجب على العملاء اختباره قبل الحادث العالمي التالي

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

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

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

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

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

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

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

بطاقة أداء لمساءلة مستوى التحكم والشبكة

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

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

الإشارة الدائمة هي سرعة السلطة المشتركة

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

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

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

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