Runbook automatisé : remédiation des serveurs par suggestion de l'IA et exécution semi-automatique via SSH

Lorsqu’un serveur de production devient « bizarre », il ne reste souvent, dans la pratique, qu’une marge étroite : stabiliser rapidement, documenter proprement, sans introduire de nouveaux risques. C’est précisément là qu’intervient un Runbook automatisé : il traduit des scénarios d’incident récurrents en étapes de vérification et mesures traçables. La nouveauté est qu’un module IA (LLM, Large Language Model – un modèle de langage qui résume des textes et génère des propositions) produit à partir des logs, métriques et du contexte une proposition IA. L’exécution reste toutefois semi-automatique : un opérateur confirme les étapes, et ce n’est qu’ensuite qu’elles sont mises en œuvre de manière contrôlée via SSH (Secure Shell – connexion distante chiffrée).

Cet article présente une architecture pragmatique et un modèle d’exploitation qui fonctionnent au sein des équipes d’administration : avec des lignes directrices de sécurité claires, des listes de contrôle, des pièges habituels, des étapes de vérification, des modèles de mise en œuvre et une stratégie de repli robuste. L’accent n’est pas sur « l’IA peut tout », mais sur : Comment utilisons‑nous l’IA de manière pertinente, sans affaiblir l’exploitation ?

Runbook automatisé : pourquoi semi-automatique — et pas entièrement automatique ?

La remédiation entièrement automatique est séduisante, mais échoue souvent dans la pratique pour deux raisons : absence de contexte et effets secondaires difficiles à prévoir. Un LLM peut formuler des étapes plausibles, mais il n’a pas de « vérité » intrinsèque ; il génère du texte sur la base de schémas. Dans la remédiation de serveurs, les effets secondaires sont concrets : redémarrages, modifications de configuration, mises à jour de paquets, reconstructions de base de données ou règles de pare-feu peuvent causer des dommages secondaires.

La semi-automatisation est donc un compromis stable :

• Chemin de diagnostic rapide : l’IA propose des vérifications structurées (p. ex. « disque plein ? », « OOM-Killer ? », « latence DNS ? »), incluant les sorties attendues.
• L’opérateur comme gardien : une personne évalue le risque, le moment, les dépendances et ne confirme que ce qui correspond à la fenêtre de changement et à la criticité du service.
• Exécution déterministe : le moteur de runbook exécute des étapes prédéfinies et versionnées — pas n’importe quel texte shell généré par l’IA.

L’objectif est moins l’admin héros, plus une exploitation répétable : mêmes symptômes, mêmes vérifications, mêmes logs, mêmes traces d’audit.

Architecture de référence : proposition IA, moteur de runbook et exécution SSH

Pour la plupart des environnements, une architecture avec séparation claire entre « proposition » et « exécution » s’avère efficace :

• Sources de signal : monitoring (métriques), plateforme de logs, tracing, CMDB/asset, ticketing/ITSM. Il est important d’avoir un identifiant d’hôte/service unique.
• Collecteur de contexte : un job collecte les extraits pertinents (p. ex. les 10 dernières minutes de logs, les alarmes actuelles, les derniers déploiements, les maintenances connues). C’est ici que se joue la capacité de l’IA à produire des propositions « pertinentes ».
• Assistant IA (module de proposition): Génère un plan de diagnostic et d’actions, y compris une évaluation des risques. Sortie idéalement au format JSON structuré (pas seulement du texte libre).
• Runbook-Katalog: Runbooks versionnés (Git), avec actions publiées, paramètres, préconditions et définition de rollback.
• Runbook-Executor: Exécute des actions via SSH, écrit des logs, impose des timeouts, collecte les sorties, définit les codes de sortie et s’arrête en cas d’écarts.
• Gate & Audit: Principe des quatre yeux, Change-ID, approbation, journalisation (qui a confirmé quoi et quand ?).

Important est la répartition des rôles : le LLM recommande, l’Executor agit. Ainsi vous évitez que des sorties textuelles « créatives » soient directement interprétées comme des commandes.

Modèle d’exploitation SSH : bastion, clés, droits

SSH est techniquement simple, mais opérationnellement plein de détails. Un modèle robuste utilise un Bastion Host (serveur de saut comme point d’entrée contrôlé), des identifiants éphémères (p. ex. clés/certificats limités dans le temps) et le principe du moindre privilège (seulement les droits nécessaires au runbook). En pratique, cela signifie :

• L’Executor se connecte uniquement à la bastion, puis de là aux hôtes cibles (segmentation réseau, point d’audit central).
• Sur les hôtes cibles existe un utilisateur dédié « runbook » avec des droits sudo restreints (seulement des commandes définies).
• Chaque action est attribuée à un ticket/incident (chaîne de changement et d’audit).

