«فينوسلوغي» تطلق وكلاء ذكاء اصطناعي ليليين: اكتشفوا خسائر في 1600 عملية تسجيل دون أي تنبيهات

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

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

كيف تعمل المنظومة الليلية

وفق جدول زمني (في Multica تُسمى هذه الميزة Autopilot) تُنشأ مهمة يلتقطها OpenCode. بعد ذلك يعمل lead-agent، فيقرأ عبر MCP من Confluence فهرس عمليات الأعمال وقواعد المراقبة الخاصة بكل عملية. في السيناريو الأساسي الخاص بـ Prometheus يبلغ عدد هذه العمليات 21. ويوزعها lead-agent على سبعة وكلاء فرعيين، لكل منهم ثلاث عمليات، فيفحص كل وكيل نطاقه بالتوازي.

قُسّم التشخيص عمدًا إلى مرحلتين. في الأولى يعمل وكيل الجمع ضمن منظومة مراقبة واحدة ويجيب عن سؤال محدد: هل هناك انحراف، وما مدى خطورته. فهو يقارن الوقائع مع SLA وbaseline، ويمنح الحالة OK أو WARNING أو BREACH. والمخرج بطاقة قصيرة: العملية، والقيمة الفعلية، وSLA، وbaseline، والبيانات الداعمة. ولا يصل إلى analyst-agent سوى حالتي WARNING وBREACH. فيفتح المستودع المرتبط ويصوغ فرضية للسبب.

إذا تأكد الانحراف، يعدّ Multica مسودة مهمة في Jira. وتتضمن المسودة عملية الأعمال، وقيم المؤشرات، ومخالفة SLA، والسياق التقني، والسبب، ومقترح الإصلاح. والكلمة المفتاحية هنا هي «مسودة»: فالمهندس هو من ينقل المهمة إلى backlog بعد مراجعة الاستنتاجات.

لماذا لا يمكن ببساطة تمرير كل السجلات إلى النموذج

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

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

ثلاثة مصادر، ثلاث طبقات من المشكلات

جرى توسيع المنظومة تدريجيًا، وأجاب كل مصدر عن سؤال مختلف.

• يبيّن Prometheus أين تغيّر شيء ما: failrate وlatency والالتزام بـ SLA لكل عملية. وقد اكتشفت النسخة الأولى القائمة على المؤشرات والشيفرة مشكلات في نحو 1000 عملية تسجيل.
• يشرح OpenSearch ما الذي حدث بالضبط: رموز HTTP ورسائل الأخطاء وstack traces. وأضاف ذلك نحو 600 عملية تسجيل أخرى. وإذا كان السبب في خدمة تابعة لجهة أخرى، يمكن للوكيل دخول مستودع الفريق المجاور عند توفر الصلاحية، ويُحدَّد الارتباط من خلال استدعاءات Feign.
• جلب Sentry فئة جديدة من الإشارات: أخطاء الواجهة الأمامية (frontend) وسرعة تحميل الصفحات. فالصفحة الخالية من الأخطاء لكنها تستغرق دقيقة في التحميل لا تعمل بالنسبة إلى المستخدم، ولن يُظهر ذلك backend failrate.

بعد كل جولة إصلاحات كانت النتيجة تستقر عند مستوى ثابت إلى أن يُربط المصدر التالي. ويصوغ المؤلفون الاستنتاج بصراحة: لم يأتِ التحسن من «ذكاء» النموذج، بل من توسيع نطاق الرؤية.

القيود وما يجب فعله عمليًا

لا يمكن اعتبار failrate صيغة واحدة. فأخطاء 500 وأخطاء 401/403/422 لها دلالات مختلفة، والأخطاء المتوقعة مثل انتهاء الجلسة لها مستوى مقبول خاص بها، ولبعض العمليات استثناءاتها الخاصة. ولا تتجاوز فائدة الوكيل دقة وصف الفريق للعمليات وSLA وbaseline ومعنى الإشارات. فالذكاء الاصطناعي لا يحل محل نموذج المراقبة، بل يستند إليه.

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

إذا أردتم تكرار هذا النهج، فلا تبدؤوا بالوكيل. أولًا حدّدوا بصورة رسمية ما يُعدّ مشكلة وما الذي تُقارن به الإشارات، وإلا فسيعيد LLM إنتاج عدم اليقين لديكم. وثبّتوا التقرير النهائي بوصفه عقدًا: العملية، وmدى الخطورة severity، والوقائع، والأثر، والشيفرة، والفرضية، ومستوى الثقة، والإجراء التالي.

يخطط الفريق لاختصار المسافة بين الفرضية والإصلاح: إصلاحات نموذجية وMR بدلًا من مسودة Jira. لكن كلما اقترب الوكيل من تعديل production، زادت أهمية المراجعة البشرية ومراقبة الوصول وقابلية إعادة الإنتاج. وحتى الآن لا يتفوق «مهندس الذكاء الاصطناعي» المستقل، بل الأدوار الضيقة والحدود الواضحة والإنسان في نقطة اتخاذ القرار.