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.

Telemetry entlang der Bestellreisearchitecture

CommerceOne korreliert Metriken, Logs und Traces über eine gemeinsame trace_id, order_id und einen stabilen Service-Namen. So kann eine langsame Bestellung vom Gateway über den Order Service bis PostgreSQL und Kafka verfolgt werden.

Gateway erzeugt oder übernimmt Trace-Kontext.
Order Service schreibt strukturierte Logs.
Datenbank- und Kafka-Spans zeigen Wartezeiten.
Metriken zeigen Umfang und Dauer des Problems.

Golden-Signal-Dashboardenterprise

Signal	CommerceOne-Frage
Traffic	Wie viele Bestellungen erreichen uns?
Errors	Welche Benutzeraktionen scheitern?
Latency	Wo entsteht Wartezeit?
Saturation	Welche Ressource ist erschöpft?

Eine portable Dashboard-Definition liegt unter operations/artifacts/commerceone-dashboard.json.

Strukturierte Logscode

{
  "level": "ERROR",
  "service": "order-service",
  "trace_id": "8b5...",
  "order_id": "ORD-1042",
  "event": "payment_authorization_failed",
  "error_code": "PAYMENT_TIMEOUT"
}

Keine Passwörter, Tokens, vollständigen Kartendaten oder unnötige personenbezogene Daten loggen.

Triage mit drei Signalentroubleshooting

Beginne mit der Benutzerwirkung im Dashboard. Öffne danach einen repräsentativen Trace und nutze dessen Kontext, um die passenden Logs zu filtern. So vermeidest du zufälliges Suchen in großen Logmengen.

Dashboards: vollständiger Zusammenhang

Ein Betriebsdashboard beantwortet eine konkrete Frage. Die oberste Ebene zeigt Benutzerwirkung und SLO; darunter folgen Service-, Abhängigkeits- und Ressourcenebenen. So beginnt die Diagnose nicht bei zufälligen Infrastrukturgraphen.

Wie funktioniert der Ablauf?Funktionsweise

Dashboards 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

Das CommerceOne-Checkout-Dashboard zeigt Erfolgsrate, p95-Latenz, Auftragsrate und Error-Budget. Ein Klick führt zu Order Service, PostgreSQL, Kafka und Traces. Alle Panels verwenden denselben Zeitraum und dieselben Service-Labels.

histogram_quantile(0.95, sum by (le) (rate(http_server_duration_seconds_bucket{service="order"}[5m])))

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

Dashboards als Diagnosepfad

Ein Dashboard sollte die Diagnose in Ebenen führen. Ebene eins zeigt Geschäfts- und Benutzerwirkung: Checkout-Rate, Erfolgsquote und Latenz. Ebene zwei zeigt den Order Service, Ebene drei Datenbank, Kafka und Identity. Ressourcenmetriken stehen weiter unten, weil sie ohne Kontext selten die wichtigste Frage beantworten.

Alle Panels verwenden konsistente Labels und Zeiträume. Eine Trace-ID oder Order-ID ermöglicht den Wechsel von einer Metrik zu Logs und Traces. Ohne diese Korrelation muss ein Team unter Zeitdruck unterschiedliche Systeme manuell zusammensuchen.

Dashboards werden mit realen Fragen getestet: Kann ein On-Call innerhalb von fünf Minuten erkennen, ob die Ursache im Gateway, Service, Pool oder Kafka liegt? Zeigt das Dashboard auch einen schleichenden Fehler? Werden personenbezogene Daten vermieden? Nicht genutzte Panels werden entfernt statt dauerhaft mitgeführt.

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

Pflege und Ownership

Jedes Dashboard besitzt einen fachlichen Eigentümer und ein Review-Datum. Panels mit unklarer Einheit, fehlendem SLO-Bezug oder dauerhaft leerer Datenquelle werden korrigiert oder entfernt. Änderungen an Labels und Instrumentierung werden gemeinsam mit Dashboards ausgeliefert.