Wenn Ihre Bereitstellung selbst entscheidet: Automatisierung von Rollback- und Promote-Entscheidungen

Sie haben gerade eine neue Version Ihrer API bereitgestellt. Fünf Minuten später steigt die Fehlerrate von 0,1 % auf 4 %. Sie sind in einer Besprechung. Als Sie das Dashboard überprüfen, sind bereits fünfzehn Minuten vergangen. Benutzer beschweren sich bereits.

Stellen Sie sich nun vor, dies passiert dreimal pro Woche. Jedes Mal muss jemand den Anstieg bemerken, das Monitoring-Tool öffnen, die Zahlen interpretieren, eine Entscheidung treffen und dann manuell einen Rollback oder einen Stopp auslösen. Für ein Team, das mehrere Bereitstellungen pro Tag durchführt, wird dieser manuelle Entscheidungsprozess ermüdend. Schlimmer noch, er ist inkonsistent. Ein Ingenieur führt vielleicht bei einer Fehlerrate von 2 % einen Rollback durch. Ein anderer wartet vielleicht bis 5 %. Ein dritter bemerkt es vielleicht gar nicht, bis ihn jemand im Chat anpingt.

Dies ist das Problem, das Deployment-Gating löst. Ein Deployment-Gate ist ein automatisierter Prüfpunkt, der entscheidet, ob eine neue Version zur nächsten Stufe übergehen kann oder gestoppt werden muss. Das Gate rät nicht. Es folgt einer Richtlinie: einer Reihe von Regeln, die besagen: „Wenn dieses Signal diesen Schwellenwert überschreitet, führe diese Aktion aus.“

Wie ein Deployment-Gate funktioniert

Stellen Sie sich ein Gate wie einen Türsteher am Clubeingang vor. Der Türsteher weiß nicht, wer Sie sind. Er überprüft nur: Stehen Sie auf der Liste? Ist Ihr Ausweis gültig? Wenn ja, gehen Sie hinein. Wenn nein, warten Sie oder gehen Sie.

Ein Deployment-Gate funktioniert genauso. Nachdem eine neue Version für eine Teilmenge von Benutzern oder in einer Staging-Umgebung bereitgestellt wurde, überprüft das Gate die Observability-Signale. Wenn die Signale gesund sind, befördert das Gate die Version zu mehr Benutzern. Wenn die Signale schlecht sind, löst das Gate einen Rollback, einen Stopp oder eine Pause aus.

Das folgende Diagramm zeigt die drei möglichen Ergebnisse, nachdem das Gate die Observability-Signale überprüft hat.

Der entscheidende Punkt ist, dass die Entscheidung automatisch getroffen wird, basierend auf Regeln, die das Team vorher vereinbart hat. Niemand muss um 2 Uhr morgens ein Dashboard überwachen. Niemand muss unter Druck eine Entscheidung treffen. Das System folgt der Richtlinie.

Was in eine Richtlinie einfließt

Eine Richtlinie ist keine einzelne Regel. Sie ist eine Reihe von Bedingungen, die an die Art des bereitgestellten Objekts gebunden sind. Verschiedene Bereitstellungsobjekte haben unterschiedliche Fehlermuster, daher benötigen sie unterschiedliche Richtlinien.

Für eine Anwendung könnte die Richtlinie Folgendes prüfen:

• Fehlerrate im Vergleich zur SLO-Baseline
• Latenz beim p95- oder p99-Perzentil
• Durchsatzabfall, der darauf hindeutet, dass der Dienst Anfragen ablehnt

Für eine Datenbankmigration könnte die Richtlinie Folgendes prüfen:

• Replikationsverzögerung zwischen Primary und Replicas
• Anzahl langsamer Abfragen nach der Migration
• Erschöpfung des Verbindungspools

Für Infrastrukturänderungen könnte die Richtlinie Folgendes prüfen:

• Knotenzustand in einem Cluster
• CPU- und Speichernutzungsmuster
• Anzahl der Pod-Neustarts

