عندما ترث نظاماً بلا شيفرة مصدريّة ولا مواصفات ── الإجراءات العمليّة لتشغيله وصيانته دون توقّف

«الشركة التي طوّرته لم تعد موجودة» أو «الموظّف الذي بناه استقال ولا يمكن الوصول إليه» أو «الملفّ التنفيذيّ وقاعدة البيانات موجودان داخل الخادم، لكن لا الشيفرة المصدريّة ولا المواصفات موجودتان» ── حالة ليست نادرة أبداً في استشارات أنظمة الأعمال الخاصّة بالشركات الصغيرة والمتوسّطة. ومع ذلك يستمرّ النظام في العمل اليوم أيضاً، ويعتمد عليه سير العمل.

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

1. الخلاصة أوّلاً

• ما ينبغي فعله أوّلاً ليس التعديل، بل «صون الوضع الحاليّ». بيئة الإنتاج العاملة نفسها هي أهمّ أصل. احصل على نسخة احتياطيّة لصورة القرص (كتحويلها إلى جهاز افتراضيّ عبر Disk2vhd مثلاً) ونسخة احتياطيّة لقاعدة البيانات، وتحقّق حتّى من إمكانيّة الاستعادة قبل الانتقال إلى الخطوة التالية.¹
• حتّى بلا مواصفات مكتوبة، يمكن استعادة المواصفات. المواد الأساسيّة هي مقابلة مستخدمي النظام في العمل، والشاشات والتقارير، ومخطّط قاعدة البيانات، والسجلّات، وملاحظة السلوك الفعليّ عبر Process Monitor.²
• تختلف إمكانيّة استعادة الشيفرة المصدريّة اختلافاً كبيراً باختلاف مجموعة التقنيّات (technology stack). فمنتَجات .NET يمكن قراءتها إلى حدّ بعيد عبر مُفكِّكات (decompilers) مثل ILSpy، بينما استعادة شيفرة أصليّة (native code) مثل VB6 أو C++ لا يُرتجى منها واقعيّاً.³⁴
• لفكّ التجميع (decompile) نقاط قانونيّة يجب مراعاتها. بموجب المادّة 30-4 من قانون حقوق التأليف والنشر، يُنظَّم استخدام أغراض التحليل والفحص على أنّه مسموح به من حيث المبدأ، لكنّ التحقّق من العقد (بنود ترخيص الاستخدام) أمر لا بدّ منه.⁵
• لا تنتظر «بعد الفهم الكامل». افهم أوّلاً، على سبيل الأولويّة، المواضع التي يتوقّف بها سير العمل إذا توقّفت والمواضع القريبة من الحاجة للتغيير، واجعل التغيير صغيراً وواحداً في كلّ مرّة وبشكل قابل للتراجع.
• عقد الصيانة يكون أساساً شبه تفويض. لا يمكن الوعد بمسؤوليّة إتمام النتيجة (عقد المقاولة) لتحقيق نظام مجهول المحتوى. يُعقَد العقد بفصل مرحلة التحقيق عن مرحلة التعديل.

هذا المقال مرتَّب بترتيب الخطوات في العمل الفعليّ. والصورة الكاملة كالتالي.

flowchart TD
    A["الفصل 3: الصون. تجميد التغييرات وصورة القرص ونسخة قاعدة البيانات مع التحقق من الاستعادة"] --> B["الفصل 3: الجرد. الملفات التنفيذية والتشغيل التلقائي والمهام والإعدادات والجهات المتصلة والحسابات"]
    B --> C["الفصل 4: استعادة المواصفات. المقابلات والشاشات والتقارير ومخطط قاعدة البيانات ومراقبة السلوك الفعلي"]
    C --> D["الفصل 5: الإمكان تقنياً. تقدير مجموعة التقنيات وفك التجميع والتحقق القانوني"]
    D --> E["الفصل 6: تحديد الاتجاه. الإطالة أو التغليف أو إعادة البناء الجزئي أو إعادة البناء الكاملة"]
    E --> F["الفصل 7: الانتقال إلى التشغيل. بيئة التحقق وسجل التغييرات والمراقبة والعقد"]
    C -.->|"سجل المواصفات المستعادة يبقى أصلاً أيّاً كان الاتجاه المختار"| E

