هل يتصرف النظام تلقائيا أم نستدعي الإنسان: حساب الحدود الآمنة للاستجابة لحوادث GPU في Kubernetes

إذا كنت مهندس SRE أو MLOps يدير عنقود GPU متعدد المستأجرين وفكر في تكليف عميل LLM بمعالجة الحوادث عن بُعد لتقليل عبء المناوبة، فمن المرجح أنك واجهت بالفعل السؤال الذي تطرحه الورقة البحثية التي نقدمها في هذا المقال. هل نترك العميل يقرر ويتصرف بنفسه، أم نستدعي الإنسان؟ بدلا من تحديد هذا الحد الفاصل بالحدس أو بمناقشات الفريق، يقدم هذا البحث صياغة رياضية لمستوى الخطورة حسب نوع الحادثة، مع حساب فعلي للعتبة التي تقلل زمن الاسترداد إلى أقصى حد ممكن ضمن سقف أمان محدد. تحتوي الورقة على منهجية يمكن لأي منظمة تدير أحمال عمل GPU باستخدام قوائم انتظار Kueue وسياسات قبول Kyverno الاستفادة منها مباشرة.

المعالجة الذاتية الكاملة والتجنب الكامل ليسا الحل

عندما يختل إعداد واحد في المجدول، أو يتوقف حجم تخزين دائم (Persistent Volume)، أو تتعرض عقدة لضغط في الذاكرة، يتوقف حمل عمل التدريب أو الاستدلال العامل فوقها، ويضطر مهندس المناوبة في النهاية إلى تحديد السبب وإصلاحه تحت ضغط الوقت. التكلفة التي نواجهها هنا نوعان. الأولى هي متوسط زمن الاسترداد (MTTR)، إذ إن كل لحظة يتوقف فيها حمل عمل GPU تعني سعة مهدورة وهدف مستوى خدمة منكسر. والثانية هي عبء المناوبة، فاستدعاء الإنسان في كل مرة بسبب مشكلة بسيطة يمكن التراجع عنها آليا ليس بطيئا فحسب بل يستنزف المشغلين أيضا. ولهذا يبدو مقترح تشغيل حلقة مغلقة يراقب فيها عميل LLM بيانات القياس عن بُعد وواجهات مستوى التحكم ويقرر ويتصرف من دون الإنسان أمرا جذابا.

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

حساب الحد الفاصل بمعادلة المخاطر و176 حادثة

يتناول فريق البحث هذا الحد الفاصل عبر أربعة أنواع من الحوادث: نفاد الذاكرة (OOM)، فشل مطالبة الحجم الدائم (PVC)، ضغط العقدة، وتجويع المجدول. وهذا إطار يوسع فكرة “استخدام المُصرِّف كإشارة مكافأة” المستمدة من هندسة الحلقات (loop-engineering) في مجال توليد الكود، ليشمل تشغيل البنية التحتية. ففي الكود، كان المُصرِّف أو حزمة الاختبارات يحكم موضوعيا على النجاح، أما في المعالجة عن بُعد للبنية التحتية، فتتولى هذه المهمة إشارات التشخيص التي يوفرها kubectl. غير أن هذه الإشارة أيضا ليست مقياسا كاملا، تماما مثل حزمة اختبارات الكود، وتوضح الورقة بشكل صريح في مواضع عدة أن الضوء الأخضر في إشارة التشخيص لا يضمن أن الإجراء كان آمنا فعلا.

نظرا لأن ربط عميل بعنقود حي فعلي للتجربة يولد متغيرات كثيرة يصعب التحكم فيها، أنشأ فريق البحث 176 حدث حادثة من خلال تقاطع 22 ملف بيان YAML من Kueue وKyverno مأخوذة من مستودعات GitOps تابعة لمنظمات حقيقية مع 8 فئات من إجراءات المعالجة عن بُعد. وجاءت تسمية كل حدث بالخطر أو الأمان من جدول معايير صريح يعتمد على إمكانية التراجع، وفقدان البيانات، وتجاوز حدود المستأجر. وبدلا من الاعتماد على ثقة العميل المنشور فعليا، وضع الفريق معادلة مخاطر شفافة تجمع بترجيح ثلاثة عناصر: الخطورة الأساسية حسب درجة إمكانية التراجع لفئة الإجراء، ومؤشر نطاق التأثير البنيوي مُطبَّع بعدد أسطر YAML، وما إذا كانت سياسة قبول Kyverno تؤثر على العنقود بأكمله. وتؤكد الورقة مرارا أن هذه المعادلة مؤشر بديل صممه بشر وليست نموذجا متعلما.