Quels types d’incidents se prêtent à la remédiation serveur via runbook ?

Tout n’est pas adapté aux runbooks. De bons candidats sont des problèmes récurrents et observables avec des points de contrôle clairs :

• Espace disque saturé : rotation des logs/journal, répertoires temporaires, dumps de crash, anciens artefacts.
• Service bloqué : échec du health-check, processus vivant mais non réactif (p. ex. deadlocks, épuisement de threads).
• OOM/pression mémoire : Out-of-Memory-Killer, swap thrashing, indicateurs de fuite.
• Erreurs DNS/réseau : problèmes de résolveur, route incorrecte, MTU/fragmentation.
• Certificats expirés : problèmes de chaîne, truststore incorrect, certificats client arrivant à expiration.

Les mauvais candidats sont des cas « uniques », des modifications avec un rayon d’impact élevé (p. ex. mise à niveau du noyau pendant l’incident) ou des symptômes peu clairs sans télémétrie fiable.

Prérequis : télémétrie, identités, conception des runbooks

Pour que la proposition de l’IA soit plus qu’une hypothèse, il faut des bases solides :

1) Télémétrie avec corrélation

Les logs, métriques et alertes doivent converger. « Corrélation » signifie en production : hostname, instance-ID, nom du service, version de déploiement et fenêtre temporelle sont cohérents. Sans cela, l’IA proposera par défaut un « redémarrage », faute de reconnaître une cause différenciée.

2) Actions de runbook déterministes

Un runbook est plus qu’un texte de wiki. Pour une exécution semi-automatique, vous avez besoin d’étapes idempotentes (exécutables plusieurs fois sans dommage) et de préconditions (conditions préalables), qui empêchent qu’une étape s’exécute dans un mauvais contexte. Exemple : « démarrer seulement si l’espace libre < 5% et que /var est la cause ».

3) Règles de changement et d’approbation

Même en incident : les modifications doivent être traçables. Standard minimal : Change-ID, approbation (au moins 1 opérateur), et un log contenant l’input, l’output, le code de sortie et l’horodatage pour chaque étape.

Intégrer correctement la proposition de l’IA : sortie comme plan, pas comme shell

Lorsqu’un LLM génère des commandes shell libres, vous encourez deux risques : une syntaxe non vérifiée et une intention non contrôlée. Mieux : le LLM fournit un plan, que votre moteur de runbook valide par rapport à un catalogue d’actions autorisées.

Un format pratique est JSON, que le moteur valide strictement (validation par schéma) :

{
  "incident_id": "INC-2026-071",
  "target": {
    "hostname": "app-17",
    "environment": "prod"
  },
  "hypotheses": [
    {
      "name": "disk_pressure_var",
      "evidence": ["/var usage high", "journald size increased"],
      "confidence": 0.72
    }
  ],
  "proposed_runbook": {
    "id": "Linux-disk-remediation",
    "steps": [
      {"action": "collect_disk_state", "params": {"paths": ["/", "/var"]}},
      {"action": "journald_vacuum", "params": {"retain": "1G"}},
      {"action": "logrotate_force", "params": {"dry_run": true}}
    ]
  },
  "risk_notes": [
    "Vacuum kann Debug-Logs entfernen; vorher Incident-Logs sichern.",
    "logrotate nur nach Review ohne dry_run ausführen."
  ]
}

Important: Le moteur n’accepte que des Runbook-IDs et des Actions qui existent dans le catalogue. Tout le reste est rejeté. Ainsi l’IA reste un système d’assistance, pas un Remote-Root.

Mise en œuvre : exécuteur de runbook via SSH avec revue, journalisation et règles d’arrêt

Un exécuteur n’a pas besoin d’être complexe, mais doit être rigoureux. Trois caractéristiques sont déterminantes en exploitation :

• Traçabilité : Chaque étape écrit des logs standardisés (début/fin, cible, commande, hash de sortie, code de sortie).
• Limites de sécurité : timeouts, commandes autorisées, cibles verrouillées (p. ex. contrôleur de domaine, contrôleur de stockage), limites de débit.
• Règles d’arrêt : En cas d’écart, on n’essaie pas de poursuivre, mais on arrête et on escalade.

Exemple : exécution SSH via bastion avec droits sudo restreints

Dans l’exemple suivant, l’exécuteur utilise un utilisateur dédié et impose une exécution non interactive. Ce n’est pas un produit complet, mais un modèle concret pour vos propres runbooks.

#!/usr/bin/env bash
set -euo pipefail