الشكل 1: التدفق الكامل للتسلّم والفصول المقابلة.

مدّة كلّ مرحلة تتغيّر كثيراً بحسب حجم النظام (عدد الشاشات والتقارير والدُفعات)، ومجموعة التقنيّات، والوقت الذي يخصّصه جانب العمل للمقابلات، وهدف «إلى أيّ حدّ يكفي الفهم»، لذلك لا يمكن وضع تقدير موحَّد قبل البدء. أقصر طريق لرفع دقّة التقدير هو إنهاء جرد الفصل 3 أوّلاً وعدّ العناصر. وما لم يظهر العدد، لا يمكن تقدير مدّة استعادة المواصفات. وبالمقابل، الجرد مرحلة ينبغي إنهاؤها في مدّة قصيرة؛ فإن طالت تعطّل التخطيط لكلّ ما بعدها.

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 22، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. لماذا تنشأ حالة «انعدام كلّ شيء»

قبل التفكير في المعالجة، يفيد التحقّق من النمط الذي تنتمي إليه شركتك، إذ يعطي فكرة عن الأدلّة المتبقّية.

النمط الأخير يُغفَل عنه غالباً، لكنّه من الناحية العمليّة يحتاج معاملة مماثلة لحالة «لا توجد شيفرة». التعديل باعتبار الشيفرة القديمة أصلاً صحيحاً، بينما كان الملفّ التنفيذيّ الفعليّ للإنتاج يحمل تعديلات امتدّت سنوات حادثة فشل نموذجيّة. حتّى إن عُثر على الشيفرة، لا تثق بها حتّى تبنيها وتقارنها بالملفّ التنفيذيّ للإنتاج.

في أيّ نمط من هذه الأنماط، تكون البحث عن العقد وإشعار التسليم وشهادة الاستلام قيّماً منذ البداية. فإن دُوِّن فيها انتماء حقوق التأليف والتزام تسليم الشيفرة المصدريّة، يصبح ذلك أساساً للتفاوض أو للتسوية القانونيّة لاحقاً.

3. ما ينبغي فعله في الأسبوع الأوّل ── صون الوضع الحاليّ والجرد

3.1 تجميد التغييرات

الأصل هو عدم المساس بالخادم أو الجهاز المستهدَف حتّى ينتهي التحقيق. فـ«لنُحدِّث نظام التشغيل احتياطاً» أو «لنُرتِّب الملفّات التي تبدو غير مستخدَمة» قد يكونان قاتلَين. لأنّه لا توجد شيفرة مصدريّة، لا يوجد خيار «الإصلاح» عند حدوث عطل. يُستحسَن أيضاً التفكير في وضع توقيت تطبيق التحديثات تحت السيطرة، بحيث لا تُغيِّر التحديثات التلقائيّة (تحديث Windows، وتغيّر سلوك برنامج مكافحة الفيروسات) البيئة من تلقاء نفسها.

3.2 النسخ الاحتياطيّ ── استنساخ البيئة نفسها كأصل

النسخ الاحتياطيّ على مستوى الملفّات وحده غير كافٍ. في هذا النوع من الأنظمة، من المحتمل أن يكون إعداد نظام التشغيل، والسجلّ (registry)، ووقت التشغيل (runtime)، وموضع النشر جميعها جزءاً من «سبب عمله»، لذا يُصان صورة القرص كاملةً.

الأداة الشائعة الاستخدام في العمل الفعليّ هي Disk2vhd من Sysinternals. يمكنها تحويل النظام العامل، وهو لا يزال متّصلاً (online)، إلى ملفّ VHD/VHDX متّسق زمنيّاً باستخدام لقطة وحدة التخزين في Windows (VSS: Volume Shadow Copy Service، خدمة نسخة الظلّ لوحدة التخزين)، ويصبح ذلك أساساً لبيئة تحقّق تُشغَّل كجهاز افتراضيّ على Hyper-V.¹ وميزة ذلك هي إمكانيّة التقدّم في معالجة تقادم الخادم الفعليّ وتأمين بيئة التحقّق دفعة واحدة (مع ملاحظة أنّ ترخيص Windows من نوع OEM قد لا يسمح بالانتقال إلى بيئة افتراضيّة، فيلزم التحقّق من نوع الترخيص¹).

