منصة مجتمعات العملاء كخدمة (SaaS): تخفيض التكاليف بنسبة 75-80%. اختصار وقت الإعداد من أسبوعين إلى ست ساعات. إعادة بناء المنصة المعيارية لتوسيع نطاقها دون المساس بميزاتها الأساسية.

التحدي

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

النهج

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