Incident Response und SRE-Praktiken für Produktionssysteme

Site Reliability Engineering (SRE) ist das Ergebnis, wenn man Operations als ein Software-Engineering-Problem betrachtet. Im Jahr 2026, da self-hosted Infrastructure immer gängiger wird und verteilte Systeme an Komplexität gewinnen, sind SRE-Praktiken nicht mehr optional – sie sind das Fundament für die Zuverlässigkeit in der Produktion.

Dieser Leitfaden behandelt die Kernpraktiken von SRE, die unabhängig davon gelten, ob Sie einen Kubernetes-Cluster mit drei Knoten oder eine Multi-Region-Flotte von 500 Servern betreiben.

SLIs, SLOs und Error Budgets

Der grundlegende Vertrag von SRE ist das Service Level Objective (SLO), gemessen durch Service Level Indicators (SLIs).

Auswahl der SLIs

Gute SLIs messen das, was Nutzer erleben, und nicht interne Infrastruktur-Metriken:

Service-Typ	Primärer SLI	Ziel
HTTP API	Request-Latenz p99	< 500ms
Datenbank	Query-Dauer p95	< 100ms
Message Queue	End-to-End-Delivery-Latenz	< 5s
Web-Applikation	Seitenladezeit p75	< 2s
Batch-Job	Abschlussrate	> 99.9%

Festlegung von SLOs

Ein SLO ist der Zielwert für einen SLI über ein rollierendes Zeitfenster (typischerweise 30 Tage):

slo:
  name: api-latency
  sli: http_request_duration_seconds
  aggregation: p99
  window: 30d
  target: 0.5 # 500ms
  compliance: 99.9

Das Error Budget ist 100 % minus das SLO. Bei einem SLO von 99,9 % haben Sie ein Budget von 0,1 % für Fehler – das entspricht etwa 43 Minuten Ausfallzeit pro 30-Tage-Fenster.

Error Budget Policy

Das Error Budget bestimmt die Release-Geschwindigkeit. Wenn das Budget aufgebraucht ist, werden alle Feature-Releases gestoppt, bis die Zuverlässigkeit wiederhergestellt ist:

error_budget_policy:
  exhaustion_action: freeze-deployments
  exhaustion_condition: budget < 10%
  notify:
    - on-call-engineer
    - team-leads
  top-level: require-approval

Dies schafft einen direkten Feedback-Loop: Sinkt die Zuverlässigkeit, sinkt die Engineering-Geschwindigkeit. Teams werden so motiviert, sowohl Features auszuliefern als auch die Zuverlässigkeit aufrechtzuerhalten.

Incident Management

Incident-Schweregrade

Definieren Sie klare Schweregrade, damit die richtigen Personen mit der entsprechenden Dringlichkeit reagieren:

Level	Label	Reaktionszeit	Beispiel
SEV1	Kritisch	15 Minuten	Vollständiger Service-Ausfall, Datenverlust
SEV2	Hoch	30 Minuten	Eingeschränkte Performance für Teilnutzer
SEV3	Mittel	4 Stunden	Feature defekt für kleinen Prozentsatz der Nutzer
SEV4	Niedrig	Nächster Werktag	Kosmetische Fehler, Dokumentationsfehler

Incident-Response-Workflow

1. Detection: Automatisierte Alerts von Prometheus/Grafana, synthetisches Monitoring oder Nutzerberichte
2. Triage: Der First Responder bestätigt den Alarm, bewertet den Schweregrad und erklärt bei Bedarf einen Incident
3. Mitigation: Die „Blutung“ stoppen – Rollback, Traffic-Umleitung, Scale-up
4. Resolution: Dauerhafte Behebung implementieren
5. Follow-up: Postmortem schreiben, Action Items tracken

Kommunikation während Incidents

Richten Sie pro Incident einen Kommunikationskanal ein. Nutzen Sie eine Statusseite für die externe Kommunikation. Aktualisieren Sie diese während laufender Incidents alle 30 Minuten, selbst wenn es keine neuen Informationen gibt.

Postmortem-Kultur

Ein blameless Postmortem ist die wichtigste Reliability-Praxis. Jeder SEV1- und SEV2-Incident erfordert ein Postmortem innerhalb von 5 Werktagen:

## Postmortem: API Latency Spike on 2026-07-15

### Summary

p99 latency increased from 200ms to 4500ms for 23 minutes, affecting 12% of traffic.

### Timeline

- 14:23 — Alert fired (p99 > 1000ms)
- 14:25 — Engineer acknowledged
- 14:28 — Identified database connection pool exhaustion
- 14:32 — Scaled connection pool from 50 to 200
- 14:46 — Latency returned to baseline

### Root Cause

A deployment at 14:00 increased per-request database connections from 2 to 8 without corresponding pool adjustment.

### Action Items

- [ ] Add connection pool utilization dashboard to standard deploy checklist
- [ ] Implement connection pool saturation alert
- [ ] Add pool size assertion to deployment pipeline

Das Kernprinzip: Die Ursache ist niemals die Person, die den Knopf gedrückt hat. Die Ursache ist immer eine Prozesslücke, ein fehlender Test oder ein Designfehler.

On-Call-Praktiken

Rotation

• Teams aus mindestens 4–6 Engineers
• Primäre Schichten von einer Woche
• Secondary für Übergaben und Eskalationen
• Kein Engineer ist in mehr als einer von vier Wochen im On-Call-Dienst

Eskalation

• Primary übernimmt SEV3/4 innerhalb der definierten Zeiten
• Secondary übernimmt SEV1/2 oder wenn Primary nicht verfügbar ist
• Engineering Leads bei länger andauernden oder teamübergreifenden Incidents

Quality of Life

• Offline zugängliche Dokumentation zur Incident Response
• Runbooks für die Top 20 Fehlerszenarien
• Shadow Shifts für neue Engineers
• Dokumentation zur Übergabe nach der Schicht

Automation

Die primäre Investition des SRE-Teams sollte in die Automatisierung fließen, die Incidents verhindert, die Reaktionszeit verkürzt und Toil eliminiert:

• Automated Rollback: Deployments, die bei Überschreitung von Alert-Schwellenwerten automatisch zurückgerollt werden
• Auto-scaling: Horizontal Pod Autoscaling mit HPA und Cluster Autoscaler
• Health Checks: Liveness-, Readiness- und Startup-Probes mit angemessenen Failure Thresholds
• Remediation Runbooks: Automatisierte Antworten auf gängige Fehlermuster (Restart, Scale, Redirect)

Measuring SRE Success

Metrik	Ziel
Mean Time to Detection (MTTD)	< 5 Minuten
Mean Time to Mitigation (MTTM)	< 15 Minuten
Mean Time to Resolution (MTTR)	< 60 Minuten
Change Failure Rate	< 5%
Deployment Frequency	Mehrfach pro Tag
Toil Percentage	< 50% der Zeit

Die ultimative SRE-Metrik ist nicht die Uptime. Es ist die Frage, ob das Team nachts ruhig schlafen kann, weil es weiß, dass seine Systeme beobachtbar, behebbar und verstanden sind.