تقييم أهمية التطبيقات لتخطيط استمرارية الأعمال

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

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

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

ما الذي يقيسه تقييم أهمية التطبيق فعليًا

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

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

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

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

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

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

مستويات الأهمية الحرجة القياسية

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

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

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

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

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

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

منهجية التقييم: تحويل الأبعاد إلى أرقام

تُحوّل منهجية التقييم المنظمة أبعاد الأهمية الأربعة إلى درجة رقمية تُحدد مستوى الأهمية بموضوعية، بدلاً من التأثر بالاعتبارات التنظيمية. ويُنتج النهج الموضح أدناه درجة مركبة تتراوح بين 0 و100 باستخدام معايير مُرجّحة.

البُعد الأول: التأثير على الأعمال (الوزن: 35%)

تأثير الإيرادات لكل ساعة من وقت التوقف	العلامة
أكثر من مليون دولار في الساعة	35
من 100 ألف دولار إلى مليون دولار في الساعة	28
من 10 دولار إلى 100 دولار في الساعة	21
من 1 دولار إلى 10 دولار في الساعة	14
أقل من 1 دولار في الساعة	7
لا يوجد تأثير مباشر على الإيرادات	0

يضيف التأثير التنظيمي (التزامات الامتثال لـ DORA و HIPAA و PCI-DSS و SOX الناجمة عن انقطاع الخدمة) ما يصل إلى 10 نقاط إضافية إلى هذا البعد.

البُعد الثاني: الاعتماد التشغيلي (الوزن: 30%)

مدخلات المروحة: التطبيقات التي تعتمد على هذا التطبيق	العلامة
أكثر من 20 تطبيقًا تابعًا	30
10-20 تطبيقات تابعة	24
5-9 تطبيقات تابعة	18
2-4 تطبيقات تابعة	12
طلب تابع واحد	6
لا يوجد معالين (مستقل)	0

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

البُعد الثالث: تعقيد التعافي (الوزن: 20%)

الوقت المقدر للاستعادة بدون نظام استعادة البيانات المُعد مسبقًا	العلامة
> 72 ساعة	20
ساعات 24-72	16
ساعات 8-24	12
ساعات 2-8	8
<ساعات 2	4
تجاوز الفشل التلقائي في أقل من 15 دقيقة	0

البُعد الرابع: حساسية البيانات والالتزامات التنظيمية (الوزن: 15%)

تصنيف البيانات والمتطلبات التنظيمية	العلامة
معلومات شخصية حساسة/معلومات صحية محمية/بيانات صحية متعلقة بالرعاية الصحية مع التزام صريح بفترة استرداد محددة	15
البيانات الخاضعة للتنظيم دون التزام بوقت استرداد محدد	12
بيانات داخلية حساسة (أسرار تجارية، سجلات مالية)	9
بيانات التشغيل الداخلية	6
بيانات داخلية غير حساسة	3
لا يتم تخزين أي بيانات	0

ربط النتيجة المركبة بالمستوى:

النتيجة المركبة	تحديد المستوى
75-100	المستوى 1، مهمة بالغة الأهمية
50-74	المستوى الثاني، بالغ الأهمية للأعمال
25-49	المستوى الثالث، العمليات التجارية
0-24	المستوى الرابع، إداري

مشكلة الاعتمادية: لماذا يخطئ التقييم القائم على الاستبيان؟

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

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

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

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

ثلاثة أنواع من التبعية التي تغفلها الدراسات الاستقصائية باستمرار:

مكونات مشتركة خفية. يُعدّ برنامج COBOL داخلي يُعنى بتحويل العملات لثلاث عمليات تجارية منفصلة، ​​لم يُحدد الاستطلاع أيًّا منها كمكون مشترك، تبعية خفية تؤثر على استعادة العمليات الثلاث. إذا كان برنامج تحويل العملات من المستوى الثالث، وكانت أيٌّ من العمليات التجارية الثلاث من المستوى الأول، فإنّ الأهمية الفعلية لبرنامج تحويل العملات تُصبح من المستوى الأول.

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

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

تكامل خطة استمرارية الأعمال: كيف تؤثر درجات الأهمية على قرارات التعافي

تُعتبر درجة الأهمية مدخلاً لستة قرارات تصميمية محددة لاستمرارية الأعمال:

1. تعريف تسلسل الاستعادة. تستعيد التطبيقات نفسها حسب ترتيب أهميتها، حيث تستعيد التطبيقات من المستوى الأول قبل التطبيقات من المستوى الثاني قبل التطبيقات من المستوى الثالث، ولكن ضمن كل مستوى، يحدد مخطط التبعية التسلسل. يمكن للتطبيقات التي ليس لها تبعيات واردة (أي لا يعتمد عليها أي تطبيق آخر) أن تستعيد نفسها بأي ترتيب ضمن مستواها. يجب أن تستعيد التطبيقات ذات التبعيات الواردة العالية نفسها قبل التطبيقات التابعة لها، بغض النظر عن درجاتها النسبية ضمن المستوى. وبالتالي، يكون تسلسل الاستعادة كما يلي: ترتيب المستويات مطبقًا على التسلسل الفرعي المقيد بالتبعية ضمن كل مستوى.

٢. تحديد أهداف وقت الاستعادة المستهدف (RTO) وهدف نقطة الاستعادة (RPO). تُستخدم درجة الأهمية لمعايرة أهداف RTO وRPO. يُشكل الحد الأقصى المسموح به لوقت التوقف (MTD) وهدف نقطة الاستعادة (RPO) لكل تطبيق إنتاجي الأساس التقني لاستراتيجية استمرارية العمل بأكملها. يُمثل MTD أقصى مدة زمنية يُمكن للشركة تحملها في حال عدم توفر التطبيق. يجب أن يكون RTO أقل من MTD. يُمثل الهامش بين RTO وMTD هامش الأمان. تتميز تطبيقات المستوى الأول ذات التأثير الكبير على العمل لكل ساعة توقف بهوامش MTD/RTO ضيقة، وتتطلب بنية تحتية مُصممة للاستعادة الآلية السريعة.

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

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

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

٦. متطلبات اتفاقية مستوى الخدمة للموردين. بالنسبة للتطبيقات التي تعتمد على خدمات جهات خارجية، تحدد درجة الأهمية متطلبات اتفاقية مستوى الخدمة التي يجب تضمينها في عقود الموردين. يتطلب تطبيق من المستوى الأول ذو وقت استعادة (RTO) مدته ٤ ساعات اتفاقية مستوى خدمة من جهة خارجية تضمن توافرًا يتوافق مع وقت الاستعادة هذا. أما تطبيق من المستوى الرابع فلا يتطلب ذلك.

تعقيدات النظام القديم

تُعقّد الأنظمة القديمة عملية تقييم الأهمية بطرق لا تُعالجها أطر إدارة محافظ التطبيقات الحديثة بشكل كافٍ. يفترض التقييم القياسي للأهمية أن مالكي التطبيقات على دراية بوظائف تطبيقاتهم ومن يعتمد عليها. بالنسبة للأنظمة القديمة، وبرامج COBOL التي تمت صيانتها من قِبل أجيال متعددة من المطورين، وتدفقات وظائف JCL التي تم توثيق تبعياتها آخر مرة في عام 2008، وبرامج RPG التي تُنتج ملفات إخراج تستهلكها عمليات لم يكتبها أي شخص يعمل حاليًا في المؤسسة، فإن هذا الافتراض لا يصح.

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

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

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

كيفية SMART TS XL يوفر أدلة الاعتماد على تقييم الأهمية الحرجة

SMART TS XL يتناول هذا البحث بُعد التبعية في تقييم أهمية التطبيقات بشكل مباشر، وذلك بالنسبة لفئة التطبيقات التي تكون فيها الأساليب القائمة على الاستبيان أقل موثوقية.

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

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

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

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

بالنسبة للمنظمات التي تدير تحديث التراث البرامج بالتوازي مع تطوير خطة استمرارية الأعمال، SMART TS XLيخدم تحليل 's كلا الغرضين في آن واحد: خريطة التبعية التي تُستخدم في تحديد درجة الأهمية تحدد أيضًا تسلسل الترحيل، ومقاييس التعقيد التي تُستخدم في تحديد درجة تعقيد الاسترداد تحدد أيضًا تقدير جهد التحديث.

تحديث النتائج: دورة المراجعة السنوية

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

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

ينبغي أن تتضمن دورة المراجعة السنوية لدرجات الأهمية ما يلي:

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

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

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

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

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

لا تكون النتيجة جيدة إلا بقدر ما تعتمد عليه الأدلة.

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

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

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