دقت تشخیص در برابر ایمنی عملیاتی در جریان‌های کاری K8sGPT

تصور کنید یک مهندس SRE در میانه شب با هشدار شکست یک سرویس حیاتی بیدار شود؛ در این لحظه، خطرناک‌ترین ابزار، هوش مصنوعی‌ای است که با اطمینان کامل، اما اشتباه، دستور اصلاح را صادر کند. باید بدانید که در مدیریت زیرساخت‌های پیچیده، «دانستن اینکه چه زمانی هیچ کاری نکنیم»، ارزشمندتر از ارائه یک راهکار احتمالی است. این توانایی حیاتی اما اغلب نادیده گرفته شده، محوریت یک محک (Benchmark) جدید برای جریان‌های کاری مبتنی بر K8sGPT است که در ۱۶ جولای ۲۰۲۶ منتشر شد. این تمرکز از آن جهت حیاتی است که یک اقدام اصلاحی توهم‌گونه و اشتباه می‌تواند یک حادثه قابل مدیریت در کوبرنتیز را به یک شکست فاجعه‌بار در محیط تولید (Production) تبدیل کند.

در محیط‌های حساس مهندسی قابلیت اطمینان سایت (SRE)، خطرناک‌ترین نوع هوش مصنوعی، مدل‌هایی هستند که با اعتمادبه‌نفس بالا، پاسخ‌های غلط می‌دهند. مدیریت این توهمات در لایه‌های مختلف سیستم، مشابه چالشی است که در رویکردهای AuraSDK برای جلوگیری از دروغ‌های با اعتمادبه‌نفس AI مورد بررسی قرار گرفته است. اکثر ارزیابی‌های فعلی از ابزارهای DevOps مبتنی بر AI بر این تمرکز دارند که آیا سیستم می‌تواند مشکل را تشخیص دهد یا خیر. با این حال، صرفاً شناسایی یک علامت (Symptom) با درک علت ریشه‌ای (Root Cause) متفاوت است. برای مثال، سناریویی را تصور کنید که در آن یک پاد در وضعیت CrashLoopBackOff گیر کرده است. یک AI ممکن است به‌درستی علامت را شناسایی کرده و ری‌استارت را پیشنهاد دهد. اما اگر علت واقعی یک وابستگی شکسته در بالادستی (Upstream Dependency)، یک مسیر اشتباه در Probe، یک پورت غلط برای Probe، یک مشکل بحرانی در NetworkPolicy یا حتی رویدادهای قدیمی مربوط به یک حادثه پیشین باشد، ری‌استارت کورکورانه در بهترین حالت بی‌فایده و در بدترین حالت مخرب است. برای یک SRE انسانی، تصمیم «فعلاً هیچ کاری نکن» اغلب امن‌ترین تصمیم است—اما تنها در صورتی که سیستم بفهمد چرا از اقدام خودداری می‌کند.

محک کالیبراسیون و اجتناب (The Calibration and Abstention Benchmark)

برای کمّی کردن این موضوع، محققان یک هارنس ارزیابی تخصصی پیرامون K8sGPT ساختند. این پروژه به‌جای بررسی رفتار اصلاحی داخلی و بومی K8sGPT، جریان‌های کاری (Workflows) پشتیبانی شده توسط آن را ارزیابی می‌کند. خودِ K8sGPT یافته‌های تحلیل‌گر (Analyzer) و توضیحات اختیاری را ارائه می‌دهد؛ اما طرح‌های اقدام ساختاریافته، امتیازات اطمینان (Confidence Scores) و منطق مسیریابی، اجزای لایه wrapper و لایه ارزیابی هستند.

این محک شامل ۱۶۳ مورد برچسب‌گذاری شده از حوادث کوبرنتیز است که بر اساس پیچیدگی و ماهیت شواهد ارائه شده، به دسته‌های زیر تقسیم شده‌اند:

• حوادث روتین (۵۰ مورد): مسائل استاندارد مانند ImagePullBackOff یا OOMKilled (ID).
• موارد نزدیک به خارج از توزیع (Near-OOD) (۴۷ مورد): علائم آشنا اما با علل غیرمعمول و غیر استاندارد.
• موارد دور از توزیع (Far-OOD) (۴۲ مورد): شکست‌هایی که لایه‌های مختلف را در بر می‌گیرند یا کاملاً خارج از تاکسونومی شناخته شده هستند.
• موارد خصمانه (Adversarial) (۲۴ مورد): سناریوهایی که دارای شواهد گمراه‌کننده، ناقص، قدیمی یا متناقض هستند.

