إيجاد السبب الجذري للحادثة بأدلة يمكن التحقق منها

ماذا يستطيع الذكاء الاصطناعي أن يفعل في تحليل السبب الجذري، وماذا لا يستطيع؟

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

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

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

الخطوة الأولى: اجمع المشكلات والنشرات والسجلات والتغييرات

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

• المشكلات والتنبيهات: ما الذي تعطّل، ومتى بدأ، وما الكيانات المتأثرة. في Dynatrace هي المشكلة مع أدلة سببها الجذري، وفي Splunk قد تكون التنبيهات المنطلقة أو الأحداث البارزة في ITSI.
• النشرات: ما البرمجيات التي تغيّرت. أحداث النشر في منصة المراقبة أسرع مصدر، إذا كان خط النشر لديك يسجّلها.
• السجلات والتتبعات والمقاييس: ما الذي فعله النظام فعلا. ابحث عن أنواع أخطاء جديدة، وزمن الاستجابة لكل عملية، واختناق الخدمات المعتمَد عليها.
• طلبات التغيير: ما غيّره الأشخاص خارج النشرات، مثل تغييرات الإعدادات أو الجدار الناري أو قاعدة البيانات أو الشهادات المعتمدة في ServiceNow.

الخطوة الثانية: وحّد كل شيء على نافذة زمنية واحدة

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

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

الخطوة الثالثة: اربط الكيان نفسه عبر الأدوات

نادرا ما تحمل الخدمة الاسم نفسه في كل مكان. يعرّفها Dynatrace بمعرّف كيان، وSplunk بحقل خادم أو مصدر أو فهرس، وServiceNow بعنصر إعداد له معرّف sys_id خاص. وقبل ربط هذه المعرّفات لا يستطيع بوتيفاي أن يعرف أن تغييرا على عنصر إعداد وارتفاعا في الأخطاء على خادم يخصّان الشيء نفسه.

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

الخطوة الرابعة: رتّب الأسباب المحتملة بدلا من تسمية سبب واحد

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

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

الخطوة الخامسة: اجعل كل نتيجة قابلة للتتبع إلى دليلها

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

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

أخطاء شائعة: اختلاف الساعات، والخلط بين الارتباط والسببية، وغيرها

أخطاء تحليل السبب الجذري بمساعدة الذكاء الاصطناعي هي في الغالب أخطاء التحليل البشري نفسها، لكنها تتكرر أسرع. انتبه لما يلي.

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

كيف يدعم بوتيفاي تحليل السبب الجذري؟

يمنح بوتيفاي أدوات ربط مخصصة لهذه الخطوات بالضبط: correlation.find_entity تعثر على الخدمة أو الخادم أو التطبيق نفسه في جميع الأنظمة المتصلة؛ وcorrelation.link_entity تسجّل أن معرّفا في أداة ما يشير إلى ذلك الكيان، وتنتظر دائما موافقة بشرية؛ وcorrelation.time_window_overlap تتحقق من تداخل نافذتين زمنيتين مع هامش سماح للأنظمة التي تختلف ساعاتها؛ وcorrelation.evidence_fetch تسترجع الأدلة الكاملة التي جُمعت خلال التشغيل، فيمكن تتبّع كل نتيجة إلى مصدرها.

تعمل هذه الأدوات إلى جانب أدوات قراءة في الموصلات: مشكلات Dynatrace ونشراته، وعمليات البحث في Splunk وأحداث ITSI البارزة، وحوادث ServiceNow والتغييرات القريبة من وقت معيّن. ويمكن تسليم النتيجة تقريرا بصيغة PDF أو XLSX أو DOCX أو CSV، بالعربية أو الإنجليزية.