AI SRE et AI DevOps en pratique : gérer plusieurs serveurs de manière centralisée avec un Agent grâce à PandaSi

Avec PandaSi, confier à un Agent la gestion centralisée de plusieurs serveurs peut commencer par une seule machine d’administration autorisée : lancer PandaPaw et l’Agent sur cette machine, laisser l’Agent accéder aux cibles figurant sur une liste explicite via le SSH, le VPN ou le bastion existants, vérifier l’identité de chaque hôte, mener une inspection en lecture seule par lots et synthétiser les résultats ; en cas de modification, tester d’abord sur un seul hôte, puis avancer par lots après approbation. AI SRE porte sur l’investigation des problèmes de fiabilité, AI DevOps sur la livraison et les changements d’infrastructure ; les deux exigent des preuves vérifiables et des limites de permissions.

PandaSi fournit une entrée de session et d’approbation multi-appareils, PandaPaw se connecte à la machine d’exécution, et les commandes concrètes sont exécutées par l’Agent choisi et ses outils. Avoir terminé l’intégration ne signifie pas avoir obtenu les permissions sur les serveurs de l’entreprise, ni avoir déjà déployé une surveillance 24 h/24, une réception automatique d’alertes ou un système de correction sans surveillance. Ce qui suit s’adresse aux développeurs et aux administrateurs système qui disposent déjà de droits d’exploitation sur les serveurs et souhaitent suivre le travail depuis un téléphone ou un autre ordinateur ; il parcourt l’intégration de la machine d’administration, la vérification en lecture seule de plusieurs machines, la synthèse des résultats et le processus de changement par lots. Les serveurs peuvent aussi être équipés séparément en installation directe, mais le fil conducteur multi-serveurs de cet article adopte la solution avec machine d’administration.

AI SRE et AI DevOps : à quoi l’Agent peut-il aider dans chaque cas ?

Ces deux termes décrivent des périmètres qui se recoupent. Dans cet article, nous les comprenons selon la répartition ci-dessous, sans les considérer comme deux produits à acheter séparément.

Par exemple, si un service de test renvoie 502 juste après une publication : déterminer à quelle couche la requête échoue relève plutôt d’AI SRE ; examiner la configuration de publication à l’origine du problème et préparer la prochaine livraison relève plutôt d’AI DevOps. Une même session Agent peut couvrir les deux types de travail ; l’essentiel réside dans le périmètre de la tâche, les permissions des outils et les critères d’acceptation.

Étape 1 : choisir l’emplacement d’exécution et obtenir l’autorisation de l’entreprise

Avant l’installation, clarifiez trois points : quelle machine peut être connectée, sous quel utilisateur système l’exécution se fait, et quels répertoires et services peuvent être consultés. Il faut aussi confirmer avant l’intégration si l’entreprise autorise l’envoi de journaux ou de code à un modèle externe. Le fait qu’une personne puisse se connecter en SSH ne signifie pas que l’entreprise approuve l’association de son compte personnel à un Agent distant.

Chemin A : exécution directe sur le serveur. Vérifiez d’abord que l’entreprise approuve non seulement le service Agent au niveau utilisateur, mais aussi la mise en réseau des appareils et les modifications de services réseau liées au processus d’installation par défaut ; le script d’installation actuel peut, sur les hôtes systemd concernés, appeler sudo pour enregistrer un service réseau au niveau système. Après avoir obtenu les autorisations correspondantes pour l’installation, l’élévation de privilèges et les changements réseau, et si l’hôte remplit les conditions de prise en charge actuelles, installez PandaPaw sur le serveur. Le répertoire de travail, le shell et les outils choisis ensuite appartiennent à cette machine d’exécution. Ne passez pas à root par défaut sous prétexte que « c’est plus pratique ».

Chemin B : passer par une machine d’administration autorisée vers le serveur. Si le serveur n’autorise pas l’installation, installez PandaPaw sur une machine d’administration approuvée par l’entreprise, et faites-y aussi tourner l’Agent. La machine d’administration doit déjà pouvoir atteindre le serveur cible via le SSH, le VPN ou le bastion reconnus par l’entreprise, avec les permissions du compte correspondant. L’Agent utilise ensuite ce canal existant ; PandaSi ne valide pas l’accès à votre place, ne contourne pas le bastion et n’ouvre pas automatiquement le réseau interne de l’entreprise.

