تحديث نظامنا القديم: كيف أنقذنا نمط ‘التين الخانق’ من كارثة محققة؟

ذاكرة لا تُنسى: ليلة إطلاق المشروع الذي كاد أن ينهار

يا جماعة، لا زلت أذكر تلك الليلة وكأنها البارحة. كنا في شركة ناشئة، وكان عندنا نظام متجانس (Monolith) قديم، مكتوب بلغة برمجة وتقنيات عفا عليها الزمن. هذا النظام كان قلب الشركة النابض، لكنه في نفس الوقت كان “العلّة” الأكبر. أي تعديل بسيط كان يأخذ أسابيع من الاختبارات خوفاً من كسر شيء في مكان آخر لا يخطر على بال. كنا نسميه “البيت المسكون”، الكل يخاف يقترب منه.

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

قضينا 9 أشهر كاملة، والله شهيد، ونحن نعمل ليل نهار. القهوة صارت صديقنا الوحيد، والاجتماعات الطويلة أصبحت روتيننا اليومي. الفريق كان منهكاً، لكن الأمل بإطلاق النظام الجديد كان يدفعنا. جاء يوم الإطلاق الموعود… وبدأت الكارثة. بيانات لم تهاجر بشكل صحيح، خدمات تسقط الواحدة تلو الأخرى، والمستخدمون يشتكون من أخطاء لم يروها من قبل. حاولنا إصلاح المشاكل على الهواء مباشرة، لكننا كنا كمن يحاول إطفاء حريق غابة بكوب ماء. بعد 4 ساعات من الجحيم، اتخذنا القرار الصعب: “أعيدوا النظام القديم!”.

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

جحيم الترحيل الشامل أو “Big Bang Migration”

قبل أن نغوص في الحل، دعونا نفهم لماذا فشلنا فشلاً ذريعاً. الطريقة التي اتبعناها تسمى في عالم هندسة البرمجيات بـ “Big Bang Migration” أو “الترحيل دفعة واحدة”. وهي تعني أنك تبني نظاماً جديداً بالكامل بالتوازي مع النظام القديم، وفي يوم الإطلاق، تقوم بإطفاء القديم وتشغيل الجديد.

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

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

بصيص الأمل: نمط التين الخانق (The Strangler Fig Pattern)

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

هذا بالضبط ما يفعله نمط التين الخانق في البرمجيات. الفكرة عبقرية في بساطتها.

“الفكرة هي إنشاء نظام جديد حول النظام القديم، وجعله ينمو تدريجياً على مدى فترة من الزمن حتى يحل محله بالكامل. في النهاية، يمكنك إيقاف تشغيل النظام القديم.” – مارتن فاولر

الفكرة ببساطة: لا تهدم البيت القديم، بل ابنِ الجديد حوله

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

خطوات عملية لتطبيق نمط التين الخانق

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

الخطوة الأولى: تحديد الوظيفة المراد خنقها (Identify Functionality)

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

الخطوة الثانية: بناء الواجهة الأمامية (Façade) أو البروكسي

هذا هو قلب النمط. تحتاج إلى مكون يجلس بين المستخدم والنظام القديم. يمكن أن يكون هذا reverse proxy مثل NGINX أو HAProxy، أو بوابة واجهة برمجية (API Gateway)، أو حتى تطبيق بسيط من صنعك. مهمته هي فحص الطلب القادم وتوجيهه إما للنظام الجديد أو القديم.

كمثال بسيط باستخدام Node.js و Express، يمكن أن يبدو البروكسي هكذا:

const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');

const app = express();

const LEGACY_SYSTEM_URL = 'http://legacy-system.internal';
const NEW_CART_SERVICE_URL = 'http://new-cart-service.internal';

// كل الطلبات التي تبدأ بـ /api/v2/cart تذهب للخدمة الجديدة
app.use('/api/v2/cart', createProxyMiddleware({ 
    target: NEW_CART_SERVICE_URL, 
    changeOrigin: true,
    pathRewrite: {
        '^/api/v2/cart': '/api/cart', // لإعادة كتابة المسار إذا لزم الأمر
    },
}));

// أي طلب آخر يذهب للنظام القديم كالمعتاد
app.use('/', createProxyMiddleware({ 
    target: LEGACY_SYSTEM_URL, 
    changeOrigin: true 
}));

app.listen(80, () => {
    console.log('Strangler Fig Proxy is running on port 80');
});

