Automatisierte LLM-CI/CD-Pipelines mit sofortigem Rollback

Notizen aus dem Release-Zyklus — Teil V

Die meistzitierte Seite, die letztes Quartal nicht ausgeliefert wurde, war die, bei der unser Observer um 2:14 Uhr morgens von selbst auslöste. Das Kandidaten-Release hatte das Gate passiert, vier Minuten lang bei 5 % verweilt, war auf 25 % vorgerückt und blieb dann stehen. Der Minuten-Qualitätsmonitor erkannte drei aufeinanderfolgende Messungen unterhalb des Schwellenwerts auf dem Slice „Recht“, stoppte das Rollout und leitete den Routing-Pointer auf das vorherige Release zurück. Bis die Benachrichtigung für den Bereitschaftsingenieur eintraf – für die Quittung, nicht für einen Ausfall – war der Produktionsverkehr bereits seit neun Minuten wieder auf dem als gesund bekannten Release.

Niemand musste irgendetwas tun. Die Architektur aus dem ersten Beitrag dieser Reihe beschreibt, was die vier Stufen sind. In diesem Beitrag geht es darum, was zwischen den menschlichen Freigaben läuft – die Automatisierungsschicht unter der Architektur, die Grenze, an der die Pipeline entweder von selbst das Richtige tut oder eben nicht.

Die Kernaussage: Die meisten Pipeline-Entscheidungen sollten automatisiert sein, aber nicht alle. Die Grenze ist entscheidend. Die Pipeline, die alles automatisiert, wird irgendwann ein Release befördern, das ein Mensch hätte abfangen müssen; die Pipeline, die nichts automatisiert, hat keinen Zweck. Diese Grenze richtig zu ziehen, ist das Thema dieses Beitrags.

Das Automatisierungsspektrum

Jede Pipeline-Entscheidung sitzt irgendwo auf einem Spektrum von „löst von selbst aus, ohne menschliche Benachrichtigung“ bis „weigert sich, ohne ausdrückliche unterzeichnete Freigabe weiterzulaufen.“ Unten ist abgebildet, wo jede der tragenden Pipeline-Aktionen in unserer ausgelieferten Pipeline auf diesem Spektrum sitzt.

Zwei der oben markierten Punkte sind rot statt in der Farbe ihrer Zone gehalten. Das sind die asymmetrischen Entscheidungen – die zwei Stellen, an denen die Pipeline eine klare Haltung dazu einnimmt, wer worüber entscheidet. Der Auto-Rollback-Trigger löst aus, ohne zu fragen; man kann ihn nicht abschalten, denn der ganze Sinn besteht darin, dass er um 2:14 Uhr morgens funktioniert. Der Gate-Fail-Override weigert sich, ohne schriftliche Begründung weiterzulaufen; auch das kann man nicht abschalten, denn der ganze Sinn besteht darin, dass das zukünftige Ich den Grund nachlesen können muss. Der Rest der Pipeline ist größtenteils konfigurierbar; diese zwei nicht.

Wie Auto-Rollback tatsächlich auslöst

Die häufigste Frage zu Auto-Rollback lautet „Was hindert es daran, aus dem falschen Grund auszulösen?“ Die ehrliche Antwort ist: nichts allein. Der Schutz ergibt sich daraus, wie der Trigger verdrahtet ist.

Die Observe-Stufe führt eine minütliche Bewertungsschleife aus. Jede Minute werden:

1. Eine kleine Menge aktueller Produktions-Traces des aktiven Release gesampelt.
2. Jeder Trace durch das aktive Modell erneut abgespielt (nicht durch den Kandidaten – wir bewerten, was tatsächlich ausgeliefert wird).
3. Jedes Replay mit dem gleichen kalibrierten, am Menschen verankerten Judge bewertet, der Gate-2 angetrieben hat^[1].
4. Ein einziger Output-Qualitätsscore über das Sample berechnet. Geschrieben nach CanaryHealthSample.

Das Rollback löst aus, wenn drei aufeinanderfolgende Minuten-Samples unter den Rollback-Schwellenwert fallen (Standard: 0,85 der Gate-Schwelle – also 0,55, wenn das Gate bei 0,65 lag). Nicht eine schlechte Minute; drei. Der Drei-Minuten-Lockout ist der Rauschfilter – eine einzelne anomale Messung löst nichts aus, aber eine anhaltende Regression schon.

Wenn der Lockout bricht, führt der Rollback-Worker aus:

