مرونة التطبيقات: الحفاظ على توفر تطبيقات ويندوز

مقدمة

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

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

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

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

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

مرونة التطبيق أكثر من وقت تشغيل الخادم

خطأ شائع هو استخدام توفر الخادم كبديل لتوفر التطبيق، الذي يعمل على الخادم.

لكي يكون تطبيق الأعمال متاحًا حقًا، يجب أن تكون مجموعة من المكونات متاحة في نفس الوقت:

البنية التحتية → نظام التشغيل → التطبيق → التبعيات → مسار الوصول → جلسة المستخدم → العملية التجارية

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

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

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

لماذا تختلف مرونة التطبيقات بالنسبة لتطبيقات ويندوز؟

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

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

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

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

في أي حالة قد تفشل توفر تطبيق ويندوز؟

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

مضيفي التطبيقات

تطبيق يعمل على خادم ويندوز واحد لديه نقطة فشل واحدة واضحة.

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

قواعد البيانات والتخزين والاعتمادات الأخرى

تعتمد العديد من تطبيقات Windows على خدمات خارجية عن مضيف التطبيق. يمكن أن تشمل هذه الخدمات:

• قواعد بيانات SQL
• مشاركة الملفات
• خوادم الترخيص
• Active Directory
• نظام أسماء النطاقات (DNS)
• شهادات
• واجهات برمجة التطبيقات
• الوسيط
• تخزين الشبكة
• بنية الطباعة

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

المصادقة والهوية

لا يمكن للمستخدمين الوصول إلى تطبيق سليم إذا كانت بنية المصادقة اللازمة غير متاحة.

تحتاج فرق تكنولوجيا المعلومات إلى تحديد خدمات الهوية التي تعتمد عليها تطبيقاتها الحيوية والتأكد من وجود خطط احتياطية في حالة عدم توفر هذه الموارد. يمكن الاعتماد على Active Directory ومنصات الهوية السحابية وخدمات المصادقة متعددة العوامل (MFA) وبوابات المصادقة لتوفير سلسلة من التوافر للتطبيق.

شبكات ومسارات الوصول عن بُعد

بالنسبة لتطبيقات ويندوز المركزية، فإن الاتصال بين المستخدمين وبيئة التطبيق يمثل مجال فشل محتمل آخر.

دعونا نتخيل السلسلة الكاملة:

جهاز المستخدم → الإنترنت أو الشبكة المحلية → البوابة → مضيف التطبيق → خدمات الخلفية

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

نقاط النهاية

لا تتطلب مرونة التطبيق بالضرورة توفر محطة العمل العادية للمستخدم.

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

يمكن أن تكون بنية تسليم التطبيقات جزءًا من استراتيجية أوسع لاستمرارية الأعمال.

ما هي عملية بناء مرونة التطبيقات لتطبيقات ويندوز؟

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

1. تحديد التطبيقات الحيوية والعمليات التجارية

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

هدفان للاسترداد يترجمان متطلبات العمل إلى مواصفات فنية. إرشادات التخطيط للطوارئ من NIST يحدد هدف وقت الاسترداد (RTO) وهدف نقطة الاسترداد (RPO) كمعلمات رئيسية لتحديد متطلبات الاسترداد:

• هدف وقت الاسترداد (RTO): مدة التوقف المقبولة قبل استعادة الخدمة.
• هدف نقطة الاسترداد (RPO): فترة مقبولة لفقدان البيانات، تقاس بالوقت.

يمكن أن يكون للتطبيق المستخدم بشكل مكثف لمعالجة الطلبات وقت استعادة التشغيل (RTO) بالدقائق، في حين أن تطبيق التقارير المالية الذي يتم تشغيله مرة واحدة في الأسبوع يمكن أن يتحمل أيامًا من التوقف.

RTO و RPO يحددان نوع الحماية اللازمة لتطبيق ما: الانتقال الفوري، إعادة استعادة الخدمات بسرعة أو مجرد إجراء استرداد موثق.

2. رسم خريطة سلسلة اعتماد التطبيق بالكامل

وثق كل ما يجب أن يكون موجودًا لكي تقوم التطبيق بعمله.

لا تتوقف عند البرنامج التنفيذي أو خادم ويندوز. لا تنسَ قواعد البيانات، التخزين، المصادقة، DNS، الشبكات، الشهادات، أنظمة الترخيص، البوابات والخدمات الخارجية.

لكل واحد، اسأل:

ماذا يحدث للتطبيق إذا اختفى هذا؟

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

3. إزالة نقاط الفشل الحرجة الفردية

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

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

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

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

4. فصل التطبيقات عن نقاط النهاية الفردية

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

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

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

قدم أكثر من طريقة وصول عملية واحدة