Disk2vhd أداة بسيطة بشاشة واحدة، لكن اختياراً خاطئاً ينتج «صورة لا تقلع». سر وفق الترتيب التالي.¹

1. جهّز وجهة الإخراج. يمكن إنشاء VHD/VHDX على وحدة التخزين المستهدَفة نفسها، لكن الوثائق الرسميّة تنصّ على أنّ الإخراج إلى قرص مختلف عن المستهدَف (محرّك خارجيّ أو NAS مثلاً) أفضل أداءً. انظر إلى مساحة حرّة لا تقلّ عن مجموع المنطقة المستخدمة في الوحدات المختارة.
2. تحقّق من BitLocker. Disk2vhd لا يدعم تحويل وحدة مفعَّل عليها BitLocker. إن كانت مستهدَفة، عطِّل BitLocker مسبقاً وانتظر اكتمال فكّ التشفير قبل التنفيذ.
3. اختر الوحدات التي تُدرَج. عند تشغيل الأداة على نظام عامل تظهر قائمة وحداته. يُنشأ VHD واحد لكلّ قرص توجد عليه الوحدات التي اخترتها، وتُحفظ بنية الأقسام، لكن ما يُنسَخ من المحتوى هو الوحدات المختارة فقط. لذلك، إن أردت إقلاع تحقّق فاختر وحدة Windows (عادة C:) وقسم النظام اللازم للإقلاع (القسم المحجوز للنظام / قسم EFI) معاً. وإسقاط وحدات البيانات الخالصة يوفّر سعة ووقتاً.
4. إن لزم، شغِّله من سطر الأوامر. للتشغيل الليليّ مثلاً يمكن سكربتته بالشكل disk2vhd <drive:> [drive:] ... <vhdfile>. ولاستهداف كلّ الوحدات حدِّد * مثل disk2vhd * e:\backup\snapshot.vhdx.
5. إقلاع التحقّق يكون على Hyper-V. أنشئ جهازاً افتراضيّاً من Hyper-V Manager، وأضِف VHD الناتج كقرص IDE إلى التكوين. عند أوّل إقلاع يكتشف Windows عتاد الجهاز الافتراضيّ، ويثبّت برامج التشغيل إن وُجدت داخل الصورة. وإلا ثبِّت مكوّنات تكامل Hyper-V.
6. لا تُرفِقه على الجهاز المصدر للإقلاع. إن أُرفِق VHD على النظام نفسه، يخصّص Windows توقيع قرص جديداً لـVHD لتفادي تعارض التوقيع مع القرص الأصليّ. وبيانات تكوين الإقلاع (BCD) تشير إلى القرص بتوقيعه، لذلك الإقلاع كجهاز افتراضيّ في هذه الحالة يفشل لأنّ قرص الإقلاع لا يُوجد. اجعل إقلاع التحقّق دائماً على جهاز آخر (مضيف Hyper-V).

بالتوازي مع ذلك، تُؤخَذ نسخة احتياطيّة لقاعدة البيانات بالوسيلة القياسيّة الخاصّة بنظام إدارة قواعد البيانات (DBMS). والأهمّ من ذلك كلّه هو الاستعادة الفعليّة من النسخة الاحتياطيّة والتأكّد من التشغيل. فالنسخة الاحتياطيّة التي لم تُختبَر استعادتها ليست سوى تأمين متوهَّم. لكن بما أنّ الصورة المُستعادة تحتفظ كما هي بإعدادات اتّصال الإنتاج والمهامّ المُجدوَلة، يجب دائماً إجراء التحقّق من التشغيل وهو مُعزول عن الشبكة (التفصيل في الفصل السابع). فإن شُغِّل عن غير قصد وهو متّصل، قد تحدِّث بيئةً تخالها للتحقّق قاعدةَ بيانات الإنتاج أو الجهات المتّصلة بها فعليّاً.