# In der Praxis — die Pipeline führt das von selbst aus. Keine menschliche Bestätigung.
POST /api/v1/releases/<previous_release_sha>/activate
# Antwort in <1s; In-Flight-Drain in ~12s bei einem ~100-Replica-Service

Eine Quittung wird ausgelöst. Der Bereitschaftsingenieur sieht eine Slack-Benachrichtigung für die Quittung, nicht für einen Ausfall. Sie öffnen die Quittung; sie sehen die drei Messungen unterhalb des Schwellenwerts, die verstrichene Zeit und die Hashes vindex_sha256_before/after^[2]. Zwölf Sekunden sind die In-Flight-Drain-Zeit; der eigentliche Swap dauert unter einer Sekunde. Wenn der Ingenieur wach genug ist, um zu fragen „muss ich etwas tun?“, lautet die Antwort „nein, aber Sie sollten trotzdem nachschauen, warum das Gate das durchgelassen hat.”

Die echte Auto-Rollback-Quittung

So sieht die Quittung in der Produktion aus. Gleiches Hash-verkettetes Format, das auf der Compliance-Seite dokumentiert ist, mit zusätzlichen Feldern speziell für ein Auto-Rollback-Ereignis:

{
  "kind": "auto_rollback",
  "release_id": "rel_a01c66",
  "previous_release_id": "rel_8f72b1",
  "trigger_at": "2026-05-29T02:14:23Z",
  "completed_at": "2026-05-29T02:14:35Z",
  "elapsed_seconds": 12,
  "trigger_reason": "observer_quality_threshold_breach",
  "observer_readings": [
    { "minute_at": "2026-05-29T02:11:00Z", "quality_score": 0.523, "below_threshold": true,  "slice": "legal-IP-licensing" },
    { "minute_at": "2026-05-29T02:12:00Z", "quality_score": 0.508, "below_threshold": true,  "slice": "legal-IP-licensing" },
    { "minute_at": "2026-05-29T02:13:00Z", "quality_score": 0.491, "below_threshold": true,  "slice": "legal-IP-licensing" }
  ],
  "rollback_threshold": 0.55,
  "active_manifest_sha256_before": "9abaeaf6c91f8b...",
  "active_manifest_sha256_after":  "8f72b1de4a93c5...",
  "audit_chain_signature": "sha256(...)",
  "notified_users": ["oncall@customer.example"],
  "notification_sent_at": "2026-05-29T02:14:36Z"
}

Die Quittung selbst ist der erste Berührungspunkt für die Bereitschaft. Sie zu lesen, beantwortet die Fragen, die ein halb wacher Ingenieur tatsächlich stellen würde: Was hat sie ausgelöst, welcher Slice ist gescheitert, um wie viel, wie lange hat der Swap gedauert, was läuft jetzt. Die Folgeaktion lautet von dort aus meist „schau nach, warum das Gate das überhaupt durchgelassen hat“ – wofür die Quittung des fehlgeschlagenen Release bereits die Per-Slice-Spearman-Tabelle enthält.

Was die Pipeline NICHT von selbst tut

Das Gegenstück zu „Auto-Rollback löst ohne Nachfrage aus“ ist, dass manches aktiv nicht passieren kann. Drei ausdrückliche Verweigerungen.

Sie befördert kein Release, das das Gate nicht bestanden hat, ohne signiertes Override. Ein Gate-Fail markiert das Release als gate_fail; der /activate-Endpunkt weigert sich, die Manifest-SHA anzunehmen; keine Kommandozeilen-Beschwörung umgeht das. Der einzige Weg vorwärts ist ein erzwungenes Override mit forceGateOverride: true UND overrideReason: "<Freitext>". Das Begründungsfeld ist Pflicht, Freitext und wandert ins Audit-Log neben die Benutzer-ID. Wir haben das so entworfen, dass das zukünftige Ich nachlesen kann, warum das gegenwärtige Ich die Slice-Regression für akzeptabel hielt. Drei Personen haben den Override-Pfad bisher in der Praxis benutzt. Ihre Begründungen stehen noch im Audit-Log.

Sie rückt nicht vom Canary auf 100 % vor, wenn irgendein Monitor sich verschlechtert. Wenn p95-Latenz, 5xx-Rate ODER Output-Qualitätsscore am Ende einer Checkpoint-Dwell außerhalb ihres Bandes liegt, hält die Pipeline an diesem Checkpoint an und löst einen Page aus. Sie rückt nicht vor und entschuldigt sich später.

