ملخص
- في أغسطس 2015، واجهت الأقراص الثابتة القياسية لمحرك حوسبة Google (Google Compute Engine Standard Persistent Disks) في المنطقة europe-west1-b أخطاء في القراءة بعد أربع ضربات برق متتالية أثرت على شبكة المرافق المحلية التي تخدم مركز بيانات أوروبي. أبلغت Google لاحقًا أن جزءًا صغيرًا جدًا من مساحة الأقراص الثابتة المخصصة في المنطقة عانى من كتابات حديثة غير قابلة للاسترداد.
- لا تتعلق قضية المساءلة بحجم النسبة المئوية. بل تتعلق بفهم العملاء أن القرص الثابت (Persistent Disk) في المنطقة، حتى مع التكرار المُدار من المزود داخل المنطقة، لا يزال ضمن نطاق الفشل المادي وليس بديلاً عن اللقطات المستقلة أو التكرار الإقليمي أو النسخ الاحتياطي على مستوى التطبيق.
- سيطرت Google على مرونة الموقع المادي، وقابلية أجهزة التخزين للتأثر، ومعالجة أحداث الطاقة، ولغة متانة الأقراص الثابتة، وتقارير الحالة، ووضوح إرشادات النسخ الاحتياطي. بينما سيطر العملاء على بنية حمل العمل، وجداول اللقطات، وأهداف الاسترداد، وخيارات التكرار، وما إذا كانت متطلبات الموقع قد تم الخلط بينها وبين قابلية الاسترداد.
- يجب أن يميز سجل الإصلاح العملي بين الخدمة المستعادة والبيانات غير القابلة للاسترداد والحل البديل المتاح للقطة وتغييرات الأجهزة والبرامج وإرشادات النسخ الاحتياطي وأدلة العملاء. في حادث سحابي يتضمن فقدان بيانات، لا يمكن لصفحة حالة خضراء أن تكون دليل الاسترداد الكامل.
نسبة صغيرة جدًا قد تكون فشلًا كبيرًا
يُذكر حادث Google Cloud بلجيكا أحيانًا كفضول لأن النسبة المئوية للتخزين المفقود بشكل دائم كانت صغيرة جدًا. هذه ليست العدسة الصحيحة الأولى. بالنسبة لعميل كان قرصه يحتوي على الكتابة الحديثة غير القابلة للاسترداد، لم تكن النسبة مهمة. السؤال ذو الصلة هو ما إذا كان لدى العميل نسخة مستقلة قابلة للاسترداد، وما إذا كان التطبيق يمكنه تحمل نقطة الاسترداد، وما إذا كانت لغة متانة المزود قد أوضحت المخاطر المتبقية للموقع المادي قبل الحادث.
بدأ حادث محرك الحوسبة العامIncident #15056في 13 أغسطس 2015 للأقراص الثابتة في europe-west1-b. أبلغت صفحة الحالة أولاً عن أخطاء في القراءة للعملاء الذين لديهم أجهزة في تلك المنطقة، ثم أوضحت أن أقل من 1 في المائة من الأقراص في المنطقة كانت عرضة لتدهور الأداء، ثم أن أقل من 0.1 في المائة كانت تعاني من أعطال في القراءة على بعض الكتل. كما أخبر سجل الحادث العملاء المتأثرين أن الاستعادة من اللقطات كانت حلاً بديلاً، بينما لم يتأثر إنشاء أقراص ثابتة جديدة والاستعادة من اللقطات.
التقارير الإعلامية التي التقطت شرح الحادث لاحقًا، بما في ذلك تقرير مركز بيانات Dynamics حولالبرق وفقدان البياناتوتقرير Silicon UK عنسبب الانقطاع، سجلت بيان Google بأن أربع ضربات برق متتالية على شبكة المرافق المحلية تسببت في فقدان قصير للطاقة لأنظمة التخزين التي تستضيف سعة القرص لحالات GCE في europe-west1-b. قالت Google إن جميع البيانات تقريبًا قد تم إيداعها في تخزين مستقر، لكن في حالات نادرة جدًا كانت الكتابات الحديثة غير قابلة للاسترداد، مما أدى إلى فقدان دائم للبيانات على القرص الثابت. الرقم المتكرر على نطاق واسع كان أقل من 0.000001 في المائة من مساحة القرص الثابت المخصصة في المنطقة المتأثرة.
يدعم هذا السجل كل من التقييد والجدية. سيكون من الخطأ وصف الحدث بأنه تدمير واسع النطاق للبيانات عبر Google Cloud. الخدمة المتأثرة كانت القرص الثابت القياسي في منطقة واحدة؛ الأقراص الثابتة SSD واللقطات والأقراص SSD المحلية تم الإبلاغ عنها بواسطة فهارس ما بعد الوفاة والتغطية المعاصرة كخارج مجتمع الفقدان الدائم. سيكون من الخطأ أيضًا رفض الحادث لأن المقام كان ضخمًا. متانة البيانات هي حقيقة ثنائية للسجل المهم. نسبة صغيرة غير قابلة للاسترداد لا تزال خسارة دائمة لشخص ما.
سؤال المساءلة ليس إذن "لماذا البرق موجود؟" البرق خطر خارجي. السؤال هو من سيطر على خيارات التصميم التي سمحت لحدث طاقة شبكة مرافق متكرر بالوصول إلى حالة القرص المكتوبة حديثًا، ومن سيطر على وضوح متانة البيانات وإرشادات النسخ الاحتياطي، ومن سيطر على بنية العميل التي إما كان أو لم يكن لديها نقطة استرداد مستقلة. المشغل كان ماديًا. قضية المساءلة الجذرية كانت الحدود بين المتانة المحلية المُدارة من المزود وقابلية الاسترداد المُدارة من العميل.