لا تفترض المرونة من مزودك السحابي

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

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

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

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

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

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

ما الذي يعنيه الاعتماد على السحابة حقًا؟

أصبحت مرونة السحابة أكثر صعوبة لأن أنظمة الشركات أصبحت الآن مترابطة بعمق. التطبيق الحديث النموذجي هو مجموعة من الخدمات المدارة، وواجهات برمجة التطبيقات (APIs)، ومنصات الهوية، ومخازن البيانات، وقوائم انتظار الرسائل، وأدوات المراقبة (observability tools)، وخطوط أنابيب النشر، وضوابط الأمان، وعمليات التكامل مع أطراف ثالثة.

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

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

كيف يمكن للشركات بناء مرونة سحابية حقيقية؟

السحابة المتعددة ليست اختصارًا. أحيانًا يكون هذا صحيحًا. ولكن غالبًا ما يكون تشتيتًا مكلفًا.

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

الإجابة الأفضل هي المرونة الخاصة بعبء العمل. ليس كل نظام يحتاج إلى نشر نشط-نشط (active-active) عبر المزودين. بعض أعباء العمل تحتاج إلى بنية متعددة المناطق (multiregion) ضمن مزود واحد. البعض الآخر يحتاج إلى تجاوز فشل نشط-سلبي (active-passive failover). بعضها يحتاج إلى نسخ احتياطي واستعادة قويين. وبعضها يمكن أن يتحمل ساعات من التوقف مع تأثير تجاري ضئيل.

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

خطة المرونة التي لم يتم اختبارها هي مجرد نظرية. لدى العديد من الشركات رسوم بيانية معمارية تُظهر مسارات تجاوز الفشل التي لم يتم ممارستها مطلقًا. لديهم نسخ احتياطية لم يتم استعادتها مطلقًا. لديهم أدلة تشغيل للاستعادة (recovery runbooks) تعتمد على خطوات قديمة. لديهم مسارات تصعيد تبدو جيدة في وثيقة ولكنها تفشل أثناء حادث فعلي.

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

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

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

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

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

جرّب الأداة: منسق ومتحقق JSON