Alarmmüdigkeit: weniger, dafür bessere Mitteilungen

Alarmmüdigkeit kommt nicht von zu vielen Problemen, sondern von zu vielen Mitteilungen pro Problem. Redis läuft sieben Minuten lang in Timeouts, die Billing-API versucht es alle zehn Sekunden erneut, und dein Handy vibriert 43-mal. Beim dritten Mal weißt du Bescheid. Beim zwanzigsten schaltest du die Mitteilungen ab, und das nächste echte Problem trifft auf ein stummes Handy.

Dagegen helfen ein paar Gewohnheiten, und zwar mit jedem Tool. Jeder Abschnitt stellt eine vor und zeigt, wie sie in Honk aussieht.

1. Ein Alarm pro Problem, nicht pro Versuch

Hinter einer Retry-Schleife stecken nicht 43 Probleme, sondern eines, das 43-mal auftritt. Leg fest, was „dasselbe Problem“ heißt, gib ihm einen festen Namen und schick diesen Namen bei jedem Ereignis mit.

In Honk ist dieser Name der group_key. Ereignisse, die in Projekt, Umgebung, Quelle, Kanal und group_key übereinstimmen, bilden eine Gruppe. Gepusht wird nur das erste Ereignis einer neuen Episode.

# Before: one push per failed attempt, 43 in seven minutes
curl … -d '{"title":"Redis timeout","message":"attempt 17 failed"}'

# After: one group, one episode, one push, then calm updates
honk-me problem --group-key billing/redis --source billing-api \
  --title "Redis connection failed" --message "Billing API could not connect to Redis (timeout after 5 s)"
# …and when it works again:
honk-me recovery --group-key billing/redis --source billing-api \
  --title "Redis is back" --message "Connected after 7 minutes"

2. Ruhig bleiben, bis es schlimmer wird

Solange das Problem anhält, willst du wissen, dass es noch da ist. Nur eben nicht 43-mal. Honk schickt höchstens ein Update pro Wartezeit (standardmäßig 5 Minuten), mit dem aktuellen Zählerstand. Steigt die Stufe, etwa von Lautem Hupen auf Dauerhupen, wird das Update sofort gepusht. Wenn es schlimmer wird, ist das eine Nachricht wert.

3. Mit einer Entwarnung abschließen

Ein Alarm ohne Ende lässt dich im Ungewissen. Sobald es wieder funktioniert, melde eine recovery für denselben group_key. Honk pusht sie, schließt die Episode, und der Vorfall braucht dich nicht mehr. Gib Entwarnung aber nur nach einem Fehler: Eine Entwarnung nach jeder erfolgreichen Prüfung ist nur neuer Lärm.

Gibt niemand Entwarnung, wird die Episode nach einer ruhigen Phase inaktiv (standardmäßig nach 24 Stunden). Inaktiv heißt nicht behoben: Das nächste Ereignis eröffnet eine neue Episode und wird wieder gepusht.

4. Routine gehört in die Zusammenfassung

Nicht jedes Ereignis verdient einen Push. Ein abgeschlossener Import, ein erfolgreiches Backup oder ein Tagesbericht ist einen Blick wert, aber keine Unterbrechung. Schick solche Ereignisse als Leichtes Hupen oder Tüt-tüt mit normaler oder niedriger Priorität und stell deine Push-Schwelle auf Hoch. Alles darunter sammelt Honk in einer Zusammenfassung, standardmäßig alle 15 Minuten. Eine leere Zusammenfassung wird nie verschickt.

Dasselbe geht ohne Codeänderung mit einer Projektregel, zum Beispiel: Jedes Ereignis der Kategorie deployments mit dem Schweregrad success geht in die Zusammenfassung.

5. Nachts nur, was nicht warten kann

Ruhezeiten halten Pushes zurück und schicken an ihrem Ende eine einzige Zusammenfassung. Leg vorher fest, was trotzdem durchkommen darf. In Honk sind das nur Ereignisse mit der Priorität urgent, und auch die nur, wenn der Ingest-Schlüssel sie senden darf und deine Ruhezeiten dringende Ereignisse durchlassen. Gib diese Erlaubnis einem einzigen Schlüssel: dem des einen Dienstes, der dich wecken darf.

6. Die Stufe ehrlich wählen

Die Honk-Skala hat fünf Stufen. Sie helfen nur, wenn sie etwas bedeuten. Nimm Dauerhupen für „etwas ist ausgefallen“ und Langes Hupen für „etwas ist fehlgeschlagen“. Wenn alles Dauerhupen ist, ist nichts mehr dringend.

Checkliste für Gruppenschlüssel

• Ein Schlüssel pro Sache, die du in einem Zug beheben würdest. billing/redis, nicht billing/redis/attempt-17.
• Keine Zeitstempel, Request-IDs oder Zufallswerte im Schlüssel, es sei denn, jedes Ereignis steht wirklich für sich, etwa eine Kundenanfrage (requests/4812).
• Nimm den Ort in den Schlüssel auf, wenn derselbe Fehler auf zwei Maschinen zwei getrennte Baustellen bedeutet: disk/app-01/var.
• Nimm für das Problem und seine Entwarnung denselben Schlüssel. Nur so weiß Honk, was wieder läuft.
• Halte ihn kurz und lesbar. Er steht im Posteingang, und Regeln können ihn abfragen.

Wie Honk das umsetzt

Honk ist rund um diese Gewohnheiten gebaut. Gruppen und Episoden entstehen nach festen Regeln auf dem Server. Wartezeiten und Zusammenfassungen gelten pro Projekt, Ruhezeiten und Stummschaltungen pro Person. Die KI auf dem iPhone kann eine Gruppe zusammenfassen, aber nie eine Mitteilung verstecken oder verzögern. Alle Regeln findest du unter So funktioniert Honk.