BASTION="bastion01"
TARGET="$1"               # z.B. app-17
RUNBOOK_ID="$2"           # z.B. Linux-disk-remediation
INCIDENT_ID="$3"          # z.B. INC-2026-071

SSH_OPTS=(
  -o BatchMode=yes
  -o StrictHostKeyChecking=yes
  -o ConnectTimeout=8
  -o ServerAliveInterval=10
  -o ServerAliveCountMax=3
  -J "runbook@${BASTION}"
)

log(){
  printf '%s %s %sn' "$(date -Is)" "${INCIDENT_ID}" "$*"
}

run(){
  local cmd="$1"
  log "STEP cmd=${cmd}"
  ssh "${SSH_OPTS[@]}" "runbook@${TARGET}" -- "${cmd}"
  log "STEP exit=$?"
}

log "START runbook=${RUNBOOK_ID} target=${TARGET}"

# Beispiel-Schritte (in der Praxis aus einem signierten Katalog geladen)
run "sudo -n /usr/local/sbin/collect_disk_state"
run "sudo -n /usr/local/sbin/journald_vacuum --retain=1G"

log "DONE runbook=${RUNBOOK_ID} target=${TARGET}"

Pourquoi ces détails sont importants : BatchMode empêche les invites de mot de passe, StrictHostKeyChecking réduit les risques de MitM (Man-in-the-Middle), et -J (Jump) impose le bastion comme point d’entrée. Les règles d’arrêt naissent ici via set -e : dès qu’une étape échoue, le script se termine de manière contrôlée.

Conception des runbooks en pratique : Preconditions, Dry-Run, Idempotenz

Pour les équipes d’administration, trois principes font la différence entre « l’automatisation aide » et « l’automatisation cause des problèmes » :

Preconditions (Vorbedingungen) : exiger le contexte

Avant de supprimer, d’arrêter ou de redémarrer, vérifiez l’état. Exemple : n’effectuez une remédiation disque que si un système de fichiers est vraiment saturé et pas, par exemple, parce qu’un montage NFS est bloqué (sinon vous aggraveriez la situation par des timeouts).

#!/usr/bin/env bash
set -euo pipefail

THRESHOLD_PERCENT=95

# Prüfen: Welche Mounts sind kritisch?
df -P | awk 'NR>1 {print $5 " " $6}' | while read -r use mount; do
  pct=${use%%%}
  if [ "${pct}" -ge "${THRESHOLD_PERCENT}" ]; then
    echo "CRITICAL ${mount} ${pct}%"
  fi
done

# Prüfen: journald-Größe (kann /var füllen)
if command -v journalctl >/dev/null 2>&1; then
  journalctl --disk-usage || true
fi

L’objectif n’est pas une « belle sortie », mais un signal objectif : le runbook ne doit poursuivre que si les preconditions sont satisfaites.

Dry-Run par défaut

Pour des actions potentiellement destructrices, la première exécution doit être en « dry » (afficher seulement ce qui se passerait). Cela s’accorde parfaitement avec une exécution semi-automatique : l’opérateur voit l’effet puis confirme l’action réelle.

#!/usr/bin/env bash
set -euo pipefail

# Beispiel: logrotate zuerst testen, dann ausführen
logrotate -d /etc/logrotate.conf
# Erst nach Freigabe:
# logrotate -f /etc/logrotate.conf

Idempotenz : même action, même effet

Idempotent signifie : si une étape s’exécute deux fois, elle n’occasionne pas de dommage supplémentaire. Exemple : « démarrer un service » est idempotent, « appliquer plusieurs fois un patch de configuration » souvent pas. Utilisez donc plutôt des modèles « replace/ensure » que « append ».

Risques et pièges typiques (du point de vue de l’exploitation)

Les runbooks assistés par IA échouent rarement à cause de SSH — ils échouent à cause de conditions limites. Les pièges les plus fréquents :

1) Hôte erroné ou mauvais environnement

Un classique : l’alerte provient de « prod », mais le collecteur de contexte consulte les logs de « stage » (homonymie, mauvais labels). Contre-mesure : vérifications strictes de l’environnement et de l’Asset-ID, plus des « deny lists » pour les systèmes particulièrement critiques.

2) Données incomplètes

Lorsque des logs manquent (rotation, Forwarding-Backpressure) ou que les métriques ne sont pas à jour, la proposition de l’IA devient incertaine. Traitez « pas de données » comme un signal à part. Dans le runbook : réparer d’abord la télémétrie (par ex. vérifier la Logforwarder-Queue), puis remédier.

3) Effets secondaires dus aux mesures standard « utiles »

