Observability und Incident Response
Einführung · 4 Abschnitte · ~11 Min Lesezeit · Stand
Ereignisse werden erst mit Kontext zu Evidenz
Ein einzelner Eventlog-Eintrag beweist selten eine Ursache. Erst Zeit, Quelle, Change-Historie, Dienstmetrik und Clientwirkung bilden eine Hypothese, die man sicher testen kann.
Die Evidenzkette
- Auswirkung und betroffene Nutzer oder Dienste erfassen
- Zeitlinie aus Monitoring, Eventlogs und Changes bilden
- Hypothese gegen unabhängige Signale prüfen
- Begrenzte Maßnahme ausführen und Wirkung verifizieren
| **Metrik** | Zeigt Umfang und Trend, etwa Latenz, freien Speicher oder Fehlerrate. |
|---|---|
| **Log** | Liefert Zeitpunkt, Komponente und Fehlermeldung. |
| **Trace/Change** | Verbindet Ursache, Abhängigkeit oder zeitgleiche Änderung. |
Bei Sicherheitsverdacht
Eine verdächtige Anmeldung oder Prozessaktivität ist kein Anlass, Logs zu löschen oder Systeme blind neu zu starten. Folge dem Incident-Runbook: Zuständigkeit informieren, Scope begrenzen, volatile und zentrale Evidenz sichern und erst dann bereinigen oder wiederherstellen.
Im Check
- Ein Service-Control-Manager-Ereignis mit der verursachenden Komponente korrelieren.
- Logging- und Monitoringausfall als eigenes Betriebsrisiko behandeln.
- Bei Verdacht auf Kompromittierung Evidence und Containment vor Neuinstallation ordnen.