Incident-Stufen definieren
SEV-1 (Critical): Produktionssystem komplett ausgefallen
→ Sofortige Eskalation, alle Hände an Deck
→ Ziel: < 15 Minuten bis erster Fix
SEV-2 (High): Teilausfall oder starke Beeinträchtigung
→ On-Call benachrichtigen
→ Ziel: < 1 Stunde bis Lösung
SEV-3 (Medium): Beeinträchtigung, Workaround vorhanden
→ Nächster Werktag
→ Ziel: < 24 Stunden
SEV-4 (Low): Kosmetische Probleme, kein User-Impact
→ Nächster Sprint
Runbook-Template
# Runbook: Nginx ist down
## Symptome
- Alert: "Nginx service is down on web-01"
- Website nicht erreichbar
- HTTP 502 von Load Balancer
## Diagnose
### Schritt 1: Service-Status
ssh admin@web-01
systemctl status nginx
### Schritt 2: Fehler-Logs
journalctl -u nginx -n 50 --no-pager
tail -50 /var/log/nginx/error.log
### Schritt 3: Port prüfen
ss -tlnp | grep :80
## Lösung A: Nginx neustart
systemctl restart nginx
systemctl status nginx
## Lösung B: Konfigurations-Fehler
nginx -t # Konfiguration prüfen
# Fehler beheben, dann:
systemctl reload nginx
## Lösung C: Out of Memory
free -h
dmesg | grep -i oom
# → RAM aufräumen oder Server-RAM erhöhen
## Eskalation
Falls nicht gelöst nach 15 Minuten:
→ [email protected] anrufen
→ #incident Slack-Channel
On-Call mit PagerDuty/OpsGenie
OpsGenie Rotation:
Mo-Fr 08:00-18:00: Primär: [email protected]
Mo-Fr 18:00-08:00: Backup: [email protected]
Wochenende: Backup: [email protected]
Alert-Eskalation:
1. Primär benachrichtigen (Slack + App)
2. Nach 5 Minuten: Backup benachrichtigen
3. Nach 15 Minuten: Management benachrichtigen
Alert-Fatigue vermeiden
Symptome von Alert-Fatigue:
- 100+ Alerts pro Tag
- Alerts werden ignoriert/stumm geschaltet
- SEV-1 geht unter in Alert-Flut
Gegenmaßnahmen:
1. Alerts regelmäßig reviewen (monatlich)
2. Jeder Alert braucht Runbook
3. "Noisy" Alerts korrigieren oder löschen
4. Alertmanager Grouping nutzen
5. Nur actionable Alerts → Pager
Post-Mortem Template
# Post-Mortem: Datenbankausfall 2025-06-10
## Zusammenfassung
- Dauer: 14:23 - 15:47 (84 Minuten)
- Impact: Alle Benutzer konnten nicht einloggen
- Root Cause: Disk voll (PostgreSQL WAL-Verzeichnis)
## Timeline
14:23 - Erster Alert: "Database connection failed"
14:31 - On-Call benachrichtigt
14:45 - Root Cause identifiziert: /var/lib/postgresql 100%
15:12 - WAL-Logs archiviert, Platz frei
15:47 - Vollständige Wiederherstellung
## Root Cause
Kein Disk-Space-Monitoring für /var/lib/postgresql.
WAL-Logs akkumulierten nach fehlgeschlagener Replikation.
## Maßnahmen
- [x] Disk-Monitoring für alle Datenbankpfade hinzufügen
- [ ] WAL-Archivierung konfigurieren
- [ ] Replication-Lag-Alert hinzufügen
- [ ] Playbook für "Disk Full" erstellen
FAQ
Was ist der Unterschied zwischen MTTR und MTTD?
MTTD: Mean Time To Detect (Wie schnell merken wir einen Ausfall?). MTTR: Mean Time To Repair (Wie schnell beheben wir ihn?). Beide sind KPIs für SRE-Teams.
Fazit
Strukturiertes Incident Management mit Runbooks, klarer Eskalation und Blameless Post-Mortems reduziert Downtime und verbessert das gesamte System kontinuierlich.
IT-Betrieb und Incident Management für KMU in Heidelberg, Mannheim und der Rhein-Neckar-Region. Anfragen.