Praxis-Lab

SRE Reliability Engineering für den CommerceOne-Checkout

Das Lab entwirft ein vollständiges, offline nachvollziehbares Reliability-Modell. Es führt keine Befehle automatisch aus und arbeitet ohne produktive Secrets.

A · Serviceziel

kritische User Journey beschreiben
Good Event und Valid Event definieren
SLO und Fehlerbudget berechnen

B · Telemetrie

Resource Attributes festlegen
Collector-Prozessoren wählen
Cardinality und Redaction prüfen

C · Betrieb

Burn-Rate Alert definieren
Runbook und Eskalation verknüpfen
Service Level Review vorbereiten

Aufgabe 1: SLI und SLO

Formuliere ein fachliches Checkout-SLI. Der Nenner enthält nur valide gestartete Checkout-Versuche; der Zähler nur innerhalb des Zielzeitfensters erfolgreich abgeschlossene Vorgänge. Begründe Ausschlüsse.

SLO = 99.9 % erfolgreiche Checkout-Abschlüsse in 30 Tagen
Error Budget = 0.1 % der validen Checkout-Versuche
Fast burn = akute starke Verletzung
Slow burn = anhaltende schleichende Verletzung

Aufgabe 2: Telemetry Pipeline

Nutze die mitgelieferte Collector-Konfiguration. Prüfe, an welcher Stelle PII entfernt, Batches gebildet, Speicher begrenzt und Tail Sampling angewendet wird.

OTel-Collector-Konfiguration

Aufgabe 3: Alert und Runbook

Jeder Paging Alert benötigt Benutzerwirkung, Severity, Owner, Dashboard, Runbook und eine eindeutige erste Diagnosehandlung. Ein Alert ohne konkrete Handlung bleibt Ticket oder Dashboard-Signal.

Prometheus Rules · Checkout Runbook

Abnahmefragen

Misst das SLI das fachliche Ergebnis oder nur einen technischen Proxy?
Kann ein Label unbegrenzt neue Zeitreihen erzeugen?
Wer darf Rohlogs und Traces sehen?
Welche Änderung wird bei schnellem Burn gestoppt?
Wie wird die Wirksamkeit nach dem Incident belegt?

Abschlusskriterium: Ziel, Signal, Datenpfad, Alert, Owner, Runbook, Kosten- und Datenschutzgrenze sowie Review-Entscheidung sind konsistent miteinander verbunden.