هذا الكود البسيط يقوم بتوجيه أي طلب يبدأ بـ /api/v2/cart إلى خدمة سلة التسوق الجديدة، بينما أي طلب آخر يذهب مباشرة إلى النظام القديم.

الخطوة الثالثة: بناء الخدمة الجديدة

الآن قم ببناء خدمة سلة التسوق الجديدة (new-cart-service) باستخدام أحدث التقنيات التي تريدها. ركز فقط على وظائف سلة التسوق. قد تحتاج هذه الخدمة إلى الوصول إلى نفس قاعدة البيانات القديمة في البداية، أو قد تقوم بمزامنة البيانات اللازمة لها. (سنتحدث عن البيانات لاحقاً).

الخطوة الرابعة: التوجيه والتحويل التدريجي

بعد أن أصبحت الخدمة الجديدة جاهزة، تقوم بتحديث البروكسي (كما في الكود أعلاه) لتوجيه الطلبات إليها. يمكنك القيام بذلك تدريجياً. مثلاً، يمكنك في البداية توجيه 1% فقط من المستخدمين للخدمة الجديدة (باستخدام تقنيات مثل Canary Releases)، ومراقبة الأداء والأخطاء. إذا كان كل شيء على ما يرام، تزيد النسبة إلى 10%، ثم 50%، حتى تصل إلى 100%.

الخطوة الخامسة: المراقبة والتكرار (حبة حبة)

المراقبة (Monitoring) هي عينك التي لا تنام. يجب أن يكون لديك لوحات تحكم (Dashboards) تظهر أداء وصحة كل من النظام القديم والخدمات الجديدة. بعد نجاح ترحيل أول جزء، احتفل مع الفريق، ثم اختر الجزء التالي الذي تريد “خنقه”، وكرر العملية. ربما يكون نظام إدارة المستخدمين هو التالي، أو البحث عن المنتجات… وهكذا.

لماذا يعتبر هذا النمط منقذاً؟

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

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

متى يجب أن تفكر مرتين؟

رغم روعته، هذا النمط ليس حلاً لكل المشاكل. هناك حالات قد لا يكون فيها الخيار الأمثل:

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

نصائح من أبو عمر (من قلب المعركة)

من خلال تجربتي مع هذا النمط، تعلمت بعض الدروس التي أود مشاركتها معكم:

1. ابدأ بالأسهل والأقل أهمية: أول قطعة “تخنقها” هي بمثابة تجربة لإثبات المفهوم. اختر شيئاً لا يسبب كارثة إذا فشل، مثل صفحة “من نحن” أو “الأسئلة الشائعة”.
2. البيانات هي التحدي الأكبر: كيف ستتعامل الخدمة الجديدة مع البيانات؟ هل ستقرأ وتكتب في نفس قاعدة البيانات القديمة؟ (مقبول في البداية ولكنه ليس مثالياً). هل ستقوم بمزامنة البيانات بين قاعدة بيانات قديمة وجديدة؟ (أكثر تعقيداً ويتطلب أدوات مثل Debezium أو Kafka). فكر في استراتيجية البيانات جيداً قبل البدء.
3. المراقبة ليست رفاهية: استثمر في أدوات المراقبة والتنبيه (مثل Prometheus, Grafana, Datadog). يجب أن تعرف فوراً إذا بدأت الخدمة الجديدة بإظهار أخطاء أو بطء.
4. لا تنسَ واجهة المستخدم (UI): إذا كان نظامك يحتوي على واجهة مستخدم، يمكنك تطبيق نفس النمط عليها. يمكنك استبدال أجزاء من الواجهة القديمة بمكونات حديثة (باستخدام تقنية مثل Micro Frontends).
5. تواصل مع الإدارة: اشرح للإدارة قيمة هذا النهج من منظور الأعمال (تقليل المخاطر، تسليم قيمة أسرع). عندما يرون النتائج الإيجابية بسرعة، ستحصل على دعمهم الكامل.

الخلاصة: لا تخف من الوحش القديم، بل روّضه 🐢

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

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

فلا تدع نظامك القديم يكون “البيت المسكون” الذي تخافه. بل انظر إليه كشجرة قديمة يمكنك أن تزرع عليها بذرة المستقبل. بالتوفيق يا جماعة في رحلات تحديثكم! 💪

أخوكم،
أبو عمر