يتلخص الفرق بين إدارة الحوادث وإدارة المشكلات في السرعة مقابل السبب. فالحادث انقطاع غير مخطط في خدمة أو تراجع في جودتها، وتوجد إدارة الحوادث لاستعادة الخدمة الطبيعية بسرعة. والمشكلة هي السبب الفعلي أو المحتمل لحادث أو أكثر، وتوجد إدارة المشكلات لإيجاد هذا السبب وتقليل تكرار الحوادث. أما تمكين التغيير، وهو اسم إدارة التغيير في ITIL 4، فيضبط التعديلات على الخدمات العاملة التي إما تعالج مشكلة أو تسبب الحادث التالي.
أربعة أنواع من الطلبات وأربعة أسئلة مختلفة
يحتوي طابور مكتب الخدمة على أكثر من الأعطال، لذا يبدأ الفصل بفرز ما يصل. وتغطي أربعة اختبارات معظم الطلبات:
- شيء معطل أو يعمل بشكل سيئ للمستخدمين الآن: هذا حادث.
- شخص يطلب شيئاً هو جزء طبيعي من الخدمة، مثل صلاحية أو معدات: هذا طلب خدمة.
- الشيء نفسه يتعطل باستمرار، أو لا أحد يعرف سبب تعطله: هذه مشكلة.
- شخص على وشك إضافة شيء أو تعديله أو إزالته بما قد يؤثر على خدمة: هذا تغيير.
قد يمس عطل واحد السجلات الأربعة، كما يوضح المثال أدناه، لكنها تبقى منفصلة لأن لكل منها هدفاً ووتيرة مختلفين. ومزجها ينتج تقارير يصعب الوثوق بها، وفصلاً بين الحوادث والمشكلات لا يستطيع أحد قياسه.
إدارة الحوادث مقابل إدارة المشكلات
تتعامل الممارستان مع الأعطال نفسها، ولهذا هما الثنائي الأكثر التباساً. وتصفهما خدمة تقنية المعلومات بجامعة إيموري بأنهما إجراءان منفصلان مترابطان بشدة ويستخدمان عادةً الأدوات نفسها، وما يفصل بينهما هو الهدف.
إدارة الحوادث في ITIL تضع استعادة الخدمة أولاً
يتمحور وصف PeopleCert لـممارسة إدارة الحوادث في ITIL 4 حول استعادة الخدمة الطبيعية بسرعة بعد الانقطاع وتقليل وقت التوقف. ومقياس النجاح هو سرعة عودة المستخدمين إلى العمل لا سبب تعطل الخدمة. ولهذا يُعد الحل المؤقت طريقة مشروعة لحل الحادث، إذ تصف خدمة تقنية المعلومات بجامعة كورنيل عمل الحوادث بأنه إصلاح أو حلول مؤقتة. فإعادة تشغيل خدمة أو تفريغ قرص ممتلئ كلاهما يُحتسب، مع أن أياً منهما لا يزيل السبب.
إجراء إدارة المشكلات يلاحق السبب
يصف ITIL 4 إدارة المشكلات بأنها تقليل احتمال الحوادث وأثرها بتحديد الأسباب الفعلية والمحتملة وإدارة الحلول المؤقتة والأخطاء المعروفة. وبعبارة بسيطة، الخطأ المعروف مشكلة فُهم سببها ولم يُصلح بعد، ويُسجل مع حله المؤقت، فيستطيع المهندس التالي الذي يواجه العَرَض حل الحادث بسرعة ريثما يُرتب الإصلاح الدائم. فالخطأ المعروف هو الجسر بين الممارستين، يتيح لجانب الحوادث التحرك بسرعة بينما يأخذ جانب المشكلات الوقت الذي يحتاجه.
لكلمة “المحتملة” أهميتها، فسجل المشكلة قد يبدأ من نمط في بيانات الطلبات، لا من انقطاع وقع بالفعل فقط.
إدارة الحوادث وإدارة المشكلات في لمحة
| السؤال | إدارة الحوادث | إدارة المشكلات |
|---|---|---|
| ما الذي يطلقها؟ | انقطاع خدمة أو تدهورها | تكرار الحوادث، أو سبب مجهول، أو نمط يشير إلى خطر |
| ما الذي تسعى إلى تحقيقه؟ | استعادة الخدمة الطبيعية بسرعة | حوادث أقل وأصغر بمعالجة الأسباب |
| ما الذي يُعد إنجازاً؟ | استعادة الخدمة، وربما بحل مؤقت | إزالة السبب، أو توثيق حل مؤقت وخطأ معروف ريثما يُرتب الإصلاح |
| ما سرعة تحركها؟ | بالسرعة التي تتطلبها الأولوية | بالوتيرة التي يحتاجها التحقيق |
| ماذا تنتج؟ | طلب محلول ومستخدم على علم | نتيجة بالسبب الجذري، وسجل خطأ معروف، وعادةً طلب تغيير |
يصف الصفان الأخيران الممارسة الشائعة لا متطلباً من ITIL.
موقع تمكين التغيير في ITIL بين الحوادث والمشكلات
يعرّف ITIL 4 التغيير بأنه إضافة أو تعديل أو إزالة أي شيء قد يكون له أثر مباشر أو غير مباشر على الخدمات. وتهدف ممارسة تمكين التغيير إلى زيادة عدد التغييرات الناجحة بضمان تقييم المخاطر، واعتماد مضي التغييرات، وإدارة جدول التغييرات. والتعريف واسع: فتحديث برمجي وقاعدة جدار حماية وإعداد تهيئة كلها قد تُعد تغييرات.
ومن الطرق الشائعة تصنيف التغييرات إلى ثلاثة أنواع، لكل منها مسار اعتماد خاص:
- التغيير القياسي. منخفض المخاطر، مفهوم وموثق جيداً، وله تفويض مسبق، فلا يحتاج أحد إلى اعتماده في كل مرة. ومثال AWS إنشاء مورد تخزين داخلي بطلب من مستخدم.
- التغيير العادي. المسار الافتراضي لأي تغيير فريد أو أعلى خطراً، ويُراجع ويُعتمد قبل تنفيذه. ومثاله النموذجي قاعدة جدار حماية تفتح منفذاً غير قياسي لخدمة جديدة.
- التغيير الطارئ. مطلوب بسرعة لاستعادة العمليات أو معالجة خطر جسيم. والاعتماد أسرع، لكن إجراءً موثقاً يبقى منطبقاً.
من يعتمد خيار تصميمي. فمجلس استشاري للتغيير خيار واحد، وتشير إرشادات AWS لتمكين التغيير إلى أبحاث تفيد بأن المراجعة بين الأقران داخل الفريق قد تضبط المخاطر بقدر ما يفعل المجلس، ما يتيح للمنشآت توزيع الاعتماد.
يقع التغيير على جانبي الحوادث والمشكلات: فالتغيير غير المراجَع قد يسبب حوادث، والإصلاح الدائم لمشكلة هو بحد ذاته تغيير يحتاج إلى التقييم نفسه.
عطل واحد وأربعة سجلات
يوضح هذا السيناريو المفترض عمل إدارة الحوادث وإدارة المشكلات والتغيير على العطل نفسه، وهو غير مبني على أي عميل أو حدث حقيقي.
- الحادث. عدة موظفين لا يستطيعون فتح نظام الإجازات والحضور. يسجل مكتب الخدمة حادثاً واحداً ويحدد أولويته حسب الأثر على الأعمال، لأن إدارة كاملة لا تستطيع تسجيل الحضور. وفي الأثناء يطلب مدير جديد صلاحية الوصول إلى تقرير، فيذهب ذلك إلى طابور طلبات الخدمة لا الحوادث.
- الحل المؤقت. يجد مهندس قرص خادم التطبيق ممتلئاً بملفات سجلات قديمة، فيحذفها ويعيد تشغيل الخدمة، ويعود المستخدمون إلى العمل خلال ساعة. ويُحل الحادث بحل مؤقت، لأن شيئاً لم يعالج سبب امتلاء القرص.
- المشكلة. بعد خمسة أسابيع يعود العطل نفسه. يربط مكتب الخدمة الحادث الجديد بالسابق ويُفتح سجل مشكلة. ويُظهر التحقيق أن تدوير السجلات أُوقف أثناء ترقية. ويسجل الفريق خطأً معروفاً مع حل التنظيف المؤقت، ويفحص الخوادم الأخرى المبنية بالطريقة نفسها، وهذا هو جانب “السبب المحتمل” في الممارسة.
- التغيير. إعادة تشغيل تدوير السجلات وتكبير القرص تعديل على نظام عامل، فيُرفع كتغيير عادي: تقييم المخاطر، وكتابة خطة التراجع، والاعتماد، والاتفاق على وقت خارج ساعات العمل. ولو امتلأ القرص مجدداً في منتصف يوم العمل دون حل مؤقت متبقٍ، لربما استُخدم تغيير طارئ بدلاً من ذلك.
- الإغلاق. بعد فترة متفق عليها دون تكرار، تُغلق المشكلة ويُلغى الخطأ المعروف.
هذه هي الحجة العملية لفصل الممارستين: فدون سجل المشكلة لتكرر التنظيف إلى ما لا نهاية.
طلب الخدمة مقابل الحادث
طلب الخدمة طلب من المستخدم لشيء متفق عليه كجزء طبيعي من الخدمة، مثل صلاحية أو معلومات أو معدات. والحادث شيء توقف عن العمل أو يعمل بشكل سيئ. فحاسب محمول لموظف جديد طلب، وحاسب لا يعمل حادث.
تصف PeopleCert إدارة طلبات الخدمة بأنها معالجة الطلبات المحددة مسبقاً التي يقدمها المستخدمون، ولهذا تكون للطلبات عادةً نماذج وخطوات اعتماد محددة. وتسجيلها كحوادث يضخم أعداد الحوادث ويدفن الأعطال الحقيقية ويشوّه أي تحليل مبني عليها. ويحتاج كل نوع إلى أهدافه الخاصة، التي يحددها نموذج اتفاقية مستوى الخدمة لمكتب الخدمة حقلاً بحقل.
أربع عادات تطمس السجلات
الفرق التي تفهم الفرق نظرياً ما زالت تنزلق عملياً.
- إغلاق الحوادث دون فحص للمشكلات. ضع قاعدة، مثل مراجعة مشكلة لكل حادث متكرر، وكل حادث احتاج إلى حل مؤقت، وكل انقطاع عالي الأولوية.
- فتح مشكلة لكل حادث. عمل المشكلات يستهلك وقت المهندسين، فاحتفظ به للحوادث المتكررة أو ذات الضرر الفعلي.
- إصلاح بيئة الإنتاج دون سجل تغيير. الإصلاح السريع يبقى تغييراً، والمهندس التالي لا يستطيع معرفة حدوثه.
- ترك الإعدادات الافتراضية للأداة تعرّف المصطلحات. اكتب التعريفات بكلماتك، ثم هيّئ التصنيفات لتطابقها.
يمكن للفرق التي تريد تعريفات ومسارات اعتماد مكتوبة لبيئتها الاطلاع على تصميم إدارة الخدمات ومكتب الخدمة المتوافق مع ITIL لدى وسنا للحلول الرقمية، الذي يبدأ عادةً بإدارة الحوادث والتغييرات ويضيف إدارة المشكلات مع تراكم بيانات الطلبات. وتجد الخلفية الأوسع في مقال ما إدارة خدمات تقنية المعلومات وعلاقتها بـ ITIL.
ملاحظة حول الأسماء والإصدارات
يسمي ITIL 4 الممارسة تمكين التغيير، بينما يعنون معيار ISO/IEC 20000-1:2018 بنده حول الموضوع نفسه “إدارة التغيير” (8.5.1)، ويجمع إدارة الحوادث (8.6.1) وإدارة طلبات الخدمة (8.6.2) وإدارة المشكلات (8.6.3) تحت “الحل والتنفيذ”. فإن استخدم عقد أو قائمة تدقيق أحد هذه الأسماء، فتحقق من التعريف الذي يعتمد عليه. والفصل بين الحوادث والمشكلات موجود في الإطارين، كممارسات منفصلة في ITIL 4 وبنود منفصلة في ISO/IEC 20000-1:2018.
يستخدم هذا المقال مصطلحات ITIL 4. وقد أصدرت PeopleCert لاحقاً ITIL (الإصدار 5)، وتذكر الأسئلة الشائعة لـ ITIL أن الخطة الحالية إيقاف جميع وحدات ITIL 4 في 31 ديسمبر 2027. فإن كنت تخطط للتدريب، فتحقق من الإصدار الذي يدرّسه المزود.
تحقق من طريقة فصل فريقك بين الحوادث والمشكلات والتغيير
أخبرنا بالأداة التي تستخدمها، وكيف تُسجل الحوادث والتغييرات حالياً، وأين تتكرر الأعطال نفسها، وسنناقش أين تحتاج التعريفات ومسارات الاعتماد إلى إحكام.
ناقش إجراءات الحوادث والتغيير لديكالمصادر
- ITIL 4 Practitioner: Incident Management، PeopleCert. تاريخ الاطلاع: 2 أكتوبر 2026.
- ITIL 4 Practitioner: Problem Management، PeopleCert. تاريخ الاطلاع: 2 أكتوبر 2026.
- ITIL 4 Practitioner: Change Enablement، PeopleCert. تاريخ الاطلاع: 2 أكتوبر 2026.
- ITIL4 Practices: Service Request Management، PeopleCert. تاريخ الاطلاع: 2 أكتوبر 2026.
- ITIL FAQ، PeopleCert. تاريخ الاطلاع: 2 أكتوبر 2026.
- Change enablement in ITIL 4، ضمن Change Enablement in the Cloud، AWS Well-Architected (يقتبس دليل ممارسة تمكين التغيير في ITIL 4). تاريخ الاطلاع: 2 أكتوبر 2026.
- Change management categories and priorities، ورقة AWS البيضاء Establishing Your Cloud Foundation on AWS. تاريخ الاطلاع: 2 أكتوبر 2026.
- Incident, Request, Problem, Change، تقنية المعلومات بجامعة كورنيل (صفحة غير مؤرخة). تاريخ الاطلاع: 2 أكتوبر 2026.
- Incident vs. Service Request vs. Change، مدونة ITIL Tattle، جامعة إدنبرة، 2 أغسطس 2019. تاريخ الاطلاع: 2 أكتوبر 2026.
- Problem Process Guidelines، تقنية المعلومات بجامعة إيموري (صفحة غير مؤرخة). تاريخ الاطلاع: 2 أكتوبر 2026.
- ISO/IEC 20000-1:2018, Information technology, Service management, Part 1: Service management system requirements، ISO؛ عناوين البنود متحقق منها في المقتطف العام المتاح. تاريخ الاطلاع: 2 أكتوبر 2026.
