ما هي مرونة التطبيقات؟

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

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

في الواقع، 98% من المؤسسات أفادت الآن بأن تكاليف التعطل عن العمل تتجاوز 100000 دولار أمريكي في الساعة، بينما تُقدّر ثلث هذه المؤسسات الخسائر ما بين مليون دولار و 5 ملايين دولار أمريكي.

بِتصميم وتنفيذ تطبيقات مرنة، يمكن للمؤسسات تجنب هذه الاضطرابات والتخفيف من حدتها.

تعتمد مرونة التطبيق على مبدأين أساسيين:

• تحمل الأخطاء: قدرة التطبيق على الاستمرار في العمل عند فشل جزء منه.

• التوافر العالي: قدرة النظام على أن يكون متاحًا وموثوقًا به بنسبة تقترب من 100% من الوقت. 

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

لإنشاء ونشر تطبيقات مرنة، يمكن للمطورين وفرق تكنولوجيا المعلومات استخدام العديد من الأدوات والممارسات خلال دورة حياة التطبيق.

تتضمن المكونات الشائعة للتطبيقات المرنة ما يلي:

• التكرار
• توزيع الأحمال
• احتواء الفشل
• قابلية الملاحظة
• الأتمتة
• التدهور التدريجي
• قابلية التوسع

التكرار يعني وجود نسخ احتياطية للأنظمة الحساسة. إذا فشل أحد الأنظمة، يتولى النظام الاحتياطي المسؤولية، مما يضمن استمرار عمل النظام.

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

عادةً ما تقوم المؤسسات ببناء التكرار في المجالات الرئيسية:

• قواعد البيانات: تخزين نسخ متعددة من البيانات في مواقع مختلفة للمساعدة في ضمان عدم فقدان أي شيء في حالة فشل نظام واحد.

• مراكز البيانات: استضافة التطبيقات عبر مواقع فعلية متعددة بحيث يمكن أن تستمر العمليات حتى في حالة تعطل أحد المواقع.

• البيئات السحابية: توزيع التطبيقات عبر مناطق أو مقدمي خدمات مختلفين—مثل Amazon Web Services (AWS) و Microsoft Azure و IBM Cloud®—بهدف التخلص من نقاط الفشل الفردية.

• اتصالات الشبكة: الاستفادة من عدة مزودين للإنترنت أو الاتصالات للحفاظ على الاتصال أثناء انقطاع الخدمة.

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

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

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

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

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

• إعادة المحاولة التلقائية: عندما يفشل طلب ما بسبب مشكلة مؤقتة (مثل خلل بسيط في الشبكة)، تقوم الشبكة تلقائيًا بإعادة المحاولة مرة أخرى بدلاً من الاستسلام الفوري.

• فصل الدائرة: تقوم الشبكة بمراقبة حالة الخدمة وتوقف مؤقتًا إرسال الطلبات إلى الخدمات التي تواجه صعوبات، مما يمنحها الوقت للتعافي ويمنع الانهيارات على مستوى النظام بالكامل.

• التتبع الموزع: تتبع الشبكة الطلبات أثناء انتقالها بين الخدمات المختلفة، مما يساعد الفرق على اكتشاف التباطؤ وتحديد مكان حدوث المشاكل بدقة.

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

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

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

تلعب الأتمتة دورًا حساسًا في مرونة التطبيق من خلال تمكين الأنظمة من الاستجابة للمشكلات دون الحاجة إلى تدخل يدوي.

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

تتضمن بعض الاستجابات الآلية الرئيسية في مرونة التطبيق ما يلي:

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

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

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

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

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

تستطيع التطبيقات القابلة للتوسع تعديل مواردها تلقائيًا لتلبية متطلبات عبء العمل. تساعد هذه القدرة على ضمان الأداء والتوافر حتى مع تذبذب حركة البيانات.

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

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

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

تؤثر أربعة عوامل بشكل خاص على تزايد التركيز على مرونة التطبيقات.

• توقعات العملاء العالية
• تكلفة فترة التعطل
• التعقيد البنيوي
• الضغوط التنظيمية

يتوقع العملاء أن تعمل الخدمات الرقمية دائمًا. وفقًا لـ Google، فإن 53% من الزوار يتخلون عن صفحة الهاتف المحمول إذا استغرق تحميلها أكثر من ثلاث ثوانٍ.

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

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

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

الحوادث الأخيرة البارزة تُظهر مدى أهمية التأثير الذي يمكن أن تحدثه:

• النقل: في عام 2016، أدى انقطاع في مركز البيانات إلى إلغاء 2000 رحلة جوية وتكبدت شركة طيران كبرى خسائر بقيمة 150 مليون دولار أمريكي.

• التجارة الإلكترونية: خلال ذروة حدث مبيعات في عام 2018، تسببت اضطرابات فنية في خسارة ما يُقدَّر بنحو 72 إلى 99 مليون دولار أمريكي من الإيرادات لمتاجر تجزئة عبر الإنترنت.

• وسائل التواصل الاجتماعي: في عام 2021، تسبب انقطاع الخدمة لمدة ست ساعات في خسارة شركة عملاقة للإنترنت ما يقرب من 100 مليون دولار أمريكي من عائدات الإعلانات المفقودة.

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

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

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

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

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

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

تتضمن بعض قوانين حماية البيانات و الخصوصية الآن معايير التوفر إلى جانب متطلبات الأمان. على سبيل المثال، تتطلب اللائحة العامة لحماية البيانات (GDPR) أن تظل البيانات الشخصية محمية وقابلة للوصول. في حالة فشل النظام، من المتوقع أن تتمكن المؤسسات من استعادة البيانات المفقودة.

تواجه الصناعات شديدة التنظيم، على وجه الخصوص، بعضًا من أكثر المعايير صرامة. 

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

تخضع المؤسسات المالية أيضًا للوائح وتوصيات خاصة بالقطاع من هيئات مثل المجلس الفيدرالي لفحص المؤسسات المالية (FFIEC)، والذي يقدم إرشادات تفصيلية حول خطط استمرارية الأعمال وأهداف وقت التعافي.

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

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

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

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

تعتمد المؤسسات على العديد من المقاييس لتقييم مرونة التطبيق. 

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

يعمل الذكاء الاصطناعي (AI) و التعلم الآلي (ML) على إعادة تشكيل الطريقة التي تتعامل بها المؤسسات مع المرونة. وتوفر هذه التقنيات أدوات جديدة فعالة لمنع فترة التعطل ولكنها تقدم أيضًا تحديات فريدة من نوعها.

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

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

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

وفي الوقت نفسه، فإن الذكاء الاصطناعي له دور مهم في تعزيز مرونة الاستخدام:

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

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

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

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

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