Sie führt keinen Auto-Canary für ein Cold-Start-Release durch. Ein Release ohne Historie an Produktionsverkehr – zum Beispiel ein frischer Fine-Tune gegen einen brandneuen Datensatz – hat nichts, womit es seine Output-Qualität vergleichen könnte. Die Pipeline weigert sich, einen Canary auf einem Cold-Start-Release zu starten. Wir verlangen zuerst ein 24-stündiges Shadow-Deployment, das den Kandidaten gegen echte Produktions-Traces beobachtet, aber keine seiner Antworten ausliefert. Nach 24 Stunden haben wir eine Qualitäts-Baseline; dann kann der Canary starten. Langsamer; ehrlich; nicht konfigurierbar.

Wie schnell ist die Wiederherstellung, end-to-end?

Die Wiederherstellungszeit, die wir veröffentlichen, beträgt 12 Sekunden. Das ist In-Flight-Drain bei einem ~100-Replica-Service. Der Manifest-Swap selbst dauert unter einer Sekunde. Damit das für Lesende nützlich ist, müssen die 12 Sekunden aufgeschlüsselt werden:

• 0–60 Sekunden vor Rollback: Die drei aufeinanderfolgenden Messungen unter Schwellenwert treffen ein. Die erste Messung unter Schwellenwert startet den Lockout-Timer. Jede weitere Minute verlängert den Lockout, wenn die Qualität weiterhin unter Schwellenwert liegt.
• t = 0: Die dritte Messung unter Schwellenwert schreibt nach CanaryHealthSample. Der Rollback-Worker beobachtet den dritten Strike und schickt /activate previous_release los.
• t < 1 Sekunde: Der aktive-Release-Pointer der Routing-Schicht (in Redis) kippt. Neue Anfragen treffen das vorherige Release.
• t = 1 bis ~12 Sekunden: Das Kandidaten-Release bedient weiterhin alle Anfragen, die zum Zeitpunkt des Swap in Flight waren. In-Flight-Drain. Manche Streaming-Antworten brauchen 8–10 Sekunden, um natürlich abzuschließen, sodass der Aufräum-Schwanz bei einem typischen Service rund 12 s beträgt.
• t ≈ 13 Sekunden: Die Audit-Log-Quittung wird geschrieben und signiert. Die Benachrichtigung wird ausgelöst.

Verglichen mit den öffentlichen Postmortems, die wir gerne als Anker zitieren: Der Cloudflare-Ausfall vom Juni 2022^[3] brauchte 44 Minuten von „wir wissen, was wir zurücknehmen müssen“ bis „das Zurücknehmen ist abgeschlossen“ – und das war die Infrastruktur-Ebene. Der Atlassian-Ausfall vom April 2022^[4] brauchte 12 Stunden pro Site, weil der Zustand auf mehrere Systeme verteilt war. Die DORA^[5]-Schwelle für „Elite Performer“ zur Wiederherstellung nach fehlgeschlagenem Deployment liegt unter einer Stunde. Zwölf Sekunden sind nicht eine Größenordnung besser als die Elite-Schwelle – sie sind drei Größenordnungen besser. Die architektonische Entscheidung, die das möglich macht, ist das gebündelte Release-Manifest aus Stufe 1. Ohne das Manifest hat man kein einzelnes Objekt, auf das man das Routing umlenken kann.

Rollback-Übungen — die unsexy Praxis, die niemand durchführt

Hier ist der Teil, den die meisten Teams überspringen: Das einzig verlässliche Signal, dass Ihr Rollback-Pfad funktioniert, ist, dass Sie eine bewusste, geplante Übung durchgeführt und das Ergebnis bestätigt haben. Wir führen jedes Quartal eine durch. Die Übung läuft so:

1. Wähle eine zufällig geplante Uhrzeit innerhalb der Werktag-Geschäftszeiten. Sage dem Team, dass es kommt, aber nicht die genaue Stunde.
2. Injiziere eine synthetische Qualitätsregression auf dem Canary-Slice. (Wir haben ein Test-Mode-Flag, mit dem das Kandidatenmodell auf einen magischen Header mit „Ich verweigere die Antwort“ reagiert – garantiert ein Fehlschlag beim kalibrierten Judge.)
3. Schiebe das Test-Release durch das Gate (es besteht – wir testen das Rollback, nicht das Gate). Starte einen Canary.
4. Der Observer bemerkt drei Messungen unter Schwellenwert. Auto-Rollback löst aus.
5. Warte auf die Reaktion des Bereitschaftsingenieurs. Stoppe die Zeit. Notiere, ob sie der Quittung genug vertrauen, um nicht alarmiert zurückzurufen.
6. Verifiziere, dass das Audit-Log das Test-Mode-Flag in der Rollback-Quittung zeigt, damit zukünftige Audits eine Übung von einem echten Vorfall unterscheiden können.

