Welle 5 · Produktionsrealität

CommerceOne im echten Betrieb

Produktionsreife entsteht nicht durch ein einzelnes Werkzeug. CommerceOne verbindet messbare Zuverlässigkeitsziele, Telemetrie, sinnvolle Alarme, vorbereitete Reaktion, getestete Wiederherstellung und lernorientierte Nachbereitung zu einem geschlossenen Betriebszyklus.

Betriebszyklus

Codefluss vom Request bis zur Plattform

Der Code Explorer ist wie ein Stadtplan für einen Request. Jede Datei übernimmt eine klar begrenzte Aufgabe: Der Controller nimmt die Anfrage an, der Use Case koordiniert, das Aggregate schützt Regeln, Adapter sprechen Datenbank und Messaging an.

Alltagstaugliche Ablaufbeschreibung

Dieser Abschnitt beschreibt den Ablauf ohne unnötige Fachsprache. Er dient als Brücke zwischen dem sichtbaren Ergebnis und der technischen Umsetzung.

HTTP Request
Controller
Command
Application Service
Domain Aggregate
Repository Port
JPA Adapter
PostgreSQL
Outbox Adapter
Kafka
Telemetrie.

Fachlicher Ablauf

Ein fachliches Ereignis informiert andere Bereiche darüber, dass sich etwas Relevantes geändert hat. Der sendende Bereich bleibt verantwortlich für seine Aussage; empfangende Bereiche entscheiden selbst, wie sie darauf reagieren.

Fachliches Ziel: Der Ablauf liefert ein fachlich eindeutiges und für Benutzer beziehungsweise Betrieb nachvollziehbares Ergebnis.
Verantwortung: Jeder beteiligte Bereich entscheidet nur innerhalb seiner eigenen fachlichen Zuständigkeit.
Sichtbares Ergebnis: Order, Inventory, Payment und Notification können unabhängig reagieren, ohne eng gekoppelte synchrone Aufrufketten.

Technischer Ablauf

Der Producer schreibt ein Event in ein Topic. Partitionierung bestimmt Reihenfolge und Parallelität, Consumer Groups verteilen Arbeit, Offsets dokumentieren den Verarbeitungsstand. Retry, Idempotenz und Dead Letter Queue schützen vor Doppelwirkung und dauerhaft fehlerhaften Nachrichten.

Daten und Schnittstellen: Daten werden an jeder Grenze validiert und nur über definierte APIs, Ports oder Events weitergegeben.
Fehlerbehandlung: Fehler werden dort behandelt, wo ausreichender Kontext und Verantwortung vorhanden sind; Wiederholungen müssen sicher und nachvollziehbar bleiben.
Technischer Nachweis: Geprüft werden Producer-Erfolg, Topic/Partition, Consumer Lag, Offset-Fortschritt, Retry-Zahl und DLQ-Einträge.

Zusammenspiel: Der fachliche Ablauf erklärt, warum etwas geschieht und welches Ergebnis zählt. Der technische Ablauf erklärt, wie dieses Ergebnis zuverlässig, sicher und beobachtbar umgesetzt wird.

Warum SLOs?grundlagen

Ein Service Level Objective beschreibt die Zuverlässigkeit aus Sicht eines Benutzers. Für CommerceOne ist nicht entscheidend, ob ein Pod läuft, sondern ob eine Bestellung erfolgreich und innerhalb einer akzeptablen Zeit angenommen wird.

Beispiel: 99,9 % der gültigen Bestellanforderungen sollen in 30 Tagen erfolgreich sein; 95 % sollen in weniger als 800 ms beantwortet werden.

CommerceOne SLO-Katalogenterprise

Journey	SLI	SLO	Fenster
Bestellung anlegen	erfolgreiche gültige Requests	99,9 %	30 Tage
Checkout-Latenz	Requests < 800 ms	95 %	28 Tage
Bestandsreservierung	Event bis Reservierung < 10 s	99,5 %	7 Tage
Login	erfolgreiche Token-Ausgabe	99,95 %	30 Tage

Die maschinenlesbare Fassung liegt in operations/artifacts/slo-catalog.yaml.

Error Budget verstehendecision

