Incident Response & SRE

Warum SRE¶

Jedes System faellt aus. Die Frage ist nicht ob, sondern wann, wie schnell Sie es bemerken und wie schnell Sie es reparieren.

Traditioneller Ansatz: Ops-Team beobachtet Dashboards, Devs schreiben Code, eine Mauer dazwischen. Wenn etwas ausfaellt, beginnt Ping-Pong — „das ist nicht unser Bug”, „das ist Infrastruktur”, „bei mir lokal funktioniert es”. MTTR (Mean Time to Recovery) wird in Stunden gemessen.

SRE-Ansatz: Zuverlaessigkeit ist ein Feature. Wir messen sie (SLOs), budgetieren sie (Error Budgets), automatisieren sie (Runbooks), lernen aus Fehlern (Post-Mortems). Ergebnis: MTTR in Minuten, nicht Stunden. Proaktiv, nicht reaktiv.

Google hat SRE geschaffen, um Dienste fuer Milliarden von Nutzern zu betreiben. Aber SRE-Prinzipien funktionieren fuer ein Unternehmen mit 5 Entwicklern genauso gut wie fuer eines mit 5.000. Der Ansatz skaliert, nicht die Kopfzahl.

SLO/SLA — Zuverlaessigkeit messen¶

Ohne Messung ist Zuverlaessigkeit nur ein Gefuehl. „Das System laeuft gut” ist keine Metrik. SLO schon.

Service Level Indicators (SLI)¶

Ein SLI ist eine Metrik, die die Benutzererfahrung misst:

• Availability SLI: Anteil erfolgreicher Requests. successful_requests / total_requests
• Latency SLI: Anteil der Requests unter einem Latenz-Schwellenwert. requests_under_500ms / total_requests
• Freshness SLI: Anteil der innerhalb eines Zeitlimits aktualisierten Daten. Fuer asynchrone Systeme, Datenpipelines.
• Correctness SLI: Anteil korrekter Ausgaben. Fuer Rechendienste, ML-Inferenz.

Service Level Objectives (SLO)¶

Ein SLO ist ein Ziel fuer einen SLI: „99,9% der Requests werden erfolgreich sein” oder „95% der Requests werden eine Latenz unter 200ms haben”.

Wie wir SLOs setzen:

1. Baseline messen — wie ist die aktuelle reale Zuverlaessigkeit?
2. Benutzererwartungen definieren — was betrachten Benutzer als akzeptabel?
3. SLO setzen — leicht ueber Baseline, unter Perfektion. 100% ist kein realistisches SLO.
4. Iterieren — verschaerfen oder lockern basierend auf Daten und Feedback.

Service Level Agreements (SLA)¶

Ein SLA ist eine vertragliche Verpflichtung — ein SLO mit Konsequenzen. SLA-Verletzung = Strafen, Credits, vertragliche Auswirkungen. Ein SLA ist immer lockerer als das interne SLO. Wenn das interne SLO 99,95% ist, ist das SLA 99,9% — Sie haben einen Puffer.

Error Budgets — datengetriebene Entscheidungsfindung¶

Error Budgets verwandeln den abstrakten Tradeoff „Geschwindigkeit vs. Zuverlaessigkeit” in eine konkrete Zahl.

Wie es funktioniert¶

SLO 99,9% Availability = 0,1% Error Budget = 43,2 Minuten Downtime pro Monat.

Error Budget > 0: Das Team hat Raum fuer Risiken. Deploys, Experimente, grosse Refactorings — los geht’s. Geschwindigkeit hat Prioritaet.

Error Budget ≈ 0: Verlangsamen. Keine riskanten Deploys. Fokus auf Stabilitaet, Bugfixes, Reliability-Verbesserungen. Bis das Budget erneuert wird.

Error Budget < 0: SLO verletzt. Incident Review. Aktionsplan zur Wiederherstellung der Zuverlaessigkeit. Feature Freeze bis sich die Situation stabilisiert.

Error Budget Policies¶

Wir definieren im Voraus, was bei verschiedenen Error-Budget-Stufen passiert:

• >50% verbleibend: Business as usual. Schnelle Deploys, Experimente erlaubt.
• 25-50% verbleibend: Erhoehte Vorsicht. Canary Deploys obligatorisch. Extra Review fuer riskante Aenderungen.
• <25% verbleibend: Reliability Sprint. Keine neuen Features. Fokus auf Stabilitaet.
• Aufgebraucht: Feature Freeze. Post-Mortem fuer jeden Incident. Budget-Wiederherstellung hat hoechste Prioritaet.

Incident Response — wenn es brennt¶

Jeder Incident hat einen Lebenszyklus: Erkennung → Triage → Mitigierung → Loesung → Post-Mortem. Wir definieren Prozesse fuer jede Phase im Voraus — nicht mitten in der Panik.

Schweregrade¶

SEV1 — Kritisch: System nicht verfuegbar oder Datenverlust. Gesamtes Team mobilisiert. Kundenkommunikation. Loesungsziel: < 1 Stunde.