Die erste Übung, die wir durchführten, brauchte 19 Sekunden end-to-end (12 s Swap + 7 s Settling-Delay, die wir beheben mussten). Die jüngste Übung – Q1 2026 – brauchte 12 Sekunden. Die Übung darf nie übersprungen werden. Jedes Quartal; jeder Kundencluster.

Die meisten Teams haben noch nie eine bewusste Rollback-Übung durchgeführt. Das erste Mal, dass ihr Rollback-Pfad läuft, ist während eines echten Vorfalls, unter Druck, mit mehreren Personen im Call. Die Übung ist das, was aus der 12-Sekunden-Zahl eine echte Zahl macht, statt einer angestrebten.

Was das nicht löst

Drei ehrliche Einschränkungen:

Auto-Rollback kann Ping-Pong spielen. Wenn sowohl der Kandidat ALS AUCH das vorherige Release schlecht sind – sagen wir, das vorherige Release hatte ebenfalls eine sich langsam entwickelnde Slice-Regression, die niemand bemerkt hat – kann die Pipeline ein Rollback machen, dann scheitert auch das vorherige Release am Post-Rollback-Observer, und es gibt kein drittes Release mehr, auf das man zurückrollen könnte. Die Pipeline hält den Verkehr auf einer Wartungsseite an, statt zu thrashen. Die Lösung ist, mehr als ein einzelnes vorheriges gesundes Release in der Manifest-Kette indiziert zu halten, damit das Rollback-Ziel konfigurierbar ist.

Der Observer erzeugt Inferenzkosten. Das Replay von Produktions-Traces durch das aktive Modell auf einem 5 %-Sample erhöht die Inferenzausgaben um etwa 5 %. Wir halten das für den richtigen Kompromiss. Manche Kunden finden es bei margenschwachen Workloads zu teuer und wollen die Sample-Rate herunterdrehen. Der Regler existiert.

Ein schlechter Judge ist schlimmer als kein Judge. Wenn der kalibrierte Judge, der den Observer antreibt, selbst miskalibriert ist – vom menschlichen Anker abgedriftet oder auf einem veralteten Korpus trainiert – kann der Observer Auto-Rollback aus dem falschen Grund auslösen. Die Rekalibrierungs-Kadenz ist entscheidend. Der Beitrag „Calibrating-the-Judge“^[6] dokumentiert das Verfahren; die operative Anforderung ist, dass Sie es tatsächlich durchführen.

FAQ

Warum sind es drei aufeinanderfolgende Minuten und nicht eine?

Weil LLM-Qualitätsscores einen Rauschboden haben – eine einzelne anomale Minutenmessung kann von einer Sampling-Eigenheit kommen (das 5 %-Trace-Sample ist zufällig auf einem schwierigen Slice gelandet) und nicht von einer echten Regression. Der Drei-Minuten-Lockout ist der günstigste Rauschfilter, der die gesamte Reaktionszeit dennoch unter eineinhalb Minuten hält. Wir haben in beide Richtungen getunt; drei ist der Sweet Spot für die typische Verkehrsform unserer Kunden. Die Dwell-Zeit ist pro Release konfigurierbar, falls Ihre Verkehrsform anders ist.

Sollte Auto-Rollback auf „aus“ konfigurierbar sein?

In unserer ausgelieferten Pipeline: nein. Der Sinn eines automatisierten Sicherheitsmechanismus ist, dass er um 2:14 Uhr morgens funktioniert, wenn niemand zuschaut. Ein abschaltbarer Auto-Rollback ist ein Klebezettel, auf dem steht „wir hatten mal ein Sicherheitsnetz.“ Das Argument für die Konfigurierbarkeit lautet, dass manche Workloads zu wenig kritisch seien, um irgendwelche False-Positive-Rollbacks zu rechtfertigen. Wir halten dieses Argument für irreführend – wenn Ihr Workload zu unkritisch für Auto-Rollback ist, brauchen Sie auch keine Release-Pipeline.

Wie gehen Sie mit dem Fall um, dass das vorherige Release ebenfalls schlecht war?

Das Rollback-Ziel ist standardmäßig previous_release, aber die Manifest-Kette speichert mehr Historie als nur N-1. Operatoren können ein Rollback auf jede historisch gesunde Manifest-SHA umlenken – /api/v1/releases/<historically_good_sha>/activate – das ist der Pfad für manuelle Eingriffe, wenn das automatische N-1-Rollback auf ein schlechtes älteres Release stößt. Das Notventil ist da. Es ist selten.

