الخلاصة

  • تعزو Google Cloud حادث الخدمة عالي الخطورة في us-west1 يوم 20 أغسطس إلى صيانة ضوئية مخطط لها أحدثت ازدحاماً غير متوقع في The Dalles بأوريغون. ويسمي سجل الحادث 27 منتجاً.
  • أوصت Google بالتحول إلى أقاليم أخرى حيثما كان ذلك ممكناً. وتعتمد قابلية تنفيذ هذه التوصية على وجود نسخ بيانات محدثة وتحكم في الحركة واعتمادات وخدمات خارجية وصلاحية قرار تعمل خارج الإقليم.

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

يضع السجل بداية الحادث عند 15:40 بالتوقيت العالمي في 20 أغسطس. وجاء أول تحديث علني عند 16:44:37، بعد أكثر من ساعة، متحدثاً عن انتهاء مهلة الطلبات وتراجع الأداء والأخطاء وارتفاع زمن الاستجابة في عدة منتجات. وعند 17:13:59 ثم 17:32:15، نصحت الشركة العملاء بالتحول إلى أقاليم أخرى عندما يكون ذلك ممكناً.

يفيد التحديث الأخير بأن المهندسين أعادوا السعة وأن المشكلة الأساسية خُففت عند 17:22 بالتوقيت العالمي. لكن هذا التوصيف الاستعادي نُشر عند 19:37:40. وخلال الفترة الفاصلة، قالت تحديثات إن إجراءات التخفيف اكتملت فيما واصلت منتجات منفردة التعافي. أما سجل الحادث نفسه فينتهي عند 19:20.

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

صُنّف الحادث عالي الخطورة وبأثر SERVICE_OUTAGE، ويشمل 27 منتجاً في الحوسبة والتخزين وقواعد البيانات ومعالجة البيانات والبناء والمراقبة والهوية والرسائل. ومن الأسماء الواردة Compute Engine وGKE وCloud Run وCloud Storage وCloud SQL وBigQuery وPub/Sub وCloud Monitoring وIAM وPersistent Disk.

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

كما حملت التحديثات المبكرة علامة موقع Global إلى جانب أوريغون. غير أن النص يضع أعراض العملاء باستمرار في us-west1. وقد تصف العلامة نطاق المنتج أو تصنيف صفحة الحالة، ولا تكفي لإثبات تعطل Google Cloud عالمياً.

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

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

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

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

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

المصادر