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

والطريقة لتجنّب ذلك هي البدء بمرحلة الحصر: جرد كامل وموثّق لما هو مثبّت فعليًا. يشرح هذا المقال ما الذي ينبغي جمعه، وكيف تجمعه على Windows وLinux، وما المفاجآت المتوقعة، وكيف تحوّل النتائج إلى خطة ترحيل.

لماذا يسبق الحصرُ الترحيلَ

لا يكون الترحيل أفضل من المعلومات التي يقوم عليها. فمن دون جرد، ستقدّر نطاق العمل اعتمادًا على الذاكرة وجداول بيانات قديمة وسجلات التراخيص، ولا يعكس أيٌّ منها ما يعمل فعليًا اليوم.

يمنحك الجرد الجيد ثلاثة أمور:

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

كما يحميك الجرد في نقاشات التراخيص. فإذا سألك أحد الموردين عن عدد التثبيتات لديك، يتيح لك جرد محدّث أن تجيب بالحقائق بدلًا من التخمين.

ما الذي ينبغي جمعه: الإصدارات والموردون والمسارات والمسؤولون

اجمع لكل تثبيت لـ Java ما يلي على الأقل:

• الجهاز المضيف: اسم الجهاز، وعنوان IP، وما إذا كان خادمًا أو آلة افتراضية أو حاسبًا مكتبيًا.
• الإصدار: سلسلة الإصدار الكاملة، مثل 1.8.0_202 أو 17.0.10، وليس مجرد “Java 8” أو “Java 17”.
• المورّد: الجهة التي بنت بيئة التشغيل، مثل Oracle أو إحدى توزيعات OpenJDK. فرقم الإصدار وحده لا يخبرك بذلك.
• النوع والمسار: هل هي JDK كاملة أم JRE فقط، والمجلد المثبّتة فيه.
• الاستخدام: التطبيقات أو الخدمات التي تستخدمها، إن أمكن معرفة ذلك.
• المسؤول: الفريق أو الشخص المسؤول عن الجهاز أو التطبيق.

وبالنسبة لخوادم Linux، اجمع أيضًا التوزيعة وإصدارها، وإصدار النواة (kernel)، وأهم الحزم المثبّتة، والخدمات قيد التشغيل. فهذا يوضح لك أي الخوادم تدخل ضمن ترحيل Linux إلى جانب ترحيل Java.

Windows وLinux والحواسب المكتبية: أساليب مختلفة

تحتاج كل بيئة إلى طريقة مختلفة قليلًا. الأوامر التالية مجرد نقطة انطلاق؛ أما عمليًا، فتضعها الفرق في سكربت وتشغّله على جميع الأجهزة باستخدام أدوات الإدارة المتوفرة لديها.

خوادم Windows

كثيرًا ما تسجّل بيئات تشغيل Java المثبّتة نفسها في سجل Windows تحت المفتاح HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft، لكن ليس جميعها تفعل ذلك. والبحث في نظام الملفات أكثر موثوقية:

Get-ChildItem -Path C:\ -Filter java.exe -Recurse -ErrorAction SilentlyContinue |
  Select-Object FullName, @{n='Version'; e={$_.VersionInfo.ProductVersion}}

افحص كل محركات الأقراص وليس C: وحده، لأن خوادم التطبيقات كثيرًا ما تُثبَّت على محرك بيانات منفصل.

خوادم Linux

على Linux، اجمع بين مدير الحزم والبحث في الملفات، لأن كثيرًا من بيئات تشغيل Java تُفك من أرشيف بدلًا من تثبيتها كحزمة:

cat /etc/os-release
rpm -qa | grep -i -E 'jdk|jre|java'
find / -xdev -type f -name java -perm -u+x 2>/dev/null

على Debian أو Ubuntu، استخدم dpkg -l | grep -i -E 'jdk|jre' بدلًا من rpm. ولكل ملف java تنفيذي يُعثر عليه، يؤدي تشغيله مع -version إلى عرض الإصدار، والمورّد في أغلب الأحيان. كما تحتوي معظم مجلدات JDK على ملف release يذكر اسم الجهة المنفِّذة (implementor).

الحواسب المكتبية

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

مفاجآت شائعة (بيئات JRE المضمّنة، والخوادم المنسيّة)

يكشف كل مشروع حصر تقريبًا عن أشياء لم يتوقعها أحد. وأكثرها شيوعًا:

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

من الجرد إلى خطة الترحيل

بعد جمع البيانات، وحّدها في مكان واحد وراجعها مع المسؤولين عن الأنظمة. ثم صنّف التثبيتات في فئات:

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

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

كيف يمكن أن تساعدك LOGIQ

تنفّذ LOGIQ مشروعات الحصر والترحيل لبيئات Java وLinux، مستخدمةً سكربتات وإجراءات جرى تحسينها في مشروعات حقيقية لعملائها على خوادم Windows وخوادم Linux والحواسب المكتبية. إذا أردت مساعدة في بناء الجرد أو تحويله إلى خطة ترحيل، تواصل مع LOGIQ.