Ce qui prête le plus à confusion entre les deux chemins, c’est la « machine courante ». Dans le scénario avec machine d’administration, si l’Agent exécute pwd par défaut, il voit le répertoire de la machine d’administration ; seules les commandes exécutées explicitement via SSH se produisent sur le serveur cible. La présence d’un nom de serveur dans la session ne remplace pas la vérification d’identité.

Étape 2 : installer PandaPaw sur la machine d’exécution

Depuis PandaSi, entrez dans l’espace de travail, connectez-vous, ouvrez la page Appareils /devices?add=1, choisissez d’ajouter un appareil et copiez la commande d’installation à usage unique générée pour le système d’exploitation courant. L’installation par défaut inclut la configuration d’interconnexion des appareils, peut demander une élévation de privilèges et modifier des services réseau du système ; faites d’abord examiner le contenu de l’installation par l’administrateur de l’entreprise et approuver les permissions correspondantes, puis exécutez la commande sur la machine d’exécution choisie à l’étape précédente. Si seule une intégration au niveau utilisateur est approuvée et non la mise en réseau des appareils, n’exécutez pas directement la commande d’installation par défaut de cet article : confirmez d’abord avec l’administrateur la solution d’installation autorisée. Lorsque l’entrée ou les libellés de marque changent selon les versions, fiez-vous à ce qu’affiche l’espace de travail actuel ; le processus hôte associé est aussi décrit dans Démarrage rapide.

La commande à usage unique contient les identifiants d’appairage de l’appareil. Ne la collez pas dans une conversation, un ticket, un script public ou une capture d’écran, et ne réutilisez pas la même commande pour connecter plusieurs machines ; si elle a déjà servi ou a expiré, récupérez-en une nouvelle depuis la page Appareils.

Si vous n’utilisez pas de commande avec identifiants à usage unique, l’entrée d’installation de base pour macOS / Linux est :

curl -fsSL https://cos.pandanpc.com/pandapaw/install.sh | sh

Cela télécharge et exécute le script d’installation ; respectez d’abord les procédures de l’entreprise en matière d’installation de logiciels et de revue de scripts. Cette fois, la vérification s’appuie uniquement sur la documentation et le code source actuels ; l’installation et l’appairage n’ont pas été testés sur un hôte vierge. L’accès au point de téléchargement public du script d’installation a été confirmé. Pour la compatibilité des plateformes hôtes et les détails d’installation, voir Guide de l’hôte PandaPaw.

Si l’autorisation de compte de l’installation de base n’est pas terminée, poursuivez sur la machine d’exécution :

pandapaw login

Suivez le processus d’autorisation de l’appareil affiché pour terminer l’appairage, puis vérifiez :

pandapaw status

Si la commande est introuvable, ouvrez d’abord un nouveau terminal pour que le shell recharge le PATH. N’installez pas de nouveau ni ne forcez une reconnexion à répétition « pour voir » ; distinguez d’abord trois cas : binaire introuvable, compte non associé, service en arrière-plan anormal.

Étape 3 : choisir la machine, le moteur et le répertoire de travail

Ouvrez l’espace de travail /agent, choisissez la machine d’exécution qui vient d’être connectée, puis sélectionnez Claude Code, Codex ou PandaCode, ainsi qu’un répertoire de travail autorisé. Validez d’abord avec un répertoire de test, pour ne pas arriver directement dans un répertoire de configuration de production.

L’appairage de l’appareil et la connexion au modèle sont deux choses distinctes. La connexion à PandaPaw indique que l’hôte a établi une liaison avec le compte de l’espace de travail ; le moteur choisi a encore besoin d’une autorisation de modèle, d’un abonnement ou d’une configuration API utilisables. Si l’appareil apparaît en ligne mais que le modèle ne répond pas, consultez d’abord les indications de connexion du moteur, le quota et la configuration du modèle, au lieu de réinstaller PandaPaw.

Vérifiez aussi les réglages de permissions des outils du moteur. Écrire « ne modifie rien pour l’instant » dans le chat est une contrainte de tâche ; cela ne remplace ni les permissions du système d’exploitation ni le mécanisme d’approbation du moteur. Si une approbation doit être donnée à chaque fois, configurez le mode de permissions correspondant et ne partez pas du principe qu’une carte de confirmation s’affichera automatiquement pour chaque commande.

