DevOps Fortgeschritten
Incident Management — Ein vollständiger Leitfaden¶
Incident ManagementSREOn-callProcess 6 min Lesezeit
Der Incident-Management-Prozess von der Erkennung bis zur Lösung. Severity-Levels, Rollen, Kommunikation und Eskalation.
Severity-Levels¶
- P1 (Critical) — Service nicht verfügbar, Auswirkung auf Umsatz/Sicherheit. Response: 5 Min
- P2 (High) — eingeschränkte Leistung, teilweiser Ausfall. Response: 15 Min
- P3 (Medium) — kleinere Funktion nicht verfügbar. Response: 1 Stunde
- P4 (Low) — kosmetisches Problem. Response: nächster Werktag
Incident-Rollen¶
- Incident Commander (IC) — koordiniert die Reaktion, entscheidet über Eskalation
- Technical Lead — leitet die technische Untersuchung
- Communications Lead — informiert Stakeholder, Status-Page
- Scribe — dokumentiert Timeline und Entscheidungen
Response-Prozess¶
- Detect — Alert oder Meldung eines Benutzers
- Triage — Severity und IC bestimmen
- Investigate — Diagnostik, Root Cause identifizieren
- Mitigate — Service wiederherstellen (Rollback, Restart, Failover)
- Resolve — dauerhafte Behebung
- Postmortem — innerhalb von 48 Std., blameless
Kommunikation¶
# Status-Page-Update-Vorlage
[Investigating] Erhöhte Fehlerrate am API Gateway.
Betroffene Services: API, Checkout.
Das Team arbeitet an der Identifizierung der Ursache.
[Identified] Ursache: hoher Speicherverbrauch nach Deployment v2.3.1.
Mitigation: Rollback auf v2.3.0 läuft.
[Monitoring] Rollback abgeschlossen. Fehlerrate sinkt.
Services werden schrittweise wiederhergestellt.
[Resolved] Incident behoben. Services voll funktionsfähig.
Postmortem wird innerhalb von 48 Std. veröffentlicht.
Zusammenfassung¶
Effektives Incident Management erfordert klare Rollen, Severity-Levels und Kommunikationsprozesse. Üben Sie regelmäßig.
Brauchen Sie Hilfe bei der Implementierung?¶
Unser Team hat Erfahrung mit dem Entwurf und der Implementierung moderner Architekturen. Wir helfen Ihnen gerne.