Alerting & Incident Response

Entstehung und Beteiligte

Alarmierung entstand aus Betriebsüberwachung, Bereitschaftsdiensten und später Site Reliability Engineering. Google prägte mit SRE Methoden wie Service Level Objectives und Error Budgets; moderne Incident-Response-Plattformen automatisieren Eskalation.

Welches Problem sollte gelöst werden?

Messdaten helfen nur, wenn relevante Störungen rechtzeitig die richtige Person erreichen. Gleichzeitig dürfen unwichtige Schwankungen nicht dauerhaft Bereitschaften wecken.

Technische Hürden und Lösungen

Statische Schwellenwerte erzeugen Flapping und Alarmmüdigkeit. Abhängigkeiten führen zu hunderten Folgealarmen. Gute Systeme deduplizieren, unterdrücken Wartungsfenster und alarmieren nach Nutzerwirkung. Nachbereitung muss Lernen statt Schuldzuweisung fördern.

Standardisierung und Einordnung

Monitoring entwickelte sich vom einfachen Prüfen erreichbarer Geräte zu einer eigenen Disziplin aus Metriken, Ereignissen, Protokollen und Traces. Die zentrale Schwierigkeit besteht nicht im Sammeln möglichst vieler Daten, sondern im Erkennen relevanter Abweichungen. Zeitstempel, eindeutige Identitäten, Aufbewahrung, Normalisierung und sinnvoll gesetzte Alarmgrenzen entscheiden darüber, ob Messdaten im Störungsfall helfen.

Technik im praktischen Betrieb

Ein Messwert benötigt Kontext: Einheit, Quelle, Intervall, Aggregation und erwarteten Normalbereich. Durchschnittswerte können kurze Spitzen verdecken, Maximalwerte kleine Ausreißer überbetonen. Aufbewahrung und Auflösung sollten zum Diagnoseziel passen. Alarme müssen einen klaren Besitzer, eine Handlungsanweisung und eine Eskalation besitzen. Regelmäßige Tests mit absichtlich ausgelösten Fehlern zeigen, ob Benachrichtigung, Bereitschaft und Runbook wirklich funktionieren.

Warum das Thema heute noch relevant ist

Historische Daten schaffen erst dann Wert, wenn sie vergleichbar bleiben. Änderungen an Geräten, Namen, Intervallen oder Messdefinitionen müssen deshalb nachvollziehbar sein. Langfristige Trends beantworten Kapazitätsfragen, detaillierte kurze Daten helfen bei Störungen. Beide Ziele verlangen unterschiedliche Auflösung. Monitoring ist zugleich Teil der Beweiskette: Ohne unabhängige Zeit, unveränderte Logs und bekannte Datenlücken lässt sich nach einem Vorfall nur schwer unterscheiden, was tatsächlich geschah und was lediglich vermutet wird.

Daten und Meilensteine

• Ein Alert sollte handlungsfähig und einer Verantwortung zugeordnet sein.
• SLOs messen Zuverlässigkeit aus Nutzersicht.
• Runbooks beschreiben erste Diagnose- und Gegenmaßnahmen.
• Postmortems dokumentieren Ursache, Wirkung und Verbesserungen.

Warum Alerting?

Monitoring ohne Alerting ist wertlos – niemand starrt 24/7 auf Dashboards. Alerting benachrichtigt automatisch das On-Call-Team (Bereitschaftsdienst) wenn Schwellwerte überschritten werden oder Anomalien auftreten. Dabei ist die Kunst: ausreichend alarmieren (keine Probleme verpassen) ohne Alert Fatigue (zu viele false positives führen dazu, dass Alarme ignoriert werden).

Gutes Alerting: Symptombasiert (not "CPU high", aber "users can't login"), actionable (es gibt eine klare Handlungsempfehlung), mit Runbooks verknüpft.

Alerting-Tools und On-Call

• PagerDuty: Marktführer für On-Call-Management. Eskalations-Policies, Rotationen, Mobiltelefon-Push/SMS/Anruf.
• OpsGenie (Atlassian): Ähnlich PagerDuty, gut in Jira integriert.
• Prometheus Alertmanager: Open-Source, für Prometheus-basierte Setups. Deduplication, Grouping, Routing.
• Grafana OnCall: Open-Source On-Call-Management, Grafana-integriert.
• Notification-Kanäle: Push-Notification (erste Wahl), SMS (zuverlässig, kein Internet nötig), Anruf (kritisch), Slack/Teams (Collaboration), E-Mail (weniger zeitkritisch).

Incident Response und Post-Mortem

Runbooks (auch Playbooks) dokumentieren Schritt-für-Schritt-Anleitungen für bekannte Probleme – "Alert X ausgelöst? Prüfe Y, dann führe Z durch." Reduziert MTTR (Mean Time to Recover).

SLAs und SLOs definieren Verfügbarkeitsziele: 99.9% = max. 8,7h Downtime/Jahr, 99.95% = 4,4h, 99.99% = 52 Min (Four Nines).

Post-Mortem (blameless): Nach jedem schwerwiegenden Incident analysieren: Was ist passiert? Warum? Was wurde getan? Was verbessern wir? Fokus auf Systeme und Prozesse, nicht Schuldzuweisungen.