Von theoretischen SLOs zu praktischen Burn-Rate-Alerts, die den On-Call-Ingenieur nur wecken, wenn die Benutzererfahrung aktiv beeinträchtigt wird.

In dem Bestreben, Alert Fatigue zu eliminieren, erkennen viele Teams, dass schwellenwertbasiertes Alerting grundlegend fehlerhaft ist. Wenn Sie einen Alert auslösen, wenn Fehlerraten 2% erreichen, der Datenverkehr aber so gering ist, dass 2% nur einer einzigen fehlgeschlagenen synthetischen Probe entspricht, haben Sie einen Ingenieur wegen einer statistischen Anomalie alarmiert.
Der Industriestandard als Ersatz für veraltete Schwellenwerte ist das auf Service Level Objectives (SLOs) basierte Alerting. Durch die Definition strenger SLIs, das Aushandeln von Error Budgets und das ausschließliche Alerting auf Burn Rates stellen SREs sicher, dass sie nur alarmiert werden, wenn Benutzer bedeutenden, anhaltenden Schmerz erleiden.
Eine der schwierigsten psychologischen Hürden in der Entwicklung ist die Akzeptanz, dass eine Anwendung keine 100% Verfügbarkeit benötigt. Das Streben nach 100% Zuverlässigkeit blockiert die Geschwindigkeit von Feature-Deployments und löst endlose Alert-Stürme für mikroskopische Probleme aus.
Typischerweise ist ein Ziel zwischen 99,9% (Drei Neunen, ungefähr 43 Minuten Ausfallzeit pro Monat) und 99,99% ideal. Die verbleibenden 0,1% sind Ihr Error Budget. Es ist eine Toleranz für akzeptable Unzuverlässigkeit. Wenn Sie innerhalb Ihres Budgets sind, laufen Deployments weiter und der Pager bleibt stumm. Wenn Sie es zu schnell aufbrauchen, klingelt der Pager, um die Blutung zu stoppen.
Ein Service Level Indicator (SLI) ist eine streng definierte, messbare Metrik, die die Benutzererfahrung repräsentiert. Das Google SRE-Buch definiert eine generische Formel, die fast alle SLI-Berechnungen vereinfacht:
Good Events / Total Events * 100
Wenden wir dies auf eine Web-API an:
Wenn wir 10.000 Anfragen erhalten und 9.900 schnell und erfolgreich sind, beträgt unser SLI 99%.
Stellen Sie sich vor, Sie setzen einen statischen Schwellenwert-Alert: Alarmiere mich, wenn der SLI über ein 5-Minuten-Fenster unter 99% fällt.
Sie werden auf zwei Fehlermodi stoßen:
Wenn die Datenbank hart abstürzt und Ihr SLI auf 0% einbricht, ist das 5-Minuten-Fenster viel zu langsam! Sie mussten 30 Sekunden nach Beginn des Ausfalls alarmiert werden, nicht 5 Minuten tief in der Ausfallzeit.
Wenn ein langsames Speicherleck konsistent 1,5% der Anfragen zum Scheitern bringt, beträgt Ihr SLI 98,5%. Da er nie drastisch abfällt, löst der Alert nie aus. Dennoch erleben Benutzer über 30 Tage konstant Frustration, und Sie zerstören leise Ihr monatliches Error Budget.
Die Lösung für diese Fehlermodi ist Burn Rate Alerting. Anstatt absolute Schwellenwerte zu prüfen, berechnen Sie, mit welcher Geschwindigkeit Ihr monatliches Error Budget aufgebraucht wird.

Eine Burn Rate von 1 bedeutet, dass das Budget in genau 30 Tagen aufgebraucht sein wird.
Eine Burn Rate von 14,4 bedeutet, dass das Budget in genau 2 Tagen vollständig aufgebraucht sein wird.
Wir konfigurieren Multi-Window Burn Rate Alerts, um sowohl schnelle als auch langsame Verbrennung zu erkennen:
Hier ist ein Beispiel-PromQL-Snippet für einen schnellen Verbrennungsalert (Rate 14,4) über ein 1-Stunden-Fenster für ein 99,9%-SLO. Die manuelle Erstellung dieser Abfragen kann komplex sein, daher werden Tools wie Sloth oder Prometheus Operator empfohlen.
sum(rate(http_requests_total{status=~"5.."}[1h]))
/
sum(rate(http_requests_total[1h]))
> (1 - 0.999) * 14.4Dies fragt genau das ab, was Sie interessiert: Verbrauchen wir unsere erlaubte Fehlertoleranz zu schnell, um den Monat zu überstehen?
Die Migration von rohen Schwellenwerten zu SLO Burn Rate Alerting erfordert einen Reifesprung für Monitoring-Kulturen. Es akzeptiert die Realität, dass kleine Ausreißer akzeptabel sind, während eine sofortige Reaktion garantiert wird, die direkt proportional zum tatsächlichen Benutzerschmerz ist.
Um SLIs sicher aufzubauen, müssen Sie die wahren Grenzen Ihrer Infrastruktur messen. Die globalen synthetischen HTTP-Checks und DNS-Anomalie-Sonden von Heimdall generieren perfekte Top-of-Funnel-SLI-Metriken und stellen sicher, dass Sie absolut sicher sein können, dass der Benutzer tatsächlich betroffen ist, wenn Heimdall ein fehlschlagendes Ziel meldet.
Schließen Sie sich Tausenden von Teams an, die sich darauf verlassen, dass Heimdall ihre Websites und APIs rund um die Uhr online hält. Starten Sie noch heute mit unserem kostenlosen Plan.
Kostenlos mit der Überwachung beginnenSenior Systems Reliability Engineer focused on uptime, incident response, and building monitoring systems that surface problems before users notice.