أنواع صيانة الأنظمة

أنواع صيانة الأنظمة

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

الصيانة ليست دليلاً على فشل المشروع؛ بل هي دليل على أن النظام يُستخدم فعلاً وأن العمل يتطور. تُشير الدراسات باستمرار إلى أن الصيانة تستهلك 60–80% من إجمالي تكلفة دورة حياة النظام. بوصفك محلل أنظمة، يُمكّنك فهم أنواع الصيانة الأربعة من تحديد نطاق طلبات التغيير، وإدارة توقعات أصحاب المصلحة، والتخطيط للخارطة التقنية، وتبرير ميزانيات تقنية المعلومات.

النموذج الرباعي للتصنيف

يُصنِّف معيار ISO/IEC 14764 (والتصنيف السابق لـ Lientz وSwanson الذي رسّخه) صيانة البرمجيات إلى أربعة أنواع متمايزة. يجيب كلٌّ منها على سؤال مختلف وينطلق من حدث مغاير.

الصيانة التصحيحية (Corrective Maintenance)

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

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

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

الصيانة التكيفية (Adaptive Maintenance)

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

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

الصيانة التحسينية (Perfective Maintenance)

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

• تحسينات الميزات — بوابة اللوجستيات التي كانت تعرض شحنات اليوم الحالي فقط، يطلب المستخدمون عرض سجل 30 يوماً. لا عيب هناك؛ بل تكتسب النظام قدرة جديدة.
• تحسينات الأداء — تقرير حجز في عيادة يستغرق 45 ثانية يُعاد كتابته ليعمل في أقل من ثانيتين بعد اكتشاف فهرس مفقود.
• تحسينات سهولة الاستخدام — إعادة هيكلة إتمام الشراء في المتجر من معالج بأربع خطوات إلى صفحة واحدة بعد اختبار A/B.

الصيانة الوقائية (Preventive Maintenance)

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

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

الصيانة الوقائية هي الأصعب تمويلاً لأنها لا تُقدِّم ميزة جديدة مرئية. يُقنَع بها عبر تكميم المخاطر: "وحدة المصادقة لم تُلمَس منذ أربع سنوات؛ المكتبة التي تستخدمها تحمل ثلاث ثغرات CVE معروفة؛ اختراق هنا يُعرِّض 50,000 سجل مريض للخطر ويستدعي غرامات تنظيمية."

مقارنة الأنواع الأربعة في طلب تغيير

تصنيف طلبات التغيير الفعلية

في الواقع العملي، تتداخل الأنواع الأربعة أحياناً. تحسين أداء (تحسيني) يُكتشف أثناء تدقيق (وقائي) ويُصحح تسرباً في الذاكرة (تصحيحي) في آنٍ معاً ليس بالأمر النادر. ما يهم هو عادة السؤال: لماذا نحتاج هذا التغيير؟

• "يتعطل النظام حين يُرسل مستخدمان طلباً في وقت واحد." ← تصحيحي
• "بوابة الدفع ستوقف واجهتها القديمة خلال 90 يوماً." ← تكيفي
• "هل يمكن إضافة تصدير CSV لتسهيل معالجة تقارير الحسابات؟" ← تحسيني
• "مكتبة المصادقة لدينا متأخرة إصدارَين رئيسيَّين والفريق قلق من الثغرات." ← وقائي

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

مقاييس الصيانة الجديرة بالمتابعة

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