AI سے چلنے والے Kubernetes اسسٹنٹس کے لیے ایک نیا سیفٹی بینچ مارک جاری کیا گیا ہے۔ یہ اس بات کی پیمائش کرتا ہے کہ آیا K8sGPT جیسے ٹولز خطرناک اصلاحات (fixes) سے صحیح طریقے سے باز رہ سکتے ہیں۔ 163 لیبل شدہ واقعات پر مبنی، یہ بینچ مارک اسسٹنٹ کو مجبور کرتا ہے کہ وہ کسی بھی کمانڈ کے جاری ہونے سے پہلے غیر یقینی صورتحال کو پہچانے اور غیر محفوظ اقدامات سے گریز کرے۔

ایک نیا بینچ مارک کیوں اہم ہے

گزشتہ سال کے دوران DevOps اور site-reliability engineering کے لیے AI ٹولز کی تعداد میں اضافہ ہوا ہے۔ اب پروڈکٹس کلسٹرز (clusters) کو اسکین کرتے ہیں، غلطیوں کو ظاہر کرتے ہیں، اور اصلاحی کمانڈز تجویز کرتے ہیں۔ زیادہ تر صارفین ایک واضح سوال پوچھتے ہیں: کیا یہ ٹول مسئلے کو حل کر سکتا ہے؟ پروڈکشن میں، یہ سوال نامکمل ہے۔ ایک پر اعتماد لیکن غلط اصلاح غلط ورک لوڈ کو دوبارہ شروع کر سکتی ہے، کسی اہم namespace کو حذف کر سکتی ہے، یا ایسی کنفیگریشن تبدیلی لاگو کر سکتی ہے جس کے نتیجے میں پورا سسٹم بند (outage) ہو جائے۔ اصل سیفٹی ٹیسٹ یہ ہے کہ آیا سسٹم کو معلوم ہے کہ کب کچھ نہ کرنا چاہیے۔

بینچ مارک کس چیز کا جائزہ لیتا ہے

یہ بینچ مارک عام "صرف تشخیص" (diagnose-only) والے ٹیسٹ سے آگے بڑھ کر سیفٹی کے وسیع تر پہلوؤں کا احاطہ کرتا ہے۔ یہ 163 کیسز کو چار زمروں میں تقسیم کرتا ہے:

  • روٹین واقعات – عام غلطیاں جیسے کہ ImagePullBackOff یا OOMKilled۔
  • چھپے ہوئے اسباب کے ساتھ مانوس علامات – ایسے مسائل جو عام نظر آتے ہیں لیکن ان کی وجہ مبہم غلط کنفیگریشنز (misconfigurations) ہوتی ہیں۔
  • پیچیدہ کراس لیئر ناکامیاں – ایسے مسائل جن میں نیٹ ورکنگ، اسٹوریج اور کنٹرول پلین کے درمیان تعامل شامل ہو۔
  • گمراہ کن یا مخالفانہ شواہد – ایسے منظرنامے جہاں لاگز (logs) یا میٹرکس جان بوجھ کر غلط سمت میں اشارہ کرتے ہیں۔

ایک نظر میں نتائج

  • روٹین ٹاسک – K8sGPT نے مستقل طور پر سادہ غلطیوں کی شناخت کی اور مناسب اصلاحات تجویز کیں۔
  • پیچیدہ مسائل – اسسٹنٹ پروب فیلئرز (probe failures) اور دیگر کثیر اجزاء والے مسائل میں الجھ گیا۔
  • باز رہنے کا رویہ (Abstention behavior) – کئی مبہم کیسز میں سسٹم نے کچھ نہ کرنے کا انتخاب کیا، جو کہ ایک غلط کمانڈ کے مقابلے میں زیادہ محفوظ ہے لیکن یہ اب بھی بنیادی وجہ (root cause) کی کم گرفت کو ظاہر کرتا ہے۔
  • LLM لیئر کا اضافہ – ورک فلو میں لارج لینگویج ماڈل (LLM) شامل کرنے سے کانفیڈنس اسکورز میں اضافہ ہوا، لیکن غیر محفوظ سفارشات بھی بڑھ گئیں۔ اس تجربے نے ایک 'رسک-اویئر روٹنگ لیئر' کی ضرورت کو اجاگر کیا جو زیادہ اعتماد والے لیکن زیادہ خطرے والے اقدامات کو فلٹر کر سکے۔

ضرورت سے زیادہ اعتماد کی قیمت

LLM سے زیادہ اعتماد درستگی کی ضمانت نہیں دیتا۔ جب ماڈل کو جواب کا "علم" ہوتا ہے، تو وہ کمانڈ کو آگے بڑھا دیتا ہے چاہے بنیادی شواہد ناکافی ہی کیوں نہ ہوں۔

مخالف دلیل: کیا باز رہنا کافی ہے؟

باز رہنا ایک غلط تبدیلی کے مقابلے میں زیادہ محفوظ ہے، لیکن یہ حقیقی فہم (comprehension) کے برابر نہیں ہے۔ ایک اسسٹنٹ جو مسلسل انسان کے فیصلے کا انتظار کرے، وہ شاید آفات سے بچ جائے، لیکن وہ ان پیداواری فوائد (productivity gains) کو فراہم کرنے میں بھی ناکام رہے گا جو AI کے استعمال کا جواز ہیں۔

آگے کیا دیکھنا ہے

  • رسک-اویئر روٹنگ – زیادہ اعتماد والے، زیادہ خطرے والے اقدامات کو فلٹر کرنے کے لیے رسک-اویئر روٹنگ لیئر کا استعمال۔

خلاصہ

K8sGPT سیفٹی بینچ مارک ظاہر کرتا ہے کہ Kubernetes کے لیے سب سے محفوظ اصلاح اکثر 'کوئی اصلاح نہ کرنا' ہوتی ہے۔ پروڈکشن کی پائیداری سسٹم کی اپنی غیر یقینی صورتحال کو پہچاننے اور پیچھے ہٹنے کی صلاحیت پر منحصر ہے۔ جیسے جیسے AI اسسٹنٹس زیادہ باصلاحیت ہوتے جا رہے ہیں، ڈویلپرز اور SREs کو ورک فلو میں ضبط (restraint) کو شامل کرنا چاہیے، اور "میرے پاس کافی شواہد نہیں ہیں" کو ایک درست، اور بعض اوقات بہترین، جواب کے طور پر لینا چاہیے۔

وسائل