3.3 الجرد ── وضع قائمة بما يعمل

بعد ذلك، تُستخرَج عناصر النظام بشكل آليّ. هذا عمل شموليّة لا حِسّ.

عندما لا تُعرَف «أين» تقع ملفّات الإعداد أو وجهة الإخراج، فمراقبة وصول العمليّة إلى الملفّات والسجلّ (registry) عبر Process Monitor هي الطريق الأسرع. تظهر المسارات التي تقرأها التطبيقات وتكتب فيها فعليّاً في قائمة كما هي.²

4. حتّى بلا مواصفات مكتوبة، يمكن استعادة المواصفات

بعد أن يتّضح «ما هو موجود» عبر الجرد، تأتي الخطوة التالية وهي استعادة «ما الذي يجري». المواد متوفّرة.

• مقابلة مستخدمي النظام في العمل ── أكبر مواصفات هي ما في ذهن من يستخدم النظام يوميّاً. اسأل، وفق تسلسل العمل اليوميّ والشهريّ والسنويّ، عن أيّ شاشة يُدخَل فيها ماذا، وماذا يخرج منها. وبوجه خاصّ، قد ينسى المسؤول نفسه المعالجة السنويّة (الإقفال المحاسبيّ، والجرد، وتحديث السنة الماليّة)، وهي نقطة تكثر فيها الحوادث عند أوّل مرّة بعد التسلّم.
• الشاشات والتقارير ── حوِّل كلّ الشاشات وكلّ التقارير إلى سجلّ (لقطة شاشة ونسخة فعليّة). مجرّد التطابق بين عناصر الإدخال وعناصر الإخراج يكشف الكثير من هيكل المعالجة.
• مخطّط قاعدة البيانات والبيانات ── تعريف الجداول، والقيود، والبيانات الفعليّة لقيم الرموز، كلّها أحافير لقواعد العمل. ملاحظة من قبيل «قيمة هذا العلَم (flag) لا تُستخدَم إلّا بثلاث حالات» تكشف مواصفات لا تظهر من الشاشة.
• السجلّات وسجلّ الأحداث ── إن وُجد سجلّ خاصّ بالتطبيق، يُقرَأ منه تسلسل المعالجة، ومن سجلّ أحداث Windows تُقرَأ نزعة الأخطاء السابقة.
• مراقبة السلوك الفعليّ ── إن سُجِّل وصول العمليّة إلى الملفّات والسجلّ (registry) والشبكة عبر Process Monitor، يمكن إثبات التطابق بين المدخلات والمخرجات من قبيل «هذه المعالجة في نهاية الشهر تقرأ ملفّ CSV من هذا المجلّد المشترَك، وتتواصل مع خادم قاعدة البيانات هذا»، دون شيفرة مصدريّة.² لكنّ ما يكشفه Process Monitor يقتصر على الطرف المقابل للاتّصال، ولا يظهر منه أيّ جدول تحديث وكيف تحديداً. من هنا فصاعداً، يُحدَّد ذلك عبر وظائف التتبّع والتدقيق الخاصّة بنظام إدارة قواعد البيانات (كالأحداث الموسَّعة في SQL Server) أو بمقارنة محتوى قاعدة البيانات قبل المعالجة وبعدها.

المهمّ هنا هو عدم محاولة توثيق كلّ الوظائف بالتساوي. فالهدف ليس موسوعة بل استمراريّة التشغيل، لذا يُعطَى الأولويّة لـ«المعالجة التي يتوقّف بها سير العمل إذا توقّفت»، و«المعالجة التي تظهر بها أخطاء»، و«المواضع القريبة من الحاجة للتغيير»، وتُراكَم دفعة الفهم في سجلّ.

قالب المقابلة ── من تسأل، وعماذا، وكيف تسجّل

«اسأل المستخدم» سهل القول، لكن إن لم تحدِّد المخاطَب والأسئلة انتهت الجلسة حديثاً عابراً. عمليّاً الأضمن تقسيم الأمر إلى ثلاث طبقات، وتخصيص وقت منفصل لكلّ منها.