Welche Metrik sollte man optimieren – MTTR oder MTBF?

MTTR – Mean Time To Recovery – mit großem Abstand, zumindest für LLM-Systeme. MTBF (Mean Time Between Failures) setzt einen deterministischen „Failure“-Begriff voraus, den LLM-Workloads nicht haben. Output-Qualität driftet kontinuierlich; „Failure“ ist eine Schwellenwertentscheidung. Auf schnelle Wiederherstellung zu optimieren ist robust dagegen, wo Sie die Schwelle setzen; auf das Niemals-Scheitern zu optimieren ist brüchig und falsch. Die Elite-Schwelle der DORA^[5] ist selbst in MTTR-Begriffen formuliert, was die richtige Rahmung ist.

Führen Sie tatsächlich Rollback-Übungen durch?

Ja – quartalsweise, geplant, mit einem Test-Mode-Flag in der Quittung, damit die Übung im Audit-Log von einem echten Vorfall unterschieden werden kann. Die erste Übung, die wir durchführten, offenbarte ein 7-Sekunden-Settling-Delay, von dem wir nicht wussten, dass es da war. Die Übung ist der einzige Weg zu wissen, dass der Pfad tatsächlich funktioniert; das Runbook zu lesen reicht nicht. Die meisten Teams haben keine durchgeführt, weshalb die MTTR-Zahlen der meisten Teams angestrebt statt gemessen sind.

References

1. LLM-as-judge calibration. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023). Der Anker dafür, warum ein kalibrierter Judge notwendig ist und warum Übereinstimmung pro Slice wichtiger ist als aggregierte Übereinstimmung. Die minütliche Bewertungsschleife des Observers hängt davon ab.
2. vindex-Gewichtsattestierung. Dokumentiert auf der Divinci-Compliance-Seite und durchgespielt im Beitrag zu regulierten Branchen. Die Felder `vindex_sha256_before/after` in der Auto-Rollback-Quittung sind der kryptografische Anker, den ein Prüfer verifizieren kann, ohne unseren Logs vertrauen zu müssen.
3. Cloudflare-Ausfall Juni 2022. Cloudflare outage on June 21, 2022. „06:58: Root cause found and understood. Work begins to revert the problematic change… 07:42: The last of the reverts has been completed." Vierundvierzig Minuten zum Zurücknehmen auf Infrastrukturebene, teils weil Ingenieure einander bei den Reverts in die Quere kamen. Anker für die These „ein manifestgetriebener Swap kann diesen Fehlermodus nicht haben."
4. Atlassian-Ausfall April 2022. Post-Incident Review: April 2022 Outage. 12 Stunden pro Site bis zur Wiederherstellung, insgesamt 14 Tage für 883 Sites, weil der Zustand über unabhängig versionierte Systeme verteilt war. Anker für die These „das gebündelte Release-Manifest ist das, was Sekunden statt Stunden möglich macht."
5. DORA-Schwelle für Wiederherstellung nach fehlgeschlagenem Deployment. DORA — Software delivery performance metrics. Die Elite-Performer-Schwelle für „failed deployment recovery time" ist mit unter einer Stunde dokumentiert. Die 12-Sekunden-Zahl der Pipeline liegt drei Größenordnungen unter der Elite-Schwelle, was die richtige Lesart des Vergleichs ist.
6. Calibrating the AI judge. Our companion post Calibrating the AI Judge. The procedure for keeping the human-anchored judge in calibration over time. The operational claim in this post — that auto-rollback only works as well as the judge driving it — only holds if the judge is in fact periodically recalibrated.
7. Intern — Divinci-Pipeline-Referenz. Die Architektur, auf der diese Automatisierungsschicht aufsitzt: der Beitrag zur vierstufigen Pipeline. Die vollständige API-Oberfläche ist in der API-Referenz dokumentiert; der Abschnitt zum Release-Management ist derjenige, von dem dieser Beitrag handelt.

Nächster Teil dieser Reihe: CI Testing for Custom Language Models in 2026. In diesem Beitrag geht es um die operative Ebene zwischen menschlichen Freigaben. Der nächste betrachtet die Ebene vor dem Pipeline-Start – Pre-Merge-CI: was zur PR-Zeit zu bewerten ist, welche Arten von Regressionen Sie tatsächlich vor dem Gate abfangen und welche nicht.