عشرة عوامل خطر تجعل أنظمة الأعمال القديمة خطيرة، والمتاعب اليومية التي تسببها، وخريطة حرارية بسيطة تجمع الاحتمالية والأثر، ونمط «شجرة التين الخانقة» لاستبدال النظام القديم وظيفةً تلو الأخرى.
Author
Anichur Rahaman
نادرًا ما تنهار البرمجيات القديمة دفعة واحدة؛ إنها تتآكل ببطء. تقرير يستغرق كل شهر وقتًا أطول قليلًا، وطريقة دفع جديدة تحتاج إلى «بضعة أسابيع» من العمل، والمطوّر الوحيد الذي يفهم وحدة المخزون يأخذ إجازة، فيتوقف الفريق كله بانتظار عودته.
يشعر أصحاب الأعمال بهذه الأعراض عادة قبل أن يسمّي أحدٌ سببها بوقت طويل. ومهمتي، كمهندس برمجيات معماري يراجع نظامًا قديمًا، أن أحوّل هذا الانزعاج الغامض إلى قائمة مخاطر محددة، وأمنح كلًّا منها درجة، ثم أقترح مخرجًا لا يوقف العمل. وهذا المقال يشرح تلك الطريقة.
ستجد فيه عشرة عوامل خطر ينبغي فحصها، والمتاعب اليومية التي يسببها كل منها، وخريطة حرارية بسيطة لتقييمها، ونهجًا للتحديث يُعرف بـنمط شجرة التين الخانقة (Strangler Fig)، يستبدل النظام القديم جزءًا بعد جزء بدل المراهنة بكل شيء على إعادة كتابة شاملة.
القِدم هنا لا يُقاس بالعمر. قد يكون نظام عمره خمس سنوات حديثًا تمامًا إذا كانت له اختبارات وتوثيق ويعمل على برمجيات مدعومة، وقد يصبح نظام عمره سنتان «قديمًا» إذا لم يعد أحد يجرؤ على تعديله. وإليك تعريفًا عمليًا:
النظام القديم هو أي نظام يعتمد عليه العمل، لكنه لا يمكن تعديله بأمان أو بسرعة أو بتكلفة معقولة.
بهذا المعنى، لا يكون السؤال «كم عمر النظام؟»، بل «ما مدى خطورة تغييره، وما مدى خطورة تركه على حاله؟»، ولكلا الخيارين ثمن.
حين ينتهي دعم إصدار لغة البرمجة أو إطار العمل، تتوقف التحديثات الأمنية، ومع كل شهر يمر تتسع الفجوة بين الثغرات المعروفة وما لديك من حماية. ويزداد الترقّي صعوبة مع الوقت، لأن المكتبات تتطور وتتخلى عن دعم إصدارك.
المتاعب اليومية: «لا يمكننا إضافة بوابة الدفع تلك؛ مكتبتها تحتاج إلى إصدار أحدث من PHP».
مطوّر واحد أو متعاقد واحد يعرف كيف يعمل النظام، ولا شيء مكتوب، فإذا غادر غادرت المعرفة معه. وهذا غالبًا أخطر المخاطر أثرًا، وآخر ما ينتبه إليه أصحاب الأعمال.
المتاعب اليومية: الإصدارات والإصلاحات، بل وحتى تصحيح بيانات بسيط، كلها تنتظر وقت شخص واحد.
من دون اختبارات يصبح كل تعديل مقامرة، فيكتفي الفريق بأقل قدر ممكن من التغيير، وتُرقَّع المشكلات من حولها بدل علاجها من جذورها، ويزداد تعديل الشيفرة صعوبة عامًا بعد عام.
المتاعب اليومية: «أصلحنا تقريب مبالغ الفواتير، فصار تقرير الخصومات خاطئًا».
مئات الجداول تقرؤها وتكتب فيها أجزاء التطبيق كلها، وأحيانًا سكربتات خارجية أيضًا. وتعديل عمود واحد قد يعطّل شاشة لم يعد أحد يتذكر وجودها.
المتاعب اليومية: تعديل حقل بسيط يتحول إلى أسبوع كامل من تتبّع آثاره الجانبية.
كلمات مرور مخزّنة بأساليب تجاوزها الزمن، ومفاتيح API مكتوبة داخل الشيفرة، ولوحات إدارة بلا تحقق بخطوتين، وصفحات أخطاء تكشف تفاصيل قاعدة البيانات، ولا حدّ لمحاولات تسجيل الدخول. كل واحدة منها تبدو صغيرة، لكنها مجتمعة بابٌ مفتوح.
المتاعب اليومية: لا أحد يرغب في الإجابة عن الاستبيان الأمني الذي يرسله عميل كبير.
بيانات العملاء في المتجر وفي نظام CRM وفي جدول بيانات، وأرصدة المخزون في النظام وفي دفتر أمين المستودع. وحين تتضارب الأرقام، يفقد الناس الثقة بها جميعًا.
المتاعب اليومية: اجتماعات تُستهلك في الجدال حول أي التقارير هو الصحيح.
ملفات CSV تُرسل ليلًا عبر FTP، وسكربتات تسحب البيانات من موقع أحد الموردين، وتكاملات تتوقف بصمت حين تنتهي صلاحية كلمة مرور. تعمل إلى أن تتوقف، ثم لا يلاحظ أحد لأيام.
المتاعب اليومية: «لم تتحدّث حالات الشحن منذ يوم الثلاثاء».
استعلامات تجلب سجلًا واحدًا في كل دورة من حلقة تكرار، ولا ذاكرة مؤقتة، وتقارير تمسح الجداول كاملة. يمر الأمر بسلام مع ألف طلب، ويصبح مؤلمًا مع مليون.
المتاعب اليومية: تقارير نهاية الشهر تعمل طوال الليل، ويتباطأ المتجر في أثنائها.
لا سجل لمن غيّر سعرًا أو راتبًا أو رصيد مخزون، ولا وسيلة لتصدير البيانات الشخصية للعميل أو حذفها إذا طلب ذلك، ولا توثيق لموافقته. وقوانين حماية البيانات في كثير من الدول تجعل هذه كلها التزامات قانونية، لا ميزات اختيارية.
المتاعب اليومية: سؤال واحد من المدقق يستغرق أسبوعًا للإجابة عنه.
نظام مغلق يتحكم مورّده في تصدير بياناتك، أو يرفع الأسعار عند التجديد، أو يتوقف عن تطوير المنتج. وأحيانًا يكون العقد نفسه هو الخطر الأكبر.
المتاعب اليومية: «نريد الانتقال إلى نظام آخر، لكننا عاجزون عن إخراج بياناتنا بصيغة قابلة للاستخدام».
لست بحاجة إلى مستشار لتبدأ. اجمع من يستخدمون النظام ومن يتولّون صيانته، وامنحوا كل خطر درجة من 1 إلى 5 على محورين:
اضرب الدرجتين. ما يحصل على 15 فأكثر يُعالَج هذا الربع، وما بين 8 و14 يُدرج في خطة التحديث، وما دون 8 يكفي أن يبقى تحت المراقبة. والخريطة الحرارية أعلاه ليست إلا هذا الجدول مرسومًا، وهي أنجح شريحة عرض أعرفها لإقناع مجلس الإدارة بتمويل التحديث.
| الخطر | الاحتمالية (1–5) | الأثر (1–5) | الدرجة | الإجراء |
|---|---|---|---|---|
| بيئة تشغيل بلا دعم | 5 | 5 | 25 | هذا الربع |
| الاعتماد على شخص واحد | 4 | 5 | 20 | هذا الربع |
| الديون الأمنية | 4 | 5 | 20 | هذا الربع |
| غياب الاختبارات المؤتمتة | 4 | 4 | 16 | هذا الربع |
| تكاملات هشّة | 3 | 3 | 9 | خطة التحديث |
| الارتهان للمورّد | 2 | 4 | 8 | خطة التحديث |
هذه الدرجات مثال للتوضيح لا معيار ثابت؛ ستخرج ورشتكم بدرجات مختلفة، والنقاش نفسه نصف الفائدة.
حين تتضح المخاطر، يبدو الحل الأكثر إغراءً: «لنُعِد بناء النظام من الصفر كما ينبغي». لكن إعادة الكتابة الشاملة تفشل أكثر بكثير مما تنجح، ولأسباب يمكن توقعها:
شجرة التين الخانقة نبات يلتف حول شجرة مضيفة وينمو حولها إلى أن يستطيع الوقوف وحده. وفي البرمجيات، ينمو النظام الجديد حول القديم ويتسلّم منه مهمة بعد أخرى، إلى أن يصبح بالإمكان إيقاف النواة القديمة نهائيًا.
ضع طبقة توجيه أمام النظام القديم، كبوابة API أو وسيط خفيف (proxy)، توجّه في البداية 100% من الحركة إلى النظام القديم. وفي الوقت نفسه:
اختر جزءًا مهمًا وحدوده واضحة، مثل الكتالوج والمخزون أو الطلبات، ثم ابنِ الوحدة الجديدة أو اعتمد وحدة جاهزة، ووجّه هذه المهمة إليها.
حين ينتقل آخر جزء، أرشف البيانات التاريخية في تخزين للقراءة فقط، وأوقف ما تبقى من الشاشات القديمة، واحذف الشيفرة القديمة. احتفظ بالبيانات، وتخلّص من الخطر.
لا يستحق كل جزء من النظام القديم المعاملة نفسها؛ فثلاثة أسئلة تحدد مسار كل جزء:
بعض الدروس لا تأتي من الكتب، بل من التجربة:
بُني StoreConsole على مجموعة من الوحدات المستقلة — الكتالوج والمخزون والطلبات والتوصيل والمحاسبة والموارد البشرية والرواتب وCRM وغيرها — تتواصل فيما بينها عبر الأحداث فقط. ولهذا فهو خيار طبيعي لمسار «الاستبدال»: ضع وحدة واحدة خلف واجهة التوجيه، وغذِّها من الصندوق الصادر في النظام القديم، ثم انتقل إلى الوحدة التالية حين تستقر الأولى. وفي كل وحدة سجل للنشاط وصلاحيات قائمة على الأدوار وتحقق بخطوتين، ما يُغلق عدة مخاطر مما سبق منذ اليوم الأول. وتعرض الجولة القصيرة أدناه الأدوار والتحقق بخطوتين وسجل التدقيق.
Anichur Rahaman مهندس برمجيات معماري ومؤسس StoreConsole، يصمّم أنظمة التجارة وERP للشركات النامية، ويهتم خصوصًا بالبنية القائمة على الأحداث وسلامة البيانات وتشغيل الأنظمة على خوادم الشركة نفسها.
About the Author
Anichur Rahaman
Continue Reading