Étape 4 : commencer par une demande en lecture seule pour vérifier l’identité

Pour la première tâche, n’écrivez pas « répare le serveur » ; envoyez plutôt :

Effectue uniquement une vérification d’identité, sans modifier de fichier ni de service. Indique le nom d’hôte actuel, l’utilisateur système et le répertoire de travail absolu, puis liste les noms de fichiers au premier niveau du répertoire. Ne lis pas le fichier .env, les clés privées ni d’autres identifiants. Si l’accès au serveur cible est nécessaire, explique d’abord la différence entre la machine d’exécution actuelle et la cible, puis attends ma vérification avant de continuer.

Les commandes de vérification d’identité utilisables sous Linux / macOS sont :

hostname
id -un
pwd

Comparez chaque valeur retournée avec ce qui est attendu : s’agit-il de la même machine d’exécution, du compte autorisé et du bon répertoire de projet ? Un nom de répertoire similaire, un appareil en ligne ou un code de sortie de commande à 0 ne prouvent pas à eux seuls que l’intégration est correcte.

Dans le scénario avec machine d’administration, vérifiez aussi les deux extrémités séparément. L’exemple ci-dessous montre uniquement l’utilisation d’un alias SSH déjà configuré par l’entreprise ; company-test-server est un exemple à remplacer par la cible confirmée par l’administrateur :

ssh company-test-server 'hostname; id -un; pwd'

Ne désactivez pas la vérification de la clé d’hôte pour résoudre l’invite de première connexion, et ne collez pas de mot de passe SSH ni de clé privée dans l’Agent. Le pwd distant peut correspondre au répertoire personnel du compte ; n’en déduisez pas que le projet a été choisi. Les commandes suivantes doivent indiquer explicitement le chemin absolu du projet distant.

Le critère de réussite est le suivant : la réponse correspond à l’hôte, à l’identité et au répertoire corrects ; vous pouvez voir ce qui a été exécuté ; les demandes de permission apparaissent comme prévu dans le mode de permissions courant. Ensuite, reconnectez-vous à la même session depuis un téléphone ou un autre client et vérifiez si l’historique est restauré. Cela se rapproche davantage d’un usage réel que la simple présence d’un point vert « en ligne ».

Étape 5 : établir d’abord un inventaire des serveurs, puis lancer une inspection en lecture seule par lots

Un Agent sur une machine d’administration peut appeler le SSH existant pour accéder successivement à plusieurs serveurs de l’inventaire ; PandaSi vous permet de suivre ces opérations d’outils et leurs résultats dans la même session. Ici, la « gestion centralisée » vient d’un même point d’entrée d’exécution, d’un inventaire explicite et d’un rapport unifié ; elle ne signifie pas que le produit intègre une découverte automatique des actifs serveurs, une répartition automatique des tâches entre connexions ou une interface de contrôle groupé en un clic. La machine d’administration doit déjà être autorisée pour chaque cible ; le fait de pouvoir accéder à une machine ne permet pas de supposer que l’on peut accéder aux autres machines du même sous-réseau.

Verrouiller les cibles avec des alias et des groupes d’environnement

Demandez à l’administrateur de tenir un inventaire sans identifiants. Tous les noms ci-dessous sont des exemples fictifs ; l’inventaire réel doit être stocké à un emplacement approuvé par l’entreprise, sans mot de passe, clé privée ni commande d’appareil à usage unique.

Un alias SSH est un nom figurant dans la configuration SSH existante de la machine d’administration, pas un nom d’appareil PandaSi. L’administrateur doit vérifier la cible, le compte, le port et le relais d’accès nécessaire correspondant à l’alias ; ne confirmez pas qu’une machine est de test uniquement parce que son nom contient test. OpenSSH prend en charge la correspondance de configuration par entrée Host, et une commande distante spécifiée en ligne de commande s’exécute sur l’hôte cible ; voir le Manuel de configuration du client SSH et le Manuel de la commande SSH.

Si PandaPaw est installé séparément sur chaque serveur, vous pouvez aussi choisir la machine d’exécution correspondante dans l’espace de travail et agir machine par machine ; mais n’interprétez pas « plusieurs machines en ligne » comme un seul Agent qui planifie automatiquement toutes les connexions. La suite de cet article adopte uniformément le scénario d’une machine d’administration passant par le SSH existant, afin d’éviter de mélanger deux emplacements d’exécution dans un même rapport.