أعد استخدام البنود نفسها في كلّ مرّة. الأسئلة العشرة التالية تصلح عبر الأنظمة.

1. ما العمليات التي لا بدّ منها يوميّاً في هذا النظام؟ في أيّ ساعة تقريباً، وكم عددها؟
2. هل توجد عمليات شهريّة أو سنويّة فقط (إقفال، حساب ختاميّ، جرد، تحديث السنة الماليّة)؟ متى كانت المرّة السابقة، ومن نفّذها؟
3. ما الورق أو الملفّ أو البريد الذي يُعدّ مصدر الإدخال؟ من أين يأتي؟
4. ماذا يخرج هذا النظام (تقارير، CSV، إرسال خارجيّ)، وإلى أين يذهب بعد ذلك؟
5. إن توقّف النظام، كم ساعة يتحمّل العمل؟ وهل يمكن البديل يدوياً حينها؟
6. هل هناك مقولة «هذه العملية وحدها لا تُفعَل»؟ وهل يُعرَف السبب؟
7. ما الذي يُكمَّل يدوياً الآن (نقل، إعادة تجميع في Excel، فحص بالنظر)؟
8. هل وقعت أخطاء أو أعطال خلال السنة الماضية؟ وكيف عولجت؟
9. أيّ الشاشات أو الوظائف غير مستخدمة؟ ومنذ متى؟
10. إن أمكن الإصلاح، ما أكثر ما يزعجكم؟

حدِّد أيضاً طريقة التسجيل. اربط الإجابة بأسماء علم مثل اسم الشاشة واسم التقرير واسم الجدول؛ لا «نجمع في نهاية الشهر» بل إلى حبيبات «طباعة التقرير الشهريّ للمبيعات من شاشة تجميع المبيعات الشهريّة (F050)»، فيمكن مطابقتها مع جدول جرد الفصل 3 وتحقيق قاعدة البيانات لاحقاً. سجِّل الصوت إن أمكن، وركِّز في الجلسة على أسماء العلم وترتيب التشغيل. إجابة 5 تفيد حكم اتجاه الفصل 6، وإجابتا 6 و7 تدلّان على موضع المواصفات الخفيّة.

5. ما الذي يمكن فعله تقنيّاً عند انعدام الشيفرة المصدريّة

مدى ما يُرتجى من «قراءة المحتوى» يتحدّد تقريباً بما بُني به النظام. قدِّر مجموعة التقنيّات من خصائص الملفّ التنفيذيّ وبنية DLL، ثمّ اضبط التوقّعات وفقاً لذلك.

نعرف أوّلاً باختصار المصطلحات المستخدمة في هذا الفصل.

في حالة تطبيق .NET المنشور بصيغة IL العاديّة، يكون الوضع جيّداً إلى حدّ بعيد، وشيفرة C# التي تُستخرَج بالتفكيك عمليّة بشكل كافٍ لفهم المعالجة. لكن كما توضّح الوثائق الرسميّة نفسها، تُفقَد المعلومات غير اللازمة وقت الترجمة (compile) مثل التعليقات وأسماء المتغيّرات المحليّة والمسافات البيضاء، وينبغي اعتبارها لا بديلاً عن الشيفرة المصدريّة الأصليّة بل «مادّة لفهم السلوك».³ كذلك توجد استثناءات. فإن كان مُطبَّقاً عليه تعتيم (obfuscation)، ترتفع صعوبة فكّ الشيفرة كثيراً، وبما أنّ الملفّ الثنائيّ المنشور عبر Native AOT لا يتضمّن اللغة الوسيطة، لا يصحّ توقّع «إمكانيّة القراءة لأنّه من صنع .NET». Native AOT أسلوب إصدار أُدخل في .NET 7، وتنصّ الوثائق الرسميّة أيضاً على أنّ «المترجم المسبَق يترجم IL إلى شيفرة أصليّة عند الإصدار» وأنّ «تطبيق Native AOT لا يستخدم مترجم JIT وقت التشغيل».⁷ أي أنّ مادّة قراءة المُفكِّك نفسها لا تبقى في المُخرَج. عند تقدير مجموعة التقنيّات، تحقّق حتّى من صيغة النشر لا لغة التطوير وحدها.

