الخطوة ١: حدّد هدف الفرز وعقد الإسناد

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

حدّد، كحد أدنى، الحقول المنطقية التالية:

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

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

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

الخطوة ٢: افصل مسؤوليات الوكلاء المتعددين

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

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

بعد ذلك، استخدم دور Team Manager لكل فريق ذي صلة أو لكل نطاق تشغيلي. ويمنح نمط Triangle الموثّق هذا الدور مسؤولية مميزة: استخدام أسماء مكونات الحادث ونطاقه الزمني للاستعلام عن قاعدة بيانات المراقبة المرتبطة بذلك الفريق. ثم يلخّص Team Manager سجلات Monitor Logs ذات الصلة مع الحادث. فهو لا يكرر نص الحادث فحسب، بل يثري النقاش بأدلة خاصة بالفريق.

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

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

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

الخطوة ٣: نفّذ إثراء الأدلة بالاعتماد على Monitor Logs

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

حوّل ذلك إلى تسلسل واضح:

1. استلام الحادث الأصلي من دون تغيير صياغته.
2. استخراج أسماء المكونات المرشحة والنطاق الزمني المرشح.
3. التحقق من هذه العناصر بالرجوع إلى فهرس المكونات المسموح بها وحدود الاستعلام الخاصة بالفريق.
4. إنشاء طلب مراقبة مهيكل لا يتضمن سوى الحقول المعتمدة.
5. تنفيذ الطلب على قاعدة بيانات المراقبة المرتبطة بذلك الفريق.
6. إرجاع أدلة محددة من Monitor Logs، وتوضيح ما إذا كان الاستعلام مكتملاً أو فارغاً أو غامضاً.
7. تلخيص الحادث والأحداث المسترجعة مع التمييز بين الملاحظات المباشرة والتفسير.

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

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

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

الخطوة ٤: نسّق نقاشات الفرق ووجّه الحادث

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

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

ينبغي للمنسق الإجابة عن أربعة أسئلة:

• أي فريق يملك أقوى دليل على مسؤوليته عن المكوّن أو عن المعالجة؟
• ما الملاحظات التي تدعمها بشكل مستقل معلومات الحادث وسجلات المراقبة؟
• ما التعارضات أو البيانات المفقودة التي تمنع إسناداً واثقاً؟
• ما الذي ينبغي على إنسان مخوّل التحقق منه قبل قبول التوجيه؟

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

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

الخطوة ٥: أضف تصعيداً بشرياً آمناً

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

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

يجب أن يتضمن سجل التصعيد الحادث الأصلي، والأدلة المسترجعة، والتفسيرات المتنافسة، والسؤال التالي المقترح، وهوية المراجع المطلوب أو دوره. تجنب اختزال التصعيد في عبارة غامضة مثل «يرجى التحقيق». فالمراجع يحتاج إلى سياق كافٍ لاتخاذ قرار توجيه في الوقت المناسب.

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

الخطوة ٦: اختبر سير العمل مقابل حالات فشل الفرز الواقعية

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

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

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

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

أهم الخلاصات

• فرز الحوادث مشكلة توجيه وتعاون، وليس مجرد مهمة لتصنيف النصوص.
• قد يؤدي ضعف الفرز إلى زيادة Time to Engage والتأثير في جودة الخدمة وثقة العملاء.
• يمكن للتصميم متعدد الوكلاء تنظيم الاستدلال المتخصص حول الفرق والأدلة.
• يستخدم نمط إثراء Team Manager أسماء المكونات والنطاق الزمني للاستعلام عن بيانات المراقبة المرتبطة بالفريق.
• ينبغي تلخيص Monitor Logs مع الحادث مع الحفاظ على إمكانية التمييز بين مصادرها.
• ينبغي أن يقود عدم اليقين وتعارض الأدلة والبيانات المفقودة إلى مراجعة بشرية مهيكلة.
• يمكن اختيار Claude أو FastAPI أو SQLite أو أي حزمة تنفيذ أخرى بشكل منفصل، لكن سياق البحث المقدّم لا يثبت أياً منها.

المصادر وملاحظات التحقق

تستند هذه المعمارية إلى منشوري Microsoft Research الموثّقين بعنواني Triangle: Empowering Incident Triage with Multi-LLM-Agents وTriangle: Empowering Incident Triage with Multi-Agent. ويصف كلاهما فرز الحوادث، وتأثيره في Time to Engage، وقيود سير العمل اليدوي والقائم على القواعد المحددة مسبقاً، والاستدلال التعاوني متعدد الوكلاء. ويصف المصدر الأول تحديداً إثراء معلومات Team Manager من خلال الاستعلام في قواعد بيانات المراقبة وتحليل Monitor Logs مع معلومات الحادث.

تعرض نتيجة في Semantic Scholar أيضاً أعمالاً ذات صلة من عام ٢٠٢٦ حول فرز التذاكر آلياً، من بينها متوسط وقت فرز مُعلن يبلغ ١٥٫٠ ثانية لنظام منفصل يسمى CoTriage. ولا تمثل هذه النتيجة دليلاً على Triangle، ولا ينبغي استخدامها كادعاء أداء للمعمارية الواردة في هذا الشرح العملي.

تحقق تحريرياً من المحتوى فريق تحرير وهندسة بوابة الذكاء الاصطناعي لصالح GateOfAI, LLC، ديلاوير، الولايات المتحدة الأمريكية.