Vérifier d’abord en série, puis limiter les éléments de l’inspection

Pour la première fois, effectuez d’abord une vérification d’identité machine par machine selon l’inventaire, sans lire les configurations applicatives ni les journaux complets. L’exemple série ci-dessous pour Bash sur la machine d’administration ne liste que les deux machines de test autorisées pour ce cycle ; il n’effectue pas d’identification automatique de l’environnement et ne remplace pas la vérification humaine de l’identité attendue.

for target in test-web-01 test-worker-01; do
  printf '\nTARGET %s\n' "$target"
  if ssh -T -o BatchMode=yes -o ConnectTimeout=5 "$target" \
    'hostname && id -un && pwd'; then
    printf 'IDENTITY_COMMAND_COMPLETED %s\n' "$target"
  else
    result=$?
    printf 'IDENTITY_COMMAND_FAILED %s exit=%s\n' "$target" "$result" >&2
  fi
done

Ces commandes servent uniquement à illustrer l’organisation ; cet article ne les a pas exécutées sur ces deux hôtes d’exemple. BatchMode=yes évite d’attendre une saisie interactive en cas d’échec d’authentification ; ConnectTimeout=5 limite la phase d’établissement de la connexion, et non la durée totale de la commande distante. La durée totale d’exécution doit être définie séparément par l’outil ou l’exécuteur de tâches autorisé. Ne désactivez pas la vérification de la clé d’hôte pour exécuter en lot ; pour un bastion nécessitant une MFA interactive, utilisez le processus d’accès approuvé par l’entreprise et n’appliquez pas cet exemple non interactif.

Une fois les commandes terminées, comparez d’abord machine par machine le nom d’hôte et le compte attendus dans l’inventaire, puis vérifiez le chemin de projet distant autorisé. Le pwd affiché ci-dessus n’est généralement que le répertoire de connexion distant ; il ne prouve pas que le chemin du projet est correct. Un code de sortie de commande à 0 indique seulement que ces commandes se sont terminées ; cela ne signifie ni que l’identité de l’hôte correspond, ni que le service fonctionne bien. Si l’identité d’une machine ne correspond pas, marquez cette cible comme bloquée et ne continuez pas à lire ses données métier ; si un doute commun apparaît sur un même environnement ou canal d’accès, suspendez la vérification de tout le lot.

Après validation de la vérification d’identité, demandez à l’Agent d’exécuter sur les machines de test de ce cycle le même ensemble de contrôles en lecture seule autorisés : état des services désignés, ports d’écoute attendus, espace disque restant, résumé d’erreurs expurgées sur une fenêtre temporelle donnée, et une requête de santé approuvée. Ne transformez pas l’« inspection » en installation de sondes, lecture récursive de tous les répertoires ou correction automatique. Les commandes de contrôle diffèrent selon les systèmes, les gestionnaires de services et les applications ; complétez-les selon l’inventaire, sans appliquer de force un même jeu de commandes à tous les hôtes.

Utiliser une invite pour expliciter les limites d’exécution

Tu t’exécutes sur la machine d’administration. Accède uniquement à test-web-01 et test-worker-01 du groupe test selon l’inventaire de serveurs approuvé ; ne scanne pas de nouvelles adresses et n’accède pas au groupe production. Vérifie d’abord en série le nom d’hôte, l’utilisateur et le chemin absolu du projet distant de chaque machine ; si un élément ne correspond pas à l’inventaire, bloque cette cible. Une fois la vérification passée, contrôle uniquement l’état des services, les ports, le disque et la requête de santé explicitement autorisés par l’inventaire ; pour les journaux, ne prends que des extraits expurgés sur la fenêtre temporelle indiquée. Pour cette première fois, tout se fait en série : ne modifie pas de configuration, ne redémarre pas, n’installe pas de dépendances et n’élève pas automatiquement les privilèges. En cas d’échec de connexion à une machine, conserve l’erreur et poursuis les contrôles indépendants en lecture seule des autres cibles déjà vérifiées ; si tu constates une anomalie d’appartenance à un environnement ou de canal d’accès commun, suspends tout le lot. Pour chaque machine, consigne séparément l’heure et le fuseau horaire, la commande, l’état de sortie, les preuves clés et les éléments non terminés, puis fais une synthèse par serveur. Pour toute correction, fournis une recommandation séparée sans l’exécuter.

