Alarme entwerfen, die niemand ignoriert

Jeder Alarm, der losgeht, ohne dass ein Mensch eingreifen muss, bringt dem Team still und leise bei, den nächsten zu ignorieren. Ein paar Wochen davon, und der Alarm, der wirklich zählt, landet in einem Kanal, den niemand liest, oder wird um 3 Uhr nachts neben den siebzehn anderen weggewischt, die nicht zählten. Teuer ist nicht der Ausfall, den man verpasst — teuer ist der On-Call-Engineer, der völlig zu Recht gelernt hat, dass Alarme nur Hintergrundrauschen sind.

Das Ziel ist also nicht 'mehr Monitoring'. Im Gegenteil: eine Handvoll Alarme, von denen jeder bedeutet, dass jetzt ein Mensch handeln muss, gekoppelt an das Tempo, mit dem ihr euer Fehlerbudget verbraucht — alles andere wird dorthin geleitet, wo es niemanden weckt. Ich leite die Rechnung her, gebe euch kopierfertige Prometheus-Regeln und spreche über den Prozess, der das Ganze ehrlich hält.

Wenn ein Mensch keine intelligente Entscheidung treffen muss, sollte ihn auch nichts wecken. Wendet diese eine Regel kompromisslos an, und der größte Teil des Lärms verschwindet.

Lärm ist selbst ein Zuverlässigkeitsproblem

Behandelt On-Call wie jedes andere System mit einem SLO. Ein vernünftiges Ziel: nicht mehr als ein bis zwei umsetzbare Pages pro Schicht und praktisch null falsche Pages. Sobald ihr das überschreitet, steigt die Zeit bis zur Reaktion, Leute schalten Kanäle stumm, und das Vertrauen in das gesamte Alarmsystem bricht zusammen — weit gefährlicher als irgendein rot gewordenes Dashboard.

Jeder falsche Page kostet etwas, das sich schwer zurückholen lässt: die Annahme, dass ein Page echt ist. Schützt diese Annahme so, wie ihr Produktionsdaten schützen würdet.

Der größte Teil des On-Call-Schmerzes ist ein Lärm- und Routing-Problem: Dutzende ursachenbasierter Alarme schrumpfen auf eine Handvoll Pages, die wirklich einen Menschen brauchen.

Drei Ziele — nur eines weckt jemanden

Bevor ihr auch nur einen Schwellenwert justiert, entscheidet, wohin die Signale gehen. Das meiste Alarm-Chaos ist im Grunde ein Routing-Problem: alles zeigte auf den Pager.

Page — ein Mensch muss innerhalb von Minuten handeln. Reserviert für nutzersichtbaren Schaden, der anhält und das Budget schnell verbrennt.
Ticket — ein Mensch muss handeln, aber es kann bis zu den Geschäftszeiten warten: langsame Budgetlecks, Kapazitätstrends, ein Zertifikat, das nächste Woche abläuft.
Dashboard / Protokoll — nur zur Information. Niemand wird geweckt; es speist die On-Call-Ansicht und das wöchentliche Review.

Euer Ein-Sekunden-Fehlerspike, der sich von selbst erholt hat, gehört in den dritten Eimer: sichtbar auf einem Dashboard, gegen das Budget verbucht, später durchgesehen. Er ist echt, er hat etwas gekostet — und er rechtfertigt ganz sicher keinen Anruf.

Entscheidet, wohin jedes Signal geht, bevor ihr an einem Schwellenwert dreht. Nur der Page weckt jemanden; der Ein-Sekunden-Spike, der sich erholt hat, gehört auf ein Dashboard.

Alarmiert auf Symptome, nicht auf Ursachen

Ursachenbasierte Alarme — 'CPU > 80 %', 'Platte zu 90 % voll', 'Pod neu gestartet' — gehen ständig los und decken sich selten mit einem leidenden Nutzer. Moderne Systeme laufen heiß und starten Dinge absichtlich neu; das ist gesund, kein Vorfall. Symptombasierte Alarme melden, was der Nutzer tatsächlich spürt:

Schlagen Requests fehl? (Fehlerrate)
Sind sie so langsam, dass der Nutzer es merkt? (Latenz-SLI)
Kommt die Arbeit durch? (Durchsatz, Queue-Alter, Datenaktualität)

Alarmiert auf das Symptom, und ihr könnt die meisten Ursachen-Alarme löschen: Ihr erfahrt, dass die Platte volllief, weil Requests anfingen fehlzuschlagen — und zwar mit einem Page statt mit neun. Ursachen gehören auf Dashboards und in Runbooks, wo sie beim Diagnostizieren helfen, nicht an den Pager, wo sie nur um eure Aufmerksamkeit konkurrieren.

Alarmiert auf das, was der Nutzer spürt; lasst die Ursachen auf Dashboards und in Runbooks, wo sie beim Diagnostizieren helfen, statt um Aufmerksamkeit zu konkurrieren.

Warum ein einzelner Schwellenwert nie gewinnen kann

Der naive SLO-Alarm lautet 'weck mich, wenn wir Budget verbrennen'. Wählt ein einziges Fenster, und ihr steckt in einem schlechten Kompromiss. Kurz, wird er nervös: ein 30-Sekunden-Schluckauf weckt jemanden wegen eines Problems, das sich längst selbst behoben hat. Lang, wird er träge: ihr könnt 20 Minuten im vollen Ausfall stecken, bevor überhaupt etwas auslöst.

Genau das ist das Ein-Sekunden-Spike-Problem. Ein kurzer Spike verbraucht einen Krümel Budget (stimmt, und gehört protokolliert), darf aber niemals pagen — und ein einzelner Schwellenwert kann 'kurz und erholt' nicht von 'anhaltend und schlimmer werdend' unterscheiden. Ihr braucht zwei Zeitskalen gleichzeitig.

Burn Rate, von Grund auf

Fangt beim Budget an. Ein Verfügbarkeits-SLO von 99,9 % über 30 Tage erlaubt, dass 0,1 % der Requests fehlschlagen — das ist euer Fehlerbudget, rund 43 Minuten Vollausfall-Äquivalent im Monat. Gebt es langsam aus, und alles ist gut; gebt es an einem Nachmittag aus, und ihr habt einen Vorfall.

Burn Rate ist, wie schnell ihr ausgebt — relativ zu 'genau im Budget'. Eine Burn Rate von 1 gibt über das SLO-Fenster exakt 100 % des Budgets aus — nachhaltig. Eine Burn Rate von 14,4 gibt 14,4× zu schnell aus: in diesem Tempo verbrennt ihr das gesamte 30-Tage-Budget in etwa zwei Tagen, und 2 % davon sind in der letzten Stunde schon weg.

burn_rate = (fehler / gesamt) / (1 - SLO)

# SLO von 99.9%  ->  1 - SLO = 0.001
# wenn gerade 1.44% der Requests fehlschlagen:
#   burn_rate = 0.0144 / 0.001 = 14.4
#
# Budget pro Fenster = burn_rate * (Fenster / SLO_Zeitraum)
#   14.4 * (1h  / 720h) =  2%   des 30-Tage-Budgets, in einer Stunde
#    6   * (6h  / 720h) =  5%   in sechs Stunden
#    1   * (72h / 720h) = 10%   in drei Tagen

Diese drei Zeilen sind nicht willkürlich — sie sind die Alarmstufen. Entscheidet, wie viel Budget ihr verlieren wollt, bevor ein Mensch einbezogen wird, und Burn Rate und Fenster fallen direkt aus der Rechnung.

Jede Burn-Rate-Stufe ist nur eine Steigung. 14.4× leert ein 30-Tage-Budget in etwa zwei Tagen, 6× in fünf, 1× landet genau am Tag 30 — und genau daher kommen die Alarmschwellen.

Multi-Window, Multi-Burn-Rate

