Rollback-Strategien für KI-Agenten: wie man einen Release sicher zurückrollt

Idee in 30 Sekunden

Rollback-Strategien sind ein Runtime-Mechanismus, um Traffic schnell auf eine stabile Version zurückzuführen, wenn ein neuer Release Metriken degradiert.

Wann das nötig ist: wenn ein Agent über Canary/Rollout releast wird und jede Regression in Production ohne langen Downtime gestoppt werden muss.

Problem

Ohne Rollback sieht das Team das Problem, kann den Impact aber nicht schnell entfernen. Während die Analyse läuft, geht Traffic weiter auf die degradierte Version und der Incident wächst.

Typisches Szenario:

error_rate oder latency_p95 steigt
Nutzer landen weiter auf der problematischen Version
Team macht manuelle Aktionen unter Zeitdruck

Analogie: Das ist wie Fahren ohne Notbremse. Wenn das System schon schleudert, kostet langsame Reaktion viel mehr als der eigentliche Fix.

Und jede Minute ohne Rollback bringt neue Fehler, Kosten und Vertrauensverlust.

Lösung

Die Lösung ist, Rollback als eigene Policy-Schicht im Runtime-Release-Flow umzusetzen. Policy prüft Degradationssignale und entscheidet: Rollout fortsetzen oder Traffic auf stable version zurückschalten.

Rollback policy layer gibt eine technische Entscheidung zurück: allow oder stop mit Grund:

rollback_required
sla_breach
error_spike

Bei stop führt das System einen kontrollierten Traffic-Switch auf active stable version aus und schreibt das Event ins Audit Log. Das ist eine dedizierte Notfall-Kontrolle, keine manuelle Improvisation im Incident.

Rollback ≠ Kill switch

Das sind unterschiedliche Werkzeuge:

Rollback bringt die vorherige stabile Version zurück.
Kill switch stoppt Aktionen oder Traffic ohne Versionswechsel.

Eins ohne das andere reicht nicht:

ohne Rollback ist es schwer, nach einer Release-Regression den Normalbetrieb wiederherzustellen
ohne Kill switch ist es schwer, riskante Aktionen bis zum Abschluss des Rollbacks schnell zu dämpfen

Beispiel:

rollback: 2.4.0 -> 2.3.3 nach error_spike
kill switch: temporär writes_disabled=true, während stable version zurückkommt

Komponenten der Rollback-Kontrolle

Diese Komponenten arbeiten bei jedem Rollout zusammen.

Komponente	Was sie kontrolliert	Zentrale Mechanik	Warum
Rollback triggers	Wann Rollback nötig ist	`error_rate` / `latency_p95` SLO thresholds	Liefert klare, nicht-manuelle Auslösekriterien
Traffic switch	Traffic-Umschaltung	from_version -> to_version stable fallback	Reduziert Degradations-Impact schnell
Rollout gate	Weiteres Candidate-Rollout	gate lock rollback window	Verhindert erneuten Traffic auf die kaputte Version
Recovery verification	Ob das System nach Rollback wieder stabil ist	post-rollback checks stability window	Bestätigt, dass Rollback das Problem wirklich gelöst hat
Rollback observability	Transparenz der Notfall-Aktionen	audit logs alerts on rollback events	Führt Rollback nicht direkt aus, liefert aber eine vollständige Entscheidungskette

Beispiel-Alert:

Slack: 🛑 Rollback triggered support-agent@2.4.0 -> 2.3.3, reason=error_spike, stage=canary.

Wie das in der Architektur aussieht

Rollback policy layer liegt zwischen Release runtime und Traffic und blockiert degradiertes Rollout vor der Skalierung. Jede Entscheidung (allow oder stop) wird im Audit Log erfasst.

Jede Rollout-Stufe passiert diesen Flow vor Traffic-Erweiterung: Runtime skaliert Candidate nicht direkt, sondern fragt zuerst die Entscheidung des Policy Layers ab.

Flow kurz zusammengefasst:

Monitoring liefert ein Degradationssignal
Policy prüft error_rate, latency_p95, tool_failures, rollback_plan
allow -> Rollout läuft weiter
stop -> Traffic wechselt auf active stable version
beide Entscheidungen werden ins Audit Log geschrieben

Beispiel

Nach Release support-agent@2.4.0 steigt tool_failure_rate in Canary. Rollback policy gibt stop (reason=rollback_required) zurück.

Ergebnis:

Traffic geht auf 2.3.3 zurück
Candidate wird für weitere Erweiterung gesperrt
Team analysiert die Ursache ohne aktiven Incident-Druck

Rollback reduziert Incident-Schaden während des Incidents, nicht erst danach.

Im Code sieht das so aus

Die vereinfachte Skizze oben zeigt den Haupt-Flow. Kritisch: Rollback muss idempotent und schnell sein, damit wiederholte Signale den Traffic-Switch nicht kaputt machen.

Beispiel für Rollback-Konfiguration:

YAML

