# Rollback-Endpunkte für autonome Deployments ohne Kollisionen Autonome Deployment-Agenten brauchen die Berechtigung, sicher zu scheitern, nicht die Berechtigung, zu raten. Ein gefährlicher Rollback ist selten ein Befehl, der fehlschlägt. Gefährlich ist ein Befehl, der erfolgreich ausgeführt wird, nachdem sich die Welt verändert hat, und ein altes Artefakt über ein Release legt, das der Agent nicht erstellt hat. Eine sichere Rollback-Aktion identifiziert einen bestimmten Deployment-Versuch, benennt ein bestimmtes früheres Release und verweigert die Ausführung, wenn ihre Sicht auf den aktuellen Zustand veraltet ist. Behandeln Sie einen Rollback als abgesicherte Zustandsänderung, nicht als Abkürzung zu «der letzten guten Version». Diese Unterscheidung entscheidet, ob ein Agent seine eigene Arbeit repariert oder die Arbeit eines anderen löscht. ## Ein Rollback muss zu einem Deployment-Versuch gehören Rollback-Endpunkte müssen die Rücksetzung an den Deployment-Versuch binden, der den vermuteten Fehler verursacht hat. Eine Versionsnummer allein reicht dafür nicht aus. Teams speichern oft eine Folge wie `1.8.4`, `1.8.5` und `1.8.6` und stellen dann eine Operation bereit, die sagt: «Deploye `1.8.4` in die Produktion.» Ein Agent deployt `1.8.5`, erhält einen Alarm und ruft diese Operation auf. Inzwischen hat ein Engineer das dringende Release `1.8.6` deployt. Der Rollback-Endpunkt akzeptiert die Anfrage, weil `1.8.4` existiert. In der Produktion läuft nun ein Artefakt, das vor beiden Änderungen entstanden ist. Die API hat genau getan, was man ihr gesagt hat. Das ist das Problem. Halten Sie diese Identitäten getrennt: - Ein **Release** ist ein unveränderliches Paket aus Code, Konfigurationsverweisen und Metadaten. Geben Sie ihm eine dauerhafte ID und einen Artefakt-Digest. - Ein **Deployment-Versuch** ist eine einzelne Anfrage, ein Release in ein benanntes Ziel zu bringen. Er hat eine Deployment-ID, einen Akteur und einen Lebenszyklus. - Der **Zielzustand** beschreibt, was die Umgebung aktuell ausführt. Er enthält eine Revision oder Generation, die sich bei jeder akzeptierten Zustandsänderung ändert. - Eine **Rollback-Absicht** besagt, dass Deployment-Versuch `D` das Ziel-Release `R` nur dann wiederherstellen darf, wenn `D` den aktuellen Zustand weiterhin besitzt. Das oft vergessene Feld ist die Verknüpfung zum Besitzer. Wenn Deployment `dep_842` das Release `rel_105` ausrollt, speichern Sie, dass `dep_842` die aktuelle Zielgeneration `gen_913` erstellt hat. Ein an `dep_842` gebundener Rollback darf nur ausgeführt werden, solange `gen_913` aktuell bleibt. Erstellt ein späteres Deployment `gen_914`, muss der Dienst die alte Anfrage ablehnen. Leiten Sie den Besitz nicht aus Zeitstempeln ab. Die Reihenfolge von Uhrzeiten versagt bei Wiederholungen, Warteschlangen, manuellen Reparaturen und in jedem System, in dem ein Benutzer ein älteres Release auswählen kann. Speichern Sie die direkte Beziehung, sobald Sie das Ausrollen akzeptieren. Damit lässt sich auch eine unangenehme operative Frage beantworten: Kann ein Agent das Deployment eines anderen Agenten zurücksetzen? Normalerweise nicht. Eine separate Instanz kann diesen Eingriff ausdrücklich genehmigen, aber die gewöhnliche Rollback-Berechtigung sollte nur Aktionen abdecken, die der Aufrufer selbst gestartet hat. Eine weitreichende Berechtigung wirkt bequem, bis zwei Deployment-Schleifen auf denselben Vorfall reagieren. ## Unveränderliche Herkunft macht das frühere Release eindeutig Der Dienst muss die Herkunft des Rollbacks erfassen, bevor er das Ziel ändert, denn nach dem Ausrollen wird das Wort «vorherig» mehrdeutig. Die Release-Historie erst nach einem Alarm abzufragen, führt leicht dazu, das Release auszuwählen, das zufällig neben einem Eintrag in einer Liste steht. Wenn ein Deployment-Dienst ein Ausrollen akzeptiert, sollte er einen Datensatz anlegen, der das zu diesem Zeitpunkt ausgewählte frühere stabile Release enthält. Dieses Release kann sich vom unmittelbar vorherigen Ereignis unterscheiden. Ein Canary kann beispielsweise `rel_105` ausrollen, während `rel_103` die stabile Basis bleibt und `rel_104` ein abgebrochenes Experiment war. Das richtige Wiederherstellungsziel kann `rel_103` sein, nicht der Eintrag direkt vor `rel_105`. Ein minimaler Datensatz kann so aussehen: ```json { "deployment_id": "dep_842", "environment": "production", "release_id": "rel_105", "artifact_digest": "sha256:8b2c...", "source_revision": "4f1d9c7", "config_digest": "sha256:1a06...", "prior_release_id": "rel_103", "created_target_generation": "gen_913", "migration_set_id": "mig_77", "actor_id": "agent-run-27" } ``` `prior_release_id` ist eine Entscheidung, kein Komfortfeld. Ihr Promotion-Controller sollte es anhand von Regeln auswählen, die Operatoren prüfen können: das zuletzt verifizierte stabile Release für dieses Ziel, gegebenenfalls mit kompatibler Konfiguration und passenden Migrationsanforderungen. Die Rollback-Operation verwendet diese gespeicherte Entscheidung. Sie berechnet sie nicht neu, weil sich die Historientabelle geändert hat. Die Identität eines Artefakts braucht mehr als ein für Menschen lesbares Release-Label. Tags können verschoben werden. Build-Labels können versehentlich wiederverwendet werden. Ein Rollback sollte die im ursprünglichen Versuch gespeicherte unveränderliche Artefaktreferenz oder einen Content-Digest deployen. Wenn Ihre Registry später zulässt, dass ein Tag auf andere Bytes zeigt, muss die Ziel-Release-ID auf einen beim Ausrollen erfassten Digest verweisen. Für die Konfiguration gilt dieselbe Disziplin. Wenn Sie nur die Anwendungscodebytes zurücksetzen, aber ein geändertes Feature-Flag, einen Verweis auf ein Laufzeitgeheimnis, eine Image-Pull-Richtlinie oder eine Ressourceneinstellung beibehalten, kann ein System entstehen, das nie getestet wurde. Sie müssen nicht jeden Wert im Deployment-Datensatz duplizieren. Speichern Sie aber eine unveränderliche Konfigurationsrevision oder einen Digest und definieren Sie, ob der Rollback sie wiederherstellt. Der Datenbankzustand bildet eine eigene Grenze. Ein Release, das nur nullable Spalten hinzufügt, erlaubt oft einen Anwendungs-Rollback. Ein Release, das eine Spalte entfernt, Werte neu schreibt oder Bedeutungen ändert, möglicherweise nicht. Versprechen Sie keinen allgemeinen «vollständigen Rollback», wenn der Release-Planer die Kompatibilität nicht nachweisen kann. Kennzeichnen Sie das Deployment als auf Anwendungsebene, im Traffic oder nur durch Reparatur rücksetzbar. Eine Ablehnung ist weniger peinlich, als alten Code gegen ein Schema laufen zu lassen, das er nicht versteht. ## Der Endpunkt braucht ein erwartetes aktuelles Release Eine Rollback-Anfrage muss sowohl das gewünschte Release als auch den aktiven Zustand enthalten, den sie ersetzen soll. Ohne diese Vorbedingung kann der Endpunkt nicht zwischen einer gültigen Wiederherstellung und einer veralteten Anweisung unterscheiden. Verwenden Sie einen Anfragevertrag wie diesen: ```http POST /v1/environments/production/rollbacks Idempotency-Key: 7e4cd1ee-62cb-4efa-985f-4ee0b77d577b Content-Type: application/json { "origin_deployment_id": "dep_842", "expected_current_release_id": "rel_105", "expected_target_generation": "gen_913", "restore_release_id": "rel_103", "reason": "error rate exceeded release threshold", "approval_id": "apr_551" } ``` Der Dienst sollte `restore_release_id` möglichst aus `origin_deployment_id` ableiten und den übermittelten Wert anschließend mit dem gespeicherten `prior_release_id` vergleichen. Beide Felder in der Anfrage helfen Auditoren, die behauptete Absicht des Agenten zu erkennen. Maßgeblich bleibt jedoch der Datensatz auf dem Server. Lassen Sie einen Aufrufer niemals sein eigenes Deployment in eine Erlaubnis verwandeln, irgendein historisches Artefakt auszuwählen. Geben Sie bei Erfolg den neu erstellten Deployment-Versuch und die neue Zielgeneration zurück. Senden Sie keine vage Antwort wie `accepted`, wenn das System die Zustandsänderung synchron reservieren kann. ```json { "rollback_deployment_id": "dep_849", "reverted_deployment_id": "dep_842", "previous_release_id": "rel_105", "current_release_id": "rel_103", "target_generation": "gen_914", "status": "running" } ``` Wenn das aktive Ziel nicht mehr übereinstimmt, geben Sie eine Konfliktantwort zurück. Der Inhalt sollte genügend Informationen enthalten, damit ein Agent den Vorfall melden kann, aber nicht so viel Berechtigung, dass er eigenständig eine neue Aktion improvisiert. ```http HTTP/1.1 409 Conflict Content-Type: application/json { "error": "stale_rollback", "origin_deployment_id": "dep_842", "expected_target_generation": "gen_913", "observed_target_generation": "gen_914", "observed_release_id": "rel_106" } ``` Ein 409 ist ein erfolgreiches Sicherheitsergebnis. Bringen Sie dem Agenten bei, bei diesem Ergebnis anzuhalten, die Antwort an seinen Vorfallsdatensatz anzuhängen und eine neue Entscheidung anzufordern. Geben Sie ihm keine Ausweichanweisung wie «Versuche es noch einmal ohne die erwartete Generation». Damit würde die Ausweichmöglichkeit Ihre Schutzmaßnahme zur bloßen Fassade machen. Manche Teams verwenden stattdessen einen `If-Match`-HTTP-Header mit einem ETag. Das funktioniert, wenn das ETag den Zielzustand darstellt und sich bei jeder Zustandsänderung ändert. Der Mechanismus ist weniger wichtig als die Invariante: Der Befehl muss den Zustand benennen, den er ersetzen darf. ## Serialisierung verhindert Kollisionen zwischen gültigen Anfragen Eine Vorbedingungsprüfung allein schützt ein Ziel nicht, wenn zwei Worker die Prüfung bestehen können, bevor einer von ihnen den Zustand festschreibt. Der Deployment-Dienst muss Änderungen an derselben Umgebung serialisieren und im Zustandsspeicher einen atomaren Compare-and-Swap-Vorgang verwenden. Angenommen, das Ziel lautet aktuell `(rel_105, gen_913)`. Ein Agent sendet einen Rollback und ein Operator sendet `rel_106`. Beide Anfragen lesen `gen_913`. Prüft der Dienst im Anwendungsspeicher und schreibt später bedingungslos, können beide Aufrufe Erfolg melden. Die spätere Schreiboperation gewinnt, und Ihr Audit-Log meldet einen Zustand, den Benutzer möglicherweise nie gesehen haben. Legen Sie Vergleich und Änderung in eine Transaktion oder eine bedingte Schreiboperation. Eine relationale Implementierung könnte diesem Muster folgen: ```sql UPDATE environment_targets SET release_id = :restore_release_id, generation = generation + 1, active_deployment_id = :rollback_deployment_id, updated_at = CURRENT_TIMESTAMP WHERE environment = :environment AND generation = :expected_generation AND release_id = :expected_release_id; ``` Der Dienst prüft die Anzahl der geänderten Zeilen. Eine geänderte Zeile reserviert die Zustandsänderung. Keine geänderte Zeile bedeutet Konflikt. Danach sollte der Dienst das aktuelle Ziel lesen und die beobachteten Werte in der 409-Antwort zurückgeben. Eine Warteschlange ersetzt diese Bedingung nicht. Warteschlangen verringern die Wahrscheinlichkeit paralleler Arbeit, aber doppelte Zustellung, ein manueller Pfad außerhalb der Warteschlange oder ein Worker-Wiederholungsversuch können weiterhin konkurrierende Befehle erzeugen. Die bedingte Schreiboperation muss dort bleiben, wo der Zustand gespeichert wird. Idempotenz löst ein anderes Problem. Ein Agent kann die Antwort verlieren, nachdem der Dienst den Rollback akzeptiert hat. Wiederholt er die Anfrage mit demselben Idempotenzschlüssel, sollte der Dienst den ursprünglichen Rollback und seinen Status zurückgeben. Er darf keine weitere Generation reservieren und keine zweite Ausführung starten. Beschränken Sie die Idempotenz auf Aufrufer und Endpunkt, speichern Sie einen Digest des Anfrageinhalts und lehnen Sie die erneute Verwendung eines Schlüssels mit einem anderen Inhalt ab. Andernfalls kann ein fehlerhafter Client durch die Wiederverwendung einer Kennung eine neue Absicht an eine frühere Anfrage anhängen. ## Ein Rollback kann einen fehlerhaften Abhängigkeitszustand beibehalten Anwendungs-Rollback und Wiederherstellung der Umgebung sind getrennte Vorgänge. Ein Endpunkt, der alten Code deployt, kann nicht automatisch jede Abhängigkeit wieder kompatibel machen. Ich habe die vorhersehbare Variante dieses Fehlers erlebt: Release `rel_105` führte Code ein, der einen neuen Enum-Wert schreibt. Eine Migration verschärfte anschließend eine Datenbankbedingung, sodass nur die neuen Werte zulässig waren. Das Release scheiterte aus einem anderen Grund, und der Operator setzte `rel_103` zurück. Der alte Code schrieb den früheren Wert, die Datenbank lehnte ihn ab, und der Vorfall eskalierte, weil das Deployment-Dashboard den Rollback als abgeschlossen anzeigte. Der Endpunkt hat die Schemaänderung nicht verursacht, aber seine Erfolgsmeldung machte eine falsche Aussage. Vermeiden Sie diese Aussage, indem Sie Release-Metadaten verlangen, die Kompatibilität konkret beschreiben. Erfassen Sie mindestens, ob das wiederherzustellende Release aktuelle Daten lesen und schreiben kann und mit der Konfigurationsrevision des Ziels funktioniert. Auch das Traffic-Management hat eine eigene Falle. Ein Canary-Rollback sollte normalerweise nur die von diesem Canary kontrollierte Traffic-Verteilung ändern. Wenn ein unabhängiges Release den stabilen Pool angepasst hat oder ein anderer Controller eine Routing-Regel geändert hat, kann ein Rollback-Endpunkt, der ein vollständiges Routing-Dokument schreibt, diese Änderungen löschen. Verwenden Sie Versionen auf Ressourcenebene oder ändern Sie nur die Verteilungsfelder, die das Deployment reserviert hat. Dasselbe Prinzip gilt für die Infrastruktur. Wenn ein Release eine Queue, einen Bucket, eine Rolle oder eine Firewall-Regel erstellt hat, die später von anderer Arbeit übernommen wurde, kann das Löschen während der Rücksetzung einen separaten Dienst beschädigen. Für die Bereinigung brauchen Sie einen Ressourcenbesitz-Datensatz und eine Prüfung, dass kein späteres Deployment die Ressource übernommen hat. Wenn sich dieser Besitz nicht nachweisen lässt, lassen Sie die Ressource bestehen und erstellen Sie eine Reparaturaufgabe. Wählen Sie bei irreversiblen Vorgängen eine Vorwärtsreparatur. Der Agent kann ein Feature-Flag deaktivieren, Traffic umleiten oder ein korrigierendes Release deployen. Operatoren mögen diese Antwort nicht, weil «Rollback» schneller klingt. Eine sauber wirkende Rücksetzung, die spätere Daten zerstört, kostet jedoch mehr Zeit als ein Reparaturplan. ## Agenten brauchen enge Berechtigungen und einen sichtbaren Haltepunkt Ein autonomer Agent sollte nur die kleinste Aktionsberechtigung erhalten, die sein Deployment abschließen kann. Er braucht keine rohen Cloud-Zugangsdaten, keine allgemeine Shell mit Produktionszugriff und keinen Endpunkt, der beliebige Release-IDs akzeptiert. Geben Sie dem Agenten beim Start eines Releases ein Deployment-Handle. Dieses Handle kann Statusabfragen, Gesundheitsprüfungen, Traffic-Änderungen innerhalb der für das Deployment reservierten Verteilung und einen Rollback autorisieren, der das ursprüngliche Deployment benennt. Lassen Sie es ablaufen, sobald das Deployment einen Endzustand erreicht, oder wenn ein Mensch den Lauf widerruft. Der Deployment-Dienst muss den Besitz trotzdem serverseitig erzwingen, weil ein Handle kopiert werden kann oder ein Client fehlerhaft sein kann. Die menschliche Genehmigung sollte vor der irreversiblen Grenze erfolgen, nicht nachdem der Agent bereits einen irreversiblen Befehl zusammengestellt hat. Eine sinnvolle Richtlinie verlangt eine Genehmigung, wenn ein Agent ein Produktions-Deployment startet, und erlaubt ihm anschließend, genau dieses Deployment zurückzusetzen, solange die Besitzvorbedingung gilt. Stößt der Agent auf ein späteres Release, braucht er für jeden Eingriff eine neue Genehmigung. Das ist ein sinnvoller Moment zum Anhalten, weil jemand die Situation verändert hat. Sallyport kann HTTP- und SSH-Zugangsdaten aus dem Agent-Prozess fernhalten, während eine Person den Agent-Lauf genehmigt oder eine Zugangsdatenfreigabe für jede Nutzung verlangt. Diese Kontrolle schützt den Aktionspfad, aber der Rollback-Dienst braucht weiterhin eigene Prüfungen von Release und Generation. Die Verwahrung von Zugangsdaten definiert nicht den Besitz eines Deployments. Vermeiden Sie Berechtigungsnamen wie `production:rollback:any`. Sie laden den Aufrufer dazu ein, den Umfang zur Laufzeit zu wählen. Bevorzugen Sie eine serverseitig ausgestellte Berechtigung, die an `dep_842`, die Umgebung `production` und die konkrete Rollback-Route gebunden ist. Fragt der Agent ein anderes Ziel an, sollte die Autorisierungsschicht dies ablehnen, bevor der Deployment-Controller die Anfrage prüft. Protokollieren Sie die Identität des Agent-Prozesses oder Workloads mit jeder Anfrage. Ein Mensch sollte beantworten können, wer `dep_842` gestartet hat, welcher Code den Aufrufer signiert oder authentifiziert hat, welche Genehmigung dafür galt und ob jemand den Zugriff widerrufen hat, bevor die Ausführung abgeschlossen war. Anonyme Automatisierungskonten machen aus jedem Vorfall eine archäologische Untersuchung. ## Die Prüfung muss das wiederhergestellte Release testen, nicht die Anfrage Ein Rollback ist erst abgeschlossen, wenn das Ziel das gewünschte Release ausführt und der Dienst die Bedingungen prüft, die die Wiederherstellung begründet haben. HTTP 202, ein erfolgreicher Befehlsabschluss oder ein Controller-Ereignis mit dem Status «applied» beweisen nicht, dass das alte Release den Traffic korrekt bedient. Definieren Sie die Prüfung anhand der tatsächlichen Fehlerart des Deployments. Wenn Latenz oder Fehler den Rollback ausgelöst haben, beobachten Sie den wiederhergestellten Dienst über denselben Messpfad, sobald Traffic ihn erreicht. Wenn ein Worker-Release fehlerhafte Jobs verarbeitet hat, prüfen Sie die Workerversion und eine kontrollierte Arbeitslast. Wenn ein Konfigurationsfehler Startfehler verursacht hat, prüfen Sie bereite Instanzen und die von ihnen geladene Konfigurationsrevision. Legen Sie ein begrenztes Beobachtungsfenster fest und speichern Sie sein Ergebnis. Der Endpunkt kann zunächst `verifying` und anschließend `succeeded`, `failed` oder `needs_operator` melden. Warten Sie nicht unbegrenzt auf eine möglicherweise nicht verfügbare Metrik. Nach Ablauf des Zeitlimits muss ein ausdrückliches Ergebnis ohne eindeutige Aussage folgen, anschließend eine Entscheidung durch einen Operator. Das Audit-Ereignis sollte alle Phasen verbinden: den Alarm oder die Regel, die die Rücksetzung angefordert hat, das ursprüngliche Deployment, den erwarteten Zustand, die bedingte Reservierung, Ausführungsereignisse, Gesundheitsnachweise, den Endzustand und jeden Widerruf. Ereignisse brauchen Reihenfolge- und Integritätsschutz, denn eine übersichtliche Deployment-Zeitleiste reicht bei einem Streit nicht aus. Sallyport zeichnet Agent-Läufe und einzelne Aktionen in einem verschlüsselten, hashverketteten Audit-Log auf. `sp audit verify` prüft diese Kette offline ohne Tresorschlüssel. Verwenden Sie solche Nachweise, um zu zeigen, dass ein Agent eine Aktion angefordert hat. Die eigenen Zustandsänderungs- und Prüfprotokolle des Deployment-Dienstes bleiben dabei die maßgebliche Quelle dafür, was sich tatsächlich geändert hat. ## Bekannte Rollback-Befehle brauchen eine sicherere Hülle `kubectl rollout undo` ist für einen Operator nützlich, der direkt an einem Kubernetes Deployment arbeitet. Für eine autonome Wiederherstellung ist der Befehl jedoch kein vollständiger Vertrag. Kubernetes dokumentiert, dass `kubectl rollout undo` standardmäßig auf die vorherige Deployment-Revision zurücksetzt, sofern der Aufrufer nicht `--to-revision` angibt. Dieser Standard ist bei einer manuellen Untersuchung sinnvoll. Er beweist nicht, dass die vorherige Revision zum fehlgeschlagenen Agent-Lauf gehört. Ein Kubernetes Deployment verwaltet die Revisionshistorie in ReplicaSets. `revisionHistoryLimit` steuert, wie viel Historie Kubernetes behält. Diese Historie ist ein Artefakt des Controllers und nicht Ihr fachlicher Datensatz für ein genehmigtes Release-Baseline, Konfigurationskompatibilität oder Agent-Besitz. Sobald die Historie bereinigt wurde, kann «undo» außerdem die Revision nicht mehr finden, die ein externes Deployment-System erwartet. Geben Sie einem Agenten keine allgemeine `kubectl`-Berechtigung und erklären Sie den Befehl zum Rollback-Endpunkt. Schalten Sie einen Controller oder Deployment-Dienst zwischen Agent und Cluster. Der Dienst sollte den Datensatz des ursprünglichen Deployments auflösen, die Live-Generation des Ziels vergleichen, die Zustandsänderung reservieren und erst danach die zugrunde liegende Plattform aufrufen. Dasselbe gilt für Befehle von Cloud-Anbietern wie «Revision X deployen» oder CI-Steuerungen wie «vorheriges Release erneut ausführen». Sie arbeiten mit einer Plattformressource. Sie wissen nicht, ob ein Release zum aktuellen Vorfall des Agenten gehört, solange Ihre Steuerungsebene diesen Kontext nicht bereitstellt. Halten Sie auch den Plattformbefehl eng. Wenn der Dienst die Revision eines benannten Workloads ändern kann, vermeiden Sie eine clusterweite Änderungsberechtigung. Eine Hülle, die weitreichende Zugangsdaten beibehält, hat die Gefahr nur hinter eine weitere API verschoben. ## Erstellen Sie ein Release-Ledger, bevor Sie die Wiederherstellung automatisieren Sie können einen abgesicherten Rollback einführen, ohne jedes Deployment-System zu ersetzen. Beginnen Sie damit, das Release-Ledger für ein Produktionsziel maßgeblich zu machen. Leiten Sie anschließend sowohl menschliche als auch agentengesteuerte Pfade durch dieselbe bedingte Zustandsänderung. Eine praktische Einführungsfolge besteht aus fünf Teilen: 1. Vergeben Sie unveränderliche IDs für Releases und Deployment-Versuche. Speichern Sie beim Ausrollen das zuvor genehmigte Release und die Zielgeneration. 2. Fügen Sie einen Endpunkt hinzu, der `origin_deployment_id`, erwartetes Release, erwartete Generation und einen Idempotenzschlüssel verlangt. 3. Machen Sie die Zielaktualisierung in der Datenbank oder Steuerungsspeicher bedingt und geben Sie bei jeder Abweichung 409 zurück. 4. Klassifizieren Sie jedes Release vor dem Ausrollen danach, ob Anwendung, Konfiguration, Daten und Traffic rücksetzbar sind. 5. Verlangen Sie Prüfnachweise, bevor der Controller einen Rollback als abgeschlossen markiert. Führen Sie diesen Vertrag zunächst in einem Berichtsmodus aus, bevor Agenten ihn verwenden dürfen. Lassen Sie den Dienst berechnen, was er wiederherstellen würde und ob er die Anfrage ablehnen würde. Vergleichen Sie diese Entscheidungen mit den tatsächlichen Aktionen bei Vorfällen. So werden fehlende Herkunftsnachweise und versteckte manuelle Pfade sichtbar, ohne dass die Automatisierung die Produktion überschreiben kann. Machen Sie Ablehnungen anschließend langweilig. Ein veralteter Rollback sollte einen verständlichen Vorfallseintrag mit beobachtetem Release und beobachteter Generation erstellen, keine rätselhafte Fehlermeldung, die jemanden dazu bringt, den Endpunkt zu umgehen. Der Endpunkt verdient Vertrauen, wenn er eine unsichere Anfrage konsequent ablehnt, auch wenn sie von den Menschen stammt, die ihn entwickelt haben. Das erste Feld, das Sie hinzufügen sollten, ist nicht `force`, sondern `expected_target_generation`. Sobald Ihre Deployments diese Tatsache mitführen und die ursprüngliche Baseline bewahren, kann ein Agent sein eigenes Release mit einer klaren Grenze zurücksetzen. Bis dahin ist ein autonomer Rollback nur ein alter Deployment-Befehl, der auf ein bewegliches Ziel zeigt.