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.

Was macht einen guten Alarm aus?grundlagen

Ein Alarm ist nur dann wertvoll, wenn er eine aktuelle oder unmittelbar bevorstehende Benutzerbeeinträchtigung anzeigt und eine sinnvolle Reaktion ermöglicht. CPU allein ist meist kein Paging-Grund.

CommerceOne Alarmkatalogenterprise

Alarm	Priorität	Reaktion
Checkout SLO Fast Burn	Sev-1	sofortige Bereitschaft
Kafka Consumer Lag wächst	Sev-2	innerhalb 30 Minuten
Backup älter als 24 h	Sev-2	am selben Tag
Zertifikat läuft in 14 Tagen ab	Ticket	geplante Erneuerung

Prometheus-Regelbeispiele: operations/artifacts/prometheus-rules.yaml.

Routing und Ownershipoperations

Jeder Alarm besitzt Eigentümer, Runbook-Link, Priorität und erwartete Reaktionszeit. Nicht zuordenbare Alarme werden nicht einfach aktiviert, sondern zunächst verbessert.

Alarmqualität prüfentroubleshooting

Hat der Alarm eine echte Aktion ausgelöst?
War er früh genug, aber nicht zu früh?
War das Runbook hilfreich?
War die Priorität korrekt?
Kann der Alarm nach einem Incident präziser werden?

Alarmierung: vollständiger Zusammenhang

Alarmregeln sollen eine relevante Benutzerbeeinträchtigung oder einen unmittelbar drohenden SLO-Verstoß anzeigen. Technische Rohsignale wie CPU sind nur dann Paging-würdig, wenn sie mit einer klaren Wirkung und Handlung verbunden sind.

Wie funktioniert der Ablauf?Funktionsweise

Alarmierung 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

Der Checkout-Fast-Burn-Alarm kombiniert Fehlerrate und Error-Budget-Verbrauch. Er enthält Eigentümer, Dashboard, Runbook und Priorität. Nach jedem Incident wird geprüft, ob der Alarm zu spät, zu früh oder ohne Handlung ausgelöst hat.

sum(rate(http_requests_total{service="order",status=~"5.."}[5m]))
/ sum(rate(http_requests_total{service="order"}[5m])) > 0.05

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: Alarmierung 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.

Vom Signal zur handlungsfähigen Alarmierung

Ein Alarm beginnt mit einer Benutzerwirkung: Checkout schlägt fehl, Zahlungen bleiben unklar oder Bestandsreservierungen verzögern sich. Erst danach wird ein technisches Signal gewählt. So verhindert CommerceOne, dass jede hohe CPU-Auslastung einen Bereitschaftseinsatz auslöst, obwohl Benutzer nichts bemerken.

Burn-Rate-Alarme verwenden mehrere Zeitfenster. Ein kurzes Fenster erkennt schnelle Verschlechterung; ein längeres verhindert, dass ein einzelner Ausreißer unnötig alarmiert. Beide müssen auf dasselbe SLO und denselben Eventualitätsplan verweisen.

Jeder Alarm wird regelmäßig überprüft: Wie oft löste er aus? War eine Aktion nötig? Führte das Runbook zur Stabilisierung? Wurde die Ursache durch den Alarm sichtbar oder nur ein Symptom? Alarme ohne Eigentümer, Runbook oder erwartete Handlung werden nicht als produktionsreif behandelt.

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

Beispiel einer Alarmbeschreibung

Titel: Checkout Error Budget Fast Burn. Wirkung: Kunden können Bestellungen nicht abschließen. Signal: Fehlerrate über zwei Zeitfenster. Owner: Order Platform. Erste Handlung: SLO-Dashboard und letzte Deployments prüfen. Nicht erlaubt: Datenbank oder Cluster ohne Hypothese neu starten.

Qualität und Pflege

Zur Pflege gehört eine monatliche Auswertung von Paging-Häufigkeit, False Positives, fehlenden Runbook-Links und durchschnittlicher Reaktionszeit. Ein Alarm, der regelmäßig ignoriert wird, ist ein Qualitätsproblem und kein unveränderlicher Bestandteil des Systems.