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

ملخص

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

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

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

يشرح هذا التمييز لماذا كان حادث 12 يونيو 2025 أقل من انقطاع كامل للبنية التحتية وأكثر من مشكلة API عادية. يقول تقرير حادث Service Control الكامل من 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 مايو، تم إصدار ميزة جديدة لـ Service Control لفحوصات إضافية لسياسة الحصص منطقة تلو الأخرى. اكتمل النشر الثنائي دون كشف الخلل لأن مسار الشيفرة الفاشل تطلب تغييرًا لاحقًا في السياسة. لم تكن الميزة محمية بعلم يمكن تمكينها تدريجيًا لمشاريع محددة، وتعاملها مع البيانات غير الصالحة سمح لقيمة فارغة بتعطيل العملية. في 12 يونيو حوالي الساعة 10:45 صباحًا بتوقيت المحيط الهادئ، تمت كتابة سياسة حصص تحتوي على حقول فارغة غير مقصودة إلى جداول Spanner الإقليمية المستخدمة بواسطة Service Control.

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

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

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

محفز قصير أنتج استردادًا طويلًا وغير متساوٍ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

أثر حدث الشبكة لعام 2019 على عدة مناطق لأن حد أتمتة مستوى التحكم عبر المواقع الفعلية. أثر حادث حصص الربط لعام 2021 على برمجة الشبكة عالميًا لأن وحدة التحكم المعنية وموارد VPC كان لها نطاق عالمي. أثر حدث Service Control لعام 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 لا يثبت أن التبعية مقبولة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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