Automatisiertes Runbook: Server-Remediation per KI-Vorschlag und halbautomatischer Ausführung über SSH

Wenn ein Produktionsserver „komisch“ wird, bleibt im Alltag oft nur ein schmaler Korridor: schnell stabilisieren, sauber dokumentieren, und dabei keine neuen Risiken einführen. Genau hier setzt ein Automatisiertes Runbook an: Es übersetzt wiederkehrende Störungsbilder in nachvollziehbare Prüfschritte und Maßnahmen. Neu ist, dass ein KI-Modul (LLM, Large Language Model – ein Sprachmodell, das Texte zusammenfasst und Vorschläge generiert) aus Logs, Metriken und Kontext einen KI-Vorschlag erzeugt. Die Ausführung erfolgt jedoch halbautomatisch: Ein Operator bestätigt die Schritte, und erst dann werden sie kontrolliert über SSH (Secure Shell – verschlüsseltes Remote-Login) umgesetzt.

Dieser Beitrag zeigt eine praxisnahe Architektur und ein Betriebsmodell, das in Admin-Teams funktioniert: mit klaren Sicherheitsleitplanken, Checklisten, typischen Stolperfallen, Prüfschritten, Umsetzungsmustern und einer belastbaren Rückfallstrategie. Schwerpunkt ist nicht „KI kann alles“, sondern: Wie nutzen wir KI sinnvoll, ohne den Betrieb zu entkernen?

Automatisiertes Runbook: Warum halbautomatisiert – und nicht vollautomatisch?

Vollautomatische Remediation klingt verlockend, scheitert in der Praxis aber häufig an zwei Punkten: fehlender Kontext und schwer vorhersehbare Nebenwirkungen. Ein LLM kann plausible Schritte formulieren, hat aber keine echte „Wahrheit“, sondern erzeugt Text auf Basis von Mustern. Bei Server-Remediation sind Nebenwirkungen jedoch konkret: Neustarts, Konfigurationsänderungen, Paketupdates, Datenbank-Rebuilds oder Firewall-Regeln können Folgeschäden erzeugen.

Halbautomatisierung ist deshalb ein stabiler Kompromiss:

• Schneller Diagnosepfad: KI schlägt strukturierte Prüfungen vor (z. B. „Disk voll?“, „OOM-Killer?“, „DNS-Latenz?“), inklusive erwarteter Ausgaben.
• Operator als Gate: Ein Mensch bewertet Risiko, Zeitpunkt, Abhängigkeiten und bestätigt nur das, was zum Change-Fenster und zur Service-Kritikalität passt.
• Deterministische Ausführung: Die Runbook-Engine führt vordefinierte, versionierte Schritte aus – nicht „irgendeinen“ KI-generierten Shell-Text.

Das Ziel ist weniger Helden-Admin, mehr wiederholbarer Betrieb: gleiche Symptome, gleiche Checks, gleiche Logs, gleiche Audit-Spuren.

Referenzarchitektur: KI-Vorschlag, Runbook-Engine und SSH-Ausführung

Für die meisten Umgebungen bewährt sich ein Aufbau mit klarer Trennung von „Vorschlag“ und „Ausführung“:

• Signalquellen: Monitoring (Metriken), Logplattform, Tracing, CMDB/Asset-Daten, Ticket/ITSM. Wichtig ist ein eindeutiger Host/Service-Identifier.
• Kontextsammler: Ein Job sammelt relevante Ausschnitte (z. B. die letzten 10 Minuten Logs, aktuelle Alarme, letzte Deployments, bekannte Wartungen). Hier entscheidet sich, ob die KI „gute“ Vorschläge macht.
• KI-Assistent (Vorschlagsmodul): Erzeugt Diagnose- und Maßnahmenplan, inklusive Risikoeinschätzung. Ausgabe idealerweise als strukturiertes JSON (nicht nur Fließtext).
• Runbook-Katalog: Versionierte Runbooks (Git), mit freigegebenen Aktionen, Parametern, Preconditions und Rollback-Definition.
• Runbook-Executor: Führt Aktionen über SSH aus, schreibt Logs, erzwingt Timeouts, sammelt Outputs, setzt Exit-Codes und stoppt bei Abweichungen.
• Gate & Audit: Vier-Augen-Prinzip, Change-ID, Approval, Protokollierung (wer hat wann was bestätigt?).

Wichtig ist die Rollenverteilung: Das LLM empfiehlt, der Executor handelt. So verhindern Sie, dass „kreative“ Textausgaben direkt als Befehle laufen.

SSH-Betriebsmodell: Bastion, Schlüssel, Rechte

SSH ist technisch simpel, operativ aber voller Details. Ein robustes Modell nutzt einen Bastion Host (Sprungserver als kontrollierter Einstiegspunkt), kurzlebige Credentials (z. B. zeitlich begrenzte Schlüssel/Zertifikate) und Least Privilege (nur die Rechte, die das Runbook braucht). Praktisch bedeutet das:

• Der Executor verbindet sich nur zur Bastion, von dort zu Zielhosts (Netzsegmentierung, zentraler Audit-Punkt).
• Auf Zielhosts existiert ein dedizierter „runbook“-User mit eingeschränkten sudo-Rechten (nur definierte Kommandos).
• Jede Aktion ist einem Ticket/Incident zugeordnet (Change- und Audit-Kette).

Welche Störungsbilder eignen sich für Server-Remediation per Runbook?

Nicht alles ist runbook-tauglich. Gute Kandidaten sind wiederkehrende und beobachtbare Probleme mit klaren Prüfpunkten:

• Speicherplatz voll: Logrotation/Journal, Temp-Verzeichnisse, Crashdumps, alte Artefakte.
• Service hängt: Health-Check fails, Prozess lebt aber reagiert nicht (z. B. Deadlocks, Thread-Exhaustion).
• OOM/Memory Pressure: Out-of-Memory-Killer, Swap-Thrashing, Leak-Indikatoren.
• DNS/Netzwerk-Fehler: Resolver-Probleme, fehlerhafte Route, MTU/Fragmentierung.
• Zertifikate abgelaufen: Kettenprobleme, falscher Truststore, ablaufende Client-Zertifikate.

Schlechte Kandidaten sind „einmalige“ Spezialfälle, Änderungen mit hoher Blast-Radius (z. B. Kernel-Upgrade im Incident) oder unklare Symptome ohne zuverlässige Telemetrie.

Voraussetzungen: Telemetrie, Identitäten, Runbook-Design

Damit der KI-Vorschlag mehr ist als Raten, braucht es solide Grundlagen:

1) Telemetrie mit Korrelation

Logs, Metriken und Alerts müssen zusammenfinden. „Korrelation“ heißt im Betrieb: Hostname, Instance-ID, Service-Name, Deployment-Version und Zeitfenster sind konsistent. Ohne das schlägt die KI im Zweifel „Neustart“ vor, weil sie keine differenzierte Ursache erkennt.

2) Deterministische Runbook-Aktionen

Ein Runbook ist mehr als ein Wiki-Text. Für halbautomatische Ausführung brauchen Sie idempotente Schritte (mehrfach ausführbar ohne Schaden) und Preconditions (Vorbedingungen), die verhindern, dass ein Schritt im falschen Kontext läuft. Beispiel: „nur starten, wenn freier Platz < 5% und /var die Ursache ist“.

3) Change- und Freigaberegeln

Auch im Incident gilt: Änderungen müssen nachvollziehbar sein. Minimalstandard: Change-ID, Approval (mindestens 1 Operator), und ein Log, das Input, Output, Exit-Code und Zeitpunkt je Schritt enthält.

KI-Vorschlag richtig einbetten: Output als Plan, nicht als Shell

Wenn ein LLM freie Shell-Kommandos generiert, bekommen Sie zwei Risiken: nicht geprüfte Syntax und nicht geprüfte Intention. Besser: Das LLM liefert einen Plan, den Ihre Runbook-Engine gegen einen Katalog zulässiger Aktionen validiert.

Ein praktikables Format ist JSON, das die Engine strikt prüft (Schema-Validierung):

{
  "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."
  ]
}

Wichtig: Die Engine akzeptiert nur Runbook-IDs und Actions, die im Katalog existieren. Alles andere wird verworfen. So bleibt KI ein Assistenzsystem, kein Remote-Root.

Umsetzung: Runbook-Executor über SSH mit Review, Logging und Stop-Regeln

Ein Executor muss nicht komplex sein, aber konsequent. Drei Eigenschaften sind im Betrieb entscheidend:

• Nachvollziehbarkeit: Jeder Schritt schreibt standardisierte Logs (Start/Ende, Target, Kommando, Output-Hash, Exit-Code).
• Sicherheitsgrenzen: Timeouts, erlaubte Kommandos, gesperrte Targets (z. B. Domain Controller, Storage-Controller), Rate-Limits.
• Stop-Regeln: Bei Abweichungen wird nicht „weiterprobiert“, sondern gestoppt und eskaliert.

Beispiel: SSH-Ausführung über Bastion mit eingeschränkten sudo-Rechten

Im folgenden Beispiel nutzt der Executor einen dedizierten User und erzwingt nicht-interaktive Ausführung. Das ist kein vollständiges Produkt, aber ein greifbares Muster für Ihre eigenen 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}"

Warum diese Details wichtig sind: BatchMode verhindert Passwort-Prompts, StrictHostKeyChecking reduziert MitM-Risiken (Man-in-the-Middle), und -J (Jump) erzwingt die Bastion als Eintrittspunkt. Stop-Regeln entstehen hier durch set -e: Sobald ein Schritt fehlschlägt, endet das Skript kontrolliert.

Runbook-Design in der Praxis: Preconditions, Dry-Run, Idempotenz

Für Admin-Teams sind drei Prinzipien der Unterschied zwischen „Automation hilft“ und „Automation macht Ärger“:

Preconditions (Vorbedingungen) erzwingen Kontext

Bevor Sie löschen, stoppen oder neu starten, prüfen Sie den Zustand. Beispiel: Disk-Remediation nur, wenn wirklich ein Filesystem eng ist und nicht z. B. ein NFS-Mount hängt (sonst verschlimmern Sie die Lage durch 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

Das Ziel ist nicht „schöne Ausgabe“, sondern ein objektives Signal: Runbook darf erst weitermachen, wenn Preconditions erfüllt sind.

Dry-Run als Standard

Bei potenziell destruktiven Schritten sollte der erste Durchlauf „dry“ sein (nur anzeigen, was passieren würde). Das passt perfekt zur halbautomatischen Ausführung: Operator sieht den Effekt und bestätigt dann den echten Schritt.

#!/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: gleiche Aktion, gleicher Effekt

Idempotent heißt: Wenn ein Schritt zweimal läuft, entsteht kein zusätzlicher Schaden. Beispiel: „Service starten“ ist idempotent, „Konfiguration mehrfach patchen“ oft nicht. Nutzen Sie daher eher „replace/ensure“-Muster als „append“.

Risiken und typische Stolperfallen (aus Betriebssicht)

KI-gestützte Runbooks scheitern selten an SSH – sie scheitern an Randbedingungen. Die häufigsten Fallen:

1) Falscher Host oder falsche Umgebung

Ein Klassiker: Alarm kommt aus „prod“, aber der Kontextsammler greift auf „stage“-Logs zu (Namensgleichheit, falsche Labels). Gegenmaßnahme: harte Checks auf Environment und Asset-ID, plus „deny lists“ für besonders kritische Systeme.

2) Unvollständige Datenlage

Wenn Logs fehlen (Rotation, Forwarding-Backpressure) oder Metriken nicht aktuell sind, wird der KI-Vorschlag unsicher. Behandeln Sie „keine Daten“ als eigenes Signal. Im Runbook: erst Telemetrie reparieren (z. B. Logforwarder-Queue prüfen), dann remediieren.

3) Nebenwirkungen durch „hilfreiche“ Standardmaßnahmen

Neustart als Standard ist riskant, wenn das System in einer Recovery-Schleife hängt, eine Datenbank-Replikation nachzieht oder ein Storage gerade degraded ist. Runbooks brauchen deshalb Stop-Regeln und „Do-not-do“-Listen, z. B. keine Paketupdates im Incident ohne separates Change-Gate.

4) Rechte zu weit oder zu eng

Zu weit: Runbook-User hat pauschales sudo, und damit ist jeder Fehler ein potenzieller Incident-Trigger. Zu eng: Runbook bricht ab und Admins umgehen den Prozess. Bewährt hat sich eine sudoers-Whitelist mit klaren Kommandopfaden.

Beispiel: sudoers-Whitelist für Runbook-Aktionen

# /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

Wichtig: Nur absolute Pfade, keine Shell-Wildcards, und nach Änderungen immer mit visudo validieren (Syntaxprüfung), bevor Sie ausrollen.

Prüfschritte vor der Ausführung: Operator-Checkliste

Bevor Sie die halbautomatische Ausführung per SSH freigeben, hilft eine kurze, konsequente Checkliste. Sie ist bewusst „betriebsnah“ formuliert:

• Scope: Betroffene Hosts/Services eindeutig? Richtige Umgebung (prod/test)?
• Impact: Was ist das Worst-Case-Risiko der vorgeschlagenen Schritte (Restart, Datenverlust, Logverlust)?
• Dependencies: Hängen andere Services am Host (z. B. Shared DB, Proxy, Queue)?
• Timebox: Wie lange darf die Remediation dauern? Gibt es ein Wartungsfenster oder SLA-Grenzen?
• Observability: Welche Metrik/Checks zeigen Erfolg? (z. B. Error-Rate sinkt, Disk < 90%, Healthcheck grün)
• Rollback: Gibt es eine definierte Rückfallstrategie je Schritt?
• Approval/Audit: Ticket/Incident-ID vorhanden, Freigabe dokumentiert.

Wenn eine dieser Fragen „unklar“ bleibt, ist das ein Signal: erst Daten sammeln, dann handeln.

Rollback- und Rückfallstrategie: Was tun, wenn die Remediation scheitert?

Eine Rückfallstrategie ist nicht optional. Sie ist Teil des Runbooks. Praktisch bewähren sich drei Ebenen:

1) Schrittweiser Rollback (wo möglich)

Konfigurationsänderungen sollten als „backup & replace“ erfolgen: vorherige Version sichern, neue Version aktivieren, Validierung, und bei Fehlern zurück.

#!/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

Wenn Preconditions brechen, Exit-Codes unerwartet sind oder die Validierung fehlschlägt, muss das System stoppen. Wichtig: Nicht „weiter“ automatisieren, sondern den Zustand einfrieren (Logs sichern, aktuelle Outputs speichern) und an 2nd/3rd-Level eskalieren.

3) „Known Good“-Pfad

Für kritische Services lohnt ein vorbereiteter Rückweg: letzter bekannter Stand (z. B. vorheriges Package, vorherige Config, vorheriges Container-Image). Auch ohne CI/CD kann das über Artefakt-Repository und definierte Versionen abgebildet werden. Entscheidend ist, dass der Pfad vorher getestet wurde.

Security und Compliance: Audit, Prompt-Daten, Geheimnisse

Bei KI-Vorschlägen ist die Datenfrage zentral: Welche Logs gehen wohin? Wer darf sie sehen? Und was passiert mit Secrets? Einige bewährte Leitplanken:

• Prompt-Hygiene: Secrets (Tokens, Private Keys, Passwörter) werden vor dem LLM-Aufruf maskiert. Maskierung heißt: bekannte Muster (z. B. „Authorization: Bearer …“) entfernen oder ersetzen.
• Datensparsamkeit: Nur die relevanten Logzeilen und Zeitfenster senden, nicht „alles“.
• On-Prem/Private LLM, wo nötig: Wenn Compliance es verlangt, bleibt das LLM in Ihrer kontrollierten Umgebung.
• Audit Logging: Jede Entscheidung (KI-Vorschlag, Operator-Approval, ausgeführte Schritte) wird revisionssicher protokolliert.

Auch wichtig: Die Runbook-Engine ist ein administrativer Zugang. Sie gehört in Ihr Threat-Modeling: Netzwerksegmentierung, Härtung, Patch-Management, MFA/SSO am Approval-Gate und klare Notfallprozesse.

Praxis-Blueprint: Ein Runbook-Flow, der im Alltag funktioniert

Ein praxistauglicher Flow ist kurz genug für den Incident, aber streng genug für Sicherheit. Ein bewährtes Muster:

1. Trigger: Alert oder Ticket erzeugt Incident-ID und Target(s).
2. Context Collect: Definierte Abfragen (Logs/Metriken/Events) werden gesammelt und gespeichert.
3. KI-Vorschlag: LLM liefert Hypothesen + vorgeschlagenes Runbook + Risiken als JSON.
4. Mapping: Engine prüft: Gibt es ein passendes, freigegebenes Runbook? Sind Actions erlaubt?
5. Operator Review: Checkliste + Freigabe einzelner Schritte (z. B. erst Diagnose, dann Remediation).
6. Execute via SSH: Schrittweise Ausführung mit Timeouts, Stop-Regeln, Outputs.
7. Validate: Erfolg wird gegen definierte SLO-/Health-Signale geprüft.
8. Close & Learn: Runbook verbessern: fehlende Preconditions, neue Stolperfallen, bessere Datensammlung.

Wenn Sie bereits Ansible oder eine Runbook-Plattform nutzen, können viele dieser Elemente integriert werden. Der Kern bleibt: KI erzeugt Vorschläge, die Ausführung bleibt kontrolliert, versioniert und auditierbar.

Troubleshooting: Wenn SSH-Remediation selbst Probleme macht

Auch das Runbook-System kann zur Fehlerquelle werden. Typische Ursachen und schnelle Checks:

SSH verbindet nicht

• Netzweg: Bastion erreichbar? Zielhost erreichbar? Routing/ACLs korrekt?
• Host Keys: StrictHostKeyChecking blockiert nach Rebuild (erwartet). Prozess: Host-Key-Rotation definiert statt „einfach abschalten“.
• Auth: Kurzlebige Credentials abgelaufen? Zeitdrift (NTP) auf Bastion/Target?

Ein minimalistischer Verbindungscheck, der im Runbook als Vorstufe laufen kann:

#!/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"

Kommandos brechen mit sudo-Fehlern ab

Dann ist meist die sudoers-Whitelist falsch (Pfad stimmt nicht, requiretty aktiv, oder das Kommando ruft intern eine Shell auf). Prüfen Sie, ob das Runbook wirklich nur die erlaubten, absoluten Pfade nutzt, und ob „sudo -n“ (non-interactive) gesetzt ist.

Runbook macht „nichts“, aber meldet Erfolg

Das ist ein Designproblem: fehlende Validierung. Jeder Remediation-Schritt braucht eine Messgröße oder einen Zustand, der sich ändert. Beispiel: Nach Log-Vacuum muss „df“ wieder unter Schwellwert sein, sonst gilt der Schritt als nicht erfolgreich.

Fazit: KI ist der Beschleuniger, das Runbook bleibt die Bremse

Server-Remediation per KI-Vorschlag und halbautomatischer Ausführung über SSH funktioniert dann zuverlässig, wenn Sie die Rollen sauber trennen: KI liefert Hypothesen und strukturierte Pläne, Ihre Runbook-Engine setzt ausschließlich freigegebene Aktionen um, und ein Operator hält die Hand am Gate. Mit Preconditions, Dry-Run, Idempotenz, Audit-Logs und getesteter Rückfallstrategie vermeiden Sie die häufigsten Risiken: falsche Targets, unklare Datenlage und „kreative“ Änderungen im Incident.

Wenn Sie das Thema weiter vertiefen möchten, lohnt es sich als nächster Schritt, Ihre Remote-Access-Architektur (Bastion, Logging, Rechte) und Ihre Runbook-Governance (Versionierung, Reviews, Change-Integration) konsequent zu standardisieren. So wird aus schneller Hilfe ein belastbarer Betriebsprozess.

Für dieses Thema sind auch Runbook Automation wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.