تطبيق التصحيحات في البيئات الصغيرة

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

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

يُولِّد نظام التصحيح هذا حاجةً إلى عقلية “التصحيح السريع”. لا ينبغي أبداً أن تبقى التصحيحات دون تطبيق؛ يجب تطبيقها في أغلب الأحيان بمجرد إصدارها واختبارها. الانتظار في تطبيق التصحيحات قد يعني العمل مع ثغرات أمنية حرجة أو إبقاء الأنظمة غير موثوقة دون داعٍ.

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

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

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

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

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