Ceci est une contrainte de tâche ; elle doit aussi s’accompagner d’un compte en lecture seule, de l’approbation des outils du moteur et de restrictions d’accès réseau. Écrire « interdiction de modifier » dans l’invite ne transforme pas automatiquement un compte inscriptible en compte en lecture seule.

Limiter la concurrence et rattacher les échecs à la bonne cible

Pour la première inspection, le mode série facilite la vérification ; si les cibles sont nombreuses, vous pouvez fixer une petite limite de concurrence dans le mode d’exécution d’outils autorisé par l’entreprise, par exemple deux machines contrôlées au maximum en même temps. Ce « deux » est ici un budget d’opération donné en exemple, et non une limite produit ou une garantie de performance de PandaSi. Si l’Agent ou l’outil choisi ne peut pas limiter la concurrence de façon fiable, continuez en série, sans remplacer cela par des tâches d’arrière-plan illimitées et improvisées.

Chaque contrôle de machine doit avoir un délai d’expiration et un enregistrement de résultat indépendants ; l’échec d’une cible ne doit pas déclencher le redémarrage, la réinstallation ou une répétition infinie de tout le lot sur les autres machines. Consignez séparément le délai de connexion dépassé, l’identité non concordante, les permissions insuffisantes et l’échec d’une commande de contrôle, sans tout regrouper sous « hors ligne ». Si l’erreur provient d’un bastion partagé, d’une source d’authentification ou d’une appartenance d’environnement incertaine, arrêtez-vous pour examiner la cause commune au lieu d’augmenter encore la concurrence.

Le tableau de synthèse doit lister, machine par machine, si l’identité correspond, quels contrôles ont réellement été exécutés, les preuves clés et les éléments inconnus. Ci-dessous, seul le format d’enregistrement est présenté ; les textes du tableau sont des consignes de remplissage, pas des résultats mesurés :

Le rapport doit indiquer « combien de machines étaient prévues, combien ont été terminées, combien ont échoué, combien ont été ignorées », et fournir les preuves pour chaque cible. En l’absence de résultat, ne considérez pas la santé comme acquise ; un code de sortie final à 0 pour une commande par lots ne doit pas non plus masquer l’échec d’une machine en cours de route.

Étape 6 : traiter d’abord l’enquête et le rétablissement d’un 502 sur un service de test

L’exemple ci-dessous est pédagogique : il ne s’agit pas d’un incident réellement mesuré dans cet article, ni d’un ensemble de commandes de correction à recopier sur tous les serveurs. Supposons qu’un service de test autorisé renvoie 502 après une publication et que vous connaissiez le domaine de test, le nom du service et le répertoire du projet.

Délimiter d’abord le périmètre de l’enquête

Vous pouvez formuler la tâche ainsi :

Enquête sur le 502 survenu après la publication du service de test. Vérifie d’abord l’hôte cible, l’utilisateur et le répertoire, puis contrôle en lecture seule le dernier enregistrement de publication, l’état des services concernés, les ports d’écoute et les journaux du proxy et de l’application sur la fenêtre temporelle indiquée. Ne redémarre pas, ne modifie pas de configuration, n’installe pas de dépendances et n’accède pas à d’autres environnements. Ne renvoie que des extraits expurgés liés à cet incident, en listant les preuves, les causes possibles et les informations manquantes.

Donnez d’abord la fenêtre temporelle et des sources de journaux explicites, pour éviter que l’Agent parcoure toute la machine de façon récursive. La lecture seule peut aussi divulguer des données : les jetons, informations client et corps de requêtes présents dans les journaux doivent encore être filtrés avant d’entrer dans le contexte du modèle, et non envoyés puis « oubliés » par le modèle.

