Yandex Cloud تستعيد 97.16% من البيانات بعد الهجمات على مراكز البيانات، والنسخ الاحتياطي يصبح مفعّلاً افتراضياً

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

ما الذي حدث وما الأرقام

وفق معلومات نُشرت بالاستناد إلى وكالة إنترفاكس، استعادت Yandex Cloud الوصول إلى 97.16% من بيانات العملاء. وقد حدث ذلك رغم أضرار جسيمة في المعدات، أي أن الأمر لا يتعلق بعطل قصير، بل بضرر مادي أصاب البنية التحتية.

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

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

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

ما الذي يتغير في المنتج

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

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

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

ماذا يفعل المطوّر والمؤسس

الدرس هنا واقعي، بلا استنتاجات كبيرة.

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

القيود

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

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