الخلاصة

  • أعلن Murex في 23 سبتمبر حصول MX.3 على شهادة للعمل على Google Cloud، فأضاف وجهة إلى مسار سحابي يشمل Azure وAWS. يقول البيان إن عملاء يدرسون الاحتمال، لكنه لا يسمّي تشغيلًا إنتاجياً أو مدة هجرة أو سعراً أو معيار أداء أو نتيجة استعادة.
  • تخفّض الشهادة تكلفة تقييم بنية أخرى، ولا تنقل تلقائياً المراكز المعتمدة والضمانات ولحظة بيانات السوق والصلاحيات وإقرارات الواجهات وتسلسل الإقفال. لا يملك البنك خيار خروج قابلاً للاستخدام إلا إذا أعاد هذه الحالة وطابقها ضمن حد الانقطاع المسموح.

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

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

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

الوجهة الثالثة تمنح خياراً قبل أن تمنح انتقالاً

ليست السحابة جديدة على MX.3. أعلن Murex شهادة Azure في 2017، وتصف صفحة السحابة الحالية دعماً لـAWS وMicrosoft Azure ونماذج متعددة ومساراً تدريجياً من إثبات المفهوم إلى التطوير والاختبار ثم الإنتاج. وفي 2025 أعلن اتفاقاً متعدد السنوات مع AWS لتوسيع الخدمات المُدارة.

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

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

يجب كذلك فصل نموذج الخدمة. يصف إعلان AWS خدمة MXSaaS بأنها مُدارة من Murex من البنية إلى الترقيات، ويعرض XVA as a Service بصورة مستقلة. إعلان Google Cloud يتحدث عن نشر MX.3، ولا يعلن تقديم MXSaaS عليها. الشهادة والبنية التي يديرها العميل والخدمة المُدارة الجاهزة توزع العمل والمسؤولية بصورة مختلفة.

MX.3 تسلسل أعمال وليست حاوية واحدة

يعرض وصف بنية MX.3 طبقات للعرض والأعمال والتنسيق والخدمات التقنية. تتولى الطبقة التقنية المصادقة والتفويض وسجل الخدمات. تستخدم الحسابات تقنيات متعددة؛ ويمكن توزيع تسعير المنتجات المعقدة على CPU أو GPU؛ وتدخل Kubernetes والحاويات في مخاطر السوق والتقارير.

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

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

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

الأصل الحاسم هو آخر حالة أعمال مقبولة

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

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

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

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

التنظيم يطلب خروجاً قابلاً للتنفيذ

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

لا يصادق DORA على بنية MX.3 أو تصميم Google Cloud بعينه، ولا يفرض تشغيل كل عبء بصورة دائمة لدى عدة سحب. بل يبقي المسؤولية على المؤسسة المالية. دعم مورد البرمجيات لوجهة أخرى يساعد، لكنه ليس إثبات خروج العميل.

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

كل نموذج تشغيل يعيد رسم المسؤولية

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

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

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

قد يزيد الاختيار الارتباط قبل أن يخفضه

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

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

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