Un 502 indique que le proxy n’a pas obtenu de réponse utilisable en amont, mais le seul code d’état ne permet pas de savoir s’il s’agit d’un processus arrêté, d’un port incompatible, d’une dépendance anormale ou d’un problème de connexion. Demandez à l’Agent d’aligner l’adresse amont du proxy, l’écoute réelle et les journaux sur la même période ; pour les journaux répartis sur plusieurs machines, unifiez d’abord les fuseaux horaires. Ne considérez pas « machine en ligne » comme « application en bonne santé », et ne concluez pas qu’aucune erreur ne s’est produite simplement parce qu’aucun journal ne correspond.

Exiger une proposition de correction vérifiable

Si les preuves étayent l’hypothèse « le port amont dans la configuration de publication ne correspond pas à l’écoute réelle », demandez à l’Agent de soumettre le fichier précis et la différence minimale, les commandes envisagées, le service de test concerné, la méthode de contrôle de configuration et les conditions de retour arrière. Il s’agit encore d’un exemple conditionnel ; si les preuves ne l’étayent pas, poursuivez l’enquête.

L’objet de l’approbation doit être un changement précis, et non « je te laisse tout gérer ». Par exemple, approuver la modification de la configuration du proxy de test désigné et le rechargement de ce proxy de test après réussite du contrôle de configuration ; il ne faut pas en profiter pour mettre à jour des dépendances, nettoyer la base de données, modifier la configuration de production ou redémarrer toute la machine. Les commandes réelles doivent être déterminées selon le gestionnaire de processus et les règles de déploiement utilisés.

Vérifier le parcours utilisateur après l’exécution

Après approbation et exécution, la recette doit au minimum couvrir : la réussite du contrôle de configuration, la conformité attendue des processus et ports concernés, le bon fonctionnement de l’interface de santé, et le rétablissement d’une requête de test réelle depuis un client indépendant via l’entrée d’origine. Si l’interface de santé renvoie 200 mais que le routage métier, l’authentification ou les requêtes à la base de données échouent encore, ne concluez pas que « le problème est résolu ».

Enfin, demandez à l’Agent de synthétiser les commandes exécutées, les modifications réelles, les résultats de vérification et les risques restants ; pour les éléments non vérifiés, indiquez explicitement qu’ils sont inconnus. Renvoyez la cause confirmée et les mesures de prévention des récidives au système d’enregistrement de l’entreprise. La phase d’enquête fait appel à l’assistance AI SRE ; intégrer ensuite la correction dans le dépôt de configuration et le processus de publication étend le travail à AI DevOps.

Étape 7 : après validation sur une machine, modifier les autres serveurs par lots

Les autorisations d’inspection par lots et de modification par lots doivent être séparées. Constater que plusieurs services n’ont pas la même version ne signifie pas qu’il faut tous les mettre à niveau immédiatement ; des services du même nom peuvent aussi remplir des rôles différents ou utiliser des configurations différentes. Vérifiez d’abord si les écarts sont attendus, puis proposez un plan de changement listant chaque cible.

Pour le premier lot, choisissez une seule machine de test clairement identifiée. Le plan doit fixer l’alias cible, l’identité d’hôte vérifiée, la version ou configuration d’origine, la différence à appliquer, l’impact attendu, la méthode de contrôle, les étapes de retour arrière et les conditions d’arrêt. Après approbation, exécutez sur cette seule machine et attendez la recette de l’interface de santé et du parcours utilisateur réel ; sans preuve de rétablissement, ne marquez pas le statut comme réussi et ne passez pas au lot suivant.

Après validation de l’essai, définissez explicitement la liste des cibles du lot suivant, la taille du lot et la limite de concurrence ; n’utilisez pas une portée implicite comme « toutes les machines restantes », qui changerait avec l’inventaire. À la fin de chaque lot, vérifiez la version réelle et les résultats des requêtes, puis consignez les cibles réussies, en échec et non exécutées. En cas d’identité non concordante, d’échec du contrôle de configuration, de dégradation des requêtes métier ou d’échec du retour arrière, arrêtez les lots suivants, conservez les preuves et transmettez-les au responsable ; ne considérez pas une approbation de test comme une approbation de production.

Le retour arrière doit aussi être défini machine par machine. Pour un changement de configuration, la configuration précédente peut être restaurée selon le mode approuvé ; lorsqu’il existe une migration de base de données, une écriture de données ou des effets de bord sur des systèmes externes, ne partez pas du principe qu’un « retour à l’ancienne version » annulera l’impact : le responsable doit d’abord déterminer la solution de rétablissement. Ne lancez le retour arrière que sur les cibles réellement modifiées qui doivent être restaurées, et n’exécutez pas une commande inverse indifférenciée sur tout le groupe de machines.

