Incident Management: Lektionen aus 5 Jahren Bereitschaftsdienst

Einführung

Nach fünf Jahren Bereitschaftsdienst in verschiedenen Organisationen – von Startups bis zu großen Unternehmen – habe ich gelernt, dass Incident Management ebenso sehr mit Menschen und Prozessen zu tun hat wie mit Technologie.

Dieser Beitrag teilt praktische Lektionen zum Aufbau einer wirklich funktionierenden Incident Response, zur Reduzierung der mittleren Wiederherstellungszeit (MTTR) und zur Schaffung einer On-Call-Kultur, die Ihr Team nicht ausbrennen lässt.

Die Anatomie effektiver Incident Response

Schweregrade, die Sinn ergeben

Die meisten Teams verkomplizieren Schweregrade unnötig. Hier ist ein einfaches Rahmenwerk, das funktioniert:

Die zentrale Erkenntnis: Schweregrad bemisst sich an der Nutzerauswirkung, nicht an der technischen Komplexität. Ein einfacher Bug, der alle Nutzer:innen betrifft, hat einen höheren Schweregrad als ein komplexes Problem, das niemanden betrifft.

Die ersten 5 Minuten

Die ersten fünf Minuten eines Vorfalls bestimmen seinen weiteren Verlauf. So sollte es ablaufen:

1. Alarm ausgelöst → Bereitschaftsdienst bestätigt (< 1 Min.)
2. Schnelle Einschätzung: Ist das echt? Wie groß ist der Wirkungsbereich?
3. Entscheidung: Kann ich das allein lösen, oder brauche ich Hilfe?
4. Bei SEV1/SEV2: Incident-Channel starten, zusätzliche Hilfe alarmieren
5. Kommunizieren: Ersten Status-Update posten

Ich habe Teams gesehen, die 20+ Minuten damit verschwendet haben herauszufinden, wer einbezogen werden sollte. Definieren Sie Eskalationspfade für häufige Szenarien im Voraus.

MTTR reduzieren: Was wirklich funktioniert

Runbooks, die tatsächlich genutzt werden

Die meisten Runbooks sind Dokumente, die nur geschrieben, aber nie gelesen werden. So machen Sie sie nützlich:

Schlechtes Runbook:

If the database is slow, check the queries and optimize them.

Gutes Runbook:

## Symptom: Datenbank-Latenz > 500 ms

### Schnelldiagnose (< 2 Min.)
1. Aktive Verbindungen prüfen: `SELECT count(*) FROM pg_stat_activity;`
   - Normal: < 100
   - Problem: > 200