إن بقي PDB (ملفّ الرموز) إلى جانب الملفّ التنفيذيّ، فقد يمكن استعادة أسماء الدوال، بل والشيفرة المصدريّة نفسها (إن وُجد مصدر مضمَّن). وقد نظّمنا ما يُحتوى وما يمكن توقّعه في «PDB (قاعدة بيانات البرنامج) ما هي؟».

النقاط القانونيّة الواجب مراعاتها ── فكّ التجميع «بعد التحقّق»

ما يمكن فعله تقنيّاً وما يجوز فعله أمران مختلفان. للهندسة العكسيّة، بما فيها فكّ التجميع (decompile)، نقاط عالقة بموجب قانون حقوق التأليف والنشر، وبموجب المادّة 30-4 من قانون حقوق التأليف والنشر المُستحدَثة في تعديل عام هيسي 30 (2018) (الاستخدام الذي لا يهدف إلى التمتّع بالفكر أو الشعور المُعبَّر عنه في المصنَّف)، يُنظَّم النسخ والتحويل الهادف إلى تحليل البرنامج وفحصه على أنّه مسموح به من حيث المبدأ في حدود الضرورة المُقرَّة. لكنّ النصّ يتضمّن استثناءً بعبارة «ما لم يُلحِق ذلك ضرراً غير عادل بمصالح صاحب حقّ التأليف»، وقد يحمل تقييماً مختلفاً في حالات مثل استخدام نتيجة التحليل لصنع منتَج منافس مثلاً.⁵

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

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

6. الإطالة، أم التغليف، أم إعادة البناء

بعد أن يتوفّر مستوى الفهم المُكتسَب من التحقيق وظروف جانب العمل معاً، يُحسَم التوجّه. هنا أيضاً، لا «إعادة بناء كاملة حتماً» ولا «إبقاء كما هو حتماً»، بل يُنظَّم الأمر بجدول قرار.

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

أمّا قرارات الإطالة أو الانتقال الخاصّة بتقنيّات محدّدة مثل VB6 وAccess فتُعالَج بالتفصيل في «إطالة عمر تطبيقات VB6 / Access في العمل ونقلها»، وبخصوص اعتماد أنظمة الويب الداخليّة على وضع IE، في «دليل التخلّص من الاعتماد على وضع IE».

7. نظام التشغيل والصيانة بعد التسلّم

إذا كان التوجّه هو «الاستمرار في التشغيل في الوقت الراهن» (وهذا واقع معظم الحالات فعليّاً)، فإنّ الالتزام بالنمط التالي يقلّل من الحوادث.

