Верный диагноз все равно требует отдельного разрешения

Исследование Radar полезно для оценки диагностики Kubernetes. Один прогон на сбой и режим только чтения ограничивают выводы о ремонте.

Ready не описывает всю систему

Pod Kubernetes может показывать Ready, хотя приложение работает неверно. В исследовании Radar отдельно выделены 14 таких сбоев. Для меня важен переход от зеленого статуса к проверяемым данным конфигурации. Здесь я читаю исследование производителя, а не сообщаю о тесте рабочего кластера.

Что измеряли

Исследование опубликовано 20 сентября и обновлено 1 октября. Radar сообщает 44 верных диагноза из 50 для Claude Code с Radar MCP 1.13.1 против 41 у kubectl-ai. На каждый сбой был один учитываемый прогон; авторы предупреждают, что небольшие разницы меняются при повторении. Пять продуктов использовали Sonnet 5 в Bedrock, AWS DevOps Agent использовал неизвестную управляемую модель.

Ограничения рядом с результатом

Сбои вносили вскоре после развертывания, что благоприятствует поиску недавних изменений. Два продукта видели дополнительные пространства имен. Заявленные 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