كيف أنتقل إلى النظام الجديد دون أن يتوقف العمل؟

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

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

لماذا تحتاج الشيفرة المحولة بالذكاء الاصطناعي اختبارا مختلفا

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

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

قارن المخرجات على المعاملات الحقيقية نفسها

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

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

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

الحالات النادرة: اسأل من يعرفها

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

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

توقيع بشري على كل وحدة قبل اعتمادها

أوضح مثال منشور على هذا المبدأ هو مسار تحويل الأنظمة المصرفية الذي أعلنته Thought Machine مع أمازون في 29 سبتمبر 2026. المسار يمر بـ 4 مراحل: استخراج منطق العمل من الأنظمة القديمة بأداة AWS Transform، ثم دمج النسخ المكررة في مواصفات موحدة، ثم توليد المنتجات المالية الجديدة واختباراتها بوكلاء ذكاء اصطناعي، ثم مرحلة التحقق التي تعطي فرق الهندسة والمخاطر في البنك صلاحية توقيع صريحة قبل اعتماد أي شيء. وحتى بعد التوقيع ينقل الناتج إلى بيئة تجريبية معزولة لمزيد من التقييم، لا إلى التشغيل مباشرة.

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

التشغيل المتوازي وخطة الرجوع

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

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

نظرة أوريجامي

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

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

تمرين هذا الأسبوع: ورقة الانتقال لكل وحدة

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

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

القادم

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