Un bon diagnostic demande encore une autorisation de réparation
L’étude Kubernetes de Radar apporte des éléments sur le diagnostic. Un seul essai par panne et un accès en lecture seule limitent les conclusions sur la réparation.
L’étude Kubernetes de Radar apporte des éléments sur le diagnostic. Un seul essai par panne et un accès en lecture seule limitent les conclusions sur la réparation.
Ready ne décrit pas toute l’application
Un pod peut afficher Ready alors que le service fonctionne mal. Radar distingue 14 pannes de ce type. Le lien entre symptôme et champ de configuration m’intéresse davantage qu’un statut vert. Cet article examine une étude du fournisseur, sans essai sur un cluster de production.
Ce qui a été mesuré
Publiée le 20 septembre et mise à jour le 1 octobre, l’étude annonce 44 diagnostics corrects sur 50 pour Claude Code avec Radar MCP 1.13.1, contre 41 pour kubectl-ai. Chaque panne a un seul essai comptabilisé. Les auteurs reconnaissent la variabilité des petits écarts. Cinq produits utilisaient Sonnet 5 sur Bedrock; AWS utilisait un modèle géré non précisé.
Les conditions comptent
Les pannes étaient injectées quelques minutes après le déploiement, ce qui favorise la corrélation avec un changement récent. Deux produits voyaient des espaces de noms supplémentaires. Les 79 secondes et$0.27 par panne concernent cette configuration, avec des différences de facturation et de cache. Les groupes ont été définis après les essais. Je ne transpose pas ces chiffres à un autre cluster.
Mon contrat proposé
Pour un essai autorisé en préproduction, je fixerais la ressource, la période, les lectures permises et les changements interdits avant connexion. La preuve doit préciser l’heure, le champ de configuration et une hypothèse réfutable. Sans champ identifié, le diagnostic reste une piste.
L’autorisation reste séparée
Tous les participants travaillaient en lecture seule. L’étude ne démontre ni réparation autonome sûre ni retour arrière. Le JSON ci-dessous sépare la preuve du droit de changer le système. C’est un exemple explicatif, pas un contrôle d’accès testé. L’exécuteur doit vérifier lui-même les droits.
{
"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
}
}Un essai capable de démentir le bénéfice
Je répéterais des pannes fixes en préproduction, dont une où le dernier changement est innocent. Garder les droits et le modèle constants, compter erreurs et refus, puis distinguer le délai vers une explication vérifiée du rétablissement du service. Je n’ai pas exécuté cet essai ni reproduit indépendamment l’étude.