لقد غيّر الذكاء الاصطناعي طريقة بناء البرمجيات، لكنه لم يغير حقيقة أساسية عن الآلات؛ فهي تغرق في الضجيج تماماً مثل

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

لماذا تكسر السجلات الخام مسارات الذكاء الاصطناعي

تولد الأنظمة الحديثة بيانات القياس عن بُعد (telemetry) بمعدل لا يمكن لأي إنسان قراءته. وهذا من شأنه أن يجعلها مثالية للذكاء الاصطناعي، لكنه لا يفعل. فنافذة السياق في نماذج اللغة الكبيرة، رغم نموها، لا تزال أنبوباً محدوداً. إذا حشوتها بسجلات الإنتاج غير المفلترة، فستضيع الرموز (tokens) على نبضات مهام cron وضجيج فحوصات الحالة، بينما تدفن الانقطاع الفعلي للخدمة. والأسوأ من ذلك، أن السجلات الخام تفتقر إلى العلاقات. فارتفاع مفاجئ في زمن الاستجابة (latency) في الساعة 2:00 مساءً وخطأ في اتصال قاعدة البيانات في سجل في نفس الطابع الزمني مرتبطان بوضوح، ولكن ما لم يقم شخص ما بهيكلة تلك العلاقة مسبقاً، فسيتعين على الذكاء الاصطناعي التخمين. والتخمين مكلف وبطيء وغالباً ما يكون خاطئاً.

الحل معماري وليس خوارزمياً. عليك أن تقرر ما الذي يتم جمعه، وكيف يتم تشكيله، وأي خلفية (backend) تجيب على أي سؤال قبل أن تقوم بكتابة أي أمر (prompt) للنموذج.

محاور المراقبة الأربعة

في airCloset، توقف الفريق الهندسي عن التعامل مع قابلية الملاحظة (observability) كأنها خرطوم مياه واحد ضخم. لقد قسموا المراقبة إلى أربعة محاور متميزة، لكل منها شكل محدد ويجيب على سؤال محدد.

• التطبيق (Application): تجيب السجلات والتتبعات على "ماذا يحدث الآن؟"
• البنية التحتية (Infrastructure): تجيب المقاييس على "هل لدينا موارد كافية؟"
• التكامل المستمر (CI): تجيب السجلات والتنبيهات على "ما الذي تعطل ومتى؟"
• نماذج اللغة الكبيرة (LLM): تجيب المقاييس والسجلات المهيكلة على "كم ننفق؟"

هذا الفصل مهم لأن الشكل المناسب لرسم بياني لزمن الاستجابة في الوقت الفعلي لا فائدة منه لتحليل التكلفة اللاحق. إن فرض مخطط (schema) واحد عبر جميع المجالات الأربعة يخلق بالضبط نوع الضجيج الذي يجعل المساعدة من الذكاء الاصطناعي عديمة الفائدة.

قابلية ملاحظة التكامل المستمر: السحب، لا الدفع

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

في airCloset، قلبوا هذا النموذج. مشغل CI لا يلمس حزمة الملاحظة (observability stack). بعد انتهاء سير عمل GitHub Actions، يقومون بسحب السجلات من GitHub API وإدخالها في Loki.

توفر بنية السحب هذه ثلاث مكاسب ملموسة.

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

الأمان (Security). لا يحتاج سير عمل CI أبداً إلى مفتاح API الخاص بـ Grafana. من المعروف أن كود الاختبار يلمس أسراراً لا ينبغي له لمسها، وإزالة هذا التعرض يقلل من نطاق التأثير (blast radius) في حال تعرض أحد التبعيات للاختراق.

الاستعلام المتقاطع (Cross-querying). بمجرد أن يقوم الـ CI