وكيل ذكاء اصطناعي محلي بدلاً من مسؤول النظام: تحليل مستقل لسجلات الخادم

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

المشكلة: السجلات تنتظر المراجعة اليدوية

الخوادم الفيزيائية تموت تدريجياً. في البداية، تظهر الأخطاء بصمت في syslog و dmesg — قطاعات معطلة، أعطال وحدات الذاكرة، تدهور RAID. ثم يتحول كل هذا إلى kernel panic، توقف غير مخطط له وعمل طوارئ ليلي مع مراجعة إلزامية لاحقة.

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

كيف يعمل الوكيل المحلي

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

القرار المعماري الرئيسي هو اللامركزية الكاملة. تبقى السجلات داخل الحدود: لا توجد طلبات للسحابة، لا توجد تبعية على واجهات برمجية خارجية، لا توجد مخاطر تسريب بيانات العميل. بالنسبة للبنية الأساسية للمؤسسات، هذا شرط أساسي وليس خياراً.

ما يقوم به الوكيل تلقائياً:

• يجمع السجلات من عدة خوادم وفقاً لجدول زمني: syslog و dmesg و SMART و mcelog
• يبحث عن حالات شاذة — أخطاء القرص وأعطال الذاكرة ومشاكل الشبكة ونظام الملفات
• يحدد أولويات النتائج: الحوادث الحرجة منفصلة عن الضوضاء الخلفية
• ينشئ تقريراً قابلاً للقراءة مع وصف المشاكل وتوصيات محددة للمعالجة
• يرسل تنبيهات إلى Telegram أو البريد الإلكتروني دون تدخل بشري

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

لماذا لا يوجد ذكاء اصطناعي سحابي

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

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

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

ماذا يعني هذا

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