خسارة قرص جوجل كلاود في بلجيكا تُظهر أين تتوقف المحلية عن كونها مرونة

الملخص

• في أغسطس 2015، عانت أقراص Google Compute Engine Standard Persistent Disks في المنطقة europe-west1-b من أخطاء القراءة بعد أربع ضربات صواعق متتالية أثرت على شبكة المرافق المحلية التي تخدم مركز بيانات أوروبي. أبلغت Google لاحقًا أن جزءًا صغيرًا جدًا من مساحة القرص المستمر المخصصة في المنطقة عانى من عمليات كتابة حديثة غير قابلة للاسترداد.
• ليست قضية المساءلة ما إذا كانت النسبة كبيرة. بل ما إذا فهم العملاء أن القرص المستمر النطاقي، حتى مع التكرار المُدار من قبل المزود داخل المنطقة، كان لا يزال داخل نطاق العطل المادي وليس بديلاً عن اللقطات المستقلة أو النسخ المتماثل الإقليمي أو النسخ الاحتياطي على مستوى التطبيق.
• سيطرت Google على مرونة الموقع الفعلي، وقابلية أجهزة التخزين، ومعالجة أحداث الطاقة، ولغة متانة القرص المستمر، والإبلاغ عن الحالة، ووضوح إرشادات النسخ الاحتياطي. سيطر العملاء على بنية العمل، وجداول اللقطات، وأهداف الاسترداد، وخيارات النسخ المتماثل، وما إذا كانت متطلبات الموقع قد تم الخلط بينها وبين قابلية الاسترداد.
• يجب أن يميز سجل الإصلاح العملي بين الخدمة المستعادة، والبيانات غير القابلة للاسترداد، والحل البديل المتاح للقطة، وتغييرات الأجهزة والبرامج، وإرشادات النسخ الاحتياطي، وأدلة العملاء. في حادث سحابي يتضمن فقدان البيانات، لا يمكن لصفحة حالة خضراء أن تكون دليل الاسترداد بأكمله.

نسبة ضئيلة لا تزال فشلًا صعبًا

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

بدأ حادث Compute Engine Incident #15056 العام لـ Google في 13 أغسطس 2015 للأقراص المستمرة في europe-west1-b. أبلغت صفحة الحالة أولاً عن أخطاء القراءة للعملاء الذين لديهم أجهزة في تلك المنطقة، ثم أوضحت أن أقل من 1% من الأقراص في المنطقة كانت عرضة للأداء المتدهور، ثم أن أقل من 0.1% كانت تعاني من أخطاء القراءة في بعض الكتل. أخبر سجل الحادث أيضًا العملاء المتأثرين أن الاستعادة من اللقطات كانت حلاً بديلاً، بينما لم يتأثر إنشاء أقراص مستمرة جديدة والاستعادة من اللقطات.

التقارير الإعلامية التي التقطت تفسير الحادث لاحقًا، بما في ذلك تقرير مركز بيانات Dynamics عن الصواعق وفقدان البيانات وحساب Silicon UK لسبب الانقطاع، سجلت بيان Google بأن أربع ضربات صواعق متتالية على شبكة المرافق المحلية تسببت في فقدان قصير للطاقة لأنظمة التخزين التي تستضيف سعة القرص لمثيلات GCE في europe-west1-b. قالت Google إن جميع البيانات تقريبًا تم إيداعها في تخزين مستقر، لكن في حالات قليلة جدًا كانت الكتابات الحديثة غير قابلة للاسترداد، مما أدى إلى فقدان دائم للبيانات على القرص المستمر. الرقم المتكرر على نطاق واسع كان أقل من 0.000001% من مساحة القرص المستمر المخصصة في المنطقة المتأثرة.

يدعم هذا السجل كلاً من ضبط النفس والجدية. سيكون من الخطأ وصف الحدث بأنه تدمير واسع النطاق للبيانات عبر Google Cloud. الخدمة المتأثرة كانت Standard Persistent Disk في منطقة واحدة؛ تم الإبلاغ عن SSD Persistent Disk واللقطات وLocal SSDs في فهارس ما بعد الوفاة والتغطية المعاصرة كخارج نطاق الفقدان الدائم. سيكون من الخطأ أيضًا تجاهل الحادث لأن المقام كان كبيرًا. متانة البيانات هي حقيقة ثنائية للسجل المهم. النسبة المئوية الصغيرة غير القابلة للاسترداد هي لا تزال خسارة دائمة لشخص ما.

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

المحلية والمتانة ليستا نفس الوعد

تحل المحلية السحابية مشاكل حقيقية. قد يختار العميل europe-west1 لزمن الوصول إلى المستخدمين البلجيكيين أو الأوروبيين، أو لأسباب الشراء، أو لخصائص الكربون المنخفضة، أو لالتزامات موقع البيانات. تشرح صفحة مواقع السحابة الحالية لـ Google ووثائق المناطق والنطاقات في Compute Engine أن الموارد تعيش في مناطق ونطاقات، وأن النطاقات والمناطق هي تجريدات منطقية للموارد المادية الأساسية. هذا التجريد مفيد لأن العملاء لا يحتاجون إلى إدارة المباني. إنه خطير إذا استنتج العملاء أن المورد النطاقي قد هرب من نطاق العطل المادي.

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

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

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

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

المحفز المادي ينتمي إلى سجل مساءلة السحابة

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

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

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

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

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

إرشادات اللقطة هي حيث تصبح المسؤولية المشتركة ملموسة

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

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

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

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

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

الأقراص الإقليمية والنسخ المتماثل يغيران نموذج الفشل، وليس الحاجة إلى التفكير في الاسترداد

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

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

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

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

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

أدلة استرداد العميل هي جزء من الحادث

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

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

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

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

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

لا ينبغي للمشتريات شراء منطقة كما لو كانت نسخة احتياطية

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

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

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

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

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

الفرق الصغيرة تحتاج إلى إعدادات افتراضية تجعل قابلية الاسترداد مرئية

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

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

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

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

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

فقدان البيانات يغير الوزن الأخلاقي للغة الحالة

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

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

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

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

يجب أن تتضمن قرارات الموقع قصة خروج

يجب أن يتضمن كل قرار موقع قصة خروج: إذا فشل هذا النطاق أو المنطقة أو خيار التخزين المحلي، أين يذهب حمل العمل وما البيانات التي تتبعه؟ العميل الذي يختار europe-west1-b في 2015 يحتاج إلى معرفة ما إذا كان القرص الفاشل يمكن استعادته في نطاق آخر، وما إذا كانت اللقطة موجودة خارج النظام الفاشل، وما إذا كان التطبيق يمكنه إرفاق القرص المستعاد، وما إذا كان DNS وبيانات الاعتماد والمشغلون يمكنهم إعادة الخدمة. هذه الأسئلة لا تزال حالية على الرغم من تغير أسماء المنتجات وميزاتها.

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

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

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

المجهولات والحدود الدقيقة

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

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

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

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

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

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

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

يجب أن يكون لهذا المالك أيضًا سلطة تمويل النسخ الاحتياطي.

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

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