Правильний діагноз усе одно потребує окремого дозволу

Дослідження 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 за збій стосуються конкретної конфігурації з різними умовами оплати й кешування. Групи збоїв визначені після прогонів. Це не загальний прогноз.

Запропонований контракт

Для дозволеної перевірки у staging я зафіксував би ресурс, часовий інтервал, дозволені читання та заборонені зміни. Доказ має містити час спостереження, поле конфігурації та спростовну гіпотезу. Без точного поля діагноз лишається напрямом пошуку.

Дозвіл на ремонт окремо

Усі учасники працювали лише на читання. Дослідження не перевіряє безпечний автономний ремонт або відкат. 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
  }
}

Як спростувати користь

Я повторив би фіксовані збої у staging, включно з невинною останньою зміною. Права й модель треба тримати сталими, помилки та відмови враховувати. Час до перевіреного пояснення відділяти від часу відновлення сервісу. Цей тест я не запускав і дослідження незалежно не відтворював.

Джерела

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