2. Nach lang laufenden Queries suchen:
   ```sql
   SELECT pid, now() - pg_stat_activity.query_start AS duration, query
   FROM pg_stat_activity
   WHERE state != 'idle'
   ORDER BY duration DESC
   LIMIT 5;

Häufige Lösungen

• Zu viele Verbindungen: Connection Pooler neu starten

  kubectl rollout restart deployment/pgbouncer

• Lang laufende Query: Beenden (falls sicher)

  SELECT pg_terminate_backend(<pid>);

Eskalation

Falls nicht in 15 Min. gelöst, @database-team alarmieren

Der Unterschied: konkrete Befehle, erwartete Werte und klare Eskalationspfade.

Observability für Vorfälle

Während eines Vorfalls brauchen Sie schnell Antworten. Strukturieren Sie Ihre Observability rund um häufige Fragen:

// Was ich während eines Vorfalls wissen möchte:
const incidentQueries = {
  // Wird das Problem schlimmer oder besser?
  errorTrend: 'rate(http_errors_total[5m])',
  
  // Wann hat das begonnen?
  changePoint: 'changes(deployment_timestamp[1h])',
  
  // Was ist betroffen?
  affectedEndpoints: 'topk(10, sum by (endpoint) (http_errors_total))',
  
  // Ist es ein einzelner Verursacher oder weitreichend?
  errorsByUser: 'sum by (user_id) (http_errors_total)',
};

Bauen Sie Dashboards, die diese Fragen mit einem Klick beantworten, nicht mit fünf Minuten Query-Schreiben.

Nachhaltigen Bereitschaftsdienst aufbauen

Der On-Call-Vertrag

Jedes Team sollte einen expliziten On-Call-Vertrag haben:

## Erwartungen an den Bereitschaftsdienst

**Reaktionszeit:**
- SEV1: Bestätigung innerhalb von 5 Minuten
- SEV2: Bestätigung innerhalb von 15 Minuten
- SEV3+: Nächster Werktag

**Vergütung:**
- X € pro Woche Bereitschaftsdienst
- Freizeitausgleich nach Vorfällen (1 Stunde frei pro Stunde Vorfall)

**Unterstützung:**
- Nie die Erwartung, allein zu lösen – Eskalation ist erwünscht
- Keine Schuldzuweisung für Alarme außerhalb der Arbeitszeit
- Sekundärer Bereitschaftsdienst als Rückendeckung

**Grenzen:**
- Kein Bereitschaftsdienst während Urlaub
- Maximal 1 Woche pro Monat
- Ruhezeiten: 22–7 Uhr (nur SEV1)

Explizite Erwartungen verhindern Burnout und Groll.

Alarm-Müdigkeit reduzieren

Alarm-Müdigkeit ist der stille Killer der Effektivität des Bereitschaftsdienstes. So bekämpfen Sie sie:

Die 80/20-Regel für Alarme:

• 80 % der Alarme sollten handlungsrelevant sein
• Wenn Sie Alarme ignorieren, löschen Sie sie

Wöchentliche Alarm-Überprüfung:

## Alarm-Überprüfung – Woche vom 15. Januar

| Alarm | Alarme | Handlungsrelevant | Maßnahme |
|-------|-------|------------|--------|
| Hohe CPU | 12 | 2 | Schwellenwert auf 90 % anheben |
| Speicherplatz | 8 | 8 | Beibehalten |
| API-Latenz | 15 | 3 | Auto-Scaling hinzufügen |
| Memory Leak | 1 | 1 | Beibehalten |

**Entscheidung:** Alarm für hohe CPU löschen, Auto-Scaling für API umsetzen

Das schuldfreie Postmortem

Postmortems sind der Ort, an dem Lernen stattfindet – oder eben nicht. Hier ist eine Vorlage, die funktioniert:

## Vorfall: Ausfall der Zahlungsabwicklung
**Datum:** 15.08.2024
**Dauer:** 47 Minuten
**Schweregrad:** SEV1
**Autor:in:** [Name]

### Zusammenfassung
Die Zahlungsabwicklung war 47 Minuten lang nicht verfügbar, 
verursacht durch die Erschöpfung des Datenbank-Connection-Pools 
aufgrund einer Query-Regression im letzten Deployment.

### Zeitleiste
- 14:23 – Deployment abgeschlossen
- 14:31 – Erste Kundenmeldung
- 14:35 – Alarm ausgelöst, Bereitschaftsdienst alarmiert
- 14:42 – Grundursache identifiziert
- 14:58 – Rollback abgeschlossen
- 15:10 – Vollständige Wiederherstellung bestätigt

### Grundursache
Einer neuen Query im Checkout-Ablauf fehlte ein Index, wodurch 
Verbindungen 30+ Sekunden statt <100 ms gehalten wurden.

### Was gut lief
- Schnelle Identifikation der Grundursache
- Rollback-Prozess funktionierte reibungslos
- Kundenkommunikation erfolgte zeitnah

### Was verbessert werden könnte
- Query-Performance wurde im Code Review nicht erkannt
- Kein Lasttest für das neue Feature
- Alarm wurde erst 8 Minuten nach der ersten Kundenmeldung ausgelöst

### Maßnahmen
| Maßnahme | Verantwortlich | Fällig am |
|--------|-------|----------|
| Query-Performance-CI-Check hinzufügen | @backend | 22.08.2024 |
| Synthetisches Monitoring implementieren | @sre | 29.08.2024 |
| Alarm-Schwellenwerte überprüfen | @on-call | 18.08.2024 |

Der Schlüssel: Fokus auf Systeme, nicht auf Personen. „Der Deployment-Prozess ließ eine langsame Query zu” statt „Max hat eine langsame Query deployt.”

Vorfallskommunikation

Interne Kommunikation

Während eines Vorfalls: lieber zu viel als zu wenig kommunizieren:

## Vorlage für Vorfalls-Updates

**Status:** In Untersuchung | Identifiziert | Beobachtung | Behoben
**Auswirkung:** [Wer ist wie betroffen]
**Aktuelle Maßnahme:** [Was gerade getan wird]
**Nächstes Update:** [Wann das nächste Update zu erwarten ist]

Beispiel:
---
🔴 **Status:** Identifiziert
**Auswirkung:** ~30 % der Checkout-Versuche schlagen fehl
**Aktuelle Maßnahme:** Rollback von Deployment v2.3.4
**Nächstes Update:** in 10 Minuten oder bei Behebung

Externe Kommunikation

Bei kundenrelevanten Vorfällen:

Tun:

• Schnell bestätigen, auch ohne Details
• Klare Sprache statt Fachjargon verwenden
• Regelmäßige Updates geben, auch wenn sich nichts geändert hat
• Mitteilen, was gegen ein erneutes Auftreten unternommen wird

Nicht tun:

• Dritten die Schuld geben (auch wenn es deren Schuld ist)
• Konkrete Lösungszeiten versprechen
• Technische Details überstrapazieren
• Nach der Behebung verschwinden

Incident Response messen

Kennzahlen, die zählen

Verfolgen Sie diese Kennzahlen monatlich:

// Wie oft haben wir Vorfälle?
const incidentMetrics = {
  incidentCount: 'count by severity',
  
  // Wie schnell reagieren wir?
  timeToAcknowledge: 'median time from alert to acknowledgment',
  
  // Wie schnell beheben wir Probleme?
  timeToResolve: 'median time from alert to resolution',
  
  // Lernen wir dazu?
  repeatIncidents: 'incidents with same root cause as previous',
  
  // Ist der Bereitschaftsdienst nachhaltig?
  pagesPerWeek: 'average pages per on-call shift',
};

In die richtige Richtung tendieren

Gutes Incident Management zeigt sich in:

• Abnehmender Anzahl von Vorfällen über die Zeit
• Stabiler oder sinkender MTTR
• Niedriger Rate wiederkehrender Vorfälle (< 10 %)
• Nachhaltigem Alarmvolumen (< 2 pro Nacht)

Gelernte Lektionen

Nach Hunderten von Vorfällen weiß ich mit Sicherheit:

1. Vorbereitung schlägt Reaktion. In Runbooks und Automatisierung investierte Zeit zahlt sich während Vorfällen 10-fach aus.
2. Kommunikation ist die halbe Miete. Der meiste Stress bei Vorfällen entsteht durch Unsicherheit, nicht durch das technische Problem.
3. Eine schuldfreie Kultur ist nicht verhandelbar. Sobald Menschen Schuldzuweisungen fürchten, hören sie auf, Probleme zu melden und Erkenntnisse zu teilen.
4. Nachhaltigkeit des Bereitschaftsdienstes zählt. Ausgebrannte Entwickler:innen treffen schlechtere Entscheidungen und verlassen das Unternehmen.
5. Jeder Vorfall ist ein Geschenk. Er ist ein kostenloser Stresstest für Ihre Systeme und Prozesse. Lernen Sie daraus.

Fazit

Bei Incident Management geht es nicht darum, alle Ausfälle zu verhindern – das ist unmöglich. Es geht darum, effektiv zu reagieren, wenn Ausfälle auftreten, daraus zu lernen und Systeme (sowohl technische als auch menschliche) aufzubauen, die sich mit der Zeit verbessern.

Die besten Incident-Response-Teams, mit denen ich gearbeitet habe, haben eines gemeinsam: Sie betrachten Vorfälle als Gelegenheiten zur Verbesserung, nicht als Fehler, die versteckt werden müssen.

Ressourcen

• Incident Management for Operations – Google SRE Book
• PagerDuty Incident Response Guide
• Learning from Incidents – Community-Ressourcen