AI SRE

Status200 AI est votre ingénieur en fiabilité des sites (SRE) piloté par l'IA. Dès qu'un nouvel incident ou une nouvelle alerte est déclaré, il se met en route, l'investigue à partir de votre propre télémétrie — journaux, métriques, traces, exceptions, moniteurs et changements récents — et publie une analyse des causes racines sourcée sur la chronologie de l'incident ou de l'alerte, généralement avant que la personne d'astreinte ait fini de lire la notification.

Chaque affirmation de l'analyse porte une citation qui renvoie directement aux données exactes qui l'étayent, et l'investigation elle-même est strictement en lecture seule : Status200 AI ne peut jamais rien modifier dans votre projet pendant qu'il investigue.

Fonctionnement#

Status200 AI fait trois choses pour un nouvel incident ou une nouvelle alerte, et chacune a son propre interrupteur :

• Il investigue (activé par défaut). Il lit votre télémétrie, ainsi que les clusters et les hôtes où tourne un agent IA, et publie une analyse des causes racines sourcée. Une investigation ne modifie rien.
• Il corrige (désactivé par défaut). Quand la correction est activée, une analyse sûre d'elle devient un correctif : une pull request pour une modification de votre code, ou un plan de commandes pour un cluster ou un hôte, exécuté comme l'agent IA de ce cluster ou de cet hôte le permet.
• Il apprend. Les pages Analyses IA indiquent ce qui ne cesse de mal tourner, à partir de tout ce qui a été enregistré.

Une analyse qui ne trouve aucune cause est publiée discrètement, sans alerter personne (voir Mode silencieux), et rien n'est corrigé sans cause.

Ce que publie l'investigation#

Quand une investigation se termine, Status200 AI publie une analyse des causes racines avec ces sections :

• Summary — une ou deux phrases qu'une personne alertée peut lire en cinq secondes.
• Most likely root cause — l'hypothèse, avec seulement la confiance que les éléments justifient, chaque affirmation factuelle étant citée. Si la télémétrie est insuffisante, l'IA le dit clairement et liste ce qu'elle a vérifié au lieu de deviner.
• Evidence — les principaux constats qui étayent ou écartent l'hypothèse, chacun cité.
• Suggested next steps — des actions concrètes pour la personne d'astreinte.

Pour les incidents, l'analyse est publiée dans le fil de l'incident et comme note interne de l'incident (là où les intervenants collaborent). Pour les alertes, elle est publiée dans le fil de l'alerte.

Pendant que l'investigation tourne, la page de l'incident ou de l'alerte affiche un panneau Investigation IA en direct qui raconte chaque étape — quels outils ont tourné, ce qu'ils ont trouvé et combien de temps ils ont pris — pour que vous puissiez la regarder réfléchir. Si une investigation échoue, le panneau affiche la raison de l'échec plutôt qu'un vide silencieux.

Une investigation tourne jusqu'à ce qu'elle ait terminé : elle n'a aucune limite de temps ni petit budget de requêtes, elle peut donc exécuter chaque requête et chaque commande kubectl ou d'infrastructure dont elle a besoin. Une longue sortie de commande (un kubectl describe node d'un nœud chargé, les journaux d'un pod) n'est jamais tronquée — Status200 AI la lit une page à la fois. Si vous voulez un arrêt net, définissez une limite de temps d'investigation par type de signal (voir Maîtrise des coûts ci-dessous).

Ce qu'une investigation lit#

Une investigation part de l'incident ou de l'alerte et de l'infrastructure à laquelle il est lié : les hôtes, les hôtes Docker et Podman, les clusters Kubernetes, les bases de données et les services que surveillent ses moniteurs. Un moniteur de site web, d'API ou synthétique surveille ce à quoi vous le liez sous Moniteur → Vue d'ensemble → Ressources liées : liez-le donc aux hôtes qui servent ce qu'il vérifie, et chaque investigation de ses incidents commence là.

• Les alertes sur cette infrastructure ouvertes dans les 30 minutes avant l'incident, ou encore ouvertes, les plus récentes d'abord, comme l'alerte de CPU élevé de l'hôte derrière un site lent. Les alertes privées sont laissées de côté.
• Les métriques de l'infrastructure elle-même, lues comme on les lit. Les métriques d'hôte comme system.cpu.utilization et system.memory.utilization sont rapportées une fois par état, et les états totalisent 100 %, donc une moyenne sur l'ensemble ne dit rien. Status200 AI les lit état par état (le CPU occupé, c'est user plus system), et toute métrique par conteneur, par point de montage ou par n'importe quel autre attribut.
• Les conteneurs d'un hôte Docker ou Podman : les plus chargés en CPU, en mémoire ou en redémarrages, et ceux qui ont cessé de remonter des données. Un conteneur arrêté n'envoie rien plutôt que zéro, donc les chiffres de l'hôte entier le cachent.
• Les changements enregistrés dans les 2 heures avant l'incident ou l'alerte — déploiements, rollouts Kubernetes, changements de configuration et correctifs que Status200 a exécutés — et ceux que la télémétrie de ses services rend suspects : un service qui s'est dégradé de façon mesurable juste après un changement. Voir Déploiements et changements.

L'activité de l'investigation sur la carte Investigation IA indique combien d'alertes ouvertes ou récentes elle a lues, et sur quelles ressources.

Vérifié de nouveau quand une nouvelle alerte s'ouvre#

