3:12 Uhr, PagerDuty: „Festplatte 75 % Staging-Datenbank.“ Der Schlummer-Bereitschaftsdienst. 3:28 Uhr: „Prometheus-dev hoher Speicher“. Schlummern. 4:05 Uhr: „Zahlungsfehlerquote 15 % prod.“ – im Lärm versunken, gelesen um 9 Uhr. Geschätzter Verlust: vier Stunden Umsatz.
Alarmmüdigkeit ist kein Werkzeugproblem. Es ist ein Vertragsproblem: zu viele Signale ohne Schwerkraft, ohne Runbook, ohne Manager – bis der Kanal zu Spam wird und die eigentliche Dringlichkeit unbemerkt bleibt. Prometheus, Datadog oder Grafana verursachen keinen Lärm: Fehlende Governance führt zu einer Anhäufung von Lärm.
Schweregrad, Routing und Seitenregel
| Ebene | Kanal | Beispiel |
|---|---|---|
| P1 kritisch | Telefonpager | Anzahlung, Datenverlust |
| P2 | Slack @oncall | p95 x2 30 min |
| P3 | Ticket | Scheibentrend 7 Tage |
| Infos | Dashboard | Kapazitätsplanung |
Eine Warnung ohne Runbook-Link und ohne Service Manager sollte in der Produktion verboten sein. Wenn die Bereitschaftsperson innerhalb von 60 Sekunden nicht weiß, was sie tun soll, handelt es sich nicht um eine Warnung, sondern um eine Benachrichtigung.
Jede nächtliche Seite muss eine konkrete Aktion verändern – sonst hätte sie nie verschwinden dürfen.
Benutzersymptome vs. Vanity-Metriken
Gut: 5xx Fehlerquote beim Bezahlvorgang; SLO-Brennrate für mehrere Fenster. Schlecht: CPU über sechzig Prozent ohne Korrelation; Das Zertifikat läuft in dreißig Tagen ab (ein Ticket reicht aus).
Prometheus Alertmanager ermöglicht „group_by“ und Hemmung: Wenn das Rechenzentrum ausfällt, verhindert die Hemmung untergeordneter Warnungen eine unnötige Lawine. Aber das Tool ersetzt nicht die Auswahl der Signale – siehe Prometheus Metrics, um zu instrumentieren, worauf es ankommt.
Fenster, Hysterese und Flattern
„for: 10m“ vermeidet einen einzelnen Peak. Schwellenwerte mit Marge: Repag nur, wenn die Situation schlimmer als gestern ist und über dem SLO liegt. Das Flattern signalisiert einen schlechten Schwellenwert oder eine schlechte Metrik – beheben Sie die Ursache, wiederholen Sie nicht die Stille.
Eine Warnung, die alle zehn Minuten zwischen ausgelöst und gelöst schwankt, strapaziert das Team stärker als ein tatsächlicher Ausfall. Messen Sie vierteljährlich die Falsch-Positiv-Rate.
Eigentum und vierteljährliche Überprüfung
Audit: Wurde in den letzten neunzig Tagen ausgelöst? Maßnahmen ergriffen? Falsch-Positiv-Rate? Unterdrücken Sie Lärm rücksichtslos. Die Vorproduktion sollte nicht dieselbe Produktionsrotation auf Seite haben – Bezeichnung „env=staging“ → nur Ticket.
Jede Warnung muss einen benannten Eigentümer haben – nicht das „Infra-Team“. Ohne Eigentum befürwortet niemand die Beseitigung von Rauschen oder die Verbesserung des Runbooks.
Menschlicher Zwang: Schlaf und Rotation
Rotation von mindestens drei Personen, dokumentierte Übergabe, Zeitausgleich. Nach dem Vorfall: Fehlende Warnung? zu laut? anpassen – ohne Vorwürfe. Ein erschöpfter Bereitschaftsdienst übersieht echte Notfälle ebenso wie eine schlecht kalibrierte Alarmierung. Dokumentieren Sie außerdem, wer eine Warnung stummschalten kann und für wie lange – dauerhaftes Schweigen bei der Inszenierung ist gesund; Dauerhaftes Zahlungsverschweigen ist ein unbehandeltes Versäumnis.
Der Gipfel: Überwachung, wer den Wolf schreit
Entscheide dich und gehe ohne blinden Fleck voran
Ordnen Sie zunächst vorhandene Warnungen nach tatsächlichem Schweregrad und Benutzerauswirkung neu. Ersetzen Sie dann die Prozessorschwellenwerte durch Warnungen, die auf Benutzer-SLOs basieren, wenn die Korrelation dies zulässt. Fügen Sie jeder Warnung, die jemanden nachts weckt, ein Runbook hinzu. Planen Sie eine vierteljährliche Überprüfung mit expliziter Geräuschunterdrückung. Isolieren Sie die Vorproduktion von der nächtlichen Produktionsrotation. Vergleichen Sie die Überwachung, die über das Verzeichnis und den Vergleicher verwaltet wird. Streben Sie nach über achtzig Prozent umsetzbaren Seiten pro Nacht.
Häufig gestellte Fragen
Wie viele Pager-Benachrichtigungen in der Produktion?
Wenig – jede Seite erfordert sofortiges Handeln. Der Rest geht an Ticket oder Dashboard. Bei guter Kalibrierung sind weniger als fünf Seiten pro Woche aktiv. darüber hinaus normalisiert das Team den Lärm.
Was ist der Unterschied zwischen Warnung und Kritisch?
Kritische Seite mit Runbook und Manager; Warnung nur während der Geschäftszeiten. Mischen Sie niemals die beiden Nachtkanäle – das zerstört die Glaubwürdigkeit des Bereitschaftsdienstes.
Wie teste ich eine Warnung?
Probeübung, Fehlerinjektion, Trigger- und Runbook-Verifizierung. Eine Warnung, die nie getestet wird, ist wahrscheinlich falsch oder wird ignoriert. Planen Sie einen vierteljährlichen Spieltag.
Infra-Warnungen vs. Benutzer-SLO?
Benutzersymptome zuerst; Prozessor nur bei nachgewiesener Korrelation. Eine hohe CPU ohne Auswirkungen auf den Benutzer sollte niemanden aufwecken.
Eine Warnung, die eine nächtliche Aktion nicht verändert, sollte niemanden wecken.