Vous pouvez formuler la tâche suivante ainsi :

À partir des preuves de l’inspection machine par machine de ce cycle, propose uniquement un plan de correction pour test-web-01, sans l’exécuter. Liste l’identité d’hôte vérifiée, les différences précises, les commandes complètes, l’impact, les étapes de retour arrière, la requête de recette et les conditions d’arrêt. L’exécution ne pourra avoir lieu qu’après approbation explicite pour cette machine ; une fois terminé, fournis des preuves réelles et attends l’autorisation pour le lot de cibles suivant. Les machines non approuvées restent non exécutées. Le groupe production ne fait pas partie de ce périmètre et ne peut pas hériter de l’approbation de test.

Lorsque les environnements de test et de production doivent tous deux être traités, la production suit séparément le processus de changement de l’entreprise. Un point d’entrée d’administration unifié n’élimine ni l’isolation des environnements, ni les fenêtres de maintenance, ni l’approbation de publication, ni les exigences d’audit.

Après une déconnexion du téléphone, vérifier d’abord l’état de la tâche

Fermer le client, mettre le téléphone en arrière-plan ou perdre le réseau ne doit pas être interprété comme l’arrêt de la commande distante. Le processus sur la machine d’exécution peut continuer de tourner ; il peut aussi échouer parce que l’hôte s’est déconnecté, que le moteur s’est arrêté ou que le canal distant est limité. En revenant dans la session d’origine, consultez d’abord les résultats des outils, puis vérifiez le processus, les artefacts et l’état des services, afin d’éviter de relancer une installation, une publication ou une migration.

La chaîne de commande distante peut produire un « état de sortie non retourné » : un délai d’expiration au niveau de la connexion ne signifie pas que la commande n’a pas commencé. Pour les tâches longues, définissez explicitement dans le canal d’exécution de l’entreprise le délai d’expiration, l’enregistrement d’état et le mode d’annulation, en particulier lorsqu’il y a plusieurs sauts SSH. Cet article ne considère pas la valeur de délai d’expiration d’une version de canal comme une règle universelle pour tous les outils SSH.

Lorsqu’il faut arrêter, utilisez une opération d’arrêt explicite et vérifiez l’état d’exécution distant ; face à un changement non idempotent dont l’état est incertain, reprenez d’abord la main manuellement pour confirmer. Ne vous fiez pas à des clics répétés ou à l’envoi de la même instruction pour déterminer si l’opération précédente a réussi.

Quel rapport entre la mise en réseau des appareils de l’entreprise et du domicile, et cet article ?

Cet article suppose que le canal d’accès autorisé entre la machine d’administration et chaque serveur existe déjà ; l’accent est mis sur la manière dont l’Agent organise son travail par cible. La façon dont plusieurs appareils de l’entreprise et du domicile rejoignent le réseau, s’accèdent mutuellement et traitent les frontières réseau constitue une autre tâche d’intégration, qui n’est pas mélangée ici ; une mise en réseau réussie ne signifie pas non plus que l’on a le droit d’exploiter tous les appareils concernés. Pour comprendre l’intégration des appareils, consultez d’abord la Documentation sur l’interconnexion des appareils existante, et respectez le processus d’approbation réseau de l’entreprise.

Limites des données de l’entreprise, des modèles et du relais

« L’outil s’exécute sur la machine locale » décrit l’emplacement d’exécution et ne garantit pas que les données quittent un jour l’entreprise. Les messages de session et les approbations passent par le canal de communication du produit ; les journaux, le code et les sorties d’outils fournis à l’Agent peuvent aussi entrer dans les requêtes adressées au fournisseur de modèle choisi. Avant l’intégration, vérifiez les modèles approuvés par l’entreprise, les conventions de traitement des données, la conservation des journaux et les politiques d’accès.

Conservez les processus existants de gestion des clés et d’audit ; lisez les identifiants depuis l’infrastructure d’identifiants autorisée sur la machine d’exécution, ne les collez pas dans une conversation ni dans un dépôt de code. Limitez le compte d’exécution et la portée réseau accessible, et accordez les permissions sur les journaux et répertoires au besoin. En cas de départ d’un collaborateur, de mise au rebut d’un appareil ou de changement de permissions, traitez en même temps l’autorisation de l’appareil dans l’espace de travail, le compte de la machine d’exécution et l’accès aux serveurs cibles ; supprimer un client ne revient pas à révoquer toutes les permissions d’exécution.