Une investigation démarre dès qu'un incident est déclaré, et une alerte d'hôte qui a besoin de quelques minutes de métriques peut s'ouvrir après. Quand une alerte s'ouvre sur l'infrastructure liée à l'incident dans les 30 minutes qui suivent l'incident, après que l'investigation l'a lue, et que l'incident est toujours ouvert, Status200 AI vérifie l'incident une fois de plus avec cette alerte en main. La nouvelle analyse commence par Checked again et l'alerte qui a provoqué la vérification, et son activité le dit aussi. Si une règle IA a fait attendre Status200 AI avant d'investiguer l'incident, ces minutes sont comptées à partir de la fin de son investigation (voir Attendre avant d'investiguer).

Cela arrive au plus une fois par incident, avec les mêmes interrupteurs et limites qu'une nouvelle investigation : Activer l'IA, Investiguer les nouveaux incidents, les crédits IA, et les limites quotidiennes et de simultanéité. Il n'y a rien à activer. Une vérification de suivi ne relance jamais la remédiation automatique et n'est jamais suivie elle-même, et l'investigation d'une alerte n'est pas vérifiée de nouveau.

Parler de l'incident avec Status200 AI#

La carte Investigation IA se termine par une conversation — Ask Status200 AI — partagée par toutes les personnes qui peuvent voir l'incident ou l'alerte. C'est une seule carte, quoi qu'il se soit passé au-dessus : sous un rapport, vous posez des questions de suivi, et quand aucune investigation automatique n'a tourné (ou qu'elle s'est arrêtée avant son rapport), la première suggestion est What is the root cause?, qui fait investiguer Status200 AI à la demande.

• Poser des questions de suivi — « quels pods utilisent le plus de mémoire ? », « qu'est-ce qui a changé juste avant le début ? », « autre chose est-il touché ? ». Status200 AI s'appuie sur son rapport, interroge des données fraîches (et exécute des commandes kubectl ou d'infrastructure en lecture seule là où il a un accès, sur les clusters et les ressources que vous pouvez voir) et cite chaque affirmation.
• Lui demander d'agir — « acquitte cet incident », « publie une mise à jour de statut disant que nous investiguons », « alerte l'astreinte base de données », « augmente la sévérité ». Il utilise les mêmes actions que Demander à l'IA et agit toujours avec vos propres autorisations, il ne peut donc jamais faire plus que vous.
• Choisir sa façon d'agir avec l'interrupteur de la zone de message, qui indique à côté ce que signifie le mode choisi : Auto-run (par défaut — il agit tout de suite sur une demande claire), Ask to act (il affiche d'abord une carte d'approbation, que toute personne sur l'incident peut approuver ou refuser) ou Lecture seule.
• Un seul fil partagé. Chaque question indique qui l'a posée, tout le monde voit la même conversation en direct, et chacun peut arrêter une réponse en cours. Les graphiques et les tableaux d'une réponse sont montrés à la personne qui a posé la question ; les autres voient la réponse sourcée. Chaque réponse liste ses Sources, et une source qui a sa propre page (journaux, métriques, un moniteur) l'ouvre. Un long fil s'ouvre sur ses messages les plus récents, avec un bouton au-dessus (par exemple Show 6 earlier messages) qui ramène le reste.

Activer les investigations IA#

Les investigations autonomes sont activées par défaut pour les nouveaux projets. C'est aussi le cas des brouillons de post-mortem et des Analyses IA. La correction démarre désactivée, et les pull requests qui en font partie ne s'ouvrent que tant qu'elle est activée (voir Correctifs de code automatiques). Un projet créé avant ce réglage par défaut garde son réglage ; activez les investigations comme à l'étape 3, ou avec Activer sur la page Agent IA de n'importe quel cluster Kubernetes (Project Owner ou Project Admin). Pour les vérifier ou les modifier :

Chaque comportement de l'IA sur ces pages est un interrupteur qui s'enregistre dès que vous le basculez ; il n'y a pas de bouton Enregistrer. La page des incidents en a trois, sous Ce que fait Status200 AI : Investiguer les nouveaux incidents, Corriger automatiquement les nouveaux incidents et Rédiger un post-mortem quand un incident est résolu. La page des alertes a les mêmes, sans le post-mortem. Corriger automatiquement les nouveaux incidents (et Corriger automatiquement les nouvelles alertes) démarre désactivé, y compris pour les nouveaux projets : il permet à Status200 AI de modifier votre infrastructure, c'est donc au projet de l'activer — voir Quels incidents sont investigués et corrigés. Les pull requests qu'elle ouvre, un correctif de votre code et la télémétrie qui manquait à une investigation, en font partie, et chaque règle IA les règle : sans règle, les deux s'ouvrent, et une règle peut désactiver l'une ou l'autre sous Plus de champs (voir Correctifs de code automatiques). Les Project Owners et les Project Admins peuvent les modifier ; pour tous les autres, chaque interrupteur est verrouillé et indique l'autorisation dont il a besoin.

Les pages ne disent deux choses que lorsqu'elles sont vraies. Si Activer l'IA est désactivé, rien n'y tourne, et la page le dit en haut, avec l'interrupteur Activer l'IA lui-même pour les personnes qui peuvent le modifier (les Project Owners, et toute personne disposant de Manage Billing) ; les autres apprennent qui le peut. Si le projet n'a aucun fournisseur LLM que Status200 AI puisse utiliser — aucun du tout, ou des fournisseurs mais aucun défini par défaut —, la page le dit aussi, avec un lien vers Paramètres du projet → IA → Fournisseurs LLM. Sur Status200 Cloud, le fournisseur global compte, donc rien n'y est dit.

Les incidents et les alertes se configurent indépendamment, vous pouvez donc donner à chaque type de signal son propre plafond de simultanéité, son budget quotidien de jetons, son budget de tâches de correction et ses propres règles. Aucune de ces limites ne s'applique tant que vous ne la définissez pas — elles sont repliées sous Plus de paramètres en bas de chaque page ; voir Maîtrise des coûts ci-dessous. Modifier un paramètre IA des alertes ne modifie pas le paramètre correspondant des incidents, et inversement.

La correction s'appuie sur les investigations : tant que Corriger automatiquement les nouveaux incidents (ou les alertes) est activé, une investigation qui identifie avec assurance une modification de code dans un dépôt ouvre automatiquement une pull request de correctif — voir Correctifs de code automatiques ci-dessous.

Accès au cluster — laisser Status200 AI exécuter kubectl#

D'origine, une investigation ne peut utiliser que la télémétrie que vos agents envoient. Pour un signal Kubernetes, cela ne suffit souvent pas : « des pods bloqués en Pending » est un problème d'ordonnancement que l'on diagnostique en décrivant le pod et en lisant ses événements, pas en regardant une métrique. L'Agent IA Kubernetes permet à Status200 AI de faire exactement cela — et, si vous l'autorisez, de corriger ce qu'il trouve.

La page de chaque cluster a une section IA dans son menu latéral :

• Agent — la page Agent IA du cluster : si l'agent est connecté, ce que l'IA peut faire sur le cluster et tout ce qui demande votre attention, chaque point avec l'étape qui le règle. La même explication apparaît dans le panneau d'investigation de l'incident quand l'IA a dû investiguer avec les seules données de Status200.
• Analyses — la page Analyses IA du cluster : ce que Status200 AI a appris sur le cluster — ce qui ne cesse de mal tourner et pourquoi, et quoi faire (voir Ce que l'IA a appris sur un cluster).
• Journaux — la page Journaux IA du cluster : tout ce que Status200 AI a fait sur le cluster, du plus récent au plus ancien (voir Tout ce que l'IA a fait sur un cluster).

La Vue d'ensemble du cluster se termine par une carte Agent IA qui résume la page de l'agent IA : si l'agent est connecté, si Investiguer avec kubectl est activé, comment les correctifs s'exécutent (Désactivé, Demander une approbation, Automatique ou Contourner l'approbation) et ce qui demande votre attention, avec un lien vers la page de l'agent IA, où on les modifie.

L'agent IA Kubernetes — activé par défaut, en lecture seule#

Le chart de l'agent Kubernetes de Status200 exécute l'agent IA Kubernetes par défaut : un petit pod (component=ai-agent, image status200/kubernetes-ai-agent) avec un ServiceAccount en lecture seule. Il se connecte avec la clé API que le chart utilise déjà, il n'y a donc rien à configurer dans le tableau de bord : en une minute, la page de l'agent IA du cluster l'affiche comme Connecté et Investiguer avec kubectl est activé — sauf si quelqu'un a déjà choisi des paramètres IA pour le cluster sur cette page, qui sont conservés tels quels.

Pour un agent installé avant l'existence de l'agent IA Kubernetes, actualisez d'abord l'index de vos charts, puis faites la mise à niveau :

helm repo update
helm upgrade kubernetes-agent status200/kubernetes-agent \
  --namespace status200-agent --reset-then-reuse-values \
  --set aiAgent.enabled=true

kubernetes-agent dans status200-agent sont le nom de release et l'espace de noms qu'utilisent les instructions d'installation du tableau de bord ; si vous avez installé l'agent avec d'autres noms, utilisez les vôtres (helm list -A | grep kubernetes-agent les affiche). Sans helm repo update, Helm peut résoudre le chart à partir duquel vous avez installé, qui ne connaît pas aiAgent et échoue avec Additional property aiAgent is not allowed. Sur un Status200 auto-hébergé, mettez Status200 à niveau avant le chart — voir Mettre à niveau l'agent. Pour exécuter le chart sans l'agent IA, passez --set aiAgent.enabled=false.

Tester la connexion, dans le menu ⋯ à côté du statut de l'agent sur la page de l'agent IA, exécute kubectl version et kubectl auth can-i --list via l'agent et affiche les résultats : ce qu'il peut atteindre et ce qu'il a le droit de faire. Si la page indique que l'agent n'est pas connecté, lisez son journal avec kubectl logs -n status200-agent -l component=ai-agent --tail=100. Une clé qui a un Pinned Service Name ne peut pas enregistrer l'agent — donnez au chart une clé qui n'en a pas. Quand le serveur refuse un enregistrement, le journal indique si le refus se lèvera de lui-même (un ancien pod de l'agent qui se signale encore, ou l'ancien Runner du cluster encore en train de s'arrêter pendant une mise à niveau) ou ce qu'il faut changer. Réinitialiser l'agent, dans le même menu, fait oublier au serveur la clé de l'agent une fois que vous avez confirmé ; le pod se reconnecte de lui-même en quelques minutes.

L'agent IA Kubernetes n'est pas un Runner et n'apparaît jamais sous Runbooks → Agents de runbook. Il n'utilise jamais que son propre ServiceAccount, donc Status200 ne lui remet jamais d'identifiant, il n'est jamais utilisé comme hôte Bash/SSH pour les runbooks, et il n'est jamais accepté comme Runner de commandes d'une règle IA.

Ce que l'IA peut faire — défini par l'agent#

Ce que Status200 AI peut faire sur un cluster se définit là où l'agent tourne, dans le chart, avec deux valeurs :

• aiAgent.investigation — true : l'IA peut exécuter kubectl en lecture seule sur le cluster pendant qu'elle investigue. false : elle investigue toujours, avec les données que Status200 a déjà.
• aiAgent.fixes — comment l'IA applique un correctif : off, ask-for-approval, automatic ou bypass-approval (voir Fonctionnement des correctifs). Chaque niveau sauf off donne à l'agent IA un accès en écriture ; avec off, il n'en a aucun et refuse lui-même toute écriture.

L'agent IA communique les deux à Status200 à chaque heartbeat, et Status200 les applique au cluster. Ce que l'IA peut faire, sur la page de l'agent IA du cluster, les affiche — Activé et le niveau de correctifs, en vert dès qu'ils sont activés — sans moyen de les y modifier ; Modifier affiche chaque option avec le helm upgrade exact qui la définit. Une modification faite ailleurs — sur la page de l'agent IA, par l'API ou par Terraform — est refusée tant que l'agent les définit.

Une release qui ne définit aucune des deux valeurs laisse l'agent utiliser ses valeurs par défaut (investigation activée ; correctifs désactivés, ou ask-for-approval avec l'ancien aiAgent.remediation.enabled=true). Status200 n'applique ces valeurs par défaut qu'à un cluster dont personne n'a choisi les paramètres IA sur sa page d'agent IA : les paramètres choisis là sont conservés tels quels, et la page affiche la commande qui les transfère dans le chart. De même pour un cluster dont l'agent IA est trop ancien pour les communiquer — mettre le chart à niveau avec les deux valeurs les transfère.

Laisser l'IA corriger ce qu'elle trouve#

Les correctifs sont désactivés tant que vous ne les activez pas avec aiAgent.fixes, qui donne aussi à l'agent IA un accès en écriture — idéalement seulement dans les espaces de noms que l'IA peut corriger, et avec les opérations sur les nœuds désactivées :

helm repo update
helm upgrade kubernetes-agent status200/kubernetes-agent \
  --namespace status200-agent --reset-then-reuse-values \
  --set aiAgent.enabled=true \
  --set aiAgent.investigation=true \
  --set aiAgent.fixes=ask-for-approval \
  --set "aiAgent.remediation.namespaces={web,api}" \
  --set aiAgent.remediation.nodeOperations=false

Ou à l'échelle du cluster :

helm repo update
helm upgrade kubernetes-agent status200/kubernetes-agent \
  --namespace status200-agent --reset-then-reuse-values \
  --set aiAgent.enabled=true \
  --set aiAgent.investigation=true \
  --set aiAgent.fixes=ask-for-approval \
  --set-json 'aiAgent.remediation.namespaces=[]'

Remplacez {web,api} par les espaces de noms que l'IA peut corriger. Chaque espace de noms listé doit déjà exister : le chart crée un RoleBinding dans chacun et ne crée jamais d'espace de noms, donc un espace manquant fait échouer toute l'installation ou la mise à niveau — collecteur compris — avec namespaces "api" not found. Créez-le d'abord, ou retirez-le de la liste ; retirez un espace de noms de la liste avant de le supprimer. Omettre l'option lors d'une mise à niveau conserve la liste stockée dans la release ; pour revenir à l'échelle du cluster, passez donc --set-json 'aiAgent.remediation.namespaces=[]' (Helm 3.10+), comme le fait la seconde commande — pas ={}, que Helm lit comme un nom vide et que le chart refuse. --set aiAgent.remediation.namespaces=null ne réinitialise pas une liste stockée sous --reuse-values : Helm garde la liste stockée. aiAgent.remediation.nodeOperations=false tient les correctifs à l'écart des nœuds ; mettez-le à true pour laisser l'IA isoler, réintégrer, vider et marquer d'un taint des nœuds (un drain, un taint ou un patch d'un nœud attend toujours un humain).

Utilisez automatic ou bypass-approval à la place de ask-for-approval pour plus d'autonomie, et --set aiAgent.fixes=off pour désactiver à nouveau les correctifs, ce qui retire aussi l'accès en écriture. Les correctifs ont aussi besoin de deux interrupteurs du projet. Corriger automatiquement les nouveaux incidents (dans Incidents → IA → Paramètres) et Corriger automatiquement les nouvelles alertes (dans Alertes → IA → Paramètres) démarrent désactivés : tant qu'aucun n'est activé, rien de nouveau de ce type n'est corrigé. Activer l'IA (Paramètres du projet → IA → Fonctionnalités IA) est activé sauf si quelqu'un l'a désactivé ; il désactive toute l'IA du projet, quelle que soit la configuration d'un agent.

Sur quels incidents agissent les correctifs d'un cluster#

Tant que Corriger automatiquement les nouveaux incidents est activé et qu'aucune règle IA n'est configurée, Status200 AI corrige chaque nouvel incident auquel le cluster est lié, dans le mode que définit la page de son agent IA — et de même pour les alertes avec Corriger automatiquement les nouvelles alertes. Avec des règles, il ne corrige que les incidents qui correspondent à une règle qui corrige avec Status200 AI (voir Quels incidents sont investigués et corrigés). Ce à quoi il n'est pas lié, il n'y touche pas — même si la cause se trouve clairement dans le cluster. Un incident ou une alerte est lié à un cluster quand :

• la télémétrie qui l'a déclenché nomme le cluster (un moniteur de métrique, de journal ou de trace sur les données du cluster) ;
• son moniteur est un moniteur Kubernetes du cluster ;
• son moniteur est lié au cluster dans Moniteur → Vue d'ensemble → Ressources liées — la façon de lier un moniteur de site web, d'API ou synthétique au cluster qui sert ce qu'il vérifie ;
• quelqu'un a choisi le cluster dans Autres ressources affectées en le déclarant (choisir un moniteur lié l'y ajoute pour vous).

Chaque incident et chaque alerte indique sur sa carte Remédiation s'il était lié à un cluster et ce qu'ont fait les correctifs du cluster ; voir Ce qu'a fait la remédiation automatique. Il en va de même pour une ressource d'infrastructure et son agent IA.

Qui peut le modifier#

Tant que l'agent IA Kubernetes définit l'investigation et les correctifs, c'est la personne qui peut modifier les valeurs du chart sur le cluster qui les modifie ; Status200 refuse une modification faite ailleurs. Les règles ci-dessous valent pour ce qui reste dans Status200 — la liste d'autorisation kubectl, et la liaison à l'ancien Runner du cluster — ainsi que pour l'investigation et les correctifs d'un cluster dont les paramètres sont encore définis dans Status200 (voir Ce que l'IA peut faire — défini par l'agent).

Activer les correctifs — tout passage de Désactivé à un autre mode — et les assouplir — passer à Automatique ou Contourner l'approbation, écrire la liste d'autorisation kubectl, ou lier un Runner — exige un Project Owner, un Project Admin ou l'autorisation Edit AI Rule, soit les mêmes personnes qui peuvent créer une règle IA qui corrige sans demander. Réinitialiser l'agent exige les mêmes personnes qu'activer les correctifs. Les resserrer — Désactivé, revenir à Demander une approbation, vider la liste d'autorisation ou la liaison du Runner — est ouvert à toute personne qui peut modifier le cluster, tout comme Tester la connexion et l'approbation d'un correctif que Status200 AI propose pour lui. Tout cela exige l'autorisation de modifier ce cluster précis : une autorisation restreinte à certaines étiquettes, ou aux clusters que vous ou vos équipes possédez, n'atteint que ces clusters, et une entrée de blocage avec étiquettes retire les clusters qui les portent.

Ce qu'une investigation peut exécuter#

Avec un accès, une investigation exécute kubectl en lecture seule via l'agent IA — get, describe, logs, events, top, rollout status/history, auth can-i —, autant de commandes qu'il lui en faut, et cite chaque commande comme n'importe quel autre élément. La sortie n'est jamais tronquée : l'agent en garde jusqu'à un mégaoctet, et Status200 AI lit une longue sortie une page à la fois. Trois vérifications indépendantes la maintiennent en lecture seule : la politique qui classe chaque commande, le serveur qui refuse de mettre en file autre chose pour une investigation, et l'agent IA, qui revérifie la même politique avant de lancer kubectl. « Lecture seule — rien n'a été modifié dans vos systèmes » reste littéralement vrai.

Fonctionnement des correctifs#

Les Correctifs de la page de l'agent IA ont quatre réglages (le aiAgent.fixes du chart : off, ask-for-approval, automatic, bypass-approval) :

• Désactivé — l'IA ne fait qu'investiguer.
• Demander une approbation — après l'analyse des causes racines, Status200 AI établit un diagnostic avec kubectl et compose le plus petit plan kubectl qui traite la cause, par exemple kubectl rollout restart deployment/web -n web. Le plan apparaît sur l'incident avec sa justification, son effet attendu et son retour arrière ; un humain l'approuve d'un clic, et Status200 exécute exactement ces commandes. Si les moniteurs ne se rétablissent pas, le retour arrière s'exécute et Status200 AI compose un plan de plus — de nouveau soumis à approbation — avec la tentative échouée sous les yeux, pour adopter une autre approche ou dire ce qu'un humain devrait examiner.
• Automatique — les modifications sûres s'exécutent d'elles-mêmes ; une modification plus risquée, jamais. Quand le tour n'a pu trouver que des correctifs plus risqués, il se termine en proposant exactement ceux-là à l'approbation d'un clic. Quand il a aussi exécuté un correctif sûr, le plus risqué reste dans l'analyse et n'est proposé que si la vérification montre que le correctif sûr n'a pas rétabli les moniteurs — par le tour de suivi, qui demande une approbation. Ajoutez la forme d'une commande plus risquée à la liste d'autorisation sur la page de l'agent IA, et elle s'exécute d'elle-même aussi. Le mode automatique résout aussi le signal une fois que la vérification confirme que les moniteurs se sont rétablis, et il est limité par un disjoncteur à trois correctifs sans surveillance par cluster et par heure : au-delà, ou tant qu'un autre tour sans surveillance de Status200 AI modifie ou vérifie encore le même cluster, un tour propose son plan à l'approbation au lieu de l'exécuter.
• Contourner l'approbation — l'IA ne demande pas. Chaque modification que la politique autorise, y compris les plus risquées, s'exécute d'elle-même, tout comme le tour de suivi après une vérification échouée ; le signal se résout de lui-même une fois que la vérification confirme le rétablissement. Ce qui exige un humain dans tous les modes (ci-dessous) l'attend toujours. Un tour propose aussi son plan à l'approbation au lieu de l'exécuter, et dit pourquoi sur l'incident, quand :
  • le disjoncteur horaire (trois correctifs sans surveillance par cluster et par heure) s'est déclenché, ou ne peut pas être vérifié ;
  • un autre tour sans surveillance de Status200 AI modifie encore le même cluster, ou y vérifie encore un correctif — une alerte et un incident d'un même moniteur sont le cas habituel —, ou cela ne peut pas être vérifié ;
  • c'est le tour de suivi après un correctif dont le retour arrière ne s'est pas terminé.

Le retour arrière d'abord. Quand Status200 a marqué un rollout Kubernetes du cluster comme suspect pour l'incident (voir Déploiements et changements), Status200 AI tente un retour arrière de ce rollout avant tout autre correctif. Status200 construit le kubectl rollout undo à partir du changement enregistré, jamais à partir de ce qu'écrit le modèle, et la commande s'exécute ou attend une approbation comme toute modification sûre dans le mode du cluster. Ce retour arrière n'est pas proposé quand le Deployment a de nouveau changé après ce rollout, car l'annulation déferait alors le changement ultérieur.

Workloads déclarés par Argo CD, Flux ou Helm. Beaucoup de clusters déclarent leurs workloads dans git et laissent Argo CD ou Flux l'appliquer, ou les installent avec Helm, et une modification kubectl de ce qui y est déclaré ne dure pas : Argo CD la rétablit en quelques secondes quand l'Application a le self-heal activé (sinon à sa prochaine synchronisation), Flux à sa prochaine réconciliation, et une release Helm à sa prochaine mise à niveau. Avant qu'Status200 AI n'exécute ou ne propose une modification kubectl, Status200 lit donc, avec kubectl en lecture seule via l'agent IA du cluster, l'objet qu'elle modifie (pour un ReplicaSet, son Deployment) et qui le déclare : Argo CD (l'annotation argocd.argoproj.io/tracking-id, le label argocd.argoproj.io/instance ou son gestionnaire de champs), Flux (les labels kustomize.toolkit.fluxcd.io/* ou helm.toolkit.fluxcd.io/*) ou une release Helm (l'annotation meta.helm.sh/release-name ou le label app.kubernetes.io/managed-by: Helm). Une modification qu'Argo CD ou Flux rétablit — rollout undo (y compris le retour arrière d'abord), scale (quand git fixe le nombre de réplicas), set image/env/resources, patch, la suppression d'un workload — ne s'exécute jamais d'elle-même, dans aucun mode, y compris Contourner l'approbation et la liste d'autorisation : elle est proposée à l'approbation d'un clic comme correctif temporaire, et le plan nomme le correctif durable, la même modification dans git (le manifeste, les values Helm ou l'overlay Kustomize dont le workload est issu). Argo CD et Helm laissent tel quel ce que git ne déclare pas, comme un rollout restart, un rollout pause ou une annotation ajoutée ; une telle modification s'exécute donc selon le mode du cluster. Une Kustomization Flux supprime même cela à sa prochaine réconciliation : une pause, un label ou une annotation y sont donc aussi un correctif temporaire. Avec Flux, un redémarrage s'exécute tout de même selon le mode : quand Flux retire son annotation, les pods redémarrent une fois de plus, sans que le redémarrage soit annulé. La suppression d'un pod défaillant s'exécute selon le mode, quel que soit celui qui déclare le workload : git ne déclare jamais un pod, et son ReplicaSet le remplace. Une release Helm ne rétablit une modification qu'à sa prochaine mise à niveau ; la modification s'y exécute donc aussi selon le mode du cluster, et le plan précise qu'elle est temporaire.

La vérification remarque un correctif rétabli. Status200 lit l'objet qu'un correctif kubectl modifie juste avant et juste après son exécution, puis de nouveau toutes les deux ou trois minutes tant que la fenêtre de vérification est ouverte. Un correctif revenu à ses anciennes valeurs (rétabli par Argo CD, Flux, une mise à niveau Helm, un opérateur ou un autoscaler) fait échouer la vérification immédiatement, et la note indique qui l'a rétabli et où va la modification durable. Son retour arrière n'est pas exécuté : le cluster l'a déjà annulé, et l'annulation pourrait réappliquer le correctif. Une modification qu'Argo CD ou Flux rétablit est jugée à la fin de sa fenêtre, et non dès que les moniteurs se rétablissent. Un redémarrage ne laisse rien à surveiller : ses pods ont été remplacés, quoi qu'il advienne ensuite de son annotation.

Une modification sûre touche exactement un objet nommé : rollout restart/undo/pause/resume, scale (vers n'importe quelle valeur sauf 0), la suppression d'un pod nommé, cordon/uncordon, et label/annotate sur un Pod, Deployment, StatefulSet, DaemonSet, ReplicaSet, Job ou CronJob nommé avec une clé ordinaire (pas une clé réservée comme *.kubernetes.io/… ou *.k8s.io/…). Tout le reste de ce que la politique autorise est plus risqué : les mêmes verbes sur un type seul (rollout restart deployment), sur plusieurs objets, avec un sélecteur ou avec --all ; scale vers 0 ; la suppression d'un job ; taint ; drain ; patch ; set image/env/resources ; create ; la suppression avec --force ; et les labels ou annotations sur tout autre type ou avec une clé réservée.

Certaines limites tiennent dans tous les modes, Contourner l'approbation compris, et aucune entrée de la liste d'autorisation ne les change :

• Une écriture dans kube-system, kube-public ou kube-node-lease exige toujours un humain. Une ressource personnalisée est jugée d'après l'espace de noms dans lequel elle est écrite, même une dont le nom ressemble à un type intégré à l'échelle du cluster (nodes.example.com, namespaces.example.com).
• Un drain, un taint ou un patch d'un nœud exige toujours un humain. Vider un nœud expulse les pods de tous les espaces de noms — les trois ci-dessus et celui de l'agent compris —, et un taint NoExecute les expulse aussi, qu'il soit posé par kubectl taint ou par un patch du nœud.
• L'agent IA ne modifie jamais rien dans son propre espace de noms — un correctif à cet endroit pourrait réduire à zéro l'agent Kubernetes, ou l'agent IA lui-même —, ni rien en dehors des espaces de noms où son chart l'autorise à écrire (aiAgent.remediation.namespaces), ni un nœud quand son chart a désactivé les opérations sur les nœuds (aiAgent.remediation.nodeOperations=false). Status200 lit ce périmètre dans ce que l'agent IA communique et refuse un tel correctif quand Status200 AI le propose, puis de nouveau quand quelqu'un l'approuve, il n'atteint donc jamais l'agent IA sous la forme d'un correctif échoué ; l'agent IA le refuse aussi, avant de lancer kubectl.
• Les commandes destructrices (ci-dessous) ne s'exécutent jamais, même avec l'approbation d'un humain.

La liste d'autorisation du mode automatique est comparée mot à mot à la commande analysée, et non comme du texte libre : * représente exactement un mot (une image, un nom), jamais des objets, des options ou un second -n en plus, et chaque option utilisée par la commande doit être écrite dans l'entrée. kubectl set image deployment/web * -n web autorise une nouvelle image pour web dans web, rien d'autre. Une entrée doit écrire son verbe en toutes lettres — et la sous-commande de rollout, set ou create — au lieu d'utiliser * à sa place, et doit compter plus d'un mot après le kubectl initial facultatif ; une entrée qui enfreint ces règles, comme scale ou kubectl *, ne pourrait jamais pré-approuver une modification et est refusée à l'enregistrement.

Ce que le RBAC de l'agent IA limite, et ne limite pas#

Ce que l'IA a appris sur un cluster#

La page Analyses IA du cluster (IA → Analyses) vous dit ce qui vaut la peine d'être su sur le cluster d'après les 30 derniers jours — non pas un relevé de ce que l'IA a fait, mais ce qu'elle a découvert :

• Ce que Status200 AI a trouvé — les quelques points qui comptent le plus, le plus important en premier, chacun avec les incidents et les alertes qui le sous-tendent et une prochaine étape :

  • un problème qui revient sans cesse : à quelle fréquence (chaque incident et chaque alerte qu'il a déclenché compte, investigué ou non) et quelle part du total cela représente, s'il est nouveau cette semaine ou s'aggrave, le moment de la journée où il commence d'habitude (dans votre propre fuseau horaire), les parties du cluster qu'il touche, ce que la dernière investigation a trouvé et la première étape que suggère son rapport ;
  • un correctif qui n'a pas résolu son problème, et les correctifs en attente de votre approbation ;
  • un risque repéré avant que quiconque soit alerté : une analyse ouverte de sévérité High ou Medium sur la propre télémétrie du cluster ;
  • le nœud, le pod, l'espace de noms ou le workload derrière plusieurs problèmes différents, lié à sa propre page dans le cluster ;
  • ce que l'IA a corrigé d'elle-même et si le correctif a tenu, et — quand votre équipe a approuvé chaque correctif proposé par l'IA — que l'IA pourrait appliquer d'elle-même des correctifs comme ceux-là ;
  • un problème qui revenait sans cesse et qui a cessé après un correctif.

  Quand rien ne ressort, la page le dit.

• Autres problèmes — tout le reste de ce que l'IA a examiné, regroupé selon ce qui l'a déclenché (un moniteur est un problème, quel que soit le nombre de pods ou de nœuds pour lesquels il s'est déclenché), le plus fréquent en premier : à quelle fréquence, quels espaces de noms, workloads, pods ou nœuds il touche, ce que la dernière investigation a trouvé et suggère, ce que sont devenus les correctifs proposés par l'IA, et ce que votre équipe et l'évaluation ont dit des constats. Un problème survenu plus d'une fois est marqué Récurrent, Nouveau cette semaine ou S'aggrave.

• Où les problèmes surviennent — les parties du cluster qui sont revenues le plus souvent, et dans combien de problèmes différents.

• Repéré avant que quiconque soit alerté — les autres analyses ouvertes que les détecteurs ont créées à partir de la propre télémétrie du cluster.

• Ce que Status200 AI a fait ici — la note de bas de page : combien d'investigations, de correctifs et de commandes il y a eu et combien ont échoué, les investigations par jour, ce que sont devenus les correctifs proposés par l'IA et si ceux qui ont été appliqués ont résolu le problème, et ce qui s'est mal passé dans le travail de l'IA elle-même (investigations échouées, commandes que l'agent n'a jamais prises en charge, constats rejetés par votre équipe), chaque point avec l'endroit où regarder.

Avec Activer l'IA désactivé pour le projet, ou sans fournisseur LLM que Status200 AI puisse utiliser, la page le dit en haut : rien de nouveau n'est investigué, donc rien de nouveau n'apparaît.

Tout ce qui figure sur la page provient de ce que Status200 a déjà enregistré — les incidents et les alertes, leurs investigations et ce qu'elles ont conclu, les verdicts à leur sujet, les correctifs et les commandes — et aucun modèle n'est appelé pour la construire : les mots qui sont ceux de l'IA (un constat, une étape suggérée) ont été écrits par l'investigation qui les a trouvés, et sont présentés comme les siens. Toute personne qui peut voir le cluster peut voir la page, et celle-ci ne nomme que les incidents et les alertes que la personne peut lire.

Tout ce que l'IA a fait sur un cluster#

La page Journaux IA du cluster (IA → Journaux) est le relevé de tout ce que Status200 AI y a fait, du plus récent au plus ancien : chaque investigation avec son incident ou son alerte et son résumé, chaque correctif qu'il a proposé ou exécuté avec son statut, et chaque commande kubectl — d'investigation ou de correctif — avec la commande, son statut et le moment où elle a tourné. Le résumé d'une investigation est son TL;DR ou, quand aucun TL;DR n'a pu être écrit, le résumé par lequel s'ouvre son rapport. Cette page s'appelait auparavant Analyses IA ; un favori de son ancienne adresse ouvre désormais la page Analyses IA, qui renvoie ici.

Via l'ancien Runner du cluster#

Les clusters configurés avec un chart antérieur (aiAccess.enabled=true) atteignent Status200 AI via l'ancien Runner du cluster jusqu'à la mise à niveau du chart. La mise à niveau remplace ce Runner par l'agent IA Kubernetes et reprend ses paramètres — voir Mettre à niveau l'agent.

Un Runner hors du cluster ne l'atteint plus : il le faisait avec un identifiant de runbook Kubernetes, et les identifiants de runbook ont été supprimés. Un cluster qui n'exécute pas le chart de l'agent Kubernetes obtient le kubectl de Status200 AI en l'installant : l'agent IA Kubernetes du chart est la porte d'entrée.

Accès à l'infrastructure — Docker, Podman, Swarm, Proxmox, VMware, Ceph, bases de données et hôtes#

Le même type d'accès existe pour le reste de votre infrastructure. Un agent IA de ressource (image status200/resource-ai-agent) tourne à côté du collecteur d'un hôte Docker ou Podman, d'un cluster Docker Swarm, d'un cluster Proxmox, d'un VMware vCenter, d'un cluster Ceph ou d'un serveur de base de données — ou seul sur un hôte Linux — et laisse Status200 AI y exécuter des commandes en lecture seule pendant qu'il investigue (docker logs, pvesh get, govc vm.info, ceph health detail, un catalogue fixe de diagnostics de base de données, systemctl status, journalctl, …) et, seulement si vous démarrez l'agent avec STATUS200_AI_ALLOW_WRITES=true et un niveau de correctifs (STATUS200_AI_FIXES), appliquer des correctifs avec les mêmes quatre modes et les mêmes trois vérifications qu'un cluster Kubernetes. Comme pour un cluster, ce que l'IA peut faire sur une telle ressource se définit là où son agent tourne (STATUS200_AI_INVESTIGATION, STATUS200_AI_FIXES) et s'affiche en lecture seule sur la page de son agent IA. Chaque ressource de ce type a les mêmes pages Agent IA, Analyses et Journaux. Voir Agents IA pour l'infrastructure pour savoir comment les installer, ce que chacun peut exécuter et son modèle de sécurité.

Mode silencieux#

Une investigation qui ne parvient pas à déterminer une cause publie son analyse sur la chronologie sans notifier votre espace de travail Slack/Teams ni l'astreinte. Une non-réponse ne devrait jamais alerter personne — l'analyse est là quand quelqu'un regarde, mais personne n'est réveillé pour « non concluant ». Les analyses sûres d'elles notifient l'espace de travail normalement.

Le fait qu'une analyse compte comme sûre d'elle est décidé par un signal vérifié par le serveur, et non par ce que dit le texte de l'analyse : une investigation qui n'a recueilli aucun élément (aucune requête de télémétrie réussie, aucune citation) est toujours traitée comme non concluante, et sinon une vérification distincte et contrainte classe l'analyse. Si cette vérification échoue elle-même, Status200 AI penche du côté de la notification — le mode silencieux échoue plus bruyamment, jamais en silence.

Correctifs de code automatiques#

Une analyse sûre d'elle qui recommande une modification de code dans un dépôt peut aller un cran plus loin que la notification : elle ouvre le correctif. Les pull requests de correctif font partie de la correction : elles ne s'ouvrent que tant que Corriger automatiquement les nouveaux incidents (dans Incidents → IA → Paramètres) ou Corriger automatiquement les nouvelles alertes (dans Alertes → IA → Paramètres) est activé, et la correction démarre désactivée, y compris pour les nouveaux projets. Sans règle IA, elles s'ouvrent pour chaque investigation qui remplit les conditions ; avec des règles, chaque règle le décide pour ce qu'elle cible, avec Pull requests de correctif sous Plus de champs, activé pour une nouvelle règle. Rien ne s'ouvre tant que le projet n'a pas de dépôt connecté via la GitHub App et de Runner doté de la capacité de correction de code. Une investigation qui remplit les conditions met automatiquement en file la même tâche de correction que le bouton Ouvrir une PR de correctif à partir de cette analyse du panneau d'investigation : une tâche d'agent IA qui transforme l'analyse publiée en pull request, prête à être relue. Le bouton utilise la même recommandation et est masqué pour les analyses dont le remède est opérationnel, purement lié à l'infrastructure, externe, un refus attendu, une erreur de l'utilisateur, ou non concluant.

Les Pull requests de télémétrie, juste à côté sous Plus de champs d'une règle et activées elles aussi pour une nouvelle règle, concernent les investigations qui se terminent sans conclusion parce que les journaux, traces ou métriques dont elles avaient besoin manquaient : Status200 AI ouvre une pull request qui ajoute cette instrumentation aux chemins de code concernés, pour que votre équipe la relise. Elles ont besoin d'un dépôt connecté via la GitHub App, et ne s'ouvrent elles aussi que tant que la correction est activée.

Une pull request ne change rien tant que votre équipe ne l'a pas fusionnée, mais la correction fait plus que les ouvrir. Pour obtenir les pull requests sans que Status200 AI modifie vos clusters ou vos hôtes, activez la correction, laissez les Correctifs désactivés sur la page Agent IA de chaque cluster Kubernetes et de chaque hôte (désactivé est leur valeur par défaut), et n'ajoutez aucune règle IA : avec la correction activée et sans règle, Status200 AI ne corrige que là où une page d'agent IA le permet. Avec des règles en place, une pull request ne s'ouvre que pour un incident (ou une alerte) que cible une règle, quand une règle qui le cible a cette pull request activée, et seulement dans les dépôts de code que nomment les règles qui le ciblent ; une règle qui le cible sans en nommer aucun autorise tous les dépôts connectés.

Par l'API ou Terraform, la correction est le champ enableAutomaticIncidentRemediation du projet (enableAutomaticAlertRemediation pour les alertes), et chaque règle IA a openCodeFixPullRequests et openTelemetryPullRequests, tous deux à true sauf si vous les définissez, ainsi que codeRepositories, vide pour tous les dépôts connectés. Les champs du projet qui portaient les deux pull requests auparavant ont disparu ; voir la note de mise à niveau.

La même classification contrainte et vérifiée par le serveur qui décide de la confiance décide aussi si une modification du dépôt est appropriée. Seule une classification positive en correctif de code propose ou ouvre automatiquement la pull request. Une investigation qui n'a recueilli aucun élément vérifié par le serveur, qui recommande un remède sans code, ou dont la classification a échoué n'en ouvre jamais — la création de PR échoue toujours vers l'inaction. Tout le reste correspond au bouton manuel : la pull request s'ouvre prête à être relue, a besoin d'un dépôt connecté via la GitHub App et d'un Runner doté de la capacité de correction de code, compte dans la limite quotidienne de tâches de correction de ce type de signal et dans le plafond de PR ouvertes du dépôt quand l'une ou l'autre est définie, et au plus une tâche de correction par incident ou par alerte peut être active à la fois. L'investigation elle-même reste en lecture seule — le correctif s'exécute comme une tâche d'agent distincte et entièrement journalisée. Voir Code pour le fonctionnement des pull requests de correctif, y compris la vérification par build et tests qui s'exécute avant l'ouverture de chaque pull request.

Vérifié en production. Fusionner un correctif ne corrige pas l'exception ; l'exécuter, si. Une fois un correctif IA d'une exception fusionné, Status200 attend un déploiement enregistré du service de l'exception qui contient le commit du correctif (voir Déploiements et changements), puis surveille l'exception dans ce déploiement. Si l'exception se reproduit, le correctif est marqué Se produit encore après le correctif et l'exception est rouverte. Si elle reste absente au moins un jour, et assez longtemps pour qu'à son rythme de la semaine précédant le correctif elle se soit produite au moins 3 fois, le correctif est marqué Corrigé en production et l'exception est résolue. Un correctif qu'aucun déploiement enregistré ne contient dans les 14 jours, ou une exception trop rare pour que 7 jours calmes veuillent dire quoi que ce soit, est marqué Non vérifié en production. La tâche de correction de l'exception indique lequel de ces cas s'applique.

Les autres correctifs sont jugés sur ce qu'ils corrigent. Un correctif d'une trace lente ou d'un insight de latence, un correctif de la cause racine trouvée par une investigation et une amélioration de la télémétrie attendent le même déploiement, puis sont jugés selon ce à quoi ils servaient :

• Une opération lente — son p99 dans le correctif déployé par rapport à la semaine précédant la fusion, une fois que le correctif a tourné une journée sur au moins 100 spans, lu dans la version du déploiement lorsque la télémétrie du service la signale. Au moins un cinquième plus rapide donne Plus rapide en production, et l'insight de latence qui a demandé le correctif est résolu ; pas plus rapide du tout donne Toujours lent après le correctif, et l'insight demande de nouveau de l'attention.
• La cause racine d'un incident ou d'une alerte — le moniteur qui l'a déclenché. Tout incident ou toute alerte qu'il déclenche après le déploiement donne Survenu de nouveau après le correctif, noté dans le fil des deux ; calme pendant une journée, et assez longtemps pour qu'à son rythme des 30 jours précédant le correctif il en ait déclenché 3, donne Corrigé en production, noté dans le fil de l'incident investigué. Tant qu'un de ses incidents reste ouvert, un moniteur n'en déclenche pas d'autre, donc ce temps ne compte pas.
• Télémétrie, journalisation ou traçage manquants — ce que les changements du correctif ajoutent et que la semaine précédant la fusion ne contenait pas : le nom d'un span, la clé d'un attribut, le message d'un log. Dès qu'une partie arrive du correctif déployé, ou qu'un service qui n'envoyait ni spans ni logs commence à en envoyer, et que le correctif a tourné une journée, il donne Arrive en production ; un service qui envoyait régulièrement des spans ou des logs et n'en envoie plus aucun après le déploiement donne Télémétrie interrompue après le correctif.

Un correctif dont on ne peut rien dire dans les 7 jours suivant son déploiement (14 pour la cause racine d'un incident) donne Non vérifié en production. Code affiche le verdict de chaque pull request de correctif, tout comme les journaux IA de l'incident et l'insight qui a demandé le correctif.

Quels incidents sont investigués et corrigés#

Deux interrupteurs sur la page des paramètres IA de chaque type de signal décident de ce que Status200 AI fait de lui-même d'un nouvel incident : Investiguer les nouveaux incidents (activé par défaut) et Corriger automatiquement les nouveaux incidents (désactivé par défaut) ; les alertes ont leur propre paire. Les Règles IA, repliées sous Plus de paramètres sur la même page, restreignent les deux : sur quels nouveaux incidents Status200 AI travaille, et ce qu'il fait de chacun. La plupart des projets n'en ont besoin d'aucune.

• Sans règle, Status200 AI investigue immédiatement chaque nouvel incident et, tant que Corriger automatiquement les nouveaux incidents est activé, corrige chacun sur les clusters Kubernetes et les hôtes auxquels il est lié, dans le mode que définit la page de l'agent IA de chacun, et peut choisir le runbook du projet qui convient, qu'il vous propose pour approbation.
• Avec des règles, Status200 AI n'investigue que les incidents qui correspondent à au moins une règle activée, et ne corrige que ceux que cible une règle qui corrige, chacun comme le disent ses règles correspondantes. Les autres le disent : un incident hors des règles sur sa carte Investigation IA (This incident was outside the AI rules that investigate at creation), où vous pouvez quand même interroger Status200 AI à son sujet, et un incident que seules des règles qui ne corrigent pas ont ciblé sur sa carte Remédiation. Des règles illisibles n'arrêtent jamais une investigation : l'incident est investigué comme s'il n'y en avait aucune.

Une règle IA pose trois questions, une par étape :

1. Correspondance — quels incidents elle cible : Tous les incidents, où démarre une nouvelle règle, ou Uniquement les incidents qui correspondent aux conditions sur les moniteurs, sévérités, labels, labels de moniteur, titre et description, les mêmes conditions que les autres règles d'incident et d'alerte du projet.
2. Investiguer — quand Status200 AI investigue ce que la règle cible : Immédiatement, ou Seulement s'il est encore ouvert après une attente (voir Attendre avant d'investiguer).
3. Correction — ce que fait Status200 AI une fois qu'il a investigué. Ne pas corriger : il publie ce qu'il trouve et ne change rien. Demander avant de corriger : rien ne s'exécute tant que quelqu'un n'a pas approuvé le correctif d'un clic. Corriger sans demander : Status200 AI corrige tout de suite partout où les paramètres de l'agent IA le permettent — un cluster ou un hôte réglé pour demander une approbation la demande quand même — et démarre les runbooks que vous avez choisis. Une nouvelle règle demande avant de corriger.

Il n'y a pas de correction sans investigation, donc chaque règle créée dans le tableau de bord investigue. Une règle qui était une règle de remédiation automatique avant que les deux sortes de règles n'en fassent plus qu'une, ou qu'un client d'API ou Terraform crée sans le préciser, peut seulement corriger : sa colonne Investigue et corrige indique N'investigue pas, son étape Investiguer le dit, et Investiguer aussi en fait une règle comme les autres. Une telle règle ne décide jamais quels incidents sont investigués : Status200 AI investigue ce qu'elle cible quand une autre règle le fait, ou quand aucune règle activée n'investigue. Une règle qui n'investigue ni ne corrige est refusée.

Status200 AI corrige via l'agent IA du cluster ou de l'hôte que l'incident affecte, avec le runbook du projet qui lui convient, s'il y en a un, et avec une pull request quand le correctif est une modification de votre code. Ce que la plupart des règles ne changent jamais est replié sous Plus de champs, à la fin de la dernière étape de la règle ; les runbooks, le Runner et les deux pull requests ne concernent qu'une règle qui corrige :

• Dépôts de code — les dépôts que Status200 AI peut lire pendant qu'il investigue et corrige, et dans lesquels il peut ouvrir des pull requests. Si aucun n'est choisi (Tous les dépôts connectés), il peut utiliser tous les dépôts connectés au projet.
• Serveurs MCP — les serveurs MCP externes que Status200 AI peut utiliser pour la règle : seulement leurs outils qui lisent pendant qu'il investigue, et les autres aussi quand il corrige. Si aucun n'est choisi (Tous les serveurs MCP), il peut utiliser tous les serveurs activés du projet, et chaque modification qu'il fait par eux attend une approbation ; choisissez-en pour qu'il n'utilise que ceux-là, et pour qu'une règle qui corrige sans demander fasse elle-même leurs modifications.
• Fournisseur LLM — le fournisseur LLM que Status200 AI utilise pour la règle : l'investigation, ainsi que les runbooks qu'il choisit, les commandes qu'il compose, ses corrections via des serveurs MCP, ses pull requests et le travail de l'agent IA sur le cluster ou l'hôte. Si aucun n'est choisi, c'est le fournisseur par défaut du projet, sinon le fournisseur global (voir Quel fournisseur LLM une règle utilise). Une règle qui ne fait que corriger et qui est réglée sur Les exécuter à chaque fois n'utilise pas d'IA, elle n'en a donc pas.
• Runbooks — les runbooks que Status200 AI peut exécuter pour la règle. Si aucun n'est choisi (N'importe quel runbook), il peut choisir n'importe quel runbook activé du projet ; choisissez-en pour qu'il n'exécute que ceux-là. Un runbook qu'il choisit parmi tous est toujours proposé pour approbation. Un runbook qu'il choisit parmi ceux de la règle démarre tout de suite pour une règle qui corrige sans demander — sauf si une autre règle correspondante demande d'abord, si l'agent IA corrige déjà l'incident sur un cluster ou un hôte, ou si la règle a déjà démarré le plus de runbooks qu'elle peut démarrer en une heure.
• Les exécuter à chaque fois — la règle démarre chaque runbook qu'elle nomme pour chaque incident qu'elle cible, de la même façon à chaque fois, au lieu de laisser Status200 AI décider. Ce champ apparaît dès que la règle nomme des runbooks.
• Agent Runbook — l'endroit où Status200 AI exécute des commandes Bash pour la règle, dans votre réseau. La liste montre vos propres Runners, celui par défaut du projet en premier, et une nouvelle règle démarre sur celui par défaut ; avec Aucun agent Runbook, Status200 AI n'exécute aucune commande de lui-même pour la règle. Les commandes sur le cluster Kubernetes ou l'hôte concerné passent toujours par son agent IA, quel que soit le choix de la règle, et un Runner global n'exécute jamais les commandes de Status200 AI. C'est le choix de l'un de vos Runners qui permet à Status200 AI d'y exécuter des commandes : un Runner n'a pas d'interrupteur pour cela.
• Pull requests de correctif et Pull requests de télémétrie — si Status200 AI ouvre une pull request de correctif, ou une qui ajoute la télémétrie manquante, pour les incidents que la règle cible (voir Correctifs de code automatiques). Les deux sont activées pour une nouvelle règle.

Quand plusieurs règles correspondent, chacune s'exécute : Status200 AI investigue l'incident une fois, après la plus courte de leurs attentes, et le corrige une fois, et chaque règle qui exécute ses runbooks à chaque fois les exécute. Si une règle correspondante qui corrige avec Status200 AI demande avant de corriger, chaque correctif de Status200 AI pour l'incident demande d'abord, et sa ligne sur la carte Remédiation nomme cette règle. Une règle correspondante qui ne corrige pas n'ajoute rien à la correction.

Une règle enregistrée avant la simplification des règles continue de faire ce qu'elle faisait. Une règle qui faisait composer à l'IA des commandes sur des Runners, ou choisir l'un des runbooks du projet, s'affiche comme Status200 AI : commandes sur les Runners ou Status200 AI : choisit un runbook et continue de le faire ; elle n'active pas les correctifs des clusters et des hôtes et ne les fait pas demander. Ses autres paramètres (la liste d'autorisation des commandes, les Runners de commandes, la fenêtre de vérification) sont conservés, et se définissent par l'API ou Terraform. En la modifiant, vous voyez ce qu'elle fait, et Corriger comme une nouvelle règle la fait corriger comme une nouvelle règle, en demandant d'abord jusqu'à ce que vous choisissiez autrement.

Via l'API, une règle IA est un AutoRemediationRule, à /api/auto-remediation-rule : la route, les autorisations et les identifiants qu'avaient les règles de remédiation automatique. investigates et fixes disent ce qu'elle fait — false et true si vous ne les définissez pas, si bien qu'un ancien client crée encore des règles qui ne font que corriger — et onlyIfOpenAfterMinutes est son attente. Dans Terraform, c'est status200_ai_rule ; status200_auto_remediation_rule fonctionne encore, mais est déprécié. La route et la ressource Terraform propres aux règles d'investigation n'existent plus : voir la note de mise à niveau.

Les commandes sur les Runners. Une commande que Status200 AI compose pour une règle qui choisit un Agent Runbook, ou pour une règle enregistrée pour composer des commandes sur des Runners, est une commande Bash qui s'exécute sur l'hôte propre de ce Runner, avec ce que l'hôte peut atteindre. Status200 AI ne compose plus de commande SSH : une telle commande atteignait un autre hôte avec un identifiant de runbook, et les identifiants de runbook ont été supprimés, si bien qu'un plan enregistré qui en contient encore une n'est pas approuvé et ne s'exécute jamais. Une commande kubectl s'exécute via l'agent IA Kubernetes du cluster, ou son ancien Runner du cluster, avec son propre ServiceAccount (voir Accès au cluster).

Quel fournisseur LLM une règle utilise#

Chaque règle de Status200 AI — règles IA et règles de post-mortem — peut choisir, sous Plus de champs, le Fournisseur LLM que Status200 AI utilise pour ce que la règle lance : l'un des fournisseurs propres au projet, ou un fournisseur global. La plupart des règles n'en choisissent aucun. Ce que lance une règle utilise, dans cet ordre :

1. le fournisseur que la règle choisit ;
2. à défaut, le fournisseur par défaut du projet, celui défini par défaut dans Paramètres du projet → IA → Fournisseurs LLM ;
3. sans fournisseur par défaut, le fournisseur global.

Un champ vide nomme le fournisseur qu'il représente, et la ligne repliée Plus de champs de la règle aussi lorsqu'il y a plus d'un fournisseur au choix.

• Tout ce que la règle lance. Le fournisseur d'une règle IA écrit l'investigation, la nouvelle vérification quand une nouvelle alerte s'ouvre, et la note quand l'incident est résolu ; Investiguer maintenant, et demander à Status200 AI de lancer une investigation, l'utilisent aussi. Pour une règle qui corrige, il élabore aussi les corrections de la règle et ouvre ses pull requests, et un tour suivant d'une correction utilise le fournisseur du tour précédent. Le fournisseur d'une règle de post-mortem écrit le brouillon et choisit son modèle.
• Plusieurs règles. Quand plusieurs règles qui investiguent correspondent, la première d'entre elles par nom qui choisit un fournisseur l'emporte. Quand plusieurs règles qui corrigent correspondent, chacune élabore ses propres corrections avec son propre fournisseur, et ce qu'elles partagent — le travail de l'agent IA sur le cluster ou l'hôte, et les pull requests — utilise la première d'entre elles par nom qui en choisit un. Une règle correspondante qui n'en choisit aucun ne masque jamais le choix d'une autre. Pour un post-mortem, la règle qui décide des modèles décide du fournisseur.
• Un fournisseur qui ne peut plus être utilisé. Supprimer un fournisseur le retire de chaque règle qui l'avait choisi. Le travail mis en file avant, et un fournisseur que le projet ne peut plus utiliser, reviennent au fournisseur par défaut du projet, sinon au fournisseur global. Un fournisseur global payé avec des crédits IA ne revient qu'au fournisseur par défaut propre au projet quand les crédits sont épuisés ou que la limite quotidienne de dépenses IA du projet l'arrête ; sans fournisseur par défaut propre, le travail s'arrête.
• L'exécution dit lequel. Une exécution dont la règle a choisi un fournisseur indique dans son activité quel fournisseur elle a utilisé, ou lequel elle a utilisé à la place, et pourquoi. Un brouillon de post-mortem l'indique dans le fil de l'incident.
• Qui peut en choisir un. Choisir un fournisseur demande l'autorisation de lire les fournisseurs LLM du projet. Un rôle personnalisé qui modifie des règles sans lire aucun fournisseur ne peut pas en choisir, et une modification qu'il fait garde le fournisseur choisi par la règle.

Par l'API ou Terraform, le fournisseur de chaque règle est son llmProviderId, vide pour aucun, et une exécution IA enregistre le fournisseur choisi par sa règle dans son propre llmProviderId.

Attendre avant d'investiguer#

Beaucoup d'incidents sont terminés en quelques minutes : un contrôle qui oscille, un déploiement qui se rétablit tout seul. Une règle IA peut faire attendre Status200 AI avant qu'il investigue les incidents auxquels elle correspond, et n'investiguer que ceux encore ouverts à la fin de l'attente. Sous Quand investiguer, chaque règle choisit l'une de deux réponses :

• Immédiatement — Status200 AI commence dès que l'incident est déclaré. Une nouvelle règle commence ainsi, et toute règle enregistrée avant que les règles puissent attendre le garde.
• Seulement s'il est encore ouvert après une attente — Status200 AI attend la durée Attente (minutes) de la règle, de 1 à 1440 (un jour), comptée à partir de la déclaration de l'incident. Un incident résolu pendant l'attente n'est pas investigué, et sa carte Investigation IA dit pourquoi : Resolved before the investigation started. Dans l'API et Terraform, l'attente est le champ onlyIfOpenAfterMinutes de la règle ; vide signifie aucune attente.

Pendant qu'un incident attend, sa carte Investigation IA affiche En attente et l'heure à laquelle Status200 AI l'investiguera s'il est encore ouvert, et la colonne Investigue et corrige du tableau des règles dit quand chaque règle investigue. Quelqu'un qui peut modifier l'incident peut lancer l'investigation plus tôt avec Investiguer maintenant sur la carte, ou en demandant à Status200 AI de la lancer. Elle démarre aussitôt, quoi que disent les règles, le seuil de sévérité ou le délai de récupération, tant que l'IA est activée, dispose d'un fournisseur LLM et de crédits IA, et qu'aucune limite n'est atteinte.

• Plusieurs règles. Quand plusieurs règles activées correspondent, l'attente la plus courte l'emporte, et une règle correspondante qui investigue immédiatement signifie immédiatement.
• Changements pendant l'attente. Quand la sévérité, les labels, les moniteurs, le titre ou la description de l'incident changent pendant qu'il attend, l'attente suit les règles auxquelles il correspond alors : une sévérité dont la règle attend moins, ou pas du tout, met fin à l'attente plus tôt.
• À la fin de l'attente. L'incident est vérifié comme un nouvel incident : les interrupteurs, les règles, le seuil de sévérité, le délai de récupération et les limites. Si les règles auxquelles il correspond désormais attendent plus longtemps, il attend jusque-là. S'il ne correspond plus à aucune règle, ou si autre chose l'arrête, il n'est pas investigué, et sa carte dit pourquoi, avec la mention Décision enregistrée à la fin de l'attente.
• La correction n'attend pas. La remédiation automatique démarre quand l'incident est déclaré, comme quand aucune investigation n'est mise en file, et l'investigation qui suit l'attente ne la relance jamais (voir La remédiation automatique attend l'analyse).
• Une nouvelle alerte ensuite. La vérification de suivi compte ses 30 minutes à partir de la fin de l'investigation, et non de la déclaration de l'incident (voir Vérifié de nouveau quand une nouvelle alerte s'ouvre).

Les alertes fonctionnent de la même façon, dans Alertes → IA → Paramètres, comptées à partir de la création de l'alerte.

La remédiation automatique attend l'analyse#

Quand le projet corrige automatiquement les nouveaux incidents ou les nouvelles alertes (Corriger automatiquement les nouveaux incidents et Corriger automatiquement les nouvelles alertes, avec les règles IA sous Plus de paramètres dans Incidents → IA → Paramètres et Alertes → IA → Paramètres), la correction attend l'investigation — l'analyse des causes d'abord :

• Quand un nouvel incident ou une nouvelle alerte met en file une investigation IA, la remédiation automatique de cet incident ou de cette alerte est reportée jusqu'à ce que l'investigation aboutisse — quelle que soit l'issue finale : l'analyse est publiée, l'exécution échoue après ses nouvelles tentatives, elle expire dans la file, ou elle devient obsolète. Ce n'est qu'alors que les règles IA s'exécutent, de sorte que le planificateur de remédiation a toujours l'analyse des causes racines publiée en entrée au lieu de faire la course avec elle.
• Quand aucune investigation n'est mise en file (investigations désactivées, ou un seuil de sévérité, un délai de récupération ou un budget que vous avez défini l'a écartée), la remédiation se déclenche immédiatement à la création de l'incident ou de l'alerte, exactement comme avant. La remédiation automatique ne dépend jamais de l'activation de la voie des investigations IA.
• Quand une règle IA fait attendre Status200 AI avant d'investiguer (voir Attendre avant d'investiguer), la remédiation n'attend pas avec elle : elle se déclenche à la création de l'incident ou de l'alerte, comme quand aucune investigation n'est mise en file.
• Un incident ou une alerte créé déjà résolu n'est ni investigué ni corrigé : il était terminé avant d'être enregistré. Sa carte Investigation IA le dit, et vous pouvez quand même interroger Status200 AI à son sujet. Voir Déclaré déjà acquitté ou résolu.

Une investigation qui échoue, expire ou devient obsolète libère quand même la remédiation — le report retarde la remédiation jusqu'à ce que l'issue soit connue ; il ne l'annule jamais.

Pendant que la remédiation attend, la carte Remédiation de l'incident ou de l'alerte le dit, et montre ce qui s'est passé une fois l'investigation aboutie.

La remédiation automatique dépend de deux interrupteurs. Corriger automatiquement les nouveaux incidents (ou les alertes), désactivé tant que le projet ne l'active pas : quand il est désactivé, aucun nouvel incident (ou alerte) n'est corrigé. Et Activer l'IA (Paramètres du projet → IA → Fonctionnalités IA), l'interrupteur principal de l'IA du projet : quand il est désactivé, aucune règle IA ne s'exécute — pas même une règle qui démarre un runbook sans IA — et aucun cluster ni aucune ressource n'est corrigé.

Ce qu'a fait la remédiation automatique#

Chaque incident et chaque alerte a une carte Remédiation qui dit ce que la remédiation automatique en a fait — y compris quand elle n'a rien fait. Chaque fois que le moteur évalue l'incident ou l'alerte, il enregistre une ligne par façon de le corriger :

• Chaque cluster Kubernetes auquel il est lié — Status200 AI a démarré un correctif (et s'il demande une approbation ou s'exécute de lui-même) ; les correctifs sont désactivés sur le cluster ; les correctifs sont activés mais bloqués, avec la raison et la prochaine étape qu'indique la page de l'agent IA du cluster ; le cluster a déjà un correctif pour lui ; ou le correctif n'a pas pu démarrer.
• Chaque ressource d'infrastructure à laquelle il est lié — la même chose, plus le fait qu'une autre ressource liée a reçu l'unique correctif IA qu'obtient un incident.
• Les règles IA — avec des règles configurées : aucune n'a correspondu (et combien ont été vérifiées), ou seulement des règles qui ne corrigent pas, donc rien n'a été corrigé ; ou ce qu'a fait chaque règle correspondante : faire corriger l'incident par Status200 AI (en demandant d'abord ou non), proposer ou démarrer un runbook, faire composer des commandes ou choisir un runbook par l'IA, ou ne pas y parvenir, et pourquoi.
• Le projet — Corriger automatiquement les nouveaux incidents (ou les alertes) est désactivé ; Activer l'IA est désactivé, donc rien ne s'exécute ; l'incident a déjà le nombre maximal de correctifs qu'il peut recevoir ; ou l'évaluation s'est arrêtée sur une erreur.

Quand l'incident n'est lié à aucun cluster ni à aucune ressource d'infrastructure, la carte le dit en une ligne — la raison la plus courante pour laquelle rien n'a été corrigé — avec un lien vers chacun de ses moniteurs, où vous pouvez les lier à ce qu'ils surveillent pour que le prochain incident qu'ils déclenchent soit lié. Chaque ligne renvoie à l'endroit où l'on change la chose : la page de l'agent IA du cluster ou de la ressource, les paramètres IA de l'incident (ou de l'alerte), où se trouvent son interrupteur de correction et ses règles, Activer l'IA, ou les fournisseurs LLM. Les incidents et les alertes créés avant que cela soit enregistré n'affichent la carte que si quelque chose a été proposé.

Ce que Status200 AI a appris, et tout ce qu'il a fait#

La section IA des menus latéraux Incidents et Alertes s'ouvre sur deux pages qui reviennent sur ce que Status200 AI a fait pour ce type de signal. Aucune ne modifie quoi que ce soit : les deux ne montrent que ce qui a été enregistré, et seulement pour les incidents (ou les alertes) que vous pouvez voir.

• Analyses (Incidents → IA → Analyses, Alertes → IA → Analyses) — la même page Analyses IA qu'un cluster (voir Ce que l'IA a appris sur un cluster), sur les incidents (ou les alertes) des 30 derniers jours, établie sur le serveur à partir de ce qui a été enregistré :

  • Ce que Status200 AI a trouvé — les quelques points qui comptent le plus, chacun avec les incidents qui le sous-tendent et une prochaine étape : un incident qui revient sans cesse (à quelle fréquence et quelle part du total cela représente, s'il est nouveau cette semaine ou s'aggrave, quand il commence d'habitude, les moniteurs qui l'ont déclenché, ce que l'IA a trouvé et l'étape qu'elle suggère), un correctif qui n'a pas aidé ou qui attend une approbation, les incidents que l'IA n'a pas examinés et pourquoi (avec le chemin vers le paramètre qui en décide, pour les personnes qui peuvent le modifier), le service ou le moniteur derrière plusieurs problèmes différents, ce que l'IA a corrigé d'elle-même, et — quand votre équipe a approuvé chaque correctif proposé par l'IA — le moyen de laisser l'IA appliquer d'elle-même des correctifs comme ceux-là.
  • Autres problèmes — le reste de ce que l'IA a examiné, regroupé selon le moniteur qui l'a déclenché (par titre quand il n'y en a pas), le plus fréquent en premier : à quelle fréquence, les moniteurs qui le sous-tendent, quels hôtes, pods ou autres éléments il touche, ce que la dernière investigation a trouvé et suggère, ce que sont devenus les correctifs proposés par l'IA, et ce que votre équipe et l'évaluation automatique ont pensé des constats.
  • Moniteurs qui tombent en panne à répétition et Services qui tombent en panne à répétition — les moniteurs à l'origine du plus grand nombre d'incidents des 30 jours, et les services qui en ont été le plus touchés, investigués ou non.
  • Ce que Status200 AI a fait ici — la note de bas de page : combien d'investigations il y a eu et combien des incidents créés pendant les 30 jours l'IA a investigués, les correctifs et les commandes et combien ont échoué, les investigations par jour, ce que sont devenus les correctifs et les pull requests de correctif, et pourquoi l'IA n'a pas investigué les autres, avec le chemin vers les paramètres IA qui en décident.

  Voir les chiffres des correctifs exige l'autorisation de lire les suggestions de remédiation automatique ; sans elle, ils sont omis, et non affichés comme zéro.

• Journaux (Incidents → IA → Journaux, Alertes → IA → Journaux) — chaque investigation, correctif, pull request de correctif et commande, du plus récent au plus ancien, chacun lié à son incident ou à son alerte. Le résumé d'une investigation est son TL;DR ou, quand aucun TL;DR n'a pu être écrit, le résumé par lequel s'ouvre son rapport. Filtrez sur un type, et utilisez Charger les entrées plus anciennes pour remonter. Les commandes exigent l'autorisation de lire les tâches des Runners, et les correctifs celle de lire les suggestions de remédiation automatique ; la page indique quels types elle omet pour votre rôle.

Les paramètres IA et les règles IA se trouvaient auparavant à …/settings/ai et …/settings/auto-remediation-rules, puis les règles à …/ai/auto-remediation-rules ; ces adresses fonctionnent toujours, et ouvrent IA → Paramètres, où se trouvent désormais les règles, sous Plus de paramètres.

Maîtrise des coûts#

Chaque limite ci-dessous est facultative, et aucune ne s'applique tant que vous ne la définissez pas : avec l'investigation automatique activée, chaque nouvel incident et chaque nouvelle alerte est investigué, quelle que soit sa sévérité, et rien ne plafonne le nombre d'investigations ou de tâches de correction qui s'exécutent. Le volume d'alertes peut être bien plus élevé que celui des incidents, ce sont donc les contrôles vers lesquels se tourner quand vous voulez un plafond.

Elles sont repliées sous Plus de paramètres en bas de la page des paramètres IA de chaque type de signal, avec les règles IA (voir Quels incidents sont investigués et corrigés) et, sur la page des incidents, les règles de post-mortem (voir Post-mortem automatique), dans Incidents → IA → Paramètres et Alertes → IA → Paramètres, en trois sections qui se modifient chacune sur une page : Quels incidents sont investigués (ou les alertes : le seuil de sévérité et le délai de récupération), Limites d'investigation (le plafond de simultanéité et la limite de temps) et Limites quotidiennes (les limites de jetons et de tâches de correction). Repliée, Plus de paramètres nomme ses tableaux de règles et les trois sections et dit ce que font les valeurs par défaut — chaque incident (ou alerte) est investigué, quelle que soit sa sévérité, chacun est corrigé tant que la correction est activée, chaque incident résolu reçoit un brouillon de post-mortem, et rien ne limite ce que fait Status200 AI — et, dès qu'une règle ou une limite est définie, affiche le tableau ou la section qui la contient. Ouverte, c'est une seule carte : chaque tableau et chaque ensemble de limites en est une section, avec son propre titre et son bouton Modifier ou Créer, séparée de la suivante par un séparateur.

Le travail de l'IA en dehors des incidents et des alertes — le tri des analyses, et les tâches de correction pour les exceptions, les analyses et les régressions de performance — n'a pas de paramètre propre ni aucune des limites du tableau ; seules les limites quotidiennes propres au projet (ci-dessous) s'y appliquent. Ses pull requests comptent dans le Nombre max de demandes de tirage de correctifs ouvertes d'un dépôt (sur la page Paramètres du dépôt) une fois que vous en définissez un ; non défini signifie aucun plafond, et 0 bloque les pull requests de correctif IA pour ce dépôt.

Comment les jetons sont comptés#

Chaque limite de jetons de cette page compte les jetons d'un appel selon ce qu'ils coûtent, tout comme les Journaux IA et, sur Status200 Cloud, les crédits IA. Un jeton que le modèle lit pour la première fois, et chaque jeton qu'il écrit, compte pour un. Une investigation ou une réponse de Demander à l'IA se compose de nombreux appels, et chaque appel renvoie toute la conversation : le fournisseur sert la partie qu'il a déjà vue depuis son cache de prompts, pour une fraction du prix. Un jeton lu dans ce cache compte pour un dixième de jeton, et un jeton écrit dans ce cache pour un et quart.

Les Journaux IA (Paramètres du projet → IA → Journaux IA) listent chaque appel avec les jetons qui comptent et, en dessous, combien de jetons il a utilisés en tout et combien d'entre eux venaient du cache ou y ont été écrits. Avec Anthropic, y compris Claude dans Microsoft Foundry, Status200 marque le prompt système, les outils et la conversation pour le cache, si bien que chaque appel d'une investigation y lit tout ce qui précède ses derniers résultats d'outils. OpenAI et Azure OpenAI mettent eux-mêmes en cache un prompt répété.

Les limites quotidiennes propres au projet#

Au-dessus de toutes les limites du tableau, un projet peut plafonner ce que Status200 AI utilise en une journée, quoi qu'il fasse : Demander à l'IA, investigations, brouillons de post-mortem, pull requests de correctif, tri des analyses, workflows, runbooks, et questions dans Slack ou Microsoft Teams. Les limites se trouvent dans Paramètres du projet → IA → Fonctionnalités IA, repliées sous Plus de paramètres, dans sa section Limites quotidiennes :

• Limite quotidienne de jetons IA : le maximum de jetons que l'IA du projet peut utiliser chaque jour, via n'importe quel fournisseur LLM.
• Limite quotidienne de dépenses IA (USD), sur Status200 Cloud : le maximum de crédits IA, en dollars US entiers, que l'IA du projet peut dépenser chaque jour. Seule l'IA facturée sur les crédits IA du projet compte, elle n'arrête donc jamais l'IA qui tourne sur le propre fournisseur LLM du projet. Les installations auto-hébergées ne facturent pas l'IA, elles ne la proposent donc pas.

Non défini (par défaut) signifie aucune limite. Une limite est un nombre entier d'au moins 1 ; pour désactiver l'IA, utilisez Activer l'IA. Une journée est une journée UTC, comme pour les limites des incidents et des alertes : l'usage est compté à partir de minuit UTC, et le compte repart au minuit UTC suivant. Repliée, la section indique ce qui s'applique et ce que l'IA a utilisé aujourd'hui, par exemple « Au plus 200 000 jetons par jour. Utilisé aujourd'hui : 45 210 jetons. » Seul un propriétaire du projet ou une personne disposant de Manage Billing peut modifier les limites : les mêmes personnes qui peuvent désactiver l'IA.

Une fois une limite atteinte, le nouveau travail de l'IA s'arrête jusqu'à minuit UTC. Un appel déjà en cours se termine, et chaque appel suivant est refusé avec une phrase qui dit quelle limite a été atteinte, combien a été utilisé, et qui peut la modifier et où : « A project owner or someone with Manage Billing can raise or remove the limit in Project Settings → AI → AI Features → More settings. » Demander à l'IA, un bouton Générer avec l'IA, un workflow, une étape de runbook, ainsi que Slack et Microsoft Teams répondent avec cette phrase, et chaque appel refusé est listé dans les Journaux IA (Paramètres du projet → IA → Journaux IA) avec le statut Budget Exceeded. Les investigations automatiques, les brouillons de post-mortem et le tri des analyses ne sont pas démarrés du tout. Un incident ou une alerte créé entre-temps le dit dans sa carte d'investigation IA, avec un lien vers les limites pour les personnes qui peuvent les modifier. Les limites quotidiennes de jetons des incidents et des alertes s'appliquent toujours sous celle du projet : l'IA s'arrête à celle qui est atteinte en premier.

Quand une limite est atteinte#

Les propriétaires du projet reçoivent un e-mail. La première fois qu'une limite arrête Status200 AI au cours d'une journée UTC, chaque propriétaire du projet reçoit un e-mail : quelle limite, ce que le projet en a utilisé aujourd'hui, quand elle se réinitialise, et un lien vers Paramètres du projet → IA → Fonctionnalités IA, où il peut la relever ou la supprimer. Il arrive une fois par jour pour chaque limite : la limite de jetons et la limite de dépenses envoient chacune le leur, et rien de plus n'est envoyé ce jour-là, quel que soit le nombre d'appels refusés. C'est le même e-mail que celui que les propriétaires reçoivent pour la facturation, et il apparaît comme lui dans les journaux d'e-mails du projet.

Les incidents et les alertes ignorés sont investigués après la réinitialisation. Un incident ou une alerte qui n'a pas été investigué parce qu'une limite était atteinte l'est dès que la limite n'arrête plus l'IA : après minuit UTC, ou dès qu'un propriétaire relève ou supprime la limite. Seulement s'il est encore ouvert et date de moins d'un jour, et une seule fois. Les paramètres du moment s'appliquent, comme pour un nouvel incident ou une nouvelle alerte : tant qu'Activer l'IA ou l'investigation automatique est désactivé, qu'il n'y a pas de fournisseur LLM ou de crédit IA, ou que la limite quotidienne de jetons des incidents ou des alertes est atteinte, il continue d'attendre ; le seuil de sévérité et le délai de récupération peuvent toujours l'écarter, et sa carte dit alors pourquoi. Un enregistrement résolu entre-temps, ou pour lequel quelqu'un a demandé entre-temps à Status200 AI d'investiguer, n'est pas investigué de nouveau. Quelques-uns sont repris toutes les cinq minutes, les plus récents d'abord, et seulement tant que la file d'investigation du projet n'a rien d'autre en attente, de sorte que les nouveaux incidents et alertes passent en premier ; si la limite est de nouveau atteinte, les autres attendent la réinitialisation suivante.

Quand les crédits IA sont épuisés#

Sur Status200 Cloud, Status200 AI sur le fournisseur global est payé avec les crédits IA du projet, dans Paramètres du projet → IA → Crédits IA. Ce qui se passe quand ils sont épuisés dépend du Rechargement automatique, sur la même page :

• Rechargement automatique activé : l'appel IA qui trouve le premier les crédits épuisés ajoute le montant défini pour le rechargement automatique, en débitant la carte du projet, puis s'exécute. Les appels qui arrivent au même moment ne débitent la carte qu'une fois. Activer le rechargement automatique alors que les crédits sont sous son seuil les ajoute tout de suite, comme le fait le rechargement automatique du solde SMS et appels.
• Rechargement automatique désactivé : Status200 AI s'arrête. Chaque appel IA est refusé en indiquant qui peut ajouter des crédits, et où : « A project owner or someone with Manage Billing can add AI credits in Project Settings → AI → AI Credits. » Chaque appel refusé est listé dans les Journaux IA (Paramètres du projet → IA → Journaux IA) avec le statut Insufficient Balance. Les investigations automatiques et les brouillons de post-mortem ne sont pas démarrés, et les pages des agents IA et Code indiquent que le projet n'a plus de crédits IA.
• Le rechargement automatique n'a pas pu débiter la carte (il n'y a pas de moyen de paiement, ou la carte a été refusée) : Status200 AI s'arrête de la même façon, et les propriétaires reçoivent l'e-mail qui indique que le rechargement a échoué. Le rechargement automatique réessaie la carte une heure plus tard. Ajouter des crédits à la main, ou enregistrer à nouveau le rechargement automatique, réessaie tout de suite. D'ici là, Crédits IA le signale en haut, à toutes les personnes qui l'ouvrent : un propriétaire du projet ou une personne disposant de Manage Billing est invité à vérifier le moyen de paiement ou à ajouter des crédits, et les autres apprennent qui le peut.

Les propriétaires du projet reçoivent un e-mail la première fois que Status200 AI s'arrête faute de crédits : quand l'appel qui dépense les derniers se termine, ou quand un appel IA est refusé ou qu'une investigation est ignorée. L'e-mail dit quoi faire et renvoie vers Crédits IA. Il arrive une fois à chaque épuisement des crédits ; une fois des crédits ajoutés, le prochain épuisement en envoie un autre.

Confiance et sécurité#

• Lecture seule, toujours. Les investigations autonomes s'exécutent avec un ensemble choisi d'outils en lecture seule (requêtes de métriques, de journaux, de traces, d'exceptions et de changements — y compris baseline_anomaly, qui juge une métrique par rapport à sa plage normale apprise pour chaque heure de la semaine). L'IA ne peut rien acquitter, résoudre, alerter ni modifier depuis une investigation.
• Les citations sont générées côté serveur à partir d'appels d'outils réellement exécutés — le modèle ne peut pas fabriquer une citation vers des données qu'il n'a jamais lues.
• Piste d'audit complète. Chaque investigation est enregistrée comme une exécution IA avec une piste d'événements ordonnée (chaque appel LLM et chaque appel d'outil), et chaque appel LLM est mesuré sur la page des Journaux IA (Paramètres du projet → IA → Journaux IA) avec le nombre de jetons et le coût.
• Les secrets sont masqués dans les résultats des outils avant que quoi que ce soit ne soit envoyé au LLM (jetons, identifiants, motifs de clés).
• Les images sont exclues de ce que lit le modèle. Une image intégrée au texte d'un incident ou d'une alerte - la capture d'écran d'un moniteur synthétique dans la description, une image collée dans une note - représente des centaines de kilo-octets de base64 que le modèle ne peut pas lire et qui seraient facturés à chaque appel. Elle est remplacée par une courte note, comme [image omitted: JPEG, 340 KB], et l'activité de l'investigation indique ce qui a été omis. Une description, une cause racine ou une note de plus de 4 000 caractères est coupée de la même façon, et se termine par une note qui indique combien il manque (16 000 caractères dans un brouillon de post-mortem ou de note). Les personnes voient toujours chaque image : seul ce que lit le modèle change.
• Auto-hébergé = aucune sortie vers des tiers. Avec votre propre fournisseur LLM (y compris Ollama en local), la télémétrie ne quitte jamais votre infrastructure.
• Ce qu'il écrit n'agit sur rien. Status200 AI écrit à partir de votre télémétrie, et la télémétrie peut contenir du texte destiné à l'orienter. Où que son Markdown aille - le rapport dans le fil et la note interne, un brouillon de post-mortem, les notes, mises à jour de statut et descriptions d'incident qu'il écrit, et ses réponses dans Slack et Microsoft Teams -, il garde ses titres, listes, tableaux et code, mais une mention Slack comme <!channel> n'y notifie personne, une image s'affiche comme un lien, un lien affiche ses mots et son adresse tels qu'ils sont écrits (une adresse seule reste un lien qui montre où il mène), et une balise HTML s'affiche comme du texte.

Post-mortem automatique#

Indépendamment des investigations, Status200 AI peut rédiger automatiquement un post-mortem quand un incident est résolu. C'est un interrupteur à part — Rédiger un post-mortem quand un incident est résolu, sur la page des paramètres IA des incidents (Incidents → IA → Paramètres) — pour que vous puissiez investiguer sans rédiger, ou rédiger sans investiguer. Il est activé par défaut pour les nouveaux projets ; un projet créé avant ce réglage par défaut garde son réglage. Le brouillon n'écrase jamais une note de post-mortem existante, et n'est pas écrit dans un post-mortem pour lequel Publier sur la page de statut est déjà activé : il y irait sur la page de statut sans relecture, et les abonnés en seraient avertis. Il est rédigé avec le fournisseur LLM du projet, ou celui que choisit la règle de post-mortem correspondante (voir Quel fournisseur LLM une règle utilise), et apparaît dans l'onglet post-mortem de l'incident pour une relecture humaine.

Les Règles de post-mortem, repliées sous Plus de paramètres sur la même page, décident quels incidents résolus reçoivent un brouillon et quels modèles de post-mortem il peut suivre. Sans règle, chaque incident résolu en reçoit un, selon le plan standard de Status200 AI. Avec des règles, la première règle activée qui correspond à l'incident décide, en partant du haut de la liste ; un incident auquel aucune règle ne correspond ne reçoit pas de brouillon, et aucun incident n'en reçoit tant que les règles ne peuvent pas être lues. Voir Choisir quels incidents reçoivent un brouillon, et son modèle.

Analyses — détection proactive#

Les investigations réagissent aux incidents et aux alertes. Les Analyses IA guettent les problèmes avant que quiconque soit alerté : toutes les 15 minutes, des détecteurs déterministes parcourent votre télémétrie à la recherche de soucis qui n'ont pas (encore) déclenché de moniteur. Il n'y a aucune IA dans la boucle de surveillance — les détecteurs sont des contrôles statistiques à seuils fixes, donc la partie toujours active de la fonctionnalité ne consomme aucun jeton et ne peut pas halluciner un constat. Les seuils sont volontairement prudents : une analyse signifie que quelque chose a vraiment bougé, pas qu'un chiffre a frémi.

Ce que surveillent les détecteurs :

Chaque constat devient une analyse dans une boîte de réception discrète — Produits → AI → Analyses dans le tableau de bord. La boîte de réception commence par ce qu'il faut regarder en premier : le constat ouvert qui compte le plus (le plus grave, le plus récemment vu) avec la conclusion de son tri, le service à l'origine de la plupart des constats ouverts quand l'un d'eux se détache, et combien sont nouveaux cette semaine. Les analyses n'alertent jamais personne et n'ouvrent jamais d'incident ; elles attendent que quelqu'un regarde. Un constat récurrent actualise son analyse existante (dernière observation, nombre d'occurrences) au lieu d'empiler des doublons, un constat que vous masquez reste hors de votre boîte de réception pendant 7 jours, et chaque analyse périodique crée au plus 10 nouvelles analyses par projet.

Quand un fournisseur LLM est configuré, chaque nouvelle analyse reçoit aussi une analyse de tri : une investigation IA sourcée en lecture seule — même moteur, même piste d'audit et même budget par exécution que les investigations autonomes — qui évalue la cause racine probable, le rayon d'impact, et la prochaine action qui vaut la peine. Le tri des analyses n'est rattaché à aucun incident ni à aucune alerte, il ne consomme donc jamais le budget de jetons des incidents ni celui des alertes. Le résultat est enregistré sur la page de l'analyse. Sans fournisseur, vous obtenez quand même les analyses ; vous vous passez simplement du tri par l'IA.

En option, Status200 AI peut aussi ouvrir une pull request de correctif pour les types d'analyses aux éléments les plus solides : les exceptions nouvelles et en pic (via le pipeline existant de correction des exceptions) et les régressions de latence des traces (fondées sur les éléments des spans enregistrés sur l'analyse). Les pics de journaux d'erreurs, la dérive de métrique et les régressions après déploiement ne sont jamais corrigés automatiquement. Chaque PR de correctif automatique s'ouvre prête à être relue et exige une relecture humaine — la fusion automatique n'existe pas. Le travail de l'IA en dehors des incidents et des alertes n'a pas de limite quotidienne de tâches de correction, donc le seul plafond que rencontrent ces pull requests est le plafond de PR ouvertes du dépôt, si vous en définissez un.

Les trois paramètres sont activés par défaut pour les nouveaux projets (un projet créé avant ce réglage par défaut garde son réglage), dans Produits → AI → Analyses → Paramètres. Chacun est un interrupteur qui s'enregistre dès que vous le basculez :

1. Surveiller la télémétrie pour détecter les problèmes — active la boucle de surveillance, la boîte de réception et le tri.
2. Ouvrir une pull request de correctif quand une analyse pointe vers votre code — active la création de tâches de correction pour les analyses éligibles. Cela demande la même configuration que le parcours manuel « Fix with AI » : un dépôt connecté via la GitHub App et un fournisseur LLM.
3. Archiver les exceptions attendues — les groupes d'exceptions que le tri classe comme refus attendus (connexions refusées, limites du forfait, scanners qui déclenchent une validation volontaire) sont archivés, pour qu'ils cessent d'apparaître comme non résolus. Les erreurs de l'utilisateur et les problèmes d'infrastructure ne le sont jamais, et vous pouvez ramener un groupe archivé depuis l'onglet Archivé.

Avec Activer l'IA désactivé, les analyses sont toujours trouvées (les détecteurs n'utilisent pas d'IA), mais aucune n'est triée, archivée ni corrigée ; la page des paramètres le dit en haut. Sans fournisseur LLM que Status200 AI puisse utiliser, elle indique que les analyses ne sont pas triées.

Chaque analyse a les boutons Confirmer et Masquer — utilisez-les même quand vous ne donnez pas suite au constat. Vos votes de confirmation et de masquage servent à mesurer la précision de chaque détecteur, et c'est cette précision mesurée qui décide quels types d'analyses méritent davantage d'automatisation avec le temps. Masquer garde aussi le même constat hors de votre boîte de réception pendant les 7 jours suivants.

Prérequis et limites#

• Un fournisseur LLM doit être configuré (propre au projet ou le fournisseur global du cloud).
• Les investigations se déclenchent uniquement sur les incidents et les alertes nouvellement créés — activer les interrupteurs n'investigue pas les signaux passés.
• La vérification baseline_anomaly a besoin d'environ deux semaines d'historique de métriques avant que ses références par heure de la semaine soient fiables ; avant cela, elle signale « insufficient baseline data » au lieu de deviner.
• Sur Status200 Cloud avec le fournisseur global, les investigations consomment des jetons IA mesurés (voir Paramètres du projet → IA → Crédits IA). Apportez votre propre clé de fournisseur pour un usage non mesuré, ou plafonnez ce que l'IA peut dépenser chaque jour avec une limite quotidienne de dépenses IA (Paramètres du projet → IA → Fonctionnalités IA → Plus de paramètres).

Dépannage#

Étapes suivantes#