برخلاف محک‌های سنتی، این سیستم فقط رصد نمی‌کند که ابزار پاسخ درست داده است یا خیر. هر مورد با علت‌های ریشه‌ای مورد انتظار، اطلاعات ریسک اقدام، انتظارات از اجتناب (Abstention)، کامل بودن شواهد و کاندیداهای اصلاحی ناایمن برچسب‌گذاری شده است. این محک سؤالات دقیقی می‌پرسد: آیا خانواده علت ریشه‌ای درست شناسایی شد؟ آیا اقدام ایمنی پیشنهاد شد؟ آیا سیستم باید تاییدیه می‌خواست یا اجتناب می‌کرد؟ آیا اطمینان مدل کالیبره بود؟ آیا پیشنهادی ناایمن یا با دسترسی بیش از حد (Overprivileged) ارائه شد؟ و آیا سیستم در شرایط عدم قطعیت، به‌صورت ایمن شکست خورد؟

جزئیات و پیاده‌سازی فنی

این ارزیابی از یک محیط خوشه kind بازتولیدپذیر استفاده می‌کند تا ثبات نتایج تضمین شود. جریان کاری از یک توالی سخت‌گیرانه پیروی می‌کند تا یافته‌ها از استنتاج‌ها جدا شوند:

۱. تزریق (Injection): یک حادثه کوبرنتیز در خوشه kind تزریق می‌شود.
۲. ضبط (Capture): شواهد جمع‌آوری شده و از طریق K8sGPT پردازش می‌شوند.
۳. نرمال‌سازی (Normalization): یافته‌ها برای استخراج یک طرح اقدام ساختاریافته نرمال‌سازی می‌شوند.
۴. طبقه‌بندی (Classification): سیستم ریسک اقدام پیشنهادی را طبقه‌بندی می‌کند.
۵. امتیازدهی (Scoring): جریان کاری در زمینه‌های تشخیص، اجتناب، کالیبراسیون و ایمنی امتیاز می‌گیرد.

برای صادقانه بودن ارزیابی، امتیازات هر مرحله به‌طور جداگانه گزارش می‌شوند. تیم تحقیق بین «کیفیت یافته‌های تحلیل‌گر K8sGPT» و «کیفیت اقدام و اجتناب لایه Wrapper» تفاوت قائل شده است. این کار مانع از این می‌شود که خروجی خام تحلیل‌گر با استنتاج‌های لایه محیطی مخلوط شود. خروجی‌های خام حفظ شده و امتیازدهی به عنوان یک فرآیند مجزا انجام می‌گیرد.

عملکرد و «شکاف اجتناب» (The Abstention Gap)

طبق نتایج منتشر شده، جریان‌های کاری K8sGPT در وظایف روتین عالی عمل می‌کنند. برای خانواده‌های رایج، تحلیل‌گر با نرخ موفقیت ۱۰ از ۱۰ برای ImagePullBackOff، CrashLoopBackOff، OOMKilled (موارد واقعی) و Pending اقدامات مورد انتظار را بازیابی کرد. با این حال، مسائل مربوط به پروب‌ها (Probes) یک نقطه کور بزرگ بودند و تنها امتیاز ۱ از ۱۰ گرفتند، زیرا سیستم اغلب یافته‌هایی فقط در سطح در دسترس بودن (Availability-only) تولید می‌کرد. این نشان می‌دهد که برخی خانواده‌های شکست نیازمند استدلال علی (Causal Reasoning) عمیق‌تری هستند.

هنگام بررسی کل کاتالوگ ۱۶۳ موردی (ارزیابی C0)، داده‌ها تضاد شدیدی را در رفتار مدل در انواع مختلف حوادث نشان می‌دهند:

