In den meisten IT-Teams entsteht Alerting reaktiv: Ein Dienst fällt aus, das Team leidet – und danach definiert jemand einen Alarm, der genau diesen Ausfall in Zukunft früher sichtbar machen soll. Dieses Muster ist zwar verständlich, aber ineffizient. Es führt zu einer ständig wachsenden Sammlung von Alarmen, deren Herkunft niemand mehr kennt, deren Schwellenwerte niemand mehr begründen kann und die zu einem erheblichen Teil On-Call-Teams in der Nacht aufwecken, ohne dass echte Handlungsbedarf besteht.
Shift-Left Alerting ist der Gegenentwurf: Alarme werden nicht nach dem ersten Produktionsausfall definiert, sondern bereits während der Entwicklung – als bewusste Entscheidung, nicht als Nachbesserung.
Was „Shift Left" im Kontext von Alerting bedeutet
Der Begriff „Shift Left" stammt ursprünglich aus dem Testen: Qualitätssicherung findet möglichst früh im Entwicklungsprozess statt, nicht erst am Ende. Übertragen auf Alerting bedeutet das: Schwellenwerte, Alert-Logik und Ownership werden bereits im Design und in der Entwicklungsphase definiert – nicht erst, wenn das System in Produktion läuft und der erste Ausfall aufgetreten ist.
In der Praxis heißt das:
- Alerts werden zusammen mit neuem Code im Pull Request besprochen und überprüft
- SLOs (Service Level Objectives) sind vor dem ersten Deployment definiert
- Alert-Definitionen liegen im gleichen Repository wie der Code
- Ownership für Alarme ist von Anfang an klar – das Team, das den Code schreibt, besitzt auch die zugehörigen Alarme
Das Problem mit reaktivem Alerting
Reaktives Alerting hat typische Symptome, die viele On-Call-Teams kennen:
- Alert Fatigue: Zu viele Alarme, zu viele False Positives – das Team beginnt, Alarme zu ignorieren oder stumm zu schalten.
- Unklare Ownership: Wer ist für diesen Alarm zuständig? Das lässt sich nach mehreren Teamwechseln und Code-Restrukturierungen oft nicht mehr eindeutig sagen.
- Unbegründete Schwellenwerte: Warum reagiert dieser Alarm bei 80 % CPU? Weil jemand irgendwann 80 % als vernünftig erschien – ohne Referenz zu SLOs oder Nutzerauswirkungen.
- Fragmentierte Alert-Konfiguration: Alarme werden direkt in Monitoring-Tools konfiguriert, nicht versioniert, nicht reviewt, nicht getestet.
Das Ergebnis ist eine Alert-Landschaft, die niemand vollständig versteht – und in der On-Call-Dienste mehr Zeit damit verbringen, Alarme einzuschätzen, als tatsächlich Probleme zu beheben.
SLO-basiertes Alerting als Fundament
Shift-Left Alerting beginnt mit einer klaren Frage: Was bedeutet es, dass dieser Dienst für Nutzerinnen und Nutzer gut läuft? Die Antwort kommt in Form von Service Level Objectives (SLOs): messbare Zielwerte für Verfügbarkeit, Latenz, Fehlerrate oder Durchsatz.
SLO-basiertes Alerting dreht die Logik um. Statt zu fragen „Wann schlagen wir Alarm?", fragt man: „Wann verbrennen wir Error Budget schneller als erlaubt?" Alarme, die direkt an SLO-Burn-Rates geknüpft sind, haben klare semantische Bedeutung: Sie signalisieren nicht, dass eine Metrik einen willkürlichen Schwellenwert überschritten hat – sie signalisieren, dass die nutzerseitige Erfahrung gefährdet ist.
Dieser Ansatz reduziert Alert Fatigue erheblich, weil jeder Alarm, der ausgeht, automatisch mit einem realen Nutzerimpact verknüpft ist.
Alert as Code: Alerts versionieren und reviewen
Ein zentraler Baustein von Shift-Left Alerting ist Alert as Code: Alert-Definitionen werden nicht in der Monitoring-Plattform manuell konfiguriert, sondern als Code im Repository gepflegt, versioniert und im PR-Prozess reviewt.
In Prometheus-basierten Setups sind das AlertManager-Regeln als YAML-Dateien, die im gleichen Repository wie die Service-Konfiguration liegen. In OpenTelemetry-Umgebungen können Alert-Regeln über die Collector-Konfiguration oder nachgeschaltete Backends versioniert werden. Terraform-Module erlauben es, Alert-Konfigurationen für Cloud-Monitoring-Dienste (Grafana Cloud, Datadog, New Relic) deklarativ zu verwalten.
Der Vorteil liegt auf der Hand: Wer Code reviewt, reviewt auch die dazugehörigen Alarme. Wer ein Deployment rückgängig macht, macht auch Alert-Änderungen rückgängig. Wer eine neue Funktion deployed, deployed gleichzeitig die passende Alarmierungslogik.
Ownership von Anfang an
Alerts ohne klare Ownership sind eines der größten Probleme in On-Call-Betrieben. Shift-Left Alerting löst das Problem strukturell: Wer den Code schreibt, definiert die Alerts – und ist damit auch der erste Ansprechpartner, wenn diese Alerts ausschlagen.
Das erzeugt einen wichtigen Anreiz: Wer weiß, dass er für Alarme in der Nacht geweckt wird, achtet beim Schreiben auf sinnvolle Schwellenwerte, gute Alert-Texte und klare Runbook-Verweise. Alarme, die unklar sind, gehen auf Kosten derjenigen, die sie selbst definiert haben – das motiviert zu besserem Alerting.
In der Praxis lässt sich Ownership über CODEOWNERS-Dateien (GitHub/GitLab) oder explizite Alert-Metadaten abbilden. Monitoring-Plattformen wie PagerDuty oder FreshCore erlauben es, Alarme zu Projekten oder Teams zuzuordnen – ein hilfreicher Schritt, um Routing und Eskalationspfade klar zu definieren.
Alerts in der CI/CD-Pipeline testen
Ein oft vergessener Aspekt: Alerts sollten in Staging-Umgebungen getestet werden, bevor sie in Produktion gehen. Das bedeutet nicht, auf Produktionsfehler zu warten, sondern gezielt Testbedingungen zu erzeugen – analog zu Chaos Engineering, aber auf Alert-Ebene.
Konkret: Eine CI/CD-Pipeline kann automatisch prüfen, ob Alert-Regeln syntaktisch korrekt sind (Prometheus bietet dafür `promtool`), ob Schwellenwerte im Testbetrieb sinnvoll reagieren und ob Routing-Konfigurationen die richtigen Personen erreichen. Manche Teams gehen weiter und simulieren systematisch Fehlerszenarien in Staging, um zu überprüfen, ob die definierten Alerts tatsächlich ausschlagen – und ob keine unerwarteten Nebeneffekte entstehen.
Praktische Einstiegspunkte
Shift-Left Alerting muss nicht sofort flächendeckend eingeführt werden. Sinnvolle erste Schritte:
- Bei neuen Services: SLOs vor dem Deployment definieren, Alert-Regeln im Code ablegen
- Bei PR-Reviews: Alert-Konfiguration explizit als Review-Kriterium einführen
- Bestehende Alarme auditieren: Welche haben keine Ownership? Welche haben keine Runbooks? Diese zuerst bereinigen
- Monitoring-Tools nutzen, die Projekte und Teams als Organisationseinheiten unterstützen – das erleichtert klare Ownership-Strukturen
- Alert-Rauschen messen: Wie viele Alarme pro Schicht? Wie viele davon actionable? Die Zahlen zeigen, wo Handlungsbedarf besteht
Gute Alarmierung ist kein Tool-Problem – es ist ein Designproblem. Und Designentscheidungen trifft man am besten, bevor der Code in Produktion läuft.
Fazit: Alerting als Ingenieursdisziplin
Shift-Left Alerting verändert, wie Teams über On-Call-Belastung nachdenken. Wenn Alarme nicht mehr reaktiv nach dem ersten Ausfall definiert werden, sondern von Anfang an mit klaren SLOs, verständlicher Logik und eindeutiger Ownership, dann wird On-Call-Bereitschaft planbar – und weniger erschöpfend.
Das ist kein utopisches Ziel. Viele Teams, die konsequent Alert-as-Code eingeführt haben, berichten von deutlich weniger nächtlichen Weckanrufen und einer besseren Nachvollziehbarkeit von Incidents. Der Schlüssel liegt nicht in besseren Monitoring-Tools, sondern darin, Alerting als Ingenieursaufgabe zu begreifen – eine, die früh im Prozess beginnt, nicht erst nach dem ersten Ausfall.
Bildquelle: Pexels.com
Quellen: Google SRE Book (SLO-basiertes Alerting); Prometheus Alerting Rules Dokumentation (prometheus.io); Rob Ewaschuk: „My Philosophy on Alerting"; PagerDuty Incident Response Guidelines.