Die Lösung für die Falle des einzelnen Schwellenwerts ist, ein langes und ein kurzes Fenster gemeinsam zu beobachten, mit mehr als einer Burn Rate. Das lange Fenster bestätigt, dass das Problem echt und anhaltend ist; das kurze — etwa ein Zwölftel des langen — macht den Alarm schnell beim Auslösen und vor allem schnell beim Abschalten, sobald ihr euch erholt habt. Der Alarm löst nur aus, wenn beide Fenster die Schwelle überschreiten.

Ein Ein-Sekunden-Spike löst das kurze Fenster aus, aber nie das lange — also pagt er nie. Ein anhaltendes Verbrennen löst beide aus und pagt. Das kurze Fenster lässt den Alarm außerdem Minuten nach der Erholung abklingen, und genau das beendet das Flapping.

Die Schwere kommt aus der Burn Rate, nicht aus dem Stapeln gleich großer Fenster. Schnelles, steiles Verbrennen = jetzt jemanden wecken. Langsames, sanftes Verbrennen = ein Ticket für morgen:

STUFE       BURN    FENSTER-L  FENSTER-K   BUDGET WEG        ZIEL
-----------------------------------------------------------------
kritisch    14.4x   1h         5m          2%  in 1 Stunde   page
hoch         6x     6h         30m         5%  in 6 Stunden  page
warnung      1x     3d         6h          10% in 3 Tagen    ticket

Lest es so, wie ihr es laut sagen würdet: ein steiles Verbrennen auf kurzem Horizont ist ein kritischer Page; ein sanftes, das erst nach Tagen sichtbar wird, ist ein Warn-Ticket für das langsame Leck, das die schnelle Stufe durchließe. Lasst alle drei gleichzeitig laufen — sie stören sich nicht, sie decken unterschiedliche Fehlerformen ab.

Das kurze Fenster ist der Teil, der den Lärm tötet. Weil der Alarm auch das kurze Fenster heiß braucht, hört er Minuten nach der Erholung auf zu pagen, statt sich über die volle Länge des langen Fensters zu ziehen. Genau das beendet das Flapping — und den 3-Uhr-Page für etwas, das sich vor 90 Sekunden behoben hat.

Die Queries

Berechne das SLI einmal

Definiere das Symptom einmal als Fehlerquote. In Prometheus berechnest du sie pro Fenster mit Recording Rules vor — günstig, lesbar und von jedem Dashboard wiederverwendet. In Datadog definierst du das SLI einmal in einem metrikbasierten SLO, und es berechnet die Fenster für dich.

groups:
- name: payments-slo
  rules:
  # Symptom-SLI: Anteil schlechter Anfragen (5xx oder zu langsam)
  - record: job:sli_err:ratio5m
    expr: |
      sum(rate(http_requests_total{job="payments",code=~"5.."}[5m]))
      / sum(rate(http_requests_total{job="payments"}[5m]))
  - record: job:sli_err:ratio1h
    expr: |
      sum(rate(http_requests_total{job="payments",code=~"5.."}[1h]))
      / sum(rate(http_requests_total{job="payments"}[1h]))
  # ...wiederhole fuer die Fenster 30m, 6h und 3d, auf die du alarmierst

# Datadog berechnet die Fenster fuer dich: definiere das SLI einmal als
# metrikbasiertes SLO (gute Ereignisse / Gesamt). Die rohe Fehlerquote:
100 * (
  sum:trace.http.request.errors{service:payments}.as_count()
  / sum:trace.http.request.hits{service:payments}.as_count()
)

Alert Rules — Multi-Window, Multi-Burn-Rate

Das SLO ist 99,9%, also ist der Budget-Nenner 0,001. Jede Stufe verlangt, dass sowohl ihr langes als auch ihr kurzes Fenster die Burn-Rate überschreiten, bevor sie feuert — in Prometheus explizit ausgeschrieben und ein eingebauter Parameter von Datadogs Burn-Rate-Monitor.

- alert: PaymentsBudgetFastBurn
  expr: |
    job:sli_err:ratio1h / 0.001 > 14.4
    and
    job:sli_err:ratio5m / 0.001 > 14.4
  labels: { severity: page }
  annotations:
    summary: "Payments verbrennt Budget mit 14,4x (2%/h)"
    runbook: "https://runbooks/payments/error-budget"

- alert: PaymentsBudgetSlowBurn
  expr: |
    job:sli_err:ratio3d / 0.001 > 1
    and
    job:sli_err:ratio6h / 0.001 > 1
  labels: { severity: ticket }
  annotations:
    summary: "Payments: langsames Budget-Leck (10%/3d)"
    runbook: "https://runbooks/payments/error-budget"

# Datadog macht Multi-Window nativ — ein Burn-Rate-Monitor auf dem SLO,
# mit langem und kurzem Fenster als Parameter:

# schnelles Brennen -> page  (2% des 30-Tage-Budgets in 1h)
burn_rate("payments-availability").over("30d").long_window("1h").short_window("5m") > 14.4

# langsames Brennen -> ticket  (10% in 3 Tagen)
burn_rate("payments-availability").over("30d").long_window("3d").short_window("6h") > 1

Füge die mittlere Stufe 6× / 6h / 30m hinzu, und du hast schnelle Ausfälle, mittlere Degradierungen und langsame Lecks mit drei Alerts pro Service abgedeckt — nicht dreißig.

Jeder Page muss sich seinen Platz verdienen

Die Rechnung liefert ein sauberes Signal; der Prozess hält es sauber. Unterzieht jeden Page vier Tests:

Umsetzbar — kann On-Call gerade nichts tun, ist es ein Ticket oder es wird gelöscht.
Mit Runbook — der Page verlinkt auf 'was kaputt ist und wo man anfängt', nicht auf eine Wiki-Suche um 3 Uhr nachts.
Mit Owner — er geht an genau ein Team, und dieses Team kann ihn ändern.
Mit Neuigkeit — er sagt etwas, das der vorige Page nicht sagte; fasst Duplikate zusammen.

Macht dann zwei Gewohnheiten billig und regelmäßig. Ein wöchentliches Fehlerbudget-Review: Wie viel haben wir ausgegeben, wofür, liegen wir im Plan. Und ein Alarm-Review: Geht jeden Page durch, der ausgelöst hat, und behaltet, repariert oder löscht ihn. Alarme zu löschen ist die am meisten unterschätzte Zuverlässigkeitsarbeit überhaupt.

Anti-Muster, die diese Woche weg können

Feste Schwellen auf zackigen Metriken ('CPU > 80 %') — sie lösen schon bei gesunder Last aus.
Platten- oder Speicher-Pages pro Host — alarmiert auf das nutzersichtbare Symptom; den Rest plant ihr als Tickets.
'Informative' Pages — ein Widerspruch in sich; schickt sie auf ein Dashboard.
Auf eine Ursache alarmieren, deren Symptom ihr schon alarmiert — ihr bekommt zwei Pages für einen Vorfall.
Jeder Alarm ohne Runbook und ohne Owner — niemand kann handeln, also ist es reiner Lärm.

Wie ihr dorthin kommt, ohne blind zu fliegen

Definiert einen SLI und ein SLO je Nutzerpfad (Checkout, Login, Payments) — Symptome, keine Hosts.
Fügt die Recording Rules für die Fenster hinzu, auf denen ihr alarmiert.
Rollt die drei Burn-Rate-Stufen zuerst nur im Ticket-Modus aus — noch keine Pages.
Beobachtet zwei bis drei Wochen; vergleicht, was gepagt hätte, mit dem, was wirklich ein Vorfall war.
Hebt die schnelle Stufe auf Page; haltet die langsame als Tickets.
Löscht die Ursachen-Pages, die dadurch überflüssig werden — einen nach dem anderen, mit Blick aufs Budget.
Richtet das wöchentliche Budget-Review und das Alarm-Review ein und stutzt weiter.

Es ging nie um 'weniger Alarme' als Eitelkeitsmetrik. Es geht darum, dass es echt ist, wenn das Telefon klingelt, umsetzbar, mit einem wartenden Runbook — damit die Leute vertrauen, abnehmen, und das System zuverlässig bleibt, weil die Menschen, die es verteidigen, nicht erschöpft sind.