SEV2 — Major: Signifikante Service-Degradation. Teile der Funktionalitaet nicht verfuegbar. On-Call + Eskalation. Loesungsziel: < 4 Stunden.

SEV3 — Minor: Geringfuegige Degradation. Workaround existiert. On-Call bearbeitet waehrend Geschaeftszeiten. Loesungsziel: < 24 Stunden.

SEV4 — Niedrig: Kosmetische Probleme, kleine Bugs. Backlog, wird im normalen Sprint bearbeitet.

On-Call-Rotation¶

Prinzip: Jemand ist immer verantwortlich. 24/7-Abdeckung, woechentliche Rotation, klare Eskalationspfade.

Was On-Call bekommt: - Alert mit Kontext (was passiert, seit wann, welcher Impact) - Runbook (was Schritt fuer Schritt zu tun ist) - Eskalationskontakt (wen anrufen wenn es zu viel wird) - Zugang zu Dashboards, Logs, Traces

Was On-Call nicht bekommt: Vagen Alert „CPU hoch” ohne Kontext. Alert Fatigue — Dutzende Alerts, von denen 90% False Positives sind. Undokumentierte Systeme, bei denen niemand weiss was zu tun ist. Das beheben wir vorher.

Runbooks¶

Ein Runbook ist eine Schritt-fuer-Schritt-Anleitung zur Loesung eines bestimmten Incidents. Direkt vom Alert verlinkt — auf Alert klicken, Runbook oeffnet sich.

Ein gutes Runbook enthaelt: - Symptome: Was sehen Sie? Wie erkennen Sie diesen Incident-Typ? - Impact: Was ist betroffen? Wer ist betroffen? - Diagnose: Welche Dashboards oeffnen? Welche Abfragen ausfuehren? - Mitigierung: Wie stoppt man die Blutung? (Neustart, Rollback, Feature Flag aus) - Loesung: Wie behebt man die Root Cause? - Eskalation: Wann und an wen eskalieren?

Runbooks sind nicht statisch. Wir aktualisieren sie nach jedem Incident. Idealerweise automatisieren wir sie — Runbook als Skript, nicht als Dokument.

Blameless Post-Mortems¶

Nach jedem SEV1/SEV2-Incident gibt es ein Post-Mortem. Ziel: verstehen was passiert ist und Wiederholung verhindern. Nicht einen Schuldigen finden.

Struktur¶

Timeline: Minute fuer Minute, was passiert ist. Objektive Fakten, keine Interpretationen.

Root Cause Analysis: 5 Whys oder Fischgraeten-Diagramm. Warum ist es passiert? Warum wurde es nicht frueher erkannt? Warum dauerte die Mitigierung so lange?

Impact: Wie viele Nutzer betroffen? Wie lange? Finanzieller Impact?

Was gut lief: Was funktionierte? Welche Prozesse halfen? Wer reagierte hervorragend?

Was schlecht lief: Was scheiterte? Welche Prozesse fehlten? Was verlangsamte die Loesung?

Action Items: Spezifisch, zugewiesen, terminiert. „Alert fuer Connection Pool Exhaustion hinzufuegen” (Owner: Jana, Deadline: Freitag), nicht „Monitoring verbessern” (niemand, nie).

Blameless Kultur¶

Menschen machen Fehler. Systeme sollten so entworfen sein, dass ein einzelner menschlicher Fehler keine Katastrophe verursacht. Ein Post-Mortem sucht nach systemischen Ursachen:

• Warum hat das System einen Deploy ohne Canary erlaubt?
• Warum gab es keinen Rollback-Mechanismus?
• Warum kam der Alert nicht frueher?
• Warum existierte das Runbook nicht?

Wenn Menschen wissen, dass sie nicht bestraft werden, melden sie Probleme offen. Beinahe-Vorfaelle werden Lernmoeglichkeiten, nicht versteckte Geheimnisse.

Wie wir SRE implementieren¶

1. Assessment — wir kartieren aktuelle Prozesse, Metriken, Incident Handling
2. SLO-Workshop — wir definieren SLIs und SLOs mit Produkt- und Engineering-Teams
3. Error Budgets — wir richten Tracking, Policies, Reporting ein
4. On-Call-Setup — Rotation, Eskalation, Runbooks, Tooling (PagerDuty/OpsGenie)
5. Post-Mortem-Prozess — Template, Facilitation, Action Item Tracking
6. Iteration — vierteljaehrliches SLO-Review, Runbook-Updates, Prozessverbesserung

Stack¶

On-Call: PagerDuty, OpsGenie, Grafana OnCall.

Incident Management: Incident.io, Rootly, Jira.

Status Pages: Statuspage, Instatus, Cachet.

Monitoring: Prometheus + Grafana, Datadog.

Kommunikation: Slack Incident Channels, Bridge Calls.

Runbooks: Notion, Confluence, Backstage oder direkt in Git.

Verwandt mit