• امتلاك بيئة تحقّق ── لكن مع عزل التشغيل الأوّل عن الشبكة دائماً ── تشغيل صورة القرص التي أُنشئت في 3.2 كجهاز افتراضيّ يجعلها بيئة تحقّق بنفس بنية الإنتاج. لكن هذه الصورة تحتفظ كما هي بسلاسل اتّصال الإنتاج، وبيانات الاعتماد، والمهامّ المُجدوَلة، وخدمات التشغيل التلقائيّ. فإن شُغِّلت وهي متّصلة بالشبكة، قد تعمل الدُفعة الليليّة مرّتين وتُحدِّث قاعدة بيانات الإنتاج، أو يُعاد إرسال بريد، أو يُستدعى API خارجيّ. اجعل التشغيل الأوّل دائماً بفصل واجهة الشبكة الافتراضيّة (vNIC) أو ضمن شبكة معزولة، وأوقِف المهامّ المُجدوَلة وخدمات التشغيل التلقائيّ، وأعِد كتابة وجهة الاتّصال لتصبح للتحقّق، ثمّ اسمح بالاتّصال ضمن النطاق اللازم فقط.
• التغيير واحداً تلو الآخر وبشكل قابل للتراجع ── سواء تغيير الإعدادات أو تطبيق تحديث Windows، غيّر واحداً في كلّ مرّة. احتفظ بالصورة قبل التغيير، وارجع إليها إن ظهرت مشكلة. اجعل تسجيل ما تغيّر (سجلّ التغييرات) جزءاً ملازماً.
• تُنمَّى الوثائق كـ«ناتج ثانويّ لما اكتُشف» ── لا تُنشئ مشروعاً لكتابة مواصفات كاملة، بل أضِف إلى السجلّ ما تتعلّمه في كلّ مرّة تتعامل فيها مع عطل أو تعديل. بعد سنة من التشغيل، تكتمل الوثائق تدريجيّاً بدءاً من المواضع الأهمّ للعمل.
• جهّز المراقبة ── مراقبة الحياة (حيّ/ميت)، والمساحة المتبقّية على القرص، وسجلّ الأخطاء، وكشف «الملفّ الذي كان من المفترض أن يخرج دائماً ولم يخرج». حتّى مع عدم رؤية داخل الصندوق الأسود، يمكن مراقبة المدخل والمخرج.
• افصل العقد بين التحقيق والتعديل ── عند تكليف طرف خارجيّ بالصيانة، ولأنّه لا يمكن الوعد بمسؤوليّة إتمام النتيجة لتحقيق نظام مجهول المحتوى، من الصحّي فصل العقد على مراحل: التحقيق والصيانة شبه تفويض، والتعديل الفرديّ بعد استقرار المواصفات مقاولة (أو شبه تفويض قائم على إتمام النتيجة).

8. الخلاصة

• عند تسلّم نظام بلا شيفرة مصدريّة ولا مواصفات، صون الوضع الحاليّ يسبق التعديل. احصل على نسخة احتياطيّة لصورة القرص (عبر Disk2vhd وغيره) ولقاعدة البيانات، وتحقّق حتّى من إمكانيّة الاستعادة.
• اجرِ جرداً للملفّات التنفيذيّة، وما يعمل تلقائيّاً، والمهامّ المُجدوَلة، والإعدادات، والجهات المتّصلة، والحسابات، وضع الصورة الكاملة للنظام في قائمة.
• يمكن استعادة المواصفات من مقابلة المستخدمين، والشاشات، والتقارير، ومخطّط قاعدة البيانات، والسجلّات، ومراقبة السلوك الفعليّ عبر Process Monitor. أعطِ الأولويّة للمواضع ذات الأثر الكبير على العمل، لا لكلّ الوظائف.
• تعتمد إمكانيّة استعادة المحتوى على مجموعة التقنيّات. يمكن قراءة .NET إلى حدّ بعيد عبر فكّ التجميع، لكنّها ليست بديلاً عن المصدر الأصليّ. تحقّق قبل التنفيذ من روح المادّة 30-4 من قانون حقوق التأليف والنشر ومن بنود الترخيص والعقد.
• يُحسَم التوجّه بين «الإطالة، التغليف، إعادة البناء الجزئيّة، إعادة البناء الكاملة» وفقاً لسنوات الاستخدام المتبقّية، وتكرار التغيير، والأثر على العمل، ومستوى الفهم. المواصفات المُستعادة بالتحقيق تصبح أصلاً أيّاً كان الطريق المُختار.
• في مرحلة التشغيل، النمط الأساسيّ هو بيئة التحقّق، والتغيير واحداً تلو الآخر، وسجلّ التغييرات، ومراقبة المدخل والمخرج، والتعاقد بشبه التفويض.

مقالات ذات صلة

