كان تحديث نظامنا القديم أشبه بجراحة قلب مفتوح: كيف أنقذنا نمط ‘التين الخانق’ من جحيم المخاطرة الكبرى؟

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

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

في تلك اللحظة، رفعت يدي بهدوء وقلت: “يا جماعة، فيه حل ثاني… حل مستوحى من الطبيعة، من شجرة تين عنيدة بتبني حياتها على حساب شجرة قديمة. شو رأيكم نسمع عن نمط ‘التين الخانق’؟”. صمت الجميع، وبدأتُ في سرد قصة نجاتنا التي أشاركها معكم اليوم.

ما هو الجحيم الذي كنا نواجهه؟ (معضلة النظام القديم)

قبل أن نغوص في الحل، دعوني أصف لكم “الوحش” الذي كنا نتعامل معه. نظامنا القديم كان مثالاً كلاسيكياً للنظام المتجانس (Monolith):

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

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

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

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

في عالم البرمجيات، الفكرة مماثلة:

بدلاً من استبدال النظام القديم دفعة واحدة، نقوم ببناء النظام الجديد “حول” النظام القديم، ونقوم بتحويل “حركة المرور” (Traffic) إليه قطعة قطعة، حتى يتم خنق النظام القديم بالكامل ويصبح بلا وظيفة، فيمكننا حينها إيقافه بأمان.

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

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

خُطتنا العملية: كيف طبقنا النمط خطوة بخطوة؟

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

الخطوة الأولى: بناء “الواجهة الخانقة” (The Strangler Facade)

هذه هي أهم خطوة. “الواجهة الخانقة” هي عبارة عن طبقة وسيطة (غالباً بروكسي عكسي – Reverse Proxy) توضع أمام النظام القديم. كل الطلبات من المستخدمين والموبايل والأنظمة الأخرى يجب أن تمر من خلال هذه الواجهة أولاً. في البداية، كل ما تفعله هذه الواجهة هو تمرير جميع الطلبات كما هي إلى النظام القديم.

الهدف هو السيطرة على تدفق الطلبات. من يسيطر على التدفق، يسيطر على عملية الترحيل.

مثال عملي (باستخدام NGINX كبروكسي عكسي):

في البداية، كان ملف الإعدادات بسيطاً جداً:

# api.mycompany.com.conf

server {
    listen 80;
    server_name api.mycompany.com;

    location / {
        # في البداية، كل شيء يمر إلى النظام القديم
        proxy_pass http://legacy_monolith_app:8080;
        proxy_set_header Host $host;
    }
}

الخطوة الثانية: تحديد وتقطيع “الضحية” الأولى

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

قمنا باختيار وحدة “إدارة المستخدمين” (User Management)، لأنها كانت معزولة نسبياً ويمكننا بناء خدمة مصغرة جديدة لها باستخدام تقنيات حديثة مثل Node.js وقاعدة بيانات جديدة.

الخطوة الثالثة: الهجرة والتحويل (Migrate and Switch)

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

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

مثال عملي (تحديث إعدادات NGINX):

# api.mycompany.com.conf (بعد ترحيل المستخدمين)

server {
    listen 80;
    server_name api.mycompany.com;

    # الطلبات المتعلقة بالمستخدمين تذهب للخدمة الجديدة
    location /api/users {
        proxy_pass http://new_users_microservice:3000;
        proxy_set_header Host $host;
    }

    # أي شيء آخر لا يزال يذهب إلى النظام القديم
    location / {
        proxy_pass http://legacy_monolith_app:8080;
        proxy_set_header Host $host;
    }
}

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

الخطوة الرابعة: اغسل، اشطف، وكرر (Wash, Rinse, Repeat)

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

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

نصائح من قلب المعركة

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

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

الخلاصة: لماذا أنقذ “التين الخانق” يومنا؟ ✅

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

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