تسود أوساط تقنية المعلومات المؤسسية خرافةٌ مريحة تقول إنّ النظام الأساسي المتقادم، الذي مضى على تشغيله خمسة عشر عامًا، جدارٌ تهدمه في نهاية المطاف خلال عطلة أسبوع بطولية واحدة: تُجمّد أعمال الشركة، وتنتقل إلى المنصة الجديدة ليلة السبت، ثم تعيد الافتتاح يوم الإثنين وقد وُلدت من جديد. أمّا في الواقع، فإنّ إعادة الكتابة الكاملة دفعةً واحدة هي المقبرة التي تُدفن فيها الميزانيات والسمعات. ومعظم هذه المشاريع يُهجر بهدوء بعد عامين من انطلاقه، ولم يُنتج سوى نظام موازٍ لم يلحق يومًا بالنظام القديم الذي ما زال يُدير الشركة.
لذلك، حين طلب منّا تاجر تجزئة وطني المساعدة في إحالة نظام ERP المتقادم لديه إلى التقاعد، كان أول التزام قطعناه هو الالتزام الذي أثار انزعاج كلّ من في القاعة: لن نُطفئ النظام القديم.
خلفية الوضع
يُشغّل العميل نحو 60 متجرًا على امتداد المنطقة، وجميعها مرتبطة بنظام ERP أحادي متجانس (monolith) جرى نشره أول مرة قبل خمسة عشر عامًا تقريبًا. ومع مرور الوقت، ابتلع هذا النظام كلّ شيء: المخزون، والتسعير، والمشتريات، وبرنامج الولاء، وتسوية المتاجر، بل وحتى جسرًا مخصصًا للرواتب. وكان كلّ تكامل يمتدّ مباشرةً إلى قاعدة بياناته. لم يجرؤ أحد على المساس ببنية الجداول (schema)، لأنّ لا أحد كان يستطيع التنبؤ الكامل بما قد ينكسر، أمّا المهندسان اللذان كانا يفهمان أقدم زواياه فقد غادرا منذ زمن بعيد.
ومع ذلك، كان النظام يعمل. وتلك بالضبط كانت المصيدة. فقد كان يُدير الأعمال بكفاءة كافية جعلت مخاطر التغيير تبدو دائمًا أكبر من كلفة البقاء على حاله، إلى أن بدأت ليالي جرد المخزون تستغرق وقتًا أطول ممّا تحتمله المتاجر، ثمّ وصل إشعار بإيقاف دعم أحد معالجات الدفع مصحوبًا بموعد نهائي صارم يعجز النظام الأحادي عن الوفاء به فعليًا.
التحدّي
كانت القيود قاسية لا تسامح فيها. فتاجر التجزئة لا يستطيع إغلاق أبوابه من أجل عملية ترحيل؛ إذ إنّ كلّ ساعة توقّف تعني إيرادات ضائعة وثقةً مفقودة عند نقطة البيع. وكانت البيانات ممتدة عبر خمسة عشر عامًا وغير متسقة، وقد ترسّخت فيها سنوات من الحلول الالتفافية المؤقتة. كما أنّ المؤسسة كانت — وهذا مفهوم — قليلة الرغبة في المخاطرة بعد أن شهدت انهيار مشروع «تحديث» لدى شركة نظيرة في العام السابق. لقد كنّا بحاجة إلى مسار يمكن إيقافه مؤقتًا، وفحصه، والتراجع عنه في أيّ لحظة؛ لا إلى قفزة في المجهول.
كيف تعاملنا مع الأمر
استبعدنا إعادة الكتابة فورًا، والتزمنا بمنهج «الخنق» التدريجي (incremental strangulation): بناء النظام الجديد حول القديم، وإعادة توجيه قدرة واحدة في كلّ مرة، وترك النظام الأحادي ينكمش حتى يصبح ما تبقّى منه قابلاً للإطفاء بهدوء.
- الرسم قبل المساس. أمضينا الأسابيع الأولى في تتبّع كلّ تكامل وإعادة بناء عقود البيانات الحقيقية — لا الموثّقة — كي نعرف بدقّة ما الذي يعتمد على ماذا.
- بناء حدّ فاصل (seam). وضعنا واجهة API أمام النظام الأحادي، بحيث تتوقف الأنظمة المتصلة عن مخاطبة قاعدة بياناته مباشرةً وتبدأ بمخاطبة واجهة نتحكّم بها نحن.
- الخنق حسب القدرة. أُعيد بناء كلّ مجال — التسعير، ثمّ المخزون، ثمّ الولاء — كخدمة مستقلة خلف تلك الواجهة، وجرى تحويله على حدة، لا دفعةً واحدة أبدًا.
- التوجيه عبر feature flags. كان كلّ تحويل مجرّد قلبٍ لمفتاح يمكننا عكسه في ثوانٍ، بدءًا بمتجر تجريبي واحد، ثمّ منطقة، ثمّ الشبكة بأكملها.
- المطابقة المستمرة. عمل النظامان القديم والجديد بالتوازي، وجرت مقارنتهما ليليًا، وكان أيّ تباين يُعامَل بوصفه مانعًا لإطلاق الإصدار.
ما الذي نفّذناه
بدأنا بالتسعير، وهو المجال الأشدّ إيلامًا والأضيق نطاقًا للأثر، وأقمناه كخدمة قائمة بذاتها تقرأ من نسخة متزامنة من البيانات. وطوال عدّة أسابيع عمل في «وضع الظلّ» (shadow mode): يحسب كلّ سعر بالتوازي مع النظام الأحادي ويسجّل مواضع الاختلاف من دون أن يمسّ عميلاً واحدًا. وحين اتّفق النظامان باطراد، قلبنا المفتاح لمتجر تجريبي واحد، وراقبنا أسبوع تداول كاملًا، ثمّ وسّعنا الطرح منطقةً تلو الأخرى.
ثمّ جاء المخزون، فبرنامج الولاء، وكلٌّ منهما يتّبع الإيقاع ذاته: واجهة، فظلّ، فتجربة، فتوسيع. وعزّزنا الحدّ الفاصل على طول الطريق: أضفنا MFA وضبط وصول سليمًا عند طبقة الـ API، ومركّزنا السجلّات في نظام SIEM لنرى السلوك فعلاً، ونشرنا EDR على أجهزة المتاجر الطرفية التي ظلّت سنوات بلا إدارة. وبحلول انتقال المجال الأخير، كان النظام الأحادي قد تقلّص إلى مهمّة تسوية رفيعة أحلناها إلى التقاعد خلال عطلة أسبوع واحدة — وكانت هي الانقطاع المخطّط الوحيد في البرنامج كلّه، وقصيرًا.
الحصيلة
| المؤشّر | قبل | بعد |
|---|---|---|
| التوقّف المخطّط لعملية الترحيل | تحويل مقدّر بعدّة أيام | أقلّ من عطلة أسبوع، نافذة قصيرة واحدة |
| جرد المخزون الليلي / إغلاق الدُفعات | يتجاوز النافذة الليلية | أسرع بنحو 3× وينتهي بهامش |
| زمن تغيير قاعدة تسعير | أيّام، عبر طلب متخصّص | في اليوم نفسه، خدمة ذاتية |
| التكاملات التي تصل قاعدة البيانات مباشرةً | جميعها تقريبًا | نحو النصف أُحيل، والبقية خلف الـ API |
| خطوات التحويل القابلة للاسترجاع | لا شيء عمليًا | كلّ خطوة قابلة للعكس عبر flag |
لا يبدو أيٌّ من هذه الأرقام مثيرًا بمعزل عن سياقه، وهذا هو بيت القصيد. فقد قِيس نجاح البرنامج بغياب الأحداث: لا يوم تداول ضائع، ولا أزمة جرد مخزون، ولا عنوان صحفي. ظلّت الأعمال تبيع بينما تُستبدل أسسها من تحتها، ولم يعلم معظم موظفي المتاجر أصلاً أنّ عملية ترحيل كانت تجري.
ما الذي صنع الفارق
- القابلية للتراجع تتفوّق على الثقة. لم نثق يومًا بتحويل لا نستطيع عكسه في ثوانٍ. حوّلت الـ feature flags كلّ قرار عالي المخاطر إلى تجربة منخفضة المخاطر وقابلة للمراقبة.
- وضع الظلّ يكسب الثقة بثمن زهيد. إنّ تشغيل الجديد والقديم جنبًا إلى جنب، ومقارنة المخرجات قبل أن يدخل أيّ شيء الخدمة، حوّل قلق العميل إلى دليل، والتقط شوائب البيانات التي ما كان أيّ قدر من التخطيط ليكشفها.
- حدِّث الحدّ الفاصل، لا الشيفرة وحدها. كانت الواجهة هي الموضع الصحيح لإضافة ضوابط الأمن — MFA، وتمركز السجلّات، وحماية الأجهزة الطرفية — التي جعلتها البنية القديمة مستحيلة.
لقد اختفى النظام الأحادي، لكنّ الحصيلة الأبقى هي أنّ التغيير التالي لم يعد يتطلّب شجاعة، بل مجرّد قلب مفتاح. وهذا هو الغرض الحقيقي من التحديث.