استنادا إلى قاعدة قرار بسيطة، تكون المعالجة ذاتية إذا كانت درجة الخطورة أقل من العتبة، وتُحال إلى الإنسان إذا تجاوزتها، فحص الفريق نطاقا من قيم العتبة مع سقف أمان يحصر نسبة الإهمال الكارثي عند 2 بالمئة أو أقل. وأسفرت النتيجة عن عتبة عالمية مثلى (τ=0.325) قللت MTTR بنسبة 41.7 بالمئة من دون أي إهمال كارثي، وهي نقطة تتفوق على كلا الطرفين، التصعيد الدائم والمعالجة الذاتية الدائمة.

عندما تتجاوز العتبة τ قيمة 0.35، ترتفع نسبة الإهمال الكارثي (الخط المتصل) بشكل حاد، بينما تستمر نسبة التصعيد غير الضروري (الخط المتقطع) في الانخفاض. عند النقطة المثلى العالمية (τ=0.325) الموضحة بمثلث، انخفض MTTR بنسبة 41.7 بالمئة من دون أي إهمال كارثي. قيست النتائج باستخدام معيار قياس محلي لعنقود AI Platform Demo (176 حدث حادثة اصطناعي)، مع افتراض تأخير قدره 40 ثانية للمعالجة الذاتية و1200 ثانية للتصعيد.

الجوهر الحقيقي: يجب ضبط عتبة منفصلة لكل نوع حادثة

يذهب الاكتشاف المحوري للورقة خطوة أبعد من هذا. فنطاق التأثير ودرجة تعرض المستأجر يختلفان اختلافا كبيرا بين أنواع الحوادث، ولذلك لا يمكن لعتبة عالمية واحدة أن تستوعب هذا التباين. وعندما حُسبت عتبة مثلى منفصلة لكل نوع من الأنواع الأربعة مع الحفاظ على سقف الأمان نفسه (2 بالمئة)، تباينت النتائج بشكل كبير: ضغط العقدة عند τ=0.30 المحافظة (تحسن 28.6 بالمئة)، وفشل PVC عند τ=0.35 (تحسن 43.9 بالمئة)، وتجويع المجدول عند τ=0.45 (تحسن 39.5 بالمئة)، ونفاد الذاكرة عند عتبة أكثر تساهلا بكثير τ=0.475 (تحسن 96.7 بالمئة). ومتوسط نسبة التحسن لهذه الأنواع الأربعة يبلغ 52.2 بالمئة، أي أعلى بنحو 10.4 نقطة مئوية من نسبة 41.7 بالمئة التي تنتج عن تطبيق عتبة عالمية واحدة على جميع الأنواع بالتساوي. وهذا يعني أنه بمجرد ضبط عتبة منفصلة لكل نوع مع الحفاظ على سقف الأمان نفسه، يمكن الحصول على قدر إضافي من الاستقلالية الذاتية بهذا المقدار.

معايرة العتبة بشكل منفصل لكل نوع حادثة تحقق تحسنا متوسطا في MTTR بنسبة 52.2 بالمئة، متجاوزة نسبة 41.7 بالمئة للعتبة العالمية الواحدة. والسبب هو اختلاف نطاق التأثير ودرجة تعرض المستأجر بين الأنواع. قيست النتائج في المعيار المحلي نفسه، وقد أمكن استخدام عتبة متساهلة بشكل خاص (τ=0.475) مع نفاد الذاكرة لأنه لا يوجد في جدول المعايير هذا أي إجراء مصنف بأنه خطير لهذا النوع.

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

ما تتركه هذه الدراسة للشركة والمجتمع