يمكن تحقيق المرونة أيضًا من خلال تجنب الاعتماد غير الضروري على نوع واحد من النقاط النهائية أو طريقة اتصال واحدة.

اعتمادًا على بنية تسليم التطبيقات، يمكن للمستخدمين استخدام خيارات مختلفة الوصول عن بعد طرق، بما في ذلك عميل متوافق مع RDP، مشغل تطبيقات مخصص، بوابة ويب أو جلسة متصفح HTML5.

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

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

6. راقب قبل أن تتحول التدهورات إلى انقطاع

مرونة التطبيق لا تتعلق فقط بالتعافي، ولكن الكشف المبكر يمكن أن يتجنب التدهور إلى انقطاع.

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

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

تنبيهات العتبة تمكّن المسؤولين من التحقيق في المؤشرات السابقة للحادث قبل أن يفقد المستخدمون الوصول.

7. خطط لذروة السعة والتبديل الفوري

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

يجب أن تأخذ التخطيط للسعة في الاعتبار ليس فقط أنماط الاستخدام اليومية ولكن أيضًا أن تأخذ في الاعتبار الذروات بسبب الطلبات الموسمية، وتغيير الورديات، والنمو، أو متطلبات الاستضافة لتطبيقات أخرى.

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

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

8. حماية البيانات والتكوين

لا فائدة كبيرة من خادم ويندوز بديل إذا لم تتمكن تكنولوجيا المعلومات من استعادة المكونات اللازمة لجعل التطبيق يعمل.

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

ستختلف الاستراتيجية اعتمادًا على هدف وقت الاسترداد (RTO) وهدف نقطة الاسترداد (RPO) للتطبيق.

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

9. تقليل نطاق تأثير التغييرات

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

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

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

10. التصميم للتدهور السلس

المرونة ليست مجرد الحفاظ على 100% من الوظائف الطبيعية تعمل في جميع الأوقات.

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

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

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

كيف يجب على فرق تكنولوجيا المعلومات مراقبة مرونة التطبيقات؟

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

نموذج واقعي يتكون من عدة طبقات:

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

طبقة وظيفة الأعمال هي واحدة من أبسط الطبقات التي يمكن تجاهلها.

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

كيف يجب اختبار مرونة التطبيق؟

معمارية مرونة لم تختبر فشلًا مُتحكمًا تحتوي على افتراضات غير مُختبرة.

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

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

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

توفير التكرار الفني فائدة قليلة إذا لم يتم اختبار العمليات لاستعادة الوصول.

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

قبل الشروع في تطبيق ويندوز حرج مرن، يجب أن تكون فرق تكنولوجيا المعلومات قادرة على الإجابة على الأسئلة التالية:

• ما هي العمليات التجارية التي تعتمد على التطبيق؟
• ما هي RTO و RPO الخاصة بها؟
• ما هي الخوادم وقواعد البيانات والخدمات الخارجية التي يحتاجها؟
• أين هي نقاط الفشل الحرجة فيها؟
• هل يمكن لمضيف تطبيق آخر قبول المستخدمين إذا فشل مضيف واحد؟
• هل يمكن للمستخدمين الاتصال إذا كان نقطة النهاية أو الموقع العادي غير متاح؟
• هل هناك سعة احتياطية كافية للتشغيل المتدهور؟
• هل تتم مراقبة مشاكل البنية التحتية والاعتماد والجلسات بنشاط؟
• هل يتم تنبيه المسؤولين قبل أن تصبح العتبات المهمة انقطاعات؟
• هل بيانات التطبيق والتكوين محمية؟
• هل تم اختبار الاستعادة بالفعل؟
• هل يمكن التراجع عن التغييرات الإشكالية؟
• هل تم توثيق تسلسل الاسترداد؟
• هل يمكن للمستخدمين إكمال عملية الأعمال المطلوبة بعد الاسترداد؟

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

ما يهم هو أن قرارات التوافر والتكرار والاسترداد تُتخذ عن عمد، بدلاً من أن تُفترض.

كيف يمكن أن تساعد TSplus في الحفاظ على توفر تطبيقات ويندوز؟

للمؤسسات التي تعتمد على تطبيقات Windows الحالية، يمكننا المساعدة في تحسين التوافر من خلال مركزية التطبيقات على خوادم Windows المدارة وتقديمها للمستخدمين عبر عملاء متوافقين مع RDP، أو الوصول على نمط RemoteApp أو بوابة ويب HTML5. هذا يقلل من الاعتماد على نقاط نهاية المستخدم الفردية ويمنح فرق تكنولوجيا المعلومات مزيدًا من المرونة عندما يحتاج المستخدمون إلى الاتصال من جهاز أو موقع آخر.

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

الختام

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

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