البرمجيات تتعفّن حتى وأنت لا تلمسها — سؤال الصيانة الذي لا يطرحه أحدٌ قبل أن يبني
النظام المخصّص ليس شيئاً تشتريه مرّةً؛ بل شيءٌ تحتفظ به. البناء هو الدفعة الأولى. والذي يقرّر إن كنت قد حصلت على قيمةٍ حقاً هو عقدٌ من الصيانة لم يسعّره أحدٌ في اجتماع الانطلاق.
عرض البرمجيات المخصّصة ينتهي دائماً تقريباً عند الإطلاق. توقّع الاستلام، ويُشغَّل النظام، ويحتفل الجميع، وتُغلَق الفاتورة. ثم يستقرّ افتراضٌ صامتٌ على طرفَي الطاولة: انتهى الأمر. يعمل اليوم، إذاً سيعمل العام المقبل. ذلك الافتراض هو أغلى سوء فهمٍ مفردٍ في هذه الصناعة — لأنّ البرمجيات هي الأصل الوحيد الذي يتآكل وهو ساكنٌ تماماً في مكانه.
لا شيء في كودك يتغيّر، لكنّ كل شيءٍ حوله يتغيّر. متصفّحٌ يطرح تحديثاً. مزوّد دفعٍ يلغي واجهةً قديمة. نظام تشغيل هاتفٍ يُسقط دعم مكوّنٍ قديم. قاعدةٌ ضريبيّة تتغيّر. مكتبةٌ لم تسمع بها قطّ تنشر تنبيهاً أمنياً في الثانية صباحاً. لا شيء من ذلك لمس منطق عملك — وكلّه قادرٌ على كسر نظامك، أو فتح ثغرةٍ فيه بصمت. النظام ليس مبنىً تُنهيه وتسلّم مفاتيحه. إنه حديقةٌ، والحدائق تنمو سواءٌ اعتنى بها أحدٌ أم لا.
هذه القطعة عن النصف من الكلفة الذي يعيش بعد الإطلاق: ما هي الصيانة فعلاً (وأغلبها ليس إصلاح أعطال)، ولماذا يحتاجها كل نظامٍ حيّ، وما الذي يكلّفه إهمالها في الأمن والتآكل البطيء، وكيف تقرّر من يملك تلك المسؤوليّة قبل أن تطلب البناء — لا في صباح يومٍ يتعطّل فيه شيءٌ ولا يقدر أحدٌ أن يقول من كانت وظيفته أن يمنعه.
الرقم الذي يفاجئ كل مشترٍ لأوّل مرّة: على امتداد عمر النظام، البناء الأصلي هو الجزء الأصغر من الفاتورة. تقاربت الصناعة عقوداً على قاعدةٍ تقريبيّة بسيطة — الصيانة تتراوح نحو 60 إلى 80 بالمئة من كلفة دورة الحياة الكاملة، تختصرها "قاعدة الستّين/ستّين" المعروفة: نحو 60 بالمئة ممّا يكلّفه النظام على مدى عمره صيانة، ونحو 60 بالمئة من تلك الصيانة تحسينٌ لا إصلاح [1]. اقرأ ذلك مرّتين. البناء الذي تتفاوض عليه هو الدفعة الأولى على التزامٍ أكبر وأطول — وأغلب ذلك الالتزام هو جعل النظام يفعل أكثر، لا إصلاح ما تعطّل.
هذا ليس رأياً؛ إنه أقرب إلى قانونٍ في الوسيط نفسه. قبل عقود، حين درس ليمان كيف تتطوّر الأنظمة الكبيرة، وضع ما يُسمّى اليوم قوانين تطوّر البرمجيات. الأوّل — التغيّر المستمر — يقول إنّ أيّ نظامٍ مغروسٍ في العالم الحقيقي يجب أن يستمرّ في التغيّر وإلّا صار تدريجياً أقلّ نفعاً. والسابع — تراجع الجودة — يقول إنّ جودة ذلك النظام ستبدو هابطةً ما لم يُصَن بصرامةٍ ويُكيَّف مع بيئته [2]. والمعنى صريح: نظامٌ تكفّ عن الاستثمار فيه لا يثبت في مكانه. بل ينزلق. السكون اتّجاهٌ، واتجاهه إلى أسفل.
يساعد أن نكون دقيقين في معنى "الصيانة" أصلاً، لأنّ الكلمة تجعل المالك يتخيّل التصليح. يقسم المعيار الدولي لدورة حياة البرمجيات الصيانة إلى أربعة أنواع: تصحيحيّة (إصلاح الأعطال التي وجدتها)، وتكيّفيّة (الإبقاء على العمل مع تبدّل العالم المحيط)، وتحسينيّة (تطوير وتوسيع ما يطلبه المستخدمون الآن)، ووقائيّة (تحصين نقاط الضعف الكامنة قبل أن تعضّ) [3]. النوع الأوّل وحده هو "إصلاح الأعطال". والثلاثة الأخرى عن البقاء حيّاً ونافعاً في عالمٍ لن يتوقّف عن الحركة — وفيها يعيش أغلب العمل.
وهنا الجزء الذي يقلب الحدس: إصلاح الأعطال هو أصغر شريحة. وجد الاستطلاع الكلاسيكيّ لكيفيّة إنفاق جهد الصيانة فعلاً أنّ النصيب الأكبر يذهب للعمل التحسينيّ والتكيّفي — نحو 60 بالمئة على التطوير والقدرة الجديدة، وأقلّ من خُمسٍ على تصحيح الأعطال، والباقي على مواكبة بيئةٍ متغيّرة [4]. فحين يقول أحدهم "لا نحتاج ميزانية صيانة، النظام بلا أعطال"، يكون قد أساء فهم المهمّة. الصيانة ليست عقوبة أنّك بنيته بشكلٍ سيّئ. إنها الكلفة الجارية لأنّ النظام ما زال مطلوباً.
تخطَّها فلا تختفي الفاتورة — بل تنتقل، وتنتقل إلى أسوأ بندٍ ممكن. أوضح مثالٍ هو الأمن. قد يكون كودك معصوماً ويصير خطراً مع ذلك، لأنّ الخطر يأتي من خارجه: مكوّنٌ تعتمد عليه يطرح ثغرةً اكتُشفت حديثاً، فتبدأ الساعة. وجد أحدث تحليلٍ واسعٍ للاختراقات أنّ استغلال الثغرات المعروفة كمدخلٍ للاختراق قفز نحو 180 بالمئة في عامٍ واحد، وأنّ المؤسّسات تستغرق نحو 55 يوماً لمجرّد ترقيع نصف ثغراتها الحرجة المُصلَحة أصلاً [5]. ومعدّل الكشف نفسه بات لا يرحم — فهرس الثغرات العام يسجّل ما يزيد على مئة مدخلٍ جديدٍ كل يوم [6]. النظام غير المُصان ليس مجمّداً في أمان يوم إطلاقه. إنه ساكنٌ بينما تتراكم التهديدات حوله يومياً.
لا شيء من هذا يدعو إلى أعلى عقد صيانةٍ وأغلاه في القائمة. بل يدعو إلى تسمية المسؤوليّة قبل أن تبني، لا بعد أن يتعطّل شيء. نمط الفشل المكلف هو النظام اليتيم: طُلِب، وأُطلِق، واحتُفِل به، ثم تُرِك بلا أحدٍ وظيفته الفعليّة أن يراقب التبعيّات، ويطبّق الترقيعات، ويستوعب التغييرات التكيّفيّة الصغيرة التي يطلبها العالم كل ربع. سؤال الصيانة — من يملك هذا في الشهر الثالث عشر — رخيصٌ أن يُجاب عند الانطلاق، وباهظٌ بقسوةٍ أن يُجاب في خضمّ عطل. اطرحه أوّلاً.
كل دولارٍ يُنفَق على الصيانة دولارٌ لم يُنفَق على بناء الشيء التالي. أطلقه، وأبقِ الفريق رشيقاً، ولا تلمس النظام إلّا حين يتعطّل شيءٌ فعلاً. عمل "إبقائه سليماً" الاستباقيّ تذهيبٌ زائد — يدفع العمل ثمن نشاطٍ لا يراه ولا يحصل مقابله على ميزةٍ جديدة. شغّله حتى يصرّ، ثم تفاعل. أغلب العمل "الوقائي" يمنع مشكلاتٍ ما كانت لتقع أصلاً.
الإطلاق خطّ البداية، لا النهاية. النظام يكسب عائده على مدى سنوات، وتلك السنوات صيانة. عامِلها بنداً ثابتاً — عقد إعالةٍ، ومالكاً مسمّى، وإيقاع ترقيعٍ — كما تعامل الإيجار أو الرواتب. الأنظمة التي تؤتي ثمارها ليست التي أُطلِقت جيّداً؛ بل التي يبقيها أحدهم حيّةً بهدوءٍ بعد حفل الإطلاق بزمنٍ طويل. البرمجيّة بلا مالكٍ تتناقص قيمتها من اليوم الثاني.
أرخص صيانةٍ هي الكود الذي لم تكتبه قطّ. كل ميزةٍ وتكاملٍ واختصارٍ ذكيّ هو التزام صيانةٍ مستقبليّ بفائدةٍ مركّبة. أبقِ النظام صغيراً، واتّكئ على أسسٍ مدعومةٍ جيّداً، وامتلك بياناتك كي لا تكون رهينةً لدورة حياة مورّدٍ واحد، واقطع بلا رحمةٍ النطاق الذي لن تتعهّده. نصف فاتورة الصيانة يُدفَع وقت التصميم، فيما تختار ألّا تبنيه.
المعسكر ج أوّلاً، ثم ب؛ والمعسكر أ هو كيف تتعفّن الأنظمة. ابنِ صغيراً عمداً ليكون السطح المحتاج إلى تعهّدٍ صغيراً — تلك أعلى قرارات الصيانة رافعةً، وتُتَّخذ قبل الإطلاق لا بعده. ثم موّل صيانة ما تبقّى التزاماً ثابتاً بمالكٍ مسمّى، لا تدريب حريق. المعسكر أ محقٌّ أنّ الصيانة يجب ألّا تصير عملاً عبثياً — لكنّ "أصلحه فقط حين يتعطّل" يختار بصمتٍ العطل والاختراق جدولاً لصيانتك. نحن نبني أنظمةً رشيقةً كفايةً للاحتفاظ بها، ونقول من يحتفظ بها قبل أن يُكتَب السطر الأوّل.
- 01ما هي ميزانية الصيانة السنويّة الصادقة لنظامٍ مخصّص — هل القاعدة التقريبيّة من 15 إلى 20 بالمئة من كلفة البناء سنوياً صحيحةٌ لعمليّتك، أم أنّ ملفّ مخاطرك وامتثالك يدفعها أعلى؟
- 02من ينبغي أن يملك الصيانة — الفريق الذي بناه، أم أهلك، أم طرفٌ ثالث — وكيف تمنع تلك الملكيّة من التلاشي بصمتٍ بعد السنة الهادئة الأولى حين لا يتعطّل شيء؟
- 03كيف تميّز الصيانة التكيّفيّة السليمة بسبب "تغيّر العالم" عن إعادة العمل التصحيحيّة بسبب "بنيناه خطأً" التي تشير في الحقيقة إلى مشكلة تصميمٍ أعمق؟
- 04متى يعبر النظام من جديرٍ بالصيانة إلى جديرٍ بالاستبدال — ما الإشارة إلى أنّ التعهّد صار رمياً للمال الجيّد خلف تصميمٍ تجاوزه الزمن؟
- 05كم من الصيانة يمكن أتمتته بأمان — تحديثات التبعيّات، والفحص الأمنيّ، وبوابات الاختبار — قبل أن يضطرّ بشرٌ مع ذلك لاتّخاذ قرار الحكم، وأين يقع ذلك الخطّ بالضبط اليوم؟
- [1]أورايلي — "قاعدة الستّين/ستّين" (97 شيئاً ينبغي أن يعرفه كل مدير مشروع): الصيانة نحو 60٪ من كلفة دورة حياة البرمجيّة، ونحو 60٪ منها تحسين.
- [2]ويكيبيديا — قوانين ليمان لتطوّر البرمجيات (التغيّر المستمر؛ تراجع الجودة).
- [3]المعيار ISO/IEC/IEEE 14764:2022 — عمليّة دورة حياة صيانة البرمجيات: الفئات التصحيحيّة والتكيّفيّة والتحسينيّة والوقائيّة.
- [4]دي-زون — ليينتز وسوانسون عن صيانة البرمجيات: أغلب جهد الصيانة تحسينيٌّ/تكيّفيّ، لا إصلاح أعطالٍ تصحيحيّاً.
- [5]فيرايزون — تقرير تحقيقات اختراقات البيانات 2024: استغلال الثغرات المعروفة كمدخلٍ للاختراق ارتفع نحو 180٪؛ ونحو 55 يوماً لترقيع نصف الثغرات الحرجة.
- [6]برنامج CVE — المقاييس: حجمٌ قياسيّ من الثغرات المنشورة حديثاً (ما يزيد على مئةٍ يومياً).
نبني أنظمةً رشيقةً كفايةً للاحتفاظ بها — ونبقى لنحتفظ بها.
النظام المخصّص علاقةٌ تمتدّ عقداً، لا فاتورةً لمرّةٍ واحدة. نحدّد النطاق لعمر النظام، لا ليوم الإطلاق فقط — مملوكٌ لك، يبقى مُرقَّعاً ومواكباً، بجوابٍ واضحٍ عن "من يملك هذا في الشهر الثالث عشر". خمس عشرة دقيقة لرسم ما سيحتاجه نظامك فعلاً بعد التشغيل.
احجز استشارة مجّانيّة 15 دقيقة