Alerting und Incident Response

In DevOps hilft uns Monitoring dabei, zu sehen, was passiert. Aber bloßes Beobachten reicht nicht aus – wir müssen wissen, wenn etwas schiefläuft!

Alarme sind Benachrichtigungen, die ausgelöst werden, wenn bestimmte Bedingungen erfüllt sind und dadurch auf ein potenzielles Problem hingewiesen wird. Sie können sie sich als Alarmglocken Ihres Systems vorstellen.

Effektives Alerting macht aus passivem Monitoring eine proaktive Problemlösung. Es ist entscheidend für:

• Früherkennung: Probleme zu erkennen, bevor sie sich auf Benutzer auswirken.
• Schnellere Behebung: Das zuständige Team sofort zu benachrichtigen.
• Vermeidung von Ausfällen: Kleinere Probleme zu beheben, bevor sie sich verschlimmern.

Wenn ein Alarm ausgelöst wird, weist dies häufig auf einen Incident hin. Ein Incident ist eine ungeplante Unterbrechung eines Dienstes oder eine Beeinträchtigung seiner Qualität.

Beispiele sind der Absturz eines Servers, eine nicht mehr reagierende Datenbank oder ein sprunghaft ansteigendes Fehlerrate einer Anwendung.

Alarme werden auf Grundlage verschiedener Metriken oder Logs konfiguriert. Hier sind einige häufige Auslöser:

• Schwellenwerte: CPU-Auslastung > 90 % über 5 Minuten.
• Fehlerraten: HTTP-500-Fehler > 1 % der Anfragen.
• Verfügbarkeit: Der Dienst gibt keine Antwort zurück.
• Logmuster: Bestimmte Fehlermeldungen erscheinen in den Logs.

Nicht alle Alarme sind gleich dringend. Wir kategorisieren sie nach ihrem Schweregrad, um Reaktionen zu priorisieren:

• Kritisch: Der Dienst ist ausgefallen oder stark beeinträchtigt. Sofortiges Handeln ist erforderlich.
• Warnung: Ein potenzielles Problem zeichnet sich ab und erfordert baldige Aufmerksamkeit.
• Information: Ein nicht dringendes Ereignis, das nur zur Information dient.

Sobald ein Alarm ausgelöst wurde, muss er die richtigen Personen erreichen. Zu den gängigen Benachrichtigungskanälen gehören:

• E-Mail: Für weniger dringende Warnungen oder Informationsmeldungen.
• Chat (z. B. Slack): Gut, um das Team zu informieren und gemeinsam eine Diagnose zu erstellen.
• SMS/Telefonanruf: Für kritische Alarme, die sofortige Aufmerksamkeit erfordern, häufig über On-Call-Tools wie PagerDuty.

Incident Response ist der strukturierte Prozess zur Bearbeitung und Behebung von Incidents. Ein typischer Ablauf umfasst:

1. Erkennung: Ein Alarm wird ausgelöst.
2. Triage: Schweregrad und Auswirkungen bewerten.
3. Diagnose: Die Ursache identifizieren.
4. Behebung: Das Problem beheben.
5. Wiederherstellung: Die vollständige Funktionsfähigkeit des Dienstes wiederherstellen.
6. Post-Mortem: Aus dem Incident lernen.

Ein Runbook ist eine ausführliche Anleitung, in der die Schritte zur Behebung häufiger Incidents beschrieben sind. Runbooks sind entscheidend für:

• Einheitlichkeit: Sicherzustellen, dass Incidents einheitlich bearbeitet werden.
• Geschwindigkeit: Diagnose und Behebung zu beschleunigen.
• Wissensweitergabe: Neue Teammitglieder zu befähigen, effektiv zu reagieren.

Nach der Behebung eines Incidents ist ein Review nach dem Incident (oder Post-Mortem) von großer Bedeutung. Dabei handelt es sich um eine vorwurfsfreie Analyse mit Fokus auf folgende Fragen:

• Was ist passiert?
• Warum ist es passiert?
• Was hätte es verhindern können?
• Welche Maßnahmen können wir ergreifen, um eine Wiederholung zu verhindern?

Ziel ist die kontinuierliche Verbesserung, nicht die Suche nach Schuldigen.

Welche der folgenden Aussagen beschreibt den Hauptzweck eines Runbooks bei der Incident Response am besten?

Wir haben untersucht, wie Alarme als Alarmsignal Ihres Systems fungieren und durch bestimmte Bedingungen ausgelöst werden. Außerdem haben wir verschiedene Alarmstufen und Benachrichtigungskanäle kennengelernt.

Das Verständnis des Ablaufs der Incident Response und die Verwendung von Runbooks sind entscheidend, um Probleme effizient zu bearbeiten. Schließlich fördern Reviews nach Incidents kontinuierliches Lernen und die Verbesserung des Systems.