• موارد روتین (ID): دقت ۸۲٪ (۰.۸۲۰) در شناسایی خانواده خطا، با نرخ اقدام ایمن درست ۴۰٪ (۰.۴۰۰). مقدار Abstention F1 برابر با ۰.۷۵۰ و ECE_action برابر با ۰.۶۰۰ بود.
• Near-OOD: دقت ۸.۵٪ (۰.۰۸۵). با این حال، به نرخ اجتناب ایمن (safe-abstain rate) ۱.۰۰۰ (۱۰۰٪) و Abstention F1 برابر با ۱.۰۰۰ رسید.
• Far-OOD: دقت ۰٪ (۰.۰۰۰). این دسته نیز نرخ اجتناب ایمن ۱.۰۰۰ (۱۰۰٪) و Abstention F1 برابر با ۱.۰۰۰ داشت.
• خصمانه (Adversarial): دقت ۰٪ (۰.۰۰۰). نرخ اجتناب ایمن ۱.۰۰۰ (۱۰۰٪) و Abstention F1 برابر با ۱.۰۰۰ حفظ شد.
• عملکرد کلی: در تمام ۱۶۳ مورد، نرخ اجتناب ایمن ۸۷.۷٪ (۰.۸۷۷) و Abstention F1 برابر با ۰.۹۳۵ بود. نرخ کلی «اصلاحات نادرست» (False Remediation) برابر با ۰.۰۰۰ ثبت شد.

در حالی که نرخ بالای اجتناب ایمن به نظر امن می‌رسد، محققان نسبت به تفسیر بیش از حد آن هشدار می‌دهند. یک جریان کاری که بیش از حد اجتناب می‌کند، ممکن است امن به نظر برسد در حالی که هنوز حادثه را درک نکرده است. اجتناب از یک اقدام خطرناک به دلیل «ترس» یا محافظه‌کاری کلی سیستم، با داشتن یک درک علی قدرتمند از شکست متفاوت است. هوش مصنوعی‌ای که به‌طور گسترده اجتناب می‌کند، ایمن است اما هنوز یک SRE هوشمند نیست.

ریسک لایه مدل‌های زبانی بزرگ (LLM)

کاتالوگ کامل شامل نتایج شرایط ترکیبی (C1-C7) با استفاده از آماده‌سازهای آفلاین اکتشافی (Heuristic) و یک زیرمجموعه زنده مبتنی بر OpenAI است. تعداد کل این ردیف‌های ترکیبی شامل ۱۴۹ آماده‌سازی آفلاین اکتشافی به علاوه ۱۴ طرح زنده حفظ شده مبتنی بر OpenAI بود.

در یک زیرمجموعه زنده ۱۴ موردی که از gpt-4o-mini برای توضیح و استخراج استفاده شد، نتایج یک تبادل خطرناک (Trade-off) را نشان داد:

• خط‌کشی اکتشافی (C0 analyzer + heuristic_v1): بسیار محافظه‌کار؛ ۱۲ مورد از ۱۴ اجتناب ایمن، ۰ مورد پیشنهاد ناایمن و میانگین اطمینان ۰.۵۳.
• Wrapper مبتنی بر LLM (C1 explain + LLM extract): «عمل‌گراتر» اما ریسکی؛ ۰ مورد از ۱۴ اجتناب ایمن و ۵ مورد پیشنهاد ناایمن، با میانگین اطمینان بالاتر (۰.۷۹).
• ترکیب Verbal + LLM (C2): ۲ مورد از ۱۴ درست-ایمن، ۰ مورد اجتناب ایمن و ۶ مورد پیشنهاد ناایمن با اطمینان ۰.۷۸.
• خود-سازگاری (Self-Consistency) (C3): ۳ مورد از ۱۴ درست-ایمن، ۱ مورد اجتناب ایمن و ۶ مورد پیشنهاد ناایمن با اطمینان ۰.۷۹.
• مسیریاب هیبریدی (C7): بازگشت به رفتار محافظه‌کار؛ ۱۱ مورد از ۱۴ اجتناب ایمن و تنها ۱ مورد پیشنهاد ناایمن با اطمینان ۰.۷۸.

این نتایج نشان می‌دهد که افزودن لایه LLM باعث می‌شود جریان کاری مفیدتر به نظر برسد و تمایل به پیشنهاد اقدامات افزایش یابد، اما بدون یک مسیریابی حساس به ریسک، این لایه به‌طور فعال نرخ پیشنهادات ناایمن را افزایش می‌دهد. Wrapper مبتنی بر LLM حتی زمانی که اقدامات خطرناک بودند، اعتمادبه‌نفس بیشتری نشان داد.

اعتبار و توافق برچسب‌گذاران

برای اطمینان از اینکه محک صرفاً ذهنی (Subjective) نیست، یک مرحله بازبینی توسط برچسب‌گذار دوم روی ۳۰ مورد از ۱۱۳ مورد OOD انجام شد. سطوح توافق به شرح زیر بود:

• کامل بودن شواهد: ۱۰۰.۰٪ (۳۰ از ۳۰)
• خانواده علت ریشه‌ای: ۸۳.۳٪ (۲۵ از ۳۰)
• رفتار مورد انتظار: ۷۰.۰٪ (۲۱ از ۳۰)
• سطح ریسک اقدام: ۶۳.۳٪ (۱۹ از ۳۰)

توافق پایین‌تر روی «سطح ریسک اقدام» در واقع مفید است. این موضوع نشان می‌دهد که تصمیم‌گیری درباره اینکه آیا یک جریان کاری SRE باید اقدام کند، تایید بخواهد یا موضوع را ارجاع (Escalate) دهد، همیشه بدیهی نیست و همین امر نیاز به یک محک ساختاریافته را توجیه می‌کند.

بازتعریف ایمنی در محیط تولید

این پژوهش اهداف ابزارهای SRE مبتنی بر AI را تغییر می‌دهد. ایمنی در محیط تولید دیگر فقط درباره دقت تشخیص نیست، بلکه درباره «کالیبراسیون اطمینان» است. این محک ثابت می‌کند که مسئله دشوار، تولید یک توضیح محتمل نیست، بلکه تصمیم‌گیری درباره سطح مناسب خودمختاری (Autonomy) است.

برای مهندسان، این بدان معناست که ارزیابی هر ابزار AI SRE اکنون باید شامل معیارهای زیر باشد:

• نرخ پیشنهادات ناایمن: ابزار هر چند وقت یک‌بار یک تغییر (Mutation) مخرب را پیشنهاد می‌دهد؟
• رفتار ارجاع (Escalation): چه زمانی ابزار تایید انسانی می‌خواهد یا کاربر را به متخصص ارجاع می‌دهد؟
• کالیبراسیون اطمینان: آیا میزان اطمینان با صحت واقعی پاسخ همخوانی دارد؟
• رفتار در OOD: عملکرد سیستم در مواجهه با حوادث ناآشنا یا خصمانه چگونه افت می‌کند؟
• کیفیت اجتناب: آیا سیستم می‌داند چرا اقدام نمی‌کند؟

اگر سیستمی نتواند تفاوت بین یک رویداد روتین OOMKilled و یک شکست خصمانه پیچیده را تشخیص دهد، نباید اجازه تجویز تغییرات در یک محیط زنده را داشته باشد. در محیط‌های کوبرنتیز، جایی که اقدامات بر روی بارهای کاری در حال اجرا، مرزهای امنیتی و سیستم‌های مشتری‌محور تأثیر می‌گذارند، دانستن زمان عدم اقدام به اندازه دانستن نحوه اقدام اهمیت دارد.

مسیرهای آینده

این پروژه قصد دارد چارچوب ارزیابی دقیق‌تری برای عیب‌یابی کوبرنتیز با کمک AI بسازد. تیم برنامه دارد که:

• ارزیابی زنده مبتنی بر LLM را فراتر از زیرمجموعه فعلی ۱۴ موردی گسترش دهد.
• خط‌کشی‌های (Baselines) دیگر مانند HolmesGPT را ادغام کند.
• سناریوهای مربوط به پروب‌ها و وابستگی‌های بالادستی را بهبود بخشد.
• یک گزارش رسمی PDF منتشر کرده و معیارهای کالیبراسیون و اجتناب را اصلاح کند.
• قابلیت بازتولید و مستندات را در مخزن گیت‌هاب (github.com/Mayank-013/k8sGPT) تقویت کند.

سخن نهایی: اکثر دموهای AI/SRE بر روی «اقدام» تمرکز دارند—شناسایی مشکل و ارائه راهکار. اما قابلیت اطمینان در محیط تولید اغلب نیازمند خویشتن‌داری است. گاهی اوقات بهترین پاسخ این است: «هنوز شواهد کافی برای اقدام ایمن وجود ندارد.»

گام بعدی شما

• در ارزیابی ابزارهای AI-SRE، به جای تمرکز بر Accuracy، نرخ «پیشنهادات ناایمن» (Unsafe Proposal Rate) را بسنجید.
• برای مدل‌های اتوماسیون، لایه «مسیریاب هیبریدی» (Hybrid Router) را پیاده‌سازی کنید تا بین اقدامات روتین و موارد پیچیده تفکیک قائل شود.
• معیارهای کالیبراسیون اطمینان را با داده‌های واقعی محیط تولید خود تطبیق دهید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.