يمكن لهذه النتائج أن تُستخدم مباشرة كإطار عمل قابل للقياس لحدود الاستقلالية الذاتية عندما تعمل ThakiCloud فعليا على أتمتة الاستجابة لحوادث GPU المستندة إلى Kueue وKubernetes. وهذا يتيح بناء خطط تقليل MTTR وعبء المناوبة على بيانات مثبتة بدلا من الحدس. وعلى نطاق أوسع، تكتسب الدراسة أهمية لأنها تقدم منهجية لتصميم الحدود الآمنة وسياسات التصعيد يمكن لأي منظمة أخرى تحاول تشغيل بنية تحتية غير مأهولة إعادة استخدامها. وينطبق الهيكل نفسه ليس فقط على عناقيد GPU، بل على أي مستوى تحكم متعدد المستأجرين تختلط فيه الإجراءات القابلة للتراجع مع غير القابلة للتراجع، مثل قواعد البيانات التي تتراوح بين ترحيل المخطط وتعديل صف بسيط، أو الشبكات التي تتراوح بين تغيير التوجيه وإعادة تهيئة الجهاز، أو التخزين الذي يتعامل مع استعادة اللقطات. أما من الناحية الأكاديمية، فتسهم الدراسة في توسيع فكرة هندسة الحلقات القائمة على “استخدام المُصرِّف كإشارة مكافأة” المستخدمة في توليد الكود لتشمل بوضوح مجال المعالجة عن بُعد للبنية التحتية، مع إضافة منهجية قياس جديدة تُكمّم المفاضلة بين الاستقلالية الذاتية والأمان حسب نوع الحادثة.

يجب توضيح القيود أيضا بوضوح

هناك افتراضات يجب تذكرها عند قراءة هذه النتائج. لم يقم فريق البحث بنشر عميل LLM فعليا في عنقود حي حقيقي وتجربته. صحيح أن ملفات بيان YAML الاثنين والعشرين موارد حقيقية مأخوذة من مستودعات GitOps فعلية، لكن أحداث الحوادث الـ176 ونتائجها مُصممة وليست ملاحظة من سجلات تشغيل فعلية. كذلك فإن معادلة الخطورة ليست نموذجا متعلما بل مؤشرا بديلا شفافا صممه بشر، ولا يوجد ما يضمن أنه يعيد إنتاج ثقة عميل منشور فعليا. وافتراضات زمن التأخير، 40 ثانية للمعالجة الذاتية و1200 ثانية للتصعيد، ليست قيما قيست من سجلات حوادث فعلية بل تقديرات مستمدة من زمن إعادة ضبط تحكم نموذجي وأهداف مستوى خدمة المناوبة. أما سقف الأمان البالغ 2 بالمئة فليس قيمة مستنتجة من البيانات، بل خيار سياسي يعكس موقفا محافظا تجاه الإجراءات التي لا يمكن التراجع عنها.

يجدر التنويه أيضا إلى أن نوع OOM يرفع متوسط نسبة التحسن البالغة 52.2 بالمئة بشكل كبير. وهذه نتيجة ناتجة عن تصنيف إجراءي OOM كلاهما كآمنين في جدول المعايير هذا، وتذكر الورقة نفسها أن هذا الرقم قد يتغير إذا أُدرج في استجابة OOM إجراء إنهاء إجباري لحاوية (Pod) تابعة لمستأجر آخر. ولذلك يجب قراءة هذه الدراسة على أنها تحقق من صحة منهجية معايرة العتبة نفسها، وليس قياسا لأداء عميل منشور محدد. وتبقى الخطوات التالية هي استبدال معادلة الخطورة بإشارات حلقة تحقق فعلية من عميل حقيقي والتحقق منها عبر سجلات حوادث فعلية، بالإضافة إلى إضافة تحكم مخاطر مطابق (conformal risk control) للارتقاء بضمان الأمان التجريبي إلى ضمان مستقل عن التوزيع.

يمكن الاطلاع على صفحة تفاصيل الورقة البحثية من الرابط التالي: https://huggingface.co/datasets/thaki-AI/daily-paper-2026-07-16-safe-autonomy-k8s-remediation