• PDB (قاعدة بيانات البرنامج) ما هي؟ ── فهم معلومات التصحيح والرموز (symbols) وSource Link
• دليل Process Monitor العمليّ
• إطالة عمر تطبيقات VB6 / Access في العمل ونقلها ── جدول قرار الإبقاء والتغليف والاستبدال
• دليل التخلّص من الاعتماد على وضع IE
• كيف ينبغي عقد اتّفاقيّات التطوير المُوكَل والتشغيل والصيانة ── التمييز بين شبه التفويض والمقاولة استناداً إلى «نموذج المعاملات والعقود» الصادر عن IPA
• ما ينبغي تنظيمه قبل تكليف جهة خارجيّة بتطوير تطبيق Windows

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت ذ.م.م. مع تحقيق الوضع الحاليّ لأنظمة الأعمال التي لا تتوفّر لها شيفرة مصدريّة ولا مواصفات (تحليل الملفّات التنفيذيّة وقاعدة البيانات والسلوك الفعليّ)، واستعادة المواصفات من السلوك، وتنظيم سياسة الإطالة أو الانتقال، وصولاً إلى التشغيل والصيانة اللاحقَين. نرحّب أيضاً بالاستشارة من مرحلة «لا أعرف من أين أبدأ».

• الاستفادة من الأصول القائمة ودعم الانتقال
• تعديل وصيانة برمجيّات Windows القائمة
• تحقيق الأخطاء وتحليل الأسباب
• الاستشارة التقنيّة ومراجعة التصميم
• التواصل معنا

روابط مرجعية

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

هل يمكن طلب الصيانة أو التعديل لنظام لا توجد له شيفرة مصدريّة؟

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

أليس فكّ التجميع (decompile) للملفّ التنفيذيّ - أي الهندسة العكسيّة - أمراً غير قانونيّ؟

ليس غير قانونيّ على إطلاقه. فبموجب المادّة 30-4 المُستحدَثة في تعديل قانون حقوق التأليف والنشر الياباني لعام هيسي 30 (2018)، يُنظَّم «الاستخدام الذي لا يهدف إلى التمتّع بالفكر أو الشعور المُعبَّر عنه في المصنَّف»، مثل تحليل البرنامج وفحصه، على أنّه مسموح به من حيث المبدأ في حدود الضرورة المُقرَّة. لكن يُستثنى من ذلك «ما يُلحِق ضرراً غير عادل بمصالح صاحب حقّ التأليف»، ويبقى موضوع كيفيّة التعامل مع حظر التحليل في عقد ترخيص الاستخدام مسألة عالقة أيضاً. تحقّق قبل التنفيذ من بنود الترخيص وعقد التطوير المُوكَل، وإن ترددت في الحكم فاستشر محامياً أو خبيراً مختصّاً.

أفلست شركة التطوير ولا يمكن الحصول على الشيفرة المصدريّة. ماذا أفعل؟

تحقّق أوّلاً من العقود والمُسلَّمات (deliverables) السابقة. فإن نصّ عقد التطوير المُوكَل على انتماء حقوق التأليف والشيفرة المصدريّة وتسليمها، فهذا يشكِّل أساساً للحصول عليها أو استخدامها. وإن وُجد أطراف يمكن التواصل معهم، يستحقّ الأمر استكشاف إمكانيّة التفاوض على الحصول عليها. لكنّ المهمّ عمليّاً هو عدم التوقّف عند «لم نحصل عليها في النهاية»، ويُنصَح بالبدء - على افتراض عدم الحصول عليها - بصون البيئة العاملة والنسخ الاحتياطيّ بالتوازي مع استعادة المواصفات من السلوك الفعليّ وقاعدة البيانات.

نظام بلا مواصفات، من أين أبدأ؟

قبل التعديل، ابدأ أوّلاً بصون الوضع الحاليّ. احصل على صورة قرص (disk image) لبيئة الإنتاج العاملة ونسخة احتياطيّة من قاعدة البيانات، وتحقّق من إمكانيّة الاستعادة منهما. ثمّ اجرِ جرداً للملفّات التنفيذيّة، وما يعمل تلقائيّاً، والمهامّ المُجدوَلة (scheduled tasks)، والإعدادات، والجهات المتّصلة، والحسابات، وضعها في جدول يعكس الصورة الكاملة للنظام. بعد ذلك، والقاعدة المُتَّبَعة هي توثيق المواصفات - مع التركيز على المواضع المهمّة للعمل - انطلاقاً من مقابلة مستخدمي النظام في العمل، وملاحظة الشاشات والتقارير ومخطّط قاعدة البيانات.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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