Zusammenfassung

Dieser KI Code Generator Rollout Simulator zeigt, wie viel deines 30-Tage-Fehlerbudgets eine fehlerhafte, KI-geschriebene Änderung verbrennt, bevor sie zurückgerollt wird. Gib Traffic, SLO, Rollout-Stufenleiter, Beobachtungszeit und Erkennungsgeschwindigkeit ein. Verglichen werden ein einzelner Deploy mit 100%, ein gestufter Rollout mit Beobachtung durch einen Menschen und ein automatisches SLO-Gate, mit einfacher Arithmetik, die du von Hand prüfen kannst.

Kostenloser Rollout-Planer

Simuliere, wie weit sich eine KI-Code-Änderung ausbreitet, bevor du zurückrollst

Trage Traffic, SLO und Stufenleiter ein. Das Tool zeigt, wie viel Fehlerbudget eine fehlerhafte Änderung eines KI-Code-Generators verbrennt, bei einem einzelnen Deploy, einem Menschen am Dashboard und einem automatischen Gate.

Simulator starten So funktioniert die Rechnung

KI-Code-Rollout-Simulator

Jedes Feld aktualisiert das Ergebnis sofort. Die Standardwerte beschreiben einen Dienst mit 200 Anfragen pro Sekunde, einem SLO von 99.9% und einer Änderung, die 20% der Anfragen fehlschlagen lässt.

Dein Rollout-Plan
StufeTrafficStartet beiAnfragen über den neuen Code
So funktioniert es

Drei Rechenschritte, kein verstecktes Modell

Fehlerbudget

Budget = (1 − SLO) × durchschnittliche Anfragen pro Sekunde × 2,592,000 Sekunden in 30 Tagen. Bei 200 Anfragen pro Sekunde und 99.9% sind das 518,400 fehlgeschlagene Anfragen, die du pro Monat tolerieren darfst.

Exposition über die Zeit

Die Stufenleiter gibt pro Minute den Anteil des Traffics an, der auf dem neuen Code läuft. Der Simulator summiert diesen Anteil von der ersten Anfrage bis zur Erkennungszeit plus Rollback-Zeit. Eine langsame Erkennung lässt die Änderung also in spätere, größere Stufen rutschen.

Fehlgeschlagene Anfragen

Fehlgeschlagen = Anfragen pro Sekunde × dein Fehleranteil × Expositionsintegral. Geteilt durch das Budget ergibt sich der Anteil des Monats, den eine fehlerhafte Änderung kostet. Drei Erkennungsmodi werden auf derselben Stufenleiter verglichen.

Für eine echte Änderung nutzen

Vom KI-generierten Diff zum Rollout-Plan

  1. 1

    Wähle pessimistische Eingaben

    Bei einer Änderung, die ein KI-Code-Generator geschrieben und nur schnell geprüft wurde, nimm einen hohen Fehleranteil an, falls sie fehlerhaft ist, und eine Erkennungszeit des Menschen, die zu deinem langsamsten jüngsten Vorfall passt, nicht zu deinem besten.

  2. 2

    Vergleiche die drei Szenarien

    Der einzelne Deploy zeigt den schlimmsten Fall. Der gestufte Fall mit Mensch zeigt, was dir deine Stufenleiter heute bringt. Das automatische Gate zeigt, was sich mit einem Gate auf deiner SLO-Metrik ändern würde.

  3. 3

    Kopiere den Plan ins Runbook

    Der Kopierbutton exportiert die Stufen und den schlimmsten Budgetverbrauch als Klartext, bereit zum Einfügen in ein Change-Ticket oder eine Pull-Request-Beschreibung.

Warum die Stufenleiter zählt

Auf der ersten Stufe wird das meiste Budget gerettet

Eine Änderung, die 20% der Anfragen bei 1% Traffic fehlschlagen lässt, erzeugt Fehler bei 0.2% der Anfragen. Dieselbe Änderung bei 100% lässt jede fünfte Anfrage scheitern. Der Abstand zwischen diesen beiden Zahlen ist das ganze Argument für einen schrittweisen Rollout. Wenn der Code von einem Generator stammt, der in Sekunden hunderte Zeilen erzeugt, sinkt die Prüfzeit pro Zeile, und die erste Stufe wird zum Ort, an dem du es herausfindest.

  • Eine erste Stufe mit 1% begrenzt den Schadensradius um 99%, bevor irgendetwas anderes gemessen wird.
  • Die Beobachtungszeit hilft nur, wenn dein Signal eine Regression innerhalb dieses Fensters zeigen kann.
  • Schneller zurückzurollen ist genauso viel wert wie schneller zu erkennen: Beides geht in das Expositionsintegral ein.
Serverschrank mit einer gelben Statusleuchte zwischen grünen
Ergebnis lesen

Was du mit den drei Zahlen anfängst

Einzelner Deploy

Liegt diese Zahl bei einem plausiblen Fehler über 5% des monatlichen Budgets, ist ein Deploy in einem Schritt eine Entscheidung, das Budget für eine einzige Änderung auszugeben. Nur wenige Teams treffen diese Entscheidung bewusst.

Gestuft, Mensch

Das ist deine heutige Realität, wenn der Bereitschaftsdienst Graphen beobachtet. Zeigt die Spitzenexposition 100%, ist deine Stufenleiter kosmetisch: Die fehlerhafte Änderung erreicht alle, bevor jemand reagiert.

Gestuft, automatisches Gate

Das spricht für ein Gate, das deine SLO-Metrik liest und ohne Rückfrage zurückrollt. Der Nutzen ist nur real, wenn das Gate auf demselben Signal auslöst, das dein SLO verwendet. Teste es deshalb mit einer absichtlich fehlerhaften Änderung.

Häufige Fragen

Ist der KI Code Generator Rollout Simulator kostenlos?
Ja. Er läuft komplett in deinem Browser, braucht keine Anmeldung und sendet außer einem anonymen Nutzungs-Beacon nichts an einen Server. Er ist selbst kein KI-Code-Generator: Er simuliert, wie weit sich eine fehlerhafte Änderung ausbreitet, sobald Code aus einem solchen Generator deine Pipeline erreicht.
Woher stammen die Zahlen?
Aus Rechnungen, die du von Hand nachprüfen kannst. Das Fehlerbudget ist (1 − SLO) mal die Anfragen in 30 Tagen. Fehlgeschlagene Anfragen sind dein Traffic mal Fehleranteil mal der Traffic-Anteil, den der neue Code erhält, integriert über die Zeit bis der Rollback abgeschlossen ist. Kein Benchmark ist eingebaut; jede Annahme ist eine Eingabe.
Warum KI-generierten Code anders modellieren als von Menschen geschriebenen?
Die Mathematik ist identisch. Verändert wird die Ausgangsannahme: Ein großer Diff, der in Minuten entsteht, hat pro Zeile weniger menschliche Prüfung erhalten, daher verdienen Fehleranteil und Erkennungszeit pessimistische Werte. Setze beide anhand deiner eigenen Incident-Historie, nicht anhand dieser Seite.
Was nimmt der Simulator an, was echter Traffic nicht tut?
Er nimmt gleichmäßigen Traffic an, eine Regression, die von der ersten Anfrage an denselben Anteil an Anfragen fehlschlagen lässt, und einen Rollback, der den Schaden sofort stoppt, sobald er abgeschlossen ist. Echte Incidents haben Anlaufphasen, Teilausfälle und langsame Rollbacks, also behandle das Ergebnis als Untergrenze des Schadens, nicht als Prognose.
Welche Erkennungszeit ist für ein automatisches SLO-Gate sinnvoll?
Das hängt von deiner Metrik-Auflösung und deinem Alarmfenster ab. Ein Gate, das eine Fehlerrate pro Minute gegen einen Schwellwert prüft, kann in zwei bis fünf Minuten auslösen. Wenn dein Alarming erst nach einem 30-Minuten-Burn-Rate-Fenster auslöst, trage stattdessen diesen Wert ein, dann zeigt der Simulator, was er kostet.
Hilft eine längere Beobachtungszeit immer?
Nein. Eine längere Beobachtung gibt dem Gate pro Stufe mehr Daten, hält aber auch eine fehlerhafte Änderung länger bei einem bestimmten Traffic-Anteil. Erkennt das Gate innerhalb von zwei Minuten, fügt eine zehnminütige Beobachtung meist nur Wartezeit hinzu. Braucht es fünfzehn Minuten, erreicht die Änderung bei einer fünfminütigen Beobachtung vorher schon 25% oder mehr.
Kann ich das auch für Feature-Flag-Rollouts nutzen, nicht nur für Deploys?
Ja. Ein prozentualer Rollout eines Flags verhält sich für diese Berechnung wie ein Canary-Deploy: ein Traffic-Anteil, eine Beobachtungszeit, eine Erkennungsverzögerung und eine Rollback-Zeit. Ersetze die Rollback-Zeit durch deine Latenz beim Kill-Switch des Flags.

Soll das Gate das Zurückrollen für dich übernehmen?

upstreamapi betreibt schrittweise Rollouts mit SLO-Gates und automatischem Rollback, daher ist die dritte Spalte die, mit der du ausliefern solltest.

upstreamapi ansehen