Jedes Objekt erhält seine eigene Richtlinie, weil jedes anders ausfällt. Ein Latenzanstieg in einer API ist nicht dasselbe wie eine Replikationsverzögerung in einer Datenbank. Die Richtlinie muss zum Fehlermodus passen.

Hier ist ein minimales Policy-as-Code-Beispiel, das die oben beschriebene Logik implementiert:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: api-deployment
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  service:
    port: 8080
  analysis:
    interval: 1m
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    metrics:
    - name: error-rate
      thresholdRange:
        max: 0.05
      interval: 2m
    - name: request-duration
      thresholdRange:
        max: 0.5
      interval: 2m
    webhooks:
    - name: rollback-on-failure
      timeout: 30s
      metadata:
        action: rollback

Diese Richtlinie überprüft alle zwei Minuten die Fehlerrate und die Latenz. Wenn einer der Werte den Schwellenwert überschreitet, wird die Bereitstellung automatisch zurückgesetzt. Wenn alle Prüfungen fünf Minuten lang bestanden werden, wird die neue Version zum nächsten Gewichtungsschritt befördert.

Fehlerbudget als Richtlinienanker nutzen

Das Fehlerbudget liefert Ihnen eine praktische Zahl, die Sie in Ihre Richtlinie einfügen können. Wenn Ihr Team eine Verfügbarkeits-SLO von 99,9 % festlegt, haben Sie etwa 43 Minuten erlaubte Ausfallzeit pro Monat. Das ist Ihr Fehlerbudget.

Stellen Sie sich nun vor, eine neue Bereitstellung verbraucht in der ersten Stunde 10 Minuten dieses Budgets. Das ist ein starkes Signal, dass etwas nicht stimmt. Eine Richtlinie kann besagen: „Wenn die neue Version in den ersten 30 Minuten mehr als 5 % des monatlichen Fehlerbudgets verbraucht, führe automatisch einen Rollback durch.“

Dieser Ansatz entfernt die Rätselraten. Das Team hat sich auf die SLO geeinigt. Die Richtlinie setzt sie durch. Niemand muss darüber diskutieren, ob 10 Minuten zu viel sind. Die Zahl ist bereits festgelegt.

Nicht alle Entscheidungen müssen ein Rollback sein

Ein häufiger Fehler ist, jede Richtlinie mit einem Rollback enden zu lassen. Das ist für viele Situationen zu aggressiv. Ein besserer Ansatz sind abgestufte Richtlinien.

Beispiel:

• Wenn die Fehlerrate um 0,5 % steigt, aber unter dem SLO-Schwellenwert bleibt, lösen Sie einen Stopp aus. Die neue Version bleibt live, wird aber nicht zu mehr Benutzern befördert. Das Team untersucht ohne Druck.
• Wenn die Fehlerrate den SLO-Schwellenwert überschreitet, lösen Sie einen Rollback aus. Das System kehrt sofort zur vorherigen Version zurück.
• Wenn die Latenz steigt, die Fehlerrate aber stabil ist, lösen Sie eine Pause aus. Es findet keine weitere Beförderung statt, aber die aktuelle Version läuft weiter. Das Team entscheidet manuell, ob fortgefahren oder ein Rollback durchgeführt wird.

Dieser abgestufte Ansatz gibt dem Team Spielraum, um verschiedene Schweregrade zu behandeln, ohne zu über- oder unterzureagieren.

Was Sie brauchen, damit das funktioniert

Deployment-Gating erfordert eine Integration zwischen Ihrem Observability-System und Ihrer Bereitstellungsplattform. Die Signale aus dem Monitoring müssen von der Pipeline oder Plattform, die Bereitstellungen verwaltet, lesbar sein.

Tools wie Argo Rollouts, Flagger und Spinnaker unterstützen dieses Muster bereits. Sie können Metriken von Prometheus, Datadog, New Relic oder jeder anderen Metrikquelle abrufen. Sie konfigurieren die Richtlinie, und das Tool führt die Entscheidung aus.

