אבחון נכון עדיין דורש הרשאה נפרדת לתיקון

מחקר Radar מספק ראיות על אבחון Kubernetes. ניסיון יחיד לכל תקלה ומצב קריאה בלבד מגבילים את המסקנות על תיקון.

Ready אינו תיאור מלא

Pod יכול לדווח Ready כשהיישום עדיין פגום. Radar הפרידה 14 תקלות כאלה במחקר. מעניין אותי הקשר בין סימפטום לשדה תצורה, במקום להסתפק במצב ירוק. זו קריאה במחקר הספק, ללא בדיקת אשכול ייצור.

מה נמדד

המחקר פורסם ב 20 בספטמבר ועודכן ב 1 באוקטובר. הוא מדווח 44 אבחונים נכונים מתוך 50 עם Claude Code וRadar MCP 1.13.1 לעומת 41 עם kubectl-ai. לכל תקלה היה ניסיון נספר יחיד. המחברים מזהירים שפער קטן יכול להשתנות. חמישה מוצרים השתמשו בSonnet 5 בBedrock; מוצר AWS השתמש במודל מנוהל שלא נחשף.

ההסתייגויות שייכות לטבלה

התקלות הוזרקו דקות אחרי פריסה, מצב שמסייע לקישור לשינוי טרי. שני מוצרים ראו מרחבי שמות נוספים. ממוצע 79 שניות ועלות$0.27 לתקלה שייכים לתצורה שנבדקה, עם הבדלי חיוב ומטמון. קבוצות התקלות נקבעו לאחר הריצות. אין כאן תחזית לביצועי אשכול אחר.

חוזה מוצע לחקירה

בניסוי מורשה בסביבת בדיקה הייתי מגדיר משאב, חלון זמן, קריאות מותרות ושינויים אסורים מראש. רשומת הראיות צריכה לכלול זמן, זהות משאב, שדה תצורה והסבר שניתן להפריך. בלי שדה מזוהה, האבחון נשאר כיוון להמשך בדיקה.

ההרשאה לתיקון נפרדת

כל המשתתפים עבדו לקריאה בלבד. המחקר אינו מוכיח תיקון אוטונומי בטוח או יכולת חזרה לאחור. JSON להלן מפריד טענה אבחונית מהרשאה לשינוי. זו המחשה ולא מערכת הרשאות שנבדקה. המבצע חייב לבדוק סמכות בעצמו.

{
  "scope": "authorized staging investigation",
  "evidence": {
    "resource": "example deployment",
    "observed_at": "record actual timestamp",
    "changed_field": "record exact field or unknown"
  },
  "diagnosis": "hypothesis requiring verification",
  "repair": {
    "authorized": false,
    "proposed_diff": null,
    "rollback": null
  }
}

ניסוי שיכול להפריך את התועלת

הייתי חוזר על תקלות קבועות בסביבת בדיקה, כולל מקרה שבו השינוי האחרון חף מאשמה. מקבע הרשאות ומודל ומתעד שגיאות וסירובים. זמן עד הסבר מאומת נמדד בנפרד מזמן השבת השירות. לא הרצתי ניסוי כזה ולא שחזרתי עצמאית את המחקר.

מקורות

• https://radarhq.io/benchmark/ai-sre-tools