یک بنچمارک ایمنی جدید برای دستیاران مبتنی بر هوش مصنوعی در Kubernetes منتشر شده است. این بنچمارک بررسی می‌کند که آیا ابزارهایی مانند K8sGPT می‌توانند به‌درستی از انجام اصلاحات پرخطر خودداری کنند یا خیر. این بنچمارک که بر پایه ۱۶۳ حادثه برچسب‌گذاری‌شده ساخته شده است، دستیار را مجبور می‌کند تا قبل از صدور هرگونه دستوری، عدم قطعیت را تشخیص داده و از اقدامات ناایمن خودداری کند.

چرا یک بنچمارک جدید اهمیت دارد

ابزارهای هوش مصنوعی برای DevOps و SRE در سال گذشته به شدت افزایش یافته‌اند. محصولات اکنون کلاسترها را اسکن می‌کنند، خطاها را آشکار می‌سازند و دستورات اصلاحی را پیشنهاد می‌دهند. اکثر کاربران سوال بدیهی را می‌پرسند: آیا این ابزار می‌تواند مشکل را حل کند؟ در محیط production، این سوال ناقص است. یک اصلاح مطمئن اما اشتباه می‌تواند باعث restart اشتباهِ یک workload، حذف یک namespace حیاتی، یا اعمال تغییر در پیکربندی شود که منجر به یک outage گسترده می‌گردد. آزمون واقعی ایمنی این است که آیا سیستم می‌داند چه زمانی نباید هیچ کاری انجام دهد.

این بنچمارک چه چیزی را ارزیابی می‌کند

این بنچمارک، تست‌های معمول «فقط تشخیص» (diagnose-only) را گسترش می‌دهد تا ابعاد وسیع‌تری از ایمنی را پوشش دهد. این بنچمارک ۱۶۳ مورد را در چهار دسته گروه‌بندی می‌کند:

  • حوادث روتین – خطاهای رایج مانند ImagePullBackOff یا OOMKilled.
  • علائم آشنا با علل پنهان – مشکلاتی که عادی به نظر می‌رسند اما از پیکربندی‌های اشتباه و مبهم ناشی می‌شوند.
  • شکست‌های پیچیده در لایه‌های مختلف – مشکلاتی که شامل تعامل بین networking، storage و control plane هستند.
  • شواهد گمراه‌کننده یا خصمانه – سناریوهایی که در آن‌ها logs یا metrics به‌طور عمدی به مسیر اشتباه اشاره می‌کنند.

نگاهی اجمالی به یافته‌ها

  • وظایف روتین – K8sGPT به‌طور مداوم خطا‌های ساده را شناسایی کرده و اصلاحات مناسب را پیشنهاد داد.
  • مسائل پیچیده – دستیار در مواجهه با شکست‌های probe و سایر مشکلات چند‌مؤلفه‌ای دچار مشکل شد.
  • رفتار خودداری (Abstention) – در بسیاری از موارد مبهم، سیستم تصمیم گرفت هیچ کاری انجام ندهد؛ این کار از اجرای یک دستور اشتباه ایمن‌تر است، اما همچنان نشان‌دهنده درک سطحی از root cause است.
  • افزودن لایه LLM – تقویت جریان کاری با یک مدل زبانی بزرگ (LLM) باعث افزایش امتیازهای اطمینان شد، اما در عین حال توصیه‌های ناایمن را نیز افزایش داد. این آزمایش بر نیاز به یک لایه routing آگاه از ریسک (risk-aware) تأکید کرد که بتواند اقدامات با اطمینان بالا اما پرخطر را فیلتر کند.

هزینه اعتمادبه‌نفس بیش از حد

اطمینان بالاتر از سوی یک LLM تضمین‌کننده صحت نیست. وقتی مدل فکر می‌کند پاسخ را «می‌داند»، حتی اگر شواهد موجود کافی نباشد، دستور را به مرحله اجرا می‌فرستد.

استدلال متقابل: آیا خودداری کردن کافی است؟

خودداری کردن از انجام کار، ایمن‌تر از اعمال یک تغییر بد است، اما با درک واقعی یکسان نیست. دستیاری که مدام کار را به انسان ارجاع می‌دهد، ممکن است از فجایع جلوگیری کند، اما در ارائه مزایای بهره‌وری که توجیه‌کننده به‌کارگیری هوش مصنوعی است نیز شکست می‌خورد.

آنچه باید در آینده زیر نظر داشت

  • مسیریابی آگاه از ریسک – استفاده از یک لایه routing آگاه از ریسک برای فیلتر کردن اقدامات با اطمینان بالا اما پرخطر.

خلاصه کلام

بنچمارک ایمنی K8sGPT نشان می‌دهد که ایمن‌ترین راه حل در Kubernetes اغلب، انجام ندادن هیچ اصلاحی است. قابلیت اطمینان در محیط production به توانایی سیستم در تشخیص عدم قطعیت خود و عقب‌نشینی بستگی دارد. با توانمندتر شدن دستیاران هوش مصنوعی، توسعه‌دهندگان و SREها باید خویشتن‌داری را در جریان کاری خود بگنجانند و عبارت «شواهد کافی ندارم» را به عنوان یک پاسخ معتبر و گاهی بهینه در نظر بگیرند.

منابع