Bei 99,9 % Verfügbarkeit sind in 30 Tagen ungefähr 43 Minuten Error Budget (Error Budget) erlaubt. Das Budget ist kein Ziel für Ausfälle, sondern ein Steuerinstrument: Wird es schnell verbraucht, haben Stabilisierung und Risikoreduktion Vorrang vor neuen Funktionen.

Entscheidungsregel

Budget gesund: normale Delivery.
Budget gefährdet: risikoreiche Änderungen reduzieren.
Budget aufgebraucht: Stabilitätsarbeit priorisieren und Ursachen beheben.

Burn-Rate-Alarmetroubleshooting

Ein Burn-Rate-Alarm erkennt, wie schnell das Error Budget verbraucht wird. Ein hoher kurzer Burn zeigt einen akuten Incident; ein moderater langer Burn zeigt eine schleichende Qualitätsverschlechterung.

sum(rate(http_server_requests_seconds_count{status=~"5.."}[5m]))
/
sum(rate(http_server_requests_seconds_count[5m]))

Der Ausdruck ist ein Lesebeispiel. Er wird nicht automatisch ausgeführt.

SLOs & Error Budgets: vollständiger Zusammenhang

Ein SLO übersetzt Zuverlässigkeit in ein messbares Versprechen. Das Error Budget macht sichtbar, wie viel Unzuverlässigkeit innerhalb eines Zeitfensters akzeptiert wird und wann Stabilitätsarbeit Vorrang vor neuen Releases erhält.

Wie funktioniert der Ablauf?Funktionsweise

SLOs & Error Budgets wird aus Benutzerwirkung und SLO abgeleitet. Verantwortliche definieren Signal, Schwelle, Handlung, Sicherheitsgrenze und Nachweis. Nach einem Incident wird überprüft, ob Messung und Prozess die richtige Entscheidung unterstützt haben.

Konkretes CommerceOne-BeispielPraxis

CommerceOne definiert für Checkout 99,9 % erfolgreiche Anfragen über 30 Tage. Ein schnelles Burn Rate Signal stoppt riskante Deployments; ein langsames Signal führt zu geplanter Ursachenarbeit.

slo: checkout-success
target: 99.9%
window: 30d
fast-burn: 14.4x / 1h
slow-burn: 2x / 6h

So liest du das Beispiel: Identitäten und Zustände werden ausdrücklich benannt. Wiederholung, Teilfehler und Beobachtbarkeit sind Teil des Designs. Das Beispiel ist zum Lesen und Anpassen gedacht; es wird nichts automatisch ausgeführt.

Entscheidungs- und DiagnosefragenReflexion

Welches fachliche Ergebnis soll für den Benutzer entstehen?
Welche Komponente besitzt die Verantwortung und welche Daten gehören ihr?
Was passiert bei Timeout, Wiederholung oder Teilausfall?
Welches Signal beweist, dass der Ablauf korrekt funktioniert?
Welche einfachere Alternative wäre ausreichend?

Zusammenfassung: SLOs & Error Budgets ist kein Dokument zum Abhaken, sondern ein überprüfbarer Teil des Betriebs. Qualität zeigt sich daran, ob Teams unter realem Druck schnell und sicher handeln können.

SLOs als gemeinsame Entscheidungsgrundlage

Ein SLO wird aus einer Benutzerreise abgeleitet. Für Checkout zählt nicht, ob jeder Pod läuft, sondern ob gültige Bestellungen innerhalb der vereinbarten Zeit erfolgreich verarbeitet werden. Der Service Level Indicator muss diese Wirkung messbar und gegen Fehlmessung robust abbilden.

Das Error Budget verbindet Produktentwicklung und Zuverlässigkeit. Wird das Budget schnell verbraucht, pausiert CommerceOne riskante Releases und priorisiert Stabilisierung. Ist ausreichend Budget vorhanden, dürfen Teams bewusst experimentieren. Diese Regel verhindert sowohl dauerhafte Instabilität als auch übertriebene Vorsicht.

SLOs werden regelmäßig überprüft. Ein Ziel, das nie verletzt wird, kann zu locker sein; ein dauerhaft unerreichbares Ziel erzeugt Alarmmüdigkeit. Änderungen benötigen Daten, Produktkontext und Zustimmung der verantwortlichen Teams.

Merksatz: Ein Inhalt gilt erst dann als verstanden, wenn Ziel, Ablauf, Fehlerfall und Nachweis in eigenen Worten erklärt werden können.