Alarme sinnvoll gestalten: wenige Meldungen, jede mit einem nächsten Schritt

Ziel

Ein Alarmset, in dem jede Meldung eine Handlung auslöst und niemand lernt, den Pager zu ignorieren.

Voraussetzungen

Das Kapitel «Monitoring Distributed Systems» des Google-SRE-Buchs nennt die vier goldenen Signale Latenz, Verkehr, Fehler und Sättigung, unterscheidet Symptome («was ist kaputt») von Ursachen («warum») und verlangt, dass jede Weckung handlungsleitend ist («Every page should be actionable»). Das SRE-Workbook beschreibt Alarme auf Basis der Verbrauchsrate des Fehlerbudgets («burn rate»). Praktisch braucht es gemessene Dienstindikatoren an der Nutzerkante, ein Alarmsystem mit Wartezeit vor dem Auslösen – bei Prometheus die Klausel for, ergänzt um keep_firing_for gegen Flackern beim Abklingen – und einen dokumentierten Eskalationsweg.

Schritte

1. Für jeden Dienst die Symptome festlegen, die Nutzer spüren: Fehlerquote, Latenzperzentile, Erreichbarkeit, Aktualität der Daten. Nur sie dürfen wecken. Ursachen wie hohe CPU-Last oder eine zu 80 Prozent volle Platte werden Tickets oder Dashboard-Kacheln.
2. Schwellen aus den Zielen ableiten: Das Workbook nennt als Ausgangspunkt für eine Weckung den Verbrauch von 2 Prozent des Fehlerbudgets in einer Stunde oder 5 Prozent in sechs Stunden; eine langsamere Rate (10 Prozent in drei Tagen) erzeugt ein Ticket statt einer Weckung.
3. Jede Regel mit einer Wartezeit versehen (for: 10m), damit ein einzelner Ausreisser nicht auslöst, und eine Regel ergänzen, die anschlägt, wenn das Messsystem selbst keine Daten mehr liefert.
4. Jedem Alarm in den Annotationen einen Runbook-Link, die betroffenen Dashboards und den ersten Prüfschritt mitgeben.
5. Dringlichkeit als Label führen (severity: page gegen ticket) und die Weiterleitung danach steuern; nachts erreicht nur die erste Stufe einen Menschen.
6. Wöchentlich alle ausgelösten Alarme durchgehen: Jeder Alarm, der keine Handlung nach sich zog, wird nachjustiert oder gelöscht; jeder Vorfall ohne vorausgehenden Alarm bekommt einen.

Erwartetes Ergebnis

Wenige Weckungen, jede mit klarem nächsten Schritt; Vorfälle werden vom Monitoring vor den Nutzern bemerkt; der Bereitschaftsdienst vertraut dem Pager.

Grenzen und Prüfbasis

Symptomalarme erkennen schleichende Verschlechterungen spät; einige führende Indikatoren mit niedriger Dringlichkeit (Warteschlangenlänge, Prognose «Platte voll in zwei Tagen») ergänzen sie. Die Grundsätze folgen den zitierten SRE-Kapiteln, die Mechanik der zitierten Prometheus-Dokumentation; ob und ab welcher Alarmrate ein Team abstumpft, ist hier nicht belegt.