التصنيف الحرجية لنظم المعلومات

"يعتبر Alfa-bank موثوقًا مثل الخزان ،

كما أن بنك Gamma موثوق به مثل البنوك!"



فيكتور بيليفين ، "Numbers"

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







إذا نظرت إلى الوظائف الشاغرة للمطورين في البنك ، فمن الممكن تمامًا أن ترى هناك من بين متطلبات المعرفة الخاصة بـ Cassandra و MongoDB ومنصات أخرى ، والتي لا تلهم بأي حال الأفكار حول توفرها بنسبة 100 ٪. ويتم تثبيت نظام DBMS مثل Oracle أو Microsoft SQL Server في مكان ما على مجموعة من الخوادم باهظة الثمن المتصلة بالمصفوفات الأكثر موثوقية وعالية الأداء ، وفي مكان ما على جهاز افتراضي عادي في مزرعة من نفس السلعة.



الأسباب واضحة - الحلول الزائدة عن الحاجة باهظة الثمن. ولكن كيف يمكن إيجاد حل وسط بين تكلفة النظام الأساسي وموثوقيته؟



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

• خوادم فئة hi-end مع صفيفات قرص من الفئة hi-end بالإضافة إلى النسخ المتماثل المتزامن ؛
• خوادم الطبقة المتوسطة مع صفائف القرص متوسطة المدى بالإضافة إلى النسخ المتماثل المتزامن ؛
• الخوادم متوسطة المدى مع مصفوفات القرص متوسطة المدى بالإضافة إلى النسخ المتماثل غير المتزامن ؛
• خوادم السلع ذات صفائف القرص متوسطة المدى بدون نسخ.

الآن كيف تختار تكوينًا لقاعدة بيانات معينة تنتمي إلى تطبيق معين؟



يمكنك عمل قائمة "بأهم التطبيقات التي يجب أن تعمل بأي ثمن". يثير هذا مشكلتين:



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



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



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



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

• البلاتين.
• ذهب؛
• فضة؛
• برونزية.

او مثل هذا:

• مهمة حرجة
• الأعمال الهامة؛
• تشغيل الأعمال
• إنتاجية المكتب.

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



عند التقييم ، من المهم مراعاة قاعدتين:



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



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



ما الذي يحدد مستوى الحرجية؟

• . , , , .
• SLA (service level agreement). , – , .
• . , , .

في الممارسة العالمية ، تم تطوير شيء مثل هذا:







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



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



دعونا نلقي نظرة على العديد من الأنظمة المصرفية.



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



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



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



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



لذلك ، يمكن تقسيم النتائج السلبية لتعطل النظام إلى 4 فئات:

• اقتصادية (خسائر مباشرة) ؛
• العميل (رفض الخدمة) ؛
• السمعة (ردود الفعل السلبية في وسائل الإعلام) ؛
• قانوني (من الإنذارات والغرامات إلى الدعاوى القضائية وإلغاء الترخيص).

لكل فئة من العواقب ، يجب صياغة معايير الخطورة وتخصيص درجات من 0 إلى 4. على سبيل المثال ، قد يبدو الجدول كما يلي:





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



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



الآن يملأ مالك كل نظام مصفوفة من 16 خلية. الأرقام الواردة في الجدول أدناه معطاة كأمثلة. الشيء الوحيد المهم بشكل أساسي هو أن تقدير النتائج لفترة أطول لا يمكن أن يكون أقل من التقدير لفترة أقصر.





بقيت ثلاث خطوات للحصول على النتيجة النهائية من هذه المصفوفة.

الخطوة الأولى - لكل فترة زمنية ، حدد الحد الأقصى للتقدير:





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





لهذا النظام نحصل على التقديرات التالية:





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



بعد تلقي هذه التقديرات ، يمكننا اختيار حل أو آخر للبنية التحتية لكل نظام.



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



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



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



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



قم بتسمية أنظمتك - وقد تكون بنيتك التحتية موثوقة كما يجب ، ولكن ليست أغلى مما يمكن أن تكون!