SSH-Erfolgsprüfungen: Beweise, dass die Remote-Arbeit abgeschlossen ist

Ein SSH-Befehl, der mit Status 0 endet, hat genau eine begrenzte Aufgabe erfüllt: Das Remote-Programm hat seiner Shell mitgeteilt, dass es erfolgreich war. Das ist ein nützlicher Hinweis, aber kein Beweis dafür, dass ein Deployment das richtige Release erreicht hat, ein Dienst stabil blieb oder eine Konfigurationsänderung wirksam wurde.

Ich habe oft erlebt, dass Automatisierung einen Erfolg meldete, weil ssh host command null zurückgab. Später stellte sich heraus, dass der Befehl in das falsche Verzeichnis geschrieben, Arbeit eingeplant hatte, die danach fehlschlug, oder einen Dienst neu gestartet hatte, der sofort wieder abstürzte. Die Lösung sind nicht noch mehr optimistische Logs. Betrachte eine Remote-Änderung erst dann als abgeschlossen, wenn drei unabhängige Fakten zusammenpassen: SSH hat das Remote-Programm erreicht, das Programm hat das erwartete Ergebnis zurückgegeben und eine unabhängige Lesung bestätigt den Zustand, den du herstellen wolltest.

Ein SSH-Exit-Code beschreibt nur eine Ebene des Vorgangs

Ein Exit-Status sagt etwas über den Abschluss eines Prozesses aus, nicht über das vollständige operative Ergebnis. Ein Remote-Befehl hängt von vielen Annahmen ab: DNS und Netzwerkverbindung, Host-Identität, Authentifizierung, Shell-Verhalten, Befehlsanalyse, Abhängigkeiten, Berechtigungen auf dem Remote-System und dem Zustand, den du ändern wolltest.

Das OpenSSH-Handbuch zu ssh(1) sagt, dass ssh den Status des Remote-Befehls zurückgibt oder 255, wenn ein Fehler auftritt. Diese Unterscheidung ist wichtig. Status 255 bedeutet normalerweise, dass der SSH-Client die Sitzung nicht wie erforderlich aufbauen oder aufrechterhalten konnte. Status 1, 2 oder ein anderer Wert ungleich null stammt normalerweise vom Remote-Befehl. Auch der Wert null stammt von diesem Befehl.

Diese Definition sagt nicht, dass null bedeutet: «Die Änderung in der Produktion ist korrekt.» Das kann SSH nicht wissen. SSH weiß nicht, ob /srv/app/current auf das gewünschte Release zeigt, ob ein Daemon nach systemctl restart Anfragen annimmt oder ob eine Datenbankmigration die von der Anwendung benötigten Zeilen festgeschrieben hat.

POSIX definiert einen Exit-Status von null als erfolgreichen Abschluss eines Befehls. Der wichtige Teil dieser Definition ist ihre Begrenztheit. Sie beschreibt den Vertrag des Befehls. Wenn dieser Vertrag nur lautet «Führe diese Shell-Zeile aus», beweist null sehr wenig. Formuliere einen engeren Vertrag und prüfe den Zustand außerhalb dieses Befehls.

Eine praktische Sicht auf Fehler besteht darin, drei Ebenen zu unterscheiden:

• SSH-Fehler: Der Client konnte keine Verbindung herstellen, sich nicht authentifizieren, den Host nicht verifizieren oder die Sitzung nicht abschließen.
• Befehlsfehler: Der Remote-Prozess hat einen Fehler erkannt und einen Status ungleich null zurückgegeben.
• Ergebnisfehler: Der Prozess gab null zurück, aber der gewünschte Remote-Zustand fehlt, ist falsch, unvollständig oder wurde später wieder geändert.

Teams werfen die letzten beiden Ebenen häufig zusammen. Das macht Incident-Berichte ungenau und Wiederholungen gefährlich. Wenn du weißt, auf welcher Ebene der Fehler lag, weißt du auch, ob du Zugangsdaten und Verbindung prüfen, den Befehl korrigieren oder den Remote-Zustand reparieren musst.

Erfolgstext ist nur dann ein Beleg, wenn du ihn genau definierst

Prüfungen der erwarteten Ausgabe finden Fehler, die ein Exit-Status nicht erkennen kann, aber nur dann, wenn die Ausgabe einem klaren Vertrag folgt. In einem menschenorientierten Protokoll nach Wörtern wie success, complete oder deployed zu suchen, liefert schwache Hinweise. Viele Tools geben diese Wörter aus, bevor ein späterer Befehl fehlschlägt. Wrapper geben sie oft aus, obwohl sie nur eine asynchrone Aufgabe eingereicht haben.

Lass den Remote-Befehl einen einzelnen Datensatz ausgeben, der die erwartete Identität und den erwarteten Zustand enthält. JSON ist dafür oft praktisch, aber eine feste, begrenzte Zeile genügt, wenn du die Werte kontrollierst. Entscheidend ist, dass das Skript den Datensatz erst ausgibt, nachdem es die Arbeit erledigt hat, über die es berichtet.

Nehmen wir an, ein Release-Skript schaltet einen symbolischen Link auf ein Release-Verzeichnis um. Dieses Remote-Skript gibt das endgültige Ziel aus und nicht nur eine vage Fortschrittsmeldung:

#!/bin/sh
set -eu

release="$1"
base=/srv/example/releases
link=/srv/example/current

[ -d "$base/$release" ]
ln -sfn "$base/$release" "$link"

actual=$(readlink "$link")
[ "$actual" = "$base/$release" ]
printf 'RELEASE_TARGET=%s\n' "$actual"

Der aufrufende Prozess kann eine exakt passende Ausgabezeile verlangen:

expected="RELEASE_TARGET=/srv/example/releases/2025.06.14"
output=$(ssh deploy@web-01 '/usr/local/sbin/activate-release 2025.06.14' 2>&1)
status=$?

if [ "$status" -ne 0 ]; then
  printf 'remote command failed, status=%s\n%s\n' "$status" "$output" >&2
  exit "$status"
fi

if ! printf '%s\n' "$output" | grep -Fxq "$expected"; then
  printf 'remote command returned unexpected output:\n%s\n' "$output" >&2
  exit 1
fi

grep -Fxq ist hier entscheidend. Es prüft eine vollständige, unveränderte Zeile. Ein lockerer Ausdruck wie grep deployed akzeptiert beliebige Zusatztexte, Teiltreffer und irreführende Fortschrittsmeldungen. Wenn deine Ausgabe dynamische Felder enthält, parse ein strukturiertes Dokument mit einem echten Parser, statt verschachtelte Daten mit einem regulären Ausdruck zu interpretieren.

Mach aus dem Abgleich der Ausgabe keine zweite Kopie des gesamten Befehls. Er sollte nur eine begrenzte Frage beantworten: Hat das Remote-Programm gemeldet, dass es den benannten Zustand erreicht hat? Die anschließende Lesung beantwortet, ob diese Aussage dort weiterhin stimmt, wo es darauf ankommt.

Nach Remote-Schreibvorgängen muss der Besitzer des Zustands lesen

Eine anschließende Lesung liefert die stärkste Bestätigung, weil sie die Komponente fragt, die den geänderten Zustand verwaltet. Welche Lesung richtig ist, hängt von der Änderung ab und unterscheidet sich oft von dem Befehl, der die Änderung vorgenommen hat.

Bei einem Wechsel des symbolischen Links prüft readlink das Dateisystem. Bei einem Paket-Rollout fragst du die installierte Paketversion ab. Nach einem Neustart fragst du den Dienstmanager nach dem aktiven Zustand und sendest anschließend eine Anfrage an den Dienst. Bei einer Datenbankänderung liest du die Zeile oder verwendest den vorgesehenen Status-Endpunkt der Anwendung. Bei einer Aufgabe in einer Warteschlange fragst du den Aufgaben-Datensatz ab, bis er einen endgültigen Zustand erreicht.

Das typische schlechte Muster sieht so aus:

ssh deploy@web-01 'deploy-release 2025.06.14 && systemctl restart example'

Der Befehl kann null zurückgeben, obwohl der Dienst «aktiv» ist, aber auf ein altes Release zeigt, weil das Deployment-Skript in einen anderen Pfad geschrieben hat. Er kann ebenfalls null zurückgeben, wenn der Dienstmanager den Neustart akzeptiert, der Prozess aber wenige Augenblicke später stirbt. Die Shell hat gesehen, dass zwei Programme null zurückgegeben haben. Die Nutzer erhalten trotzdem einen defekten Dienst.

Verwende eine Lesung, durch die die gewünschte Bedingung sichtbar wird. Eine Deployment-Prüfung kann so aussehen:

ssh deploy@web-01 '
  test "$(readlink /srv/example/current)" = /srv/example/releases/2025.06.14 &&
  systemctl is-active --quiet example &&
  curl --fail --silent --show-error http://127.0.0.1:8080/healthz
'

Das ist besser als der erste Befehl, weil es drei Aussagen prüft, die der ursprüngliche Befehl nur angenommen hat. Es beweist trotzdem nicht, dass jeder externe Nutzer den Dienst erreichen kann. Wenn die Änderung einen öffentlichen Endpunkt betrifft, führe eine passende Prüfung von der Netzwerkposition aus, an der sich die Nutzer tatsächlich befinden. Gesundheitsprüfungen über Loopback erkennen einen Prozessfehler, aber keinen Fehler an Firewall oder Load Balancer.

Read-after-write-Prüfungen sollten nach Möglichkeit einen unabhängigen Weg verwenden. Eine zweite Funktion im selben Deployment-Skript ist besser als nichts, kann aber dieselbe falsche Variable, denselben falschen Host oder dieselbe simulierte Abhängigkeit übernehmen. Ein separater Befehl, der Dateisystem, Dienstmanager, API oder Datenbank abfragt, verringert dieses gemeinsame Fehlerrisiko.

Ein Befehl muss angeben, ob er synchron arbeitet

Viele Remote-Befehle geben null zurück, weil sie eine Aufgabe angenommen haben, nicht weil diese Aufgabe abgeschlossen ist. Für eine Warteschlangenübermittlung, einen Hintergrundjob, eine Anfrage zum Neuladen eines Dienstes oder eine Orchestrierungs-API ist das ein korrektes Ergebnis. Es wird zum Fehler, wenn der Aufrufer die Annahme mit dem Abschluss verwechselt.

Trenne die beiden Verträge in Namen und Ausgabe. submit-backup kann eine Job-ID ausgeben und null zurückgeben, sobald der Server die Anfrage angenommen hat. wait-backup kann erst dann null zurückgeben, wenn genau dieser Job den Abschluss meldet. Nenne nicht beide Aktionen backup und hoffe, dass sich der Operator merkt, welche Version auf welchem Host läuft.

Ein Remote-Skript, das Arbeit im Hintergrund startet, braucht besondere Sorgfalt. Diese Shell-Zeile gibt Erfolg zurück, sobald sie einen Prozess gestartet hat, selbst wenn dieser Prozess sofort fehlschlägt:

long-task >/var/log/long-task.log 2>&1 &
printf 'started\n'

Der spätere Exit-Code des Prozesses steht dem SSH-Aufrufer nicht zur Verfügung. Speichere ihn dauerhaft und frage ihn später ab oder halte die Sitzung offen, bis die Aufgabe einen aussagekräftigen Zustand erreicht. Wenn du die Aufgabe abkoppelst, schreibe eine Operations-ID in eine Datei oder Datenbank und gib diese ID zurück. Der Aufrufer kann dann den Operations-Datensatz regelmäßig abfragen oder auf ihn warten.

Ein nützlicher Abschlussdatensatz enthält genügend Informationen, um die Arbeit abzugleichen:

operation=4f2c1a status=accepted release=2025.06.14

Der Aufrufer sollte diesen Datensatz nicht als abgeschlossenes Deployment akzeptieren. Er sollte operation=4f2c1a abfragen und einen endgültigen Status wie completed verlangen, zusammen mit einer Prüfung des erzeugten Zustands. Das mag für ein einfaches Skript übertrieben wirken. Es ist deutlich weniger umständlich, als nach einem Timeout zu raten, ob das Skript sicher erneut ausgeführt werden kann.

Für Timeouts gilt dieselbe Unterscheidung. Ein lokales Timeout sagt dir, dass der Aufrufer nicht länger gewartet hat. Es sagt nicht, dass der Remote-Befehl angehalten wurde. Das Netzwerk kann ausgefallen sein, nachdem der Remote-Host eine Änderung festgeschrieben hat. Prüfe vor einer Wiederholung den Remote-Zustand oder frage die Operations-ID ab. Das erneute Aktivieren eines Releases kann ungefährlich sein, wenn die Operation idempotent ist. Eine Zahlung, eine Geheimnisrotation oder der Versand einer E-Mail kann den Schaden dagegen vergrößern.

Shell-Verknüpfungen verbergen Fehler, wenn du sie nicht entsprechend schreibst

Die Syntax der Remote-Shell kann einen echten Fehler in einen erfolgreichen abschließenden Exit-Status verwandeln. Das ist eine der ältesten Ursachen dafür, dass ein SSH-Lauf sauber aussieht, während auf dem Rechner ein beschädigter Zustand zurückbleibt.

Betrachte diesen Befehl:

ssh ops@db-01 'backup-db; upload-backup; prune-old-backups'

Die Remote-Shell gibt den Status von prune-old-backups zurück, also ihres letzten Befehls. Wenn das Backup fehlschlägt, das Aufräumen aber gelingt, liefert der gesamte SSH-Befehl null. Im Protokoll kann weit oben ein Fehler stehen, während eine Pipeline, die nur den Status liest, den Lauf als erfolgreich markiert.

Verwende in einem von dir kontrollierten Skript set -e oder verknüpfe abhängige Befehle mit &&, wenn ein kompakter Befehl lesbar bleibt:

ssh ops@db-01 'backup-db && upload-backup && prune-old-backups'

set -e ist kein Zaubermittel. Shells haben Ausnahmen bei Bedingungen, Befehlssubstitutionen und einigen zusammengesetzten Konstruktionen. Schreibe keinen langen Remote-Einzeiler und nimm nicht an, dass eine einzelne Option jeden Fehler sichtbar macht. Packe umfangreiche Arbeiten in ein Remote-Skript, gib jeder Operation eine klare Erfolgskondition und teste das Verhalten bei Fehlern.

Pipelines führen zu einer weiteren bekannten Falle. In vielen POSIX-Shells ist die Pipeline erfolgreich, wenn das letzte Programm erfolgreich ist, selbst wenn ein früherer Produzent fehlschlägt:

collect-metrics | format-report > /var/tmp/report.txt

Einige Shells unterstützen set -o pipefail, /bin/sh möglicherweise aber nicht. Wenn die Remote-Umgebung POSIX-kompatibel bleiben muss, verwende eine Pipeline nicht als einzige Fehlergrenze. Schreibe die Zwischendaten in eine temporäre Datei, prüfe den Status des Produzenten und verarbeite sie erst danach. Alternativ kannst du das Skript mit einer Shell ausführen, deren pipefail-Verhalten du ausdrücklich voraussetzt.

Beende einen Remote-Befehl außerdem nicht mit diagnostischer Ausgabe, die nach einem echten Fehler noch erfolgreich sein kann:

apply-config
printf 'finished\n'

Ohne set -e oder eine explizite Prüfung wird printf zum Exit-Status. Dieser Fehler tritt bei handgeschriebenen Incident-Befehlen auf, weil jemand eine freundliche Abschlussmeldung möchte. Gib die Meldung erst nach einer Bedingungsprüfung aus oder lass der fehlgeschlagene Befehl das Skript beenden.

Quoting-Fehler können dazu führen, dass du den falschen Rechner prüfst

Eine lokale Shell erweitert nicht maskierte Variablen, bevor SSH den Befehl sendet. Dadurch kann ein Befehl gegen das falsche Release laufen, lokale statt Remote-Ausgabe vergleichen oder Werte in der lokalen Prozessliste und in Logs offenlegen.

Das ist falsch, wenn die Remote-Seite $release auswerten soll:

ssh deploy@web-01 "test \"$(readlink /srv/example/current)\" = \"$release\""

Die lokale Shell wertet $(readlink ...) aus, bevor sie SSH startet. Du hast damit den /srv/example/current-Pfad deiner Arbeitsstation, sofern vorhanden, mit einer lokalen Variable verglichen und anschließend den daraus entstandenen Text an die Remote-Shell gesendet. Der Exit-Status kann null sein. Die Prüfung hat den Zielhost nicht untersucht.

Halte das Remote-Programm in einfachen Anführungszeichen, wenn darin Shell-Syntax enthalten ist, die remote ausgeführt werden muss. Übergib nicht vertrauenswürdige oder dynamische Werte als Positionsparameter, statt Shell-Text zusammenzusetzen. Zum Beispiel:

release='2025.06.14'
ssh deploy@web-01 'sh -s -- "$1"' sh "$release" <<'REMOTE'
set -eu
release=$1
target=$(readlink /srv/example/current)
[ "$target" = "/srv/example/releases/$release" ]
printf 'verified=%s\n' "$target"
REMOTE

Der maskierte Here-Doc-Begrenzer verhindert, dass die lokale Shell den Skriptkörper erweitert. Der Release-Wert wird als Shell-Argument übertragen, sodass die Remote-Shell ihn korrekt quoten kann. Das macht beliebige Eingaben nicht automatisch zu einem sicheren Release-Namen. Validiere erlaubte Zeichen und erwartete Formate, bevor du benutzergesteuerte Werte in Pfaden, Befehlen oder Datenbankabfragen verwendest.

Für Automatisierung ist ein Remote-Skript mit Parametern einem immer längeren String aus verschachtelten Anführungszeichen vorzuziehen. Quoting-Fehler sind bei Code-Reviews schwer zu erkennen, weil der Befehl auf den ersten Blick plausibel wirken kann. Sie lassen sich leichter diagnostizieren, wenn Logs die genaue Version des Remote-Skripts, sicher protokollierbare Parameterwerte und die eigene Ausgabe des Verifizierungsbefehls zeigen.

Ein sinnvoller SSH-Vertrag hat drei getrennte Ergebnisse

Behandle jede folgenreiche SSH-Aktion als kleines Protokoll mit getrennten Feldern für Transport, Befehlsergebnis und beobachteten Zustand. Der Aufrufer braucht alle drei Informationen, um zu entscheiden, ob er fortfahren, wiederholen oder Hilfe anfordern kann.

Diese Bash-Funktion zeigt die Struktur. Sie erfasst stderr zusammen mit stdout, damit ein fehlgeschlagener Vorgang diagnostische Hinweise hinterlässt. Gleichzeitig meldet sie einen SSH-Transportfehler getrennt von einer unerwarteten Erfolgsantwort.

run_remote_check() {
  local host=$1
  local expected=$2
  shift 2

  local output status
  output=$(ssh "$host" "$@" 2>&1)
  status=$?

  if [ "$status" -eq 255 ]; then
    printf 'ssh_transport=failed host=%s\n%s\n' "$host" "$output" >&2
    return 255
  fi

  if [ "$status" -ne 0 ]; then
    printf 'remote_command=failed host=%s status=%s\n%s\n' \
      "$host" "$status" "$output" >&2
    return "$status"
  fi

  if ! printf '%s\n' "$output" | grep -Fxq "$expected"; then
    printf 'remote_result=unexpected host=%s expected=%s\n%s\n' \
      "$host" "$expected" "$output" >&2
    return 1
  fi

  printf 'remote_result=confirmed host=%s\n' "$host"
}

Rufe sie mit einem Befehl auf, der erst nach seinen eigenen internen Prüfungen ausschließlich einen Vertragsdatensatz ausgibt:

run_remote_check \
  deploy@web-01 \
  'RELEASE_TARGET=/srv/example/releases/2025.06.14' \
  '/usr/local/sbin/activate-release 2025.06.14'

Führe danach eine anschließende Lesung als separate Aktion aus. Halte sie in Logs und Statusmeldungen getrennt. Wenn die Aktivierung gelingt, aber die Dienstprüfung fehlschlägt, sollten Operatoren genau diese Grenze sehen. Ein undurchsichtiges Ergebnis wie «Deployment fehlgeschlagen» zwingt sie dazu, Befehle erneut auszuführen, nur um herauszufinden, was bereits passiert ist.

Bei Befehlen, die strukturierte Daten zurückgeben, solltest du ein kleines JSON-Objekt zurückgeben und mit einem JSON-Parser verarbeiten. Verwende grep nicht für JSON, außer die Ausgabe ist bewusst ein einzeiliger Sentinel und du musst ihre Felder nicht interpretieren. Zeichenkettenvergleiche mit beliebigem JSON brechen, wenn sich Leerzeichen, Reihenfolge oder maskierte Inhalte ändern.

Der Vertrag sollte außerdem das Zielobjekt benennen. status=ok allein unterscheidet Release 2025.06.14 nicht vom gestrigen Release. Nimm die Deployment-ID, den Hostnamen, sofern relevant, die Objektversion oder die Operations-ID auf. Dieses kleine Detail verhindert einen erstaunlich häufigen Fehlalarm: Eine Prüfung bestätigt, dass irgendein gesunder Zustand existiert, aber nicht, dass es der Zustand ist, den dieser Lauf gerade verändert hat.

Beobachtbarkeit muss das Verifizierungsergebnis erhalten

Ein Log, das nur den Remote-Befehl und den Exit-Status aufzeichnet, lässt die wichtigste Frage offen: Hat der Aufrufer den gewünschten Zustand unabhängig beobachtet? Zeichne die Verifizierungsaktion und ihr Ergebnis neben der Änderung auf.

Bei einem Deployment kann ein nützlicher Datensatz den Zielhost, die Release-ID, den SSH-Status, den Befehlsstatus, den exakten Vertragsdatensatz, den Status des Folgekommandos und ein kurzes Ergebnis der Gesundheits- oder Zustandsprüfung enthalten. Protokolliere keine Geheimnisse, vollständigen Autorisierungs-Header oder privaten Befehlsargumente, nur weil sie bei der Fehlersuche nützlich sind. Gestalte die Befehlsschnittstelle so, dass aussagekräftige Nachweise sicher gespeichert werden können.

Sallyport führt ein Activity-Journal für einzelne Aktionen und ein Sessions-Journal für Agent-Läufe. Beide werden aus einem verschlüsselten, durch Hashes verketteten Audit-Log erstellt. Dadurch kann ein Operator eine ausgeführte SSH-Aktion von einer Verifizierungsaktion unterscheiden, die ein Ergebnis bestätigt hat, statt einen einzelnen erfolgreichen Aufruf als vollständige Geschichte zu behandeln.

Manipulationsnachweise helfen bei der Frage, ob ein aufgezeichneter Vorgang nachträglich verändert wurde. Sie machen aus einem schwachen Befehlsvertrag aber keinen Beweis für ein gutes Ergebnis. sp audit verify kann die Log-Kette offline über dem Chiffretext prüfen. Das Aktionsdesign braucht trotzdem eine ausdrückliche Read-back-Prüfung.

Halte die Verifizierung nah genug an der Änderung, damit ein anderer Akteur den gewünschten Zustand nicht unbemerkt in der Zwischenzeit ersetzen kann. Auf einem gemeinsam genutzten System lassen sich Wettlaufsituationen nicht immer beseitigen. Du kannst sie durch unveränderliche Release-IDs, Operations-IDs, Versionsprüfungen und APIs mit bedingten Aktualisierungen verringern. Wenn sich der Zustand erneut ändern kann, speichere die beobachtete Version oder den Zeitstempel und lass spätere Automatisierung diese Information vor einer Aktion prüfen.

Vor Wiederholungen müssen Retries den Zustand abgleichen

Ein Timeout, eine abgebrochene Verbindung oder ein unterbrochener CI-Lauf erzeugt ein unbekanntes Ergebnis. Der Remote-Host kann die Änderung abgeschlossen haben, sie noch ausführen oder auf halbem Weg gescheitert sein. Dass der Aufrufer keine Ausgabe mehr empfängt, sagt allein nichts darüber aus.

Löse diese Unsicherheit nicht mit einer blinden Wiederholung. Führe zuerst einen schreibgeschützten Abgleichsbefehl aus, der den Remote-Zustand einordnet. Bei der Aktivierung eines Releases prüfst du den aktuellen symbolischen Link und die Dienstgesundheit. Bei einer Migration fragst du eine Migrationstabelle ab. Bei einer erstellten Ressource suchst du mit einer vom Aufrufer erzeugten Operations-ID. Bei einer Geheimnisrotation prüfst du, welche Version die Verbraucher tatsächlich verwenden, bevor du eine weitere erzeugst.

Ein guter Abgleichsbefehl gibt eine kleine, klar definierte Menge an Ergebnissen zurück:

• completed: Der Zielzustand entspricht der angeforderten Operation.
• running: Die Operation arbeitet noch, und der Aufrufer sollte warten.
• absent: Es gibt keine Hinweise auf die Operation, daher kann eine Wiederholung angemessen sein.
• conflict: Ein anderer Zustand ist vorhanden, und ein Mensch oder übergeordneter Controller muss entscheiden.

Zwinge nicht jedes Ergebnis in Erfolg oder Fehler. running und conflict sind nützliche Ergebnisse. Ein System, das sie als Fehler bezeichnet, wiederholt häufig Arbeit, die besser unangetastet geblieben wäre.

Idempotenz senkt die Kosten legitimer Wiederholungen, aber der Begriff wird oft falsch verwendet. Ein Befehl ist idempotent, wenn eine Wiederholung derselben Anfrage den gewünschten Zustand nach der ersten erfolgreichen Ausführung unverändert lässt. ln -sfn kann für ein bestimmtes Linkziel idempotent sein. «Ein neues Backup mit der aktuellen Uhrzeit erstellen» ist es nicht. «Eine E-Mail versenden» ist es ebenfalls nicht, es sei denn, das nachgelagerte System dedupliziert anhand einer stabilen Nachrichten-ID.

Baue die Read-back-Prüfung ein, bevor du Retries hinzufügst. Wenn du nicht sagen kannst, wie eine abgeschlossene Operation erkannt wird, kannst du Wiederholungen nach einer unklaren Situation nicht sicher automatisieren. An diesem Punkt ist SSH-Automatisierung keine bloße Shell-Annehmlichkeit mehr, sondern braucht ein Operationsmodell.

Die erste Reparatur besteht darin, deine grünen Läufe zu prüfen

Beginne mit Remote-Befehlen, die den Produktionszustand verändern und derzeit nur einen grünen Exit-Code melden. Schreibe für jeden Befehl auf, welches Remote-Objekt sich ändern muss, welcher exakte Zustand als Erfolg zählt, welche Komponente diesen Zustand lesen kann und was nach einem Timeout unklar bleibt.

Ändere danach die Befehlsschnittstelle so, dass sie nach ihren eigenen Prüfungen einen exakten Ergebnisdatensatz ausgibt. Füge eine separate Read-back-Aktion hinzu. Bewahre beide Ergebnisse im Laufdatensatz auf. Du wirst Befehle finden, die nie synchron waren, Skripte, deren abschließendes printf einen früheren Fehler verbarg, und Deployment-Prüfungen, die den Rechner abfragten, auf dem der Befehl gestartet wurde, statt den Rechner, der ihn empfangen hatte.

Ein Exit-Status von null hat weiterhin seinen Platz. Er ist die erste Schranke, nicht das abschließende Urteil. Wer ihn so behandelt, erhält Automatisierung, die erklären kann, was passiert ist, wenn sich das einfache grüne Signal als falsch herausstellt.