تولى مساعد مدعوم بالذكاء الاصطناعي مهام المناوبة (on-call) الخاصة بي لمدة سبعة أيام، حيث قام بمعالجة 11 تنبيهًا، وقلص متوسط الوقت الذي أستغرقه لإصلاح المشكلة من 45 دقيقة إلى 20 دقيقة. تكمن أهمية هذه التجربة في أن نموذجًا لغويًا محدود النطاق يمكنه توفير نصف ساعة من وقت الاستجابة للحوادث، مع استمرار حاجته إلى إشراف بشري صارم.

لماذا وضعت ذكاءً اصطناعيًا في مهام المناوبة

تقضي فرق السحابة (Cloud teams) معظم نوبات عملها في البحث في السجلات (logs)، والتحقق من عمليات النشر الأخيرة، والتأكد من أن طلب التوسعة (scaling request) آمن. هذه المهام "المملة" هي مهام قابلة للتكرار، وكثيفة البيانات، وعرضة للإجهاد البشري. وقد وعدت التطورات الأخيرة في النماذج اللغوية الكبيرة بأتمتة هذا النوع من عمل مطابقة الأنماط بالضبط، ولكن معظم العروض التوضيحية العامة تعمل في بيئات تجريبية (sandbox). أردت أن أرى ما إذا كان هذا الزخم سيصمد في عنقود (cluster) بمستوى الإنتاج يخدم عملاء يدفعون مقابل الخدمة بالفعل.

إعداد الاختبار

  • الوصول (Access) – كان بإمكان الوكيل (agent) قراءة كل مقياس وسجل وتعريف للنشر. لكنه لم يكن مسموحًا له بالكتابة إلا ضمن قائمة مسموحات (whitelist) ضيقة: إعادة تشغيل pod، أو زيادة عدد النسخ المتماثلة (replica count)، أو توسعة عملية نشر (scale a deployment). أي إجراء يتجاوز ذلك كان يتطلب موافقتي الصريحة.
  • الدور (Role) – عاملت النموذج كمهندس مبتدئ في أول نوبة مناوبة له. كان يتلقى التنبيه، ويجري تحليله، ثم ينشر توصية في قناة الحوادث (incident channel).
  • شبكات الأمان (Safety nets) – كانت جميع إجراءات الكتابة مقيدة بمطالبة يدوية بـ "نعم/لا". كما وضعت حدًا أقصى لاستهلاك النموذج للرموز (tokens) للحفاظ على تكاليف يمكن التنبؤ بها.

أين تألق الذكاء الاصطناعي

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

  • 8 كانت مشكلات روتينية (ارتفاعات مفاجئة في الذاكرة، إعادة تشغيل الحاويات، أخطاء بسيطة في الإعدادات). وقد حدد الذكاء الاصطناعي السبب الجذري بشكل صحيح في كل مرة.
  • قام برصد زيادة تدريجية في الذاكرة في إحدى الخدمات المصغرة (microservice) قبل أن تتفاقم المشكلة وتتحول إلى انقطاع في الخدمة في الساعة 2 صباحًا، مما منح الفريق فرصة للتدخل المبكر.
  • ظل استهلاك الرموز (tokens) طوال الأسبوع في حدود 30 دولارًا، وهو ما يقع تمامًا ضمن ميزانية المناوبة المعتادة عند وضع سقف لها.

تُترجم هذه النتائج إلى تقليل ملموس في متوسط وقت الحل (MTTR) من 45 دقيقة إلى 20 دقيقة، مما يفرغ المهندسين للتركيز على أعمال ذات تأثير أكبر.

أين تعثر

الثقة لا تعني الصحة. فقد كان الذكاء الاصطناعي مخطئًا بثقة في 3 من أصل 11 تنبيهًا:

  1. ألقى باللوم على عملية نشر كود حديثة في فشل الاتصال بقاعدة البيانات، لكن هذا التفسير كان غير صحيح.
  2. عندما واجه خللًا غير مألوف في الشبكة، قدم حلولاً عامة لم تعالج المشكلة الأساسية.
  3. أثناء تنبيه متعلق بالحمل (load)، اقترح توسعة الخدمة من 3 إلى 30 نسخة متماثلة. لم يكن الحمل هو المشكلة، بل كان هناك خطأ في الإعدادات (config).

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

إدارة التكلفة والمخاطر

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

  • تقييد الإجراءات (Action gating) – السماح للنموذج بالاقتراح فقط، وليس التنفيذ أبدًا، للتغييرات عالية التأثير دون نقرة بشرية.
  • سقف الميزانية (Budget caps) – وضع حدود صارمة لاستهلاك الرموز وتنبيه الفريق عندما يقترب النموذج من الحد الأقصى.

ما يجب مراقبته لاحقًا

حتى ذلك الحين، يجب على الفرق القيام بما يلي:

  • تتبع نسبة الاقتراحات التي يولدها الذكاء الاصطناعي والتي تتطلب تجاوزًا يدويًا.
  • قياس التأثير على متوسط وقت الحل (MTTR) عبر فئات الحوادث المختلفة (الروتينية مقابل المستحدثة).
  • اختبار النموذج في بيئة اختبار (staging) باستخدام تنبيهات اصطناعية قبل منحه أي صلاحيات كتابة في بيئة الإنتاج.

خلاصات لفرق العمليات

  • أتمتة الـ 80% المملة – استخدم الذكاء الاصطناعي لتجميع السجلات، وربط المقاييس، وتوليد الفرضيات الأولية.
  • اترك الـ 20% الخطرة للبشر – يجب أن تظل عمليات التوسعة التي تتجاوز حدًا معينًا، وعمليات التراجع (rollbacks)، وعمليات الحذف، خلف خطوة موافقة يدوية.
  • تعامل مع النموذج كشريك، وليس كبديل – المهندس الذي يعرف النظام يمكنه التحقق من مخرجات الذكاء الاصطناعي بشكل أسرع من أي شخص جديد، مما يحول المساعد إلى مضاعف للقوة (force multiplier).

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