Aber das Tool ist nicht der schwierige Teil. Der schwierige Teil ist die Definition der Richtlinie. Sie müssen wissen:

• Welche Signale für jede Art von Bereitstellung wichtig sind
• Welche Schwellenwerte auf ein echtes Problem im Gegensatz zu Rauschen hinweisen
• Wie schnell Sie bei verschiedenen Fehlerschweregraden reagieren müssen

Fangen Sie einfach an. Wählen Sie ein Signal, einen Schwellenwert und eine Aktion. Lassen Sie es eine Woche laufen. Sehen Sie, wie viele Fehlalarme Sie erhalten. Passen Sie an. Fügen Sie nach und nach weitere Signale hinzu.

Ist es sicher, das System entscheiden zu lassen?

Diese Frage kommt jedes Mal auf. Die Antwort lautet: Es hängt davon ab, wie gut Sie die Richtlinie definieren.

Eine gute Richtlinie ersetzt nicht vollständig das menschliche Urteilsvermögen. Sie übernimmt Entscheidungen, die bereits vorhersehbar sind. Wenn das Team weiß, dass eine Fehlerrate über 2 % für fünf Minuten immer zu einem Rollback führt, warum auf einen Menschen warten? Automatisieren Sie diese Entscheidung.

Was ist mit Randfällen? Das Team sollte immer einen Überschreibungsmechanismus haben. Wenn eine Richtlinie fälschlicherweise ausgelöst wird, sollte jemand in der Lage sein, den Rollback zu stoppen oder manuell zu befördern. Die Automatisierung erledigt die Routinefälle. Menschen kümmern sich um die Ausnahmen.

Das Ziel ist nicht, Menschen aus dem Prozess zu entfernen. Das Ziel ist, Menschen von den langweiligen, sich wiederholenden, vorhersehbaren Entscheidungen zu befreien, damit sie sich auf die konzentrieren können, die tatsächlich Kontext und Urteilsvermögen erfordern.

Eine kurze Checkliste für den Einstieg

Bevor Sie Ihr erstes Deployment-Gate bauen, stellen Sie sicher, dass Folgendes vorhanden ist:

• Ein Observability-Signal, dem Sie vertrauen (beginnen Sie mit Fehlerrate oder Latenz)
• Ein klarer Schwellenwert basierend auf Ihrer SLO oder Ihrem Fehlerbudget
• Eine Bereitstellungsplattform, die Gating unterstützt (Argo Rollouts, Flagger, Spinnaker oder ähnliches)
• Ein Überschreibungsmechanismus für manuelle Eingriffe
• Ein Überprüfungsrhythmus, um die Wirksamkeit der Richtlinie alle zwei Wochen zu überprüfen

Versuchen Sie nicht, am ersten Tag eine perfekte Richtlinie zu erstellen. Beginnen Sie mit einem Gate, einem Signal, einer Aktion. Lernen Sie aus den Ergebnissen. Erweitern Sie von dort aus.

Der wahre Wert ist Konsistenz

Der größte Vorteil automatisierter Bereitstellungsentscheidungen ist nicht die Geschwindigkeit, obwohl das hilft. Es ist die Konsistenz. Jede Bereitstellung durchläuft dasselbe Gate, wird nach denselben Standards beurteilt, mit derselben Entscheidungslogik. Niemand bekommt eine Freikarte, weil er mit dem Bereitschaftsingenieur befreundet ist. Niemandem wird unfairerweise ein Rollback aufgezwungen, weil der Prüfer schlechte Laune hatte.

Wenn Ihre Bereitstellungsentscheidungen durch Richtlinien automatisiert werden, kann Ihr Team häufiger bereitstellen, ohne auszubrennen. Das System übernimmt die routinemäßigen Entscheidungen. Ihr Team kümmert sich um die Ausnahmen und die Verbesserungen. Das ist der Unterschied zwischen einem Team, das häufig bereitstellt, und einem Team, das nachhaltig bereitstellt.