rollback:
  stable_version: support-agent@2.3.3
  candidate_version: support-agent@2.4.0
  triggers:
    error_rate_p95: 0.05
    latency_p95_ms: 1800
    tool_failure_rate: 0.03
  lock_candidate_after_rollback: true

PYTHON

release_cfg = load_release_config("support-agent")
signal = monitor.read(version_id=release_cfg.candidate_version)
decision = rollback_policy.check(signal, release_cfg)

if decision.outcome == "stop":
    switch_result = traffic.switch(
        from_version=release_cfg.candidate_version,
        to_version=release_cfg.stable_version,
    )

    if release_cfg.lock_candidate_after_rollback:
        rollout.lock(version_id=release_cfg.candidate_version)

    audit.log(
        run_id,
        decision=decision.outcome,
        reason=decision.reason,
        from_version=release_cfg.candidate_version,
        to_version=release_cfg.stable_version,
        switch_status=switch_result.status,
    )
    alerts.notify_if_needed(release_cfg.candidate_version, decision.reason)
    return stop(
        decision.reason,
        from_version=release_cfg.candidate_version,
        to_version=release_cfg.stable_version,
    )

allow_decision = Decision.allow(reason=None)  # standard allow outcome/reason model
audit.log(
    run_id,
    decision=allow_decision.outcome,
    reason=allow_decision.reason,
    version_id=release_cfg.candidate_version,
    stage="canary",
)
return continue_rollout()

Wie das während der Ausführung aussieht

Szenario 1: rollback_required in Canary

Candidate-Version bekommt 5% Traffic.
Metriken verletzen Schwellen (error_rate und tool_failure_rate).
Policy gibt stop (reason=rollback_required) zurück.
Traffic geht auf stable version zurück.
Candidate bleibt bis zur Incident-Analyse gesperrt.

Szenario 2: false alarm, kein Rollback nötig

Monitoring meldet einen kurzen Spike, aber Schwellen werden nicht verletzt.
Policy gibt allow zurück.
Rollout läuft auf aktueller Stage weiter.
Event wird im Audit Log erfasst.
System bleibt stabil ohne unnötigen Rollback.

Szenario 3: wiederholtes Signal nach Rollback

Nach dem Rollback kommt ein weiterer Alert mit demselben Signal.
Idempotente Logik macht keinen wiederholten Switch.
Policy gibt einen technischen Status ohne doppelte Aktionen zurück.
In Logs ist sichtbar, dass Rollback bereits angewendet wurde.
Team arbeitet an Root Cause ohne zusätzlichen Lärm.

Typische Fehler

Rollback wird nur manuell gestartet, ohne Policy-Trigger
es gibt keine stable version für schnelle Rückkehr
Candidate wird nach Rollback nicht gesperrt
Rollback schaltet Traffic um, prüft aber keine Recovery-Metriken
keine Idempotency für wiederholte Rollback-Signale
im Audit Log fehlen from/to version und reason

Ergebnis: Rollback wirkt vorhanden, ist im Incident aber langsam und unvorhersehbar.

Selbstcheck

Schneller Rollback-Strategie-Check vor dem Production-Start:

Es gibt explizite Rollback-Trigger: error_rate, latency, tool failures
Es gibt eine garantierte stable version für schnellen switch-back
Rollback läuft über einen zentralen Policy-Layer
Nach Rollback bleibt Candidate bis zur Analyse gesperrt (gate lock)
Rollback-Aktionen sind idempotent bei wiederholten Signalen
Alle Rollback-Entscheidungen werden ins Audit Log geschrieben
Es gibt post-rollback Stabilitätsprüfung
Es gibt ein getestetes Runbook: detect -> switch -> verify -> recover

Fortschritt: 0/8

⚠ Grundlegende Governance-Kontrollen fehlen

Vor production brauchen Sie mindestens Zugriffskontrolle, Limits, audit logs und einen Not-Stopp.

FAQ

Q: Wann Rollback automatisch auslösen, wann manuell?
A: Bei klaren SLO-Schwellen ist automatisch besser. Bei mehrdeutigen Fällen (z. B. riskante Business-Operation) human approval zusätzlich zur Policy nutzen.

Q: Duplizieren Rollback und Kill switch einander?
A: Nein. Rollback bringt stable version zurück, Kill switch begrenzt schnell Aktionen. In Production sollten beide zusammen arbeiten.

Q: Was nach einem Rollback tun?
A: Incident-Snapshot sichern (Version, reason, Metriken), Candidate sperren und Rollout erst nach Fix und Verifikation neu starten.

Q: Braucht man Rollback, wenn Canary existiert?
A: Ja. Canary reduziert nur den Blast Radius, Rollback wird gebraucht, um schnell in einen stabilen Zustand zurückzukehren.

Q: Welche Felder müssen geloggt werden?
A: reason, from_version, to_version, stage, switch_status, timestamp, actor (wenn Rollback manuell ist).

Wo Rollback im Gesamtsystem liegt

Rollback-Strategien sind eine der Ebenen von Agent Governance. Zusammen mit versioning, Limits, Budgets, Approval und Audit bilden sie ein System sicherer Production-Änderungen.