Redémarrer par défaut est risqué si le système est bloqué dans une boucle de récupération, si une réplication de base de données suit en arrière-plan ou si un stockage est actuellement dégradé. Les runbooks ont donc besoin de règles d’arrêt et de listes « ne pas faire », p. ex. pas de mise à jour de paquets pendant un incident sans un Change-Gate séparé.

4) Droits trop larges ou trop RESTreints

Trop larges : l’utilisateur du runbook dispose d’un sudo sans RESTriction, ce qui fait de chaque erreur un déclencheur potentiel d’incident. Trop RESTreints : le runbook s’interrompt et les administrateurs contournent le processus. Une liste blanche sudoers avec des chemins de commande clairs s’est montrée efficace.

Exemple : liste blanche sudoers pour les actions Runbook

# /etc/sudoers.d/runbook
Defaults:runbook !requiretty
runbook ALL=(root) NOPASSWD: 
  /usr/local/sbin/collect_disk_state, 
  /usr/local/sbin/journald_vacuum, 
  /usr/local/sbin/service_healthcheck, 
  /bin/systemctl RESTart myservice

Important : uniquement des chemins absolus, pas de jokers shell, et après toute modification toujours valider avec visudo (vérification de la syntaxe) avant de déployer.

Étapes de vérification avant exécution : checklist opérateur

Avant d’autoriser l’exécution semi-automatique via SSH, une checklist courte et stricte est utile. Elle est délibérément rédigée « proche de l’exploitation » :

• Périmètre : Hôtes/services concernés identifiés de manière unique ? Environnement correct (prod/test) ?
• Impact : Quel est le risque en cas de pire scénario des étapes proposées (redémarrage, perte de données, perte de logs) ?
• Dépendances : D’autres services dépendent-ils de l’hôte (p. ex. DB partagée, proxy, queue) ?
• Timebox : Combien de temps la remédiation peut-elle durer ? Y a-t-il une fenêtre de maintenance ou des contraintes SLA ?
• Observabilité : Quelles métriques/vérifications indiquent le succès ? (p. ex. taux d’erreur en baisse, disque < 90 %, healthcheck vert)
• Rollback : Existe-t-il une stratégie de retour définie pour chaque étape ?
• Approbation/Audit : ID de ticket/incident présente, validation documentée.

Si l’une de ces questions RESTe « incertaine », c’est un signal : d’abord collecter des données, puis agir.

Stratégie de rollback et de retour en arrière : que faire si la remédiation échoue ?

Une stratégie de retour n’est pas optionnelle. Elle fait partie du Runbook. Trois niveaux se sont avérés pratiques :

1) Rollback progressif (si possible)

Les modifications de configuration devraient se faire en « backup & replace » : sauvegarder la version précédente, activer la nouvelle version, valider, et en cas d’erreur revenir en arrière.

#!/usr/bin/env bash
set -euo pipefail

CFG="/etc/myservice/myservice.conf"
BK="${CFG}.$(date +%Y%m%d%H%M%S).bak"

cp -a "${CFG}" "${BK}"

# Beispiel: neue Konfiguration aus gerendertem Artefakt einspielen
cp -a /var/lib/runbook/rendered/myservice.conf "${CFG}"

systemctl reload myservice

# Validierung: Service muss aktiv sein
systemctl is-active --quiet myservice

echo "OK: config applied; backup at ${BK}"

2) Safe Stop: Automation hält an, Mensch übernimmt

Si les préconditions sont rompues, si les codes de sortie sont inattendus ou si la validation échoue, le système doit s’arrêter. Important : ne pas automatiser davantage, mais geler l’état (sauvegarder les logs, enregistrer les sorties actuelles) et escalader vers le 2nd/3rd-Level.

3) Chemin « Known Good »

Pour les services critiques, un chemin de retour préparé est utile : dernier état connu (p. ex. paquet précédent, configuration précédente, image de conteneur précédente). Même sans CI/CD, cela peut être géré via un dépôt d’artefacts et des versions définies. L’essentiel est que le chemin ait été testé au préalable.

Sécurité et conformité : audit, données de prompt, secrets

Dans les propositions d’IA, la question des données est centrale : quels logs vont où ? Qui est autorisé à les consulter ? Et que deviennent les secrets ? Quelques lignes directrices éprouvées :

• Hygiène des prompts : Les secrets (tokens, clés privées, mots de passe) sont masqués avant l’appel au LLM. Masquer signifie : supprimer ou remplacer des motifs connus (p.ex. « Authorization: Bearer … »).
• Minimisation des données : N’envoyez que les lignes de logs et fenêtres temporelles pertinentes, pas « tout ».
• On-Prem / LLM privé, si nécessaire : Si la conformité l’exige, le LLM reste dans votre environnement contrôlé.
• Journalisation d’audit : Chaque décision (suggestion IA, approbation opérateur, étapes exécutées) est consignée de façon intègre et auditable.

Autre point important : le moteur de runbook est un accès administratif. Il doit être intégré à votre modélisation des menaces : segmentation réseau, durcissement, gestion des patchs, MFA/SSO sur le point d’approbation et procédures d’urgence claires.

Plan pratique : un flux de runbook opérationnel

Un flux applicable en pratique est suffisamment court pour l’incident, mais suffisamment strict pour la sécurité. Un schéma éprouvé :

1. Trigger : Alert ou ticket génèrent un ID d’incident et des cibles.
2. Context Collect : Requêtes définies (logs/métriques/événements) sont collectées et stockées.
3. Proposition IA : Le LLM fournit des hypothèses + un runbook proposé + les risques au format JSON.
4. Mapping : Le moteur vérifie : existe-t-il un runbook approuvé adapté ? Les actions sont-elles autorisées ?
5. Operator Review : Liste de contrôle + approbation des étapes individuelles (p.ex. d’abord diagnostic, puis remédiation).
6. Execute via SSH : Exécution pas à pas avec timeouts, règles d’arrêt, sorties.
7. Validate : Le succès est vérifié par rapport à des signaux SLO / de santé définis.
8. Clôturer & apprendre : Améliorer le runbook : préconditions manquantes, nouveaux pièges, meilleure collecte de données.

Si vous utilisez déjà Ansible ou une plateforme de runbook, beaucoup de ces éléments peuvent être intégrés. L’essentiel reste : l’IA génère des propositions, l’exécution reste contrôlée, versionnée et auditable.

Dépannage : lorsque la remédiation via SSH pose elle-même des problèmes

Le système de runbook lui-même peut aussi être une source d’incidents. Causes typiques et vérifications rapides :

Connexion SSH impossible

• Trajet réseau : Bastion accessible ? Hôte cible joignable ? Routage/ACLs corrects ?
• Clés d’hôte : StrictHostKeyChecking bloque après un rebuild (attendu). Processus : définir une rotation des clés d’hôte au lieu de « simplement désactiver ».
• Auth : Identifiants éphémères expirés ? Dérive horaire (NTP) sur bastion/cible ?

Un contrôle de connexion minimaliste, qui peut s’exécuter comme pré-étape dans le runbook :

#!/usr/bin/env bash
set -euo pipefail

BASTION="bastion01"
TARGET="$1"

ssh -o BatchMode=yes -o ConnectTimeout=5 "runbook@${BASTION}" -- "echo BASTION_OK"
ssh -o BatchMode=yes -o ConnectTimeout=5 -J "runbook@${BASTION}" "runbook@${TARGET}" -- "echo TARGET_OK"

Les commandes sont interrompues par des erreurs sudo

Dans ce cas, la whitelist sudoers est généralement incorrecte (chemin erroné, requiretty activé, ou la commande appelle une shell en interne). Vérifiez que le runbook n’utilise que des chemins absolus autorisés et que « sudo -n » (non-interactif) est configuré.

Le runbook ne fait « rien », mais signale un succès

C’est un problème de conception : absence de validation. Chaque étape de remédiation nécessite une mesure ou un état qui change. Exemple : après un Log-Vacuum, la sortie de « df » doit de nouveau être en dessous du seuil, sinon l’étape n’est pas considérée comme réussie.

Conclusion : l’IA est l’accélérateur, le Runbook reste le frein

La remédiation des serveurs sur la base d’une proposition de l’IA et d’une exécution semi-automatique via SSH fonctionne de manière fiable lorsque vous séparez clairement les rôles : l’IA fournit des hypothèses et des plans structurés, votre moteur de Runbook n’exécute que des actions approuvées, et un opérateur garde la main sur le déclenchement. Avec des préconditions, des dry-runs, l’idempotence, des journaux d’audit et une stratégie de repli testée, vous évitez les risques les plus courants : cibles erronées, situation de données peu claire et modifications « créatives » pendant l’incident.

Si vous souhaitez approfondir le sujet, il est utile, comme étape suivante, de standardiser de manière cohérente votre architecture d’accès distant (bastion, journalisation, droits) et votre gouvernance des Runbooks (versioning, revues, intégration des changements). Ainsi, une aide rapide devient un processus opérationnel fiable.

L’automatisation des Runbooks est également importante pour ce sujet. L’article situe clairement ces aspects et montre ce qui compte au quotidien.