FAQ

PandaSi peut-il assurer une astreinte automatique, recevoir des alertes et corriger la production ?

Cet article traite des sessions distantes, des opérations autorisées et du suivi humain. La surveillance 24 h/24, l’intégration des alertes, le déclenchement automatique et la correction sans surveillance nécessitent des systèmes de supervision, des déclencheurs, des runbooks et une gouvernance des permissions supplémentaires ; la réussite de l’intégration ne permet pas d’en déduire que ces capacités sont déjà en place.

L’entreprise n’autorise pas l’installation de logiciels sur ses serveurs : est-ce quand même utilisable ?

Vous pouvez envisager la solution d’une machine d’administration autorisée, à condition que cette machine dispose déjà des permissions réseau et d’identité légitimes pour accéder aux cibles. Si l’entreprise interdit aussi ce type d’intégration d’Agent externe, passez d’abord par l’approbation, au lieu de chercher une autre route de connexion dissimulée.

Faut-il ouvrir un port SSH public sur les serveurs ?

Les connexions de session de PandaPaw sont établies par des connexions sortantes initiées des deux côtés ; il n’est généralement pas nécessaire d’ajouter un port entrant public pour l’intégration du client. Toutefois, la machine d’administration doit toujours disposer d’un canal d’accès reconnu par l’entreprise vers le serveur cible ; si les connexions sortantes sont restreintes, la configuration doit être faite par l’administrateur réseau, sans désactiver vous-même les protections.

Faut-il installer PandaPaw sur chaque serveur ?

La solution avec machine d’administration décrite dans cet article n’exige pas d’installer PandaPaw sur chaque cible SSH, mais la machine d’administration doit disposer d’un canal réseau autorisé et d’un compte distant. Dans la solution d’installation directe, l’Agent s’exécute sur l’hôte correspondant et chaque hôte est intégré séparément ; ne confondez pas les deux avec une même capacité de contrôle groupé automatique.

Si l’inspection d’une machine échoue, les autres machines peuvent-elles continuer ?

Pour des contrôles en lecture seule indépendants et dont l’identité a été vérifiée, vous pouvez conserver les preuves d’échec de cette cible et poursuivre avec les autres cibles ; s’il s’agit d’une panne d’accès commune ou d’un doute sur l’appartenance à un environnement, suspendez tout le lot. En phase de changement, appliquez les conditions d’arrêt approuvées ; la règle « l’inspection peut continuer » ne s’applique pas.

Que valider en premier après l’intégration ?

Validez d’abord la machine d’administration, la réponse du modèle et la restauration de la session, puis vérifiez machine par machine l’identité de la cible, le répertoire et les permissions selon l’inventaire, réalisez l’inspection en lecture seule et la synthèse des résultats, et enfin faites passer sur un service de test l’approbation, la recette par requête réelle et le processus de changement par lots ultérieur. La valeur de l’intégration est de permettre un suivi continu des tâches autorisées ; l’opportunité d’étendre à davantage de services doit être décidée à partir des preuves de cette recette.

Sources et périmètre de vérification

La première version de cet article a été vérifiée le 31 octobre 2026 par rapport au démarrage rapide du projet, à la documentation de l’hôte PandaPaw, à la logique de génération des commandes d’installation d’appareil et au point de téléchargement public du script d’installation ; le 1er novembre, le processus d’opération multi-serveurs a été complété, et la configuration et la sémantique des paramètres SSH ont été vérifiées par rapport au manuel officiel OpenSSH. Cette fois, la vérification s’appuie uniquement sur la documentation et le code source actuels ; l’installation et l’appairage n’ont pas été testés sur un hôte vierge, et l’inspection, les changements par lots ou l’exemple de 502 de cet article n’ont pas été exécutés dans un véritable environnement multi-serveurs ; les réseaux, approbations de moteur et conformités des données de chaque entreprise doivent être validés dans leur propre environnement de test. Les illustrations sont des schémas conceptuels ou de processus générés par IA, et non des captures d’interface.