SLOs, Incident Response und Runbook-Szenarien
Von Metriken zu Entscheidungen: SLO, Error Budget, Burn Rate, Incident-Triage und Postmortem.
SLOIncidentRunbookBurn Rate
SLI und SLO
Ein SLI misst ein relevantes Symptom. Ein SLO setzt das Ziel. Error Budget macht sichtbar, wie viel Risiko für Änderungen verfügbar ist.
Incident Triage
Bei Störungen zählt zuerst Impact: Wer ist betroffen, wie stark, seit wann, gibt es Workaround und wer entscheidet über Rollback?
Runbook-Fragen
| Frage | Beispiel |
|---|---|
| Ist es ein Symptom-Alert? | Checkout Error Rate > 2% |
| Welche Metrik begrenzt? | DB Pool Wait Time |
| Was ist erste Mitigation? | Traffic reduzieren, Feature Flag aus |
| Wer ist Owner? | Order Platform On-Call |
Praxisübertragung auf das V4-Beispielprojekt
Entscheidung
Dokumentiere die getroffene Architekturentscheidung als ADR, inklusive Alternativen, Folgen und Betriebsrisiken.
Code-Nachweis
Markiere verwendete Entwurfsmuster direkt im Code und ergänze sie in docs/design-patterns.md.
Betrieb
Definiere Metrik, Alert, Runbook-Schritt und Rollback-Option für diesen Bereich.
Typische Fehlerbilder
- Framework-Feature wird eingesetzt, ohne fachliche Grenze zu verstehen.
- Technische Wiederholung wird nicht idempotent gemacht.
- Observability wird erst nach Produktionsproblem ergänzt.
- Tests prüfen nur Happy Path und keine Wiederanläufe.