# Ein lokales Aktionsgateway aktualisieren, ohne die Arbeit von Agenten zu unterbrechen

Ein Update des Aktionsgateways ist eine Änderung an der Steuerungsebene und keine routinemäßige Desktop-Pflege. Wenn ein Agent gerade eine Repository-Änderung, einen HTTP-Schreibvorgang oder eine SSH-Operation ausführt, kann das Update eine Arbeitseinheit in zwei unsichere Hälften teilen. Der sichere Weg besteht darin, eine Arbeitsgrenze festzulegen, aktive Aktionen bewusst auslaufen zu lassen oder zu stoppen und nachzuweisen, dass die neue Version Arbeit autorisieren, ausführen und verbuchen kann, bevor die Automatisierung weiterläuft.

Der häufigste Fehler besteht darin, jeden aktiven Agenten als entbehrlich zu behandeln. Manche sind es. Andere halten einen sorgfältig erstellten Plan, eine offene Remote-Shell oder eine Anfrage, deren Ergebnis der Aufrufer noch nicht erhalten hat. Sie müssen wissen, mit welcher Art von Prozess Sie es zu tun haben, bevor Sie die Anwendung anfassen.

## Updates an einer Arbeitsgrenze einplanen

Ein gutes Wartungsfenster beginnt, wenn der Agent einen Zustand erreicht hat, den ein Mensch verstehen und fortsetzen kann. Die Grenze bedeutet nicht, dass jede Aufgabe abgeschlossen sein muss. Sie bedeutet, dass die nächste Person, der nächste Prozess oder der nächste Agent erkennen kann, was geschehen ist, was noch fehlt und was nicht wiederholt werden darf.

Bitten Sie den Agenten zuerst, keine neuen externen Aktionen mehr anzunehmen. Lassen Sie ihn dann eine kurze Übergabe im Repository, Ticket oder in den Notizen für Betreiber schreiben. Diese Übergabe sollte den aktuellen Branch und Commit, geänderte aber noch nicht committete Dateien, bereits ausgeführte Tests, kontaktierte entfernte Systeme und die nächste geplante Aktion nennen. Das ist hilfreicher als ein Transkript, aus dem jemand die Absicht aus Hunderten von Tool-Aufrufen rekonstruieren muss.

Ein sinnvolles Update-Fenster hat vier Phasen:

1. Einen Stopp für neue Agent-Läufe und neue Aufrufe mit Zugangsdaten ankündigen.
2. Begrenzte Arbeit auslaufen lassen oder an einer aufgezeichneten Grenze stoppen.
3. Das Update durchführen und mit einem neuen Agent-Prozess eine kleine Zahl von Prüfungen ausführen.
4. Die Sperre erst aufheben, wenn die Aktivität während des Fensters abgeglichen wurde.

Warten Sie bei einem Sicherheitsfehler des Gateways, der Zugangsdaten oder Autorisierung betrifft, nicht auf einen Kalendereintrag. Stoppen oder widerrufen Sie zuerst gefährdete Arbeit, dokumentieren Sie die Unterbrechung und aktualisieren Sie nach den Regeln eines Vorfalls. Erfinden Sie aber keine Dringlichkeit, nur weil eine neue Version verfügbar ist. Häufige beiläufige Updates bringen Teams dazu, die Prüfungen zu überspringen, die falsche Annahmen aufdecken.

Bei routinemäßiger Wartung ist ein Zeitpunkt sinnvoll, nachdem der Agent seinen Code committet hat und bevor er mit Deployment, Datenmigration, Kontoänderungen oder Bereinigung auf entfernten Systemen beginnt. Eine lokale Codeänderung lässt sich meist fortsetzen. Eine halb abgeschlossene Berechtigungsänderung oft nicht.

Für das Fenster brauchen Sie außerdem eine verantwortliche Person. Sie entscheidet, wann die Arbeit eingefroren wird, bewertet unklare Ergebnisse und erklärt das Gateway für bereit. Ein Chatkanal voller Menschen, die annehmen, jemand anderes habe das Update überwacht, ist kein Betriebsmodell.

## Prozessautorisierung und Abschluss einer Aktion getrennt betrachten

Ein genehmigter Agent-Prozess und eine abgeschlossene externe Aktion beantworten unterschiedliche Fragen. Sie werden oft vermischt, weil beides ungefähr zur selben Zeit sichtbar wird. Für die Wiederherstellung nach einer Unterbrechung ist die Unterscheidung jedoch entscheidend.

Die Prozessautorisierung fragt: «Darf dieses bestimmte laufende Programm das Gateway um eine Aktion bitten?» Der Abschluss einer Aktion fragt: «Hat das entfernte System diese bestimmte Anfrage angenommen und abgeschlossen?» Ein Neustart der Anwendung kann die erste Antwort ändern. Ein Netzwerkfehler kann die zweite Antwort verbergen. Keine der beiden Antworten lässt sich aus der anderen ableiten.

Notieren Sie bei HTTP-Aufrufen, ob eine Operation sicher wiederholt werden kann. Eine Leseanfrage ist das meistens. Einen Benutzer anlegen, eine Zahlung senden, ein Release veröffentlichen oder einen Zugangsschlüssel austauschen kann man dagegen möglicherweise nicht sicher wiederholen. Wenn der Agent nach dem Absenden einer solchen Anfrage in ein Timeout läuft, muss er das Zielsystem nach dem entstandenen Objekt oder Ereignis fragen, bevor er es erneut versucht. Ein erneuter Versuch, nur weil der Tool-Aufruf kein sichtbares Ergebnis hat, erzeugt doppelte Arbeit.

SSH hat eigene Fehlerbilder. Ein Terminal kann einen Vordergrundbefehl, einen Hintergrundjob, einen Editorpuffer, eine Datenbanktransaktion oder ein Deployment-Tool enthalten, das nach dem Verbindungsabbruch weiterläuft. Bitten Sie den Agenten vor der Wartung, den entfernten Host, das Arbeitsverzeichnis, den aktuellen Befehl und alle Job-IDs zu melden. Wenn er einen langen Vorgang gestartet hat, entscheiden Sie, ob Sie warten, ihn über einen ausdrücklich angegebenen Remote-Befehl beenden oder an einen überwachten Prozess übergeben, der die Shell überlebt.

Starten Sie das Gateway nicht einfach neu, um vage «aufzuräumen». Das schafft Unsicherheit, ohne die beabsichtigte Beendigung zu dokumentieren. Widerrufen oder beenden Sie den konkreten Agent-Lauf, wenn Sie ihn stoppen wollen, und lassen Sie den Agenten angeben, was er zuletzt beobachtet hat.

Eine praktische Übergabenotiz kann ganz schlicht aussehen:

```text
Agent run: release-fix
Repository state: commit 4f2c... created, working tree clean
Remote work: SSH command started on build host, job ID 8127
HTTP writes: staging deployment request accepted, status still pending
Safe next action: query deployment status; do not submit another deployment
```

Dieses Dokument gibt dem Betreiber eine Möglichkeit, die Lage nach dem Update zu prüfen. Ohne diese Notiz starten Teams den Agenten häufig neu und verwechseln eine frische Erklärung mit Kontinuität.

## Neue Arbeit einfrieren, bevor alte Arbeit ausläuft

Eine Wartungssperre funktioniert nur, wenn sie den Eingang für neue Arbeit schließt. Entwickler höflich aufzufordern, keinen weiteren Agenten zu starten, ist unzuverlässig, besonders wenn Editor-Integrationen, Terminals und geplante Skripte Prozesse unabhängig voneinander starten können.

Erfassen Sie vor der Sperre jeden aktiven Agent-Prozess. Halten Sie genug Informationen fest, um die Prozesse zu unterscheiden: Wer hat ihn gestartet, welches Repository oder welche Aufgabe gehört ihm, welchen externen Zugriff soll er haben und führt er gerade Arbeit aus? Wenn das Gateway eine Sitzungsansicht anbietet, verwenden Sie sie als primäre Aufzeichnung. Ergänzen Sie sie um den menschlichen Aufgabenverantwortlichen, denn ein Prozessdatensatz sagt nicht, ob eine unfertige Änderung noch gewünscht ist.

Teilen Sie die aktive Arbeit anschließend in drei Gruppen ein:

- Arbeit ohne externe Nebenwirkung kann sofort stoppen.
- Kurze, beobachtbare Aktionen können unter Aufsicht fertig werden.
- Lange laufende oder nicht umkehrbare Vorgänge brauchen eine ausdrückliche Entscheidung des Aufgabenverantwortlichen.

Lassen Sie das Auslaufen nicht endlos dauern. Setzen Sie eine Frist, die zur Operation passt. Eine Anfrage, die in Sekunden fertig sein sollte, aber viel länger läuft, ist bereits eine Untersuchung und kein Grund, die Wartung unbegrenzt zu verschieben. Erfassen Sie ihre Kennungen und ermitteln Sie ihren Zustand beim entfernten Dienst.

Ein Agent, der während der Sperre weiter lokale Änderungen erzeugt, kann auch dann Verwirrung stiften, wenn er keine externen Tools aufrufen kann. Bitten Sie ihn, nach dem Schreiben der Übergabe sauber zu stoppen. Wenn der Kontext erhalten bleiben soll, bewahren Sie die Aufgabennotizen und den Repository-Zustand auf, statt sich auf eine ununterbrochene Prozesslaufzeit zu verlassen.

Sallyport erfasst Agent-Läufe in seinem Sitzungsjournal und einzelne Aufrufe in seinem Aktivitätsjournal. Nutzen Sie diese Aufzeichnungen, um die Arbeit zu identifizieren, deren Abschluss Sie bewusst erlaubt haben, statt dies später aus dem Scrollback eines Terminals abzuleiten.

## Unklare Netzwerkergebnisse wie einen Vorfall behandeln

Wenn eine Anfrage während eines Updates ihre Antwort verliert, bleibt ihr Ergebnis unbekannt, bis das entfernte System etwas anderes mitteilt. Sie als fehlgeschlagen zu bezeichnen, weil der lokale Client einen Fehler gesehen hat, ist eine kostspielige Abkürzung.

Angenommen, ein Agent sendet eine API-Anfrage zum Erstellen eines Deployments und das lokale Gateway wird geschlossen oder neu gestartet, bevor die Antwort eintrifft. Vier Ergebnisse sind weiterhin möglich: Die Anfrage hat den Rechner nie verlassen, der Dienst hat sie abgelehnt, der Dienst hat sie angenommen, aber noch nicht beendet, oder der Dienst hat sie abgeschlossen. Die lokale Fehlermeldung unterscheidet diese Fälle nicht zuverlässig.

Lösen Sie die Unklarheit in dieser Reihenfolge:

1. Finden Sie die Anfrage-ID, den Deployment-Namen, den Commit-Verweis oder einen anderen Korrelationswert, den der Agent verwendet hat.
2. Fragen Sie den entfernten Dienst mit einer neuen, überwachten Aktion nach diesem Wert.
3. Vergleichen Sie das Ergebnis des entfernten Systems mit der beabsichtigten Änderung und dem Auditdatensatz.
4. Wiederholen Sie die Anfrage nur, wenn das entfernte System zeigt, dass keine gleichwertige Operation stattgefunden hat.

Darum ist Idempotenz wichtig. Wenn eine API ein Idempotenz-Token oder eine vom Client gelieferte Anfrage-ID unterstützt, sollte der Agent dieses bei Schreiboperationen verwenden. Dasselbe Token macht aus einem unsicheren Wiederholungsversuch eine abfragbare Operation. Unterstützt eine API dies nicht, verwenden Sie einen Objektnamen oder eine Änderungsreferenz, mit der ein Mensch feststellen kann, ob der erste Versuch wirksam wurde.

Die Spezifikation für HTTP-Semantik, RFC 9110, definiert idempotente Methoden anhand der beabsichtigten Wirkung wiederholter Anfragen, nicht anhand der Frage, ob der Server jedes Mal dieselbe Antwort zurückgibt. Das ist hilfreich, macht aber nicht jedes `PUT` oder `DELETE` in Ihrer Umgebung harmlos. Eine wiederholte Anfrage kann weiterhin Benachrichtigungen auslösen, mit einem anderen Schreiber konkurrieren oder eine Ressource löschen, die ein anderer Akteur neu angelegt hat. Betrachten Sie die RFC-Klassifizierung als Ausgangspunkt und berücksichtigen Sie dann das Verhalten des Zieldienstes.

Sammeln Sie bei SSH Belege vom entfernten Host. Prüfen Sie Prozesstabellen, Dienstprotokolle, Deployment-Status, Transaktionsstatus und vom Befehl erzeugte Dateien. Bitten Sie den Agenten nicht, einen Shell-Befehl einfach deshalb erneut auszuführen, weil seine lokale Sitzung verschwunden ist. Shell-Befehle verfügen selten über die Wiederholungssicherungen moderner APIs.

## Das Release prüfen, bevor es in den Aktionspfad gelangt

Ein signiertes Anwendungspaket zeigt, wer den Code signiert hat und ob das Paket nach der Signatur verändert wurde. Es zeigt nicht, ob das Release Ihr Tresorformat, Sitzungsverhalten, die Kompatibilität von Helfern oder den Ablauf für Betreiber beibehält.

Apple Platform Security erklärt, dass Codesignaturen macOS ermöglichen, signierten Code zu erkennen und Veränderungen festzustellen. Das ist für eine Anwendung, die Zugangsdaten verarbeitet, eine notwendige Eigenschaft. Es ersetzt jedoch keine Versionshinweise, keinen Testlauf und keinen Wiederherstellungsplan. Teams schreiben Signaturen oft zu viel Magie zu, weil die kryptografische Prüfung klar und sichtbar ist, während die betriebliche Kompatibilität es nicht ist.

Lesen Sie vor dem Fenster die Versionshinweise auf Änderungen in diesen Bereichen:

- Speicherung oder Migration des Tresors
- Autorisierung und Sitzungsverwaltung
- enthaltene Befehlshelfer und Verbindungsdetails der Agenten
- Speicherung, Export oder Prüfung von Audits
- macOS-Versionen und Berechtigungen

Halten Sie die laufende und die Zielversion in der Wartungsnotiz fest. Entscheiden Sie außerdem, was zum Abbruch führt: ein Fehler beim Entsperren des Tresors, beim Aufbau einer neuen genehmigten Agent-Sitzung, eine unerwartete Aktionsverweigerung oder ein Fehler bei der Audit-Prüfung sind alles gültige Abbruchbedingungen.

Ein Rollback-Plan braucht mehr als eine alte Anwendungskopie. Er braucht eine Regel, wann sie verwendet wird, und einen Plan für den Zustand, den die neue Version möglicherweise verändert hat. Wenn ein Release lokale Daten migriert, kann ein Rollback ohne Anweisungen des Anbieters aus einem behebbaren Problem einen Datenverlust machen. Testen Sie den genauen Upgrade-Pfad auf einem Ersatz-Mac oder einer unkritischen Einrichtung, wenn sich Speicher- oder Autorisierungsverhalten ändert. Eine saubere Neuinstallation sagt fast nichts über den Zustand aus, den Sie tatsächlich betreiben.

Testen Sie nicht mit dem Zugang, der den größten Schaden verursachen könnte. Beginnen Sie mit einem Konto, das nur einen ungefährlichen Lesezugriff hat, oder mit einem wegwerfbaren Endpunkt. Sie prüfen den Weg durch Anwendung, Autorisierung, Einfügen der Zugangsdaten und Verarbeitung des Ergebnisses. Ein Produktions-Deployment ist nicht nötig, um nachzuweisen, dass eine Menüleisten-App gestartet wurde.

## Nach dem Update mit einem neuen Agent-Prozess prüfen

Ein Test nach dem Update sollte die Wege nachweisen, die aktive Agenten verwenden werden, und nicht nur zeigen, dass sich die Oberfläche öffnet. Starten Sie einen neuen Agent-Prozess, damit Sie genau die Autorisierungsgrenze prüfen, die nach der Wartung gelten soll.

Prüfen Sie zuerst die Tresorsperre. Sperren und entsperren Sie den Tresor über den normalen lokalen Ablauf. Versuchen Sie im gesperrten Zustand die sichere Testaktion und bestätigen Sie, dass das Gateway sie verweigert. Entsperren Sie den Tresor anschließend und prüfen Sie, ob ein neuer Prozess den erwarteten Autorisierungsdialog oder Genehmigungsweg erhält. So erkennen Sie die falsche Annahme, eine alte Genehmigung sei erhalten geblieben, oder die neue Version könne den aufrufenden Prozess nicht identifizieren.

Führen Sie danach einen sicheren HTTP-Aufruf und einen sicheren SSH-Aufruf aus, wenn Ihr Team beide Kanäle nutzt. Ein sinnvoller HTTP-Test fragt einen schreibgeschützten Endpunkt mit einem eindeutig erkennbaren Ergebnis ab. Ein sinnvoller SSH-Test führt auf einem unkritischen Host einen ungefährlichen Befehl aus, etwa die Ausgabe des aktuellen Verzeichnisses oder einer festen Markierung. Notieren Sie Zeit, Ziel und Ergebnis, damit Sie die Aufrufe später im Aktivitätsverlauf finden.

Sallyport bewahrt Zugangsdaten in seinem verschlüsselten Tresor auf und führt HTTP- und SSH-Aktionen selbst aus. Der Agent erhält also das Ergebnis und nicht das Geheimnis. Das verringert, was der Update-Test offenlegen muss, ersetzt aber nicht den Test jedes benötigten Kanals.

Prüfen Sie zum Schluss die Auditspur. Führen Sie den dokumentierten Offline-Prüfbefehl aus:

```sh
sp audit verify
```

Die erwartete Ausgabe sollte eine erfolgreiche Prüfung der Auditkette melden. Verlassen Sie sich nicht auf einen gemerkten Satz und parsen Sie die Ausgabe nicht in einem fragilen Skript, sofern die Dokumentation kein stabiles maschinenlesbares Format verspricht. Das wichtige Ergebnis ist einfach: Der Befehl endet erfolgreich, meldet eine erfolgreiche Prüfung und die absichtlich ausgeführten Testaufrufe sind in den Journalen auffindbar.

Wenn die Prüfung fehlschlägt, stoppen Sie. Ignorieren Sie den Fehler nicht, nur weil die Anwendung weiterhin eine Anfrage ausführen kann. Eine Auditkette, die sich nach der Wartung nicht prüfen lässt, nimmt Ihnen genau dann Belege, wenn Sie die Änderung verstehen müssen.

## Jede Aktion abgleichen, die das Wartungsfenster überschritten hat

Das Update endet erst, wenn Sie Aktionen berücksichtigt haben, die vor der Sperre begonnen, währenddessen weitergelaufen oder nach dem Start der neuen Version erschienen sind. Bei diesem Abgleich entdecken sorgfältige Betreiber den Wiederholungsversuch, der einen API-Aufruf dupliziert hat, oder den SSH-Job, der unbemerkt weiterlief.

Erstellen Sie im Wartungsprotokoll eine kurze Tabelle. Notieren Sie für jeden Agenten, der zu Beginn aktiv war, die geplante letzte Aktion, das beobachtete Ergebnis, die Quelle, die es bestätigt, und ob ein Mensch einen Wiederholungsversuch erlaubt hat. Die Quelle kann ein Aktivitätsdatensatz, eine Statusseite des entfernten Dienstes, ein Hostprotokoll oder ein Repository-Commit sein. Wenn zwei Quellen widersprechen, behandeln Sie das entfernte System als maßgeblich für den externen Zustand und untersuchen Sie die Abweichung.

Achten Sie besonders auf langsam antwortende Aktionen. Ein Gateway kann protokollieren, dass es eine Anfrage gesendet hat, während das Zielsystem noch den Status «ausstehend» meldet. Das ist kein Widerspruch. Es zeigt, wie weit die Aktion gelangt ist, nicht ob ein asynchroner Remote-Job beendet wurde. Überwachen Sie ihn über den normalen Statusmechanismus des Zielsystems, bis er einen Endzustand erreicht oder der Aufgabenverantwortliche übernimmt.

Sitzungsaufzeichnungen helfen bei der Frage, wer während des Fensters autorisiert war. Aktivitätsaufzeichnungen helfen bei der Frage, welche Aufrufe stattgefunden haben. Ersetzen Sie nicht das eine durch das andere. Ein genehmigter Prozess kann keine Aufrufe ausführen; ein abgeschlossener Aufruf kann vor dem Öffnen des Wartungsprotokolls begonnen haben.

Der Abgleich sollte außerdem unerwartete Aufrufer sichtbar machen. Ein neuer Prozess, der während der Sperre auftaucht, bedeutet, dass die Sperre unvollständig war, selbst wenn sein Aufruf keinen Schaden verursacht hat. Finden Sie den Startweg vor dem nächsten Fenster. Es kann ein Entwicklerterminal, eine Editor-Erweiterung oder ein unbeaufsichtigtes lokales Skript sein, das niemand als Teil des Agentenablaufs betrachtet hat.

## Genehmigungsgrenzen nach dem Update beibehalten

Updates sind ein verlockender Zeitpunkt, Kontrollen zu lockern, weil Betreiber Tests schnell erfolgreich abschließen wollen. Machen Sie eine weitreichende Genehmigung nicht zur dauerhaften Lösung für einen lauten Ablauf.

Eine sitzungsbezogene Autorisierung passt zur normalen Agent-Arbeit, wenn ein bekannter Prozess mehrere zusammengehörige Aufrufe benötigt. Der Betreiber kann diesen Lauf erkennen und genehmigen und seine Aktivität anschließend als Einheit prüfen. Eine Bestätigung pro Aufruf passt zu Zugangsdaten, bei denen jede Verwendung eine bewusste menschliche Entscheidung verdient, etwa bei Änderungen an Produktionszugängen, beim Löschen von Daten oder beim Auslösen eines nicht umkehrbaren externen Ereignisses.

Der Fehler besteht darin, die strengere Einstellung nach einem Vorfall als Strafe zu aktivieren und sie dann für alltägliche, risikoarme Lesezugriffe beizubehalten, bis Menschen Aufforderungen ungesehen bestätigen. Wiederholte Genehmigungen bringen Menschen dazu, genau den Bildschirm wegzuklicken, der sie eigentlich innehalten lassen soll. Aktivieren Sie die Bestätigung pro Aufruf für Zugangsdaten, bei denen eine falsche Aktion teuer wäre. Belassen Sie den Rest unter Sitzungsprüfung und begrenzen Sie den Umfang der Zugangsdaten, wo immer möglich.

Die Tresorsperre sollte eine absolute Unterbrechung bleiben. Sperren Sie den Tresor bei geplanter Wartung, wenn Sie eine harte Grenze brauchen, die alle Aktionen verweigert. Entsperren Sie ihn zur Prüfung erst, wenn der ausgewählte Testprozess bereitsteht. So wird aus einem großen Wartungsereignis eine kleine Zahl beobachteter Aktionen.

Verwechseln Sie ein Aktionsgateway nicht mit einer allgemeinen Richtlinien-Engine. Ein Gateway kann Zugangsdaten von einem Agenten fernhalten und einen Menschen an Autorisierungsgrenzen setzen. Es kann nicht die geschäftliche Bedeutung jedes API-Aufrufs erkennen, einen fehlerhaften Deployment-Plan reparieren oder wissen, dass ein harmlos wirkender Endpunkt einen teuren nachgelagerten Ablauf auslöst. Diese Entscheidungen bleiben beim Aufgabenverantwortlichen.

## Das Runbook für die tatsächliche Unterbrechung schreiben

Ein brauchbares Runbook sagt nicht «Gateway aktualisieren und testen». Es nennt die Belege, die Sie erfassen, die Entscheidungen, die Sie bei Unsicherheit treffen, und den genauen Punkt, an dem autonome Arbeit fortgesetzt werden darf.

Halten Sie das Runbook so kurz, dass jemand es unter Druck verwendet. Mein Runbook enthält eine verantwortliche Person für die Sperre, eine Liste aktiver Läufe, eine ausdrückliche Regel für aktive SSH-Sitzungen und unklare HTTP-Schreibvorgänge, die Zielversion, eine Rollback-Entscheidung, Tests mit einem neuen Prozess, die Audit-Prüfung und den Abgleich. Außerdem gibt es einen Platz für die unangenehme Frage, die immer auftaucht: «Wurde diese Aktion beendet, bevor wir sie unterbrochen haben?»

Wenn Sie diese Frage nicht anhand der Agent-Übergabe, des Aktivitätsdatensatzes und des Zielsystems beantworten können, starten Sie den Agenten nicht mit der Erlaubnis neu, die Aktion zu wiederholen. Halten Sie die Aufgabe an und klären Sie zuerst den externen Zustand. Diese Disziplin kostet einige Minuten und ist wesentlich schneller, als zwei Deployments, zwei Zugriffsänderungen oder einen Remote-Befehl zu entwirren, von dem sowohl Agent als auch Betreiber glaubten, er sei beendet.

Die erste Verbesserung ist einfach: Jeder Agent, der externe Systeme erreichen kann, muss vor der Wartung eine fortsetzbare Übergabe hinterlassen. Sobald das Routine ist, hängen Release-Zeitpunkt, Autorisierung, Update-Tests und Wiederherstellung nicht mehr vom Gedächtnis einer Person an ein Terminalfenster ab.