Verhindern Sie ein Überangebot an Alerts

1) Problem und Zweck

Alert fatigue tritt auf, wenn das System zu viele irrelevante oder nicht aktivierbare Benachrichtigungen sendet. Das Ergebnis ist das Ignorieren von Pages, das Wachstum von MTTA/MTTR und das Überspringen echter Vorfälle.
Das Ziel: Signale durch Bindung an SLOs und Playbooks rar, aussagekräftig und durchsetzbar zu machen.

2) Taxonomie der Signale (Kanal = Konsequenzen)

Page (P0/P1) - weckt eine Person; nur wenn eine manuelle Aktion jetzt erforderlich ist und es ein Runbook gibt.
Ticket (P2) - asynchrone Arbeit in Stunden/Tag; wird nicht geweckt, sondern per SLA verfolgt.
Dash-only (P3) - Beobachtung/Trend ohne aktive Aktionen; erzeugt keinen Lärm.
Silent Sentry - Metriken/Audit im Hintergrund (für RCA/Post Mortems).

3) Gestaltung der „richtigen“ Alert

• Ziel/Hypothese (was wir schützen: SLO, Sicherheit, Geld, Compliance).
• Auslösebedingungen (Schwelle, Fenster, Quorum der Quellen).
• Runbook/Playbook (kurze Schritt-ID + Link).
• Eigentümer (Team/Rollenspiel-Gruppe).
• Abschlusskriterien (wenn geschlossen, Auto-Resolve).
• Klasse der Schwachstelle (user-impact/platform/security/cost).

4) SLO-orientierte Überwachung

SLI/SLO → die primären Signale: Verfügbarkeit, Latenz, Erfolg von Geschäftsvorgängen.

• Kurz: 5% des Budgets für 1 Stunde → Page.
• Lange: 2% des Budgets für 6 Stunden → Ticket.
• Kohorte: Alerts nach Region/Anbieter/VIP-Segment - weniger falsche globale Alarme.

5) Lärmminderungstechniken

1. Quorum der Sonden: Auslösen nur, wenn ≥2 unabhängige Quellen (verschiedene Regionen/Anbieter) das Problem bestätigen.
2. Deduplizierung: Gruppierung identischer Ereignisse (Aggregationsschlüssel: service + region + code).
3. Hysterese/Dauer: „in der roten Zone ≥ N Minuten“, um die Spikes herauszufiltern.
4. Rate-Limit: nicht mehr als X Warnungen/Stunde/Service; bei Überschreitung - eine Seite + Zusammenfassung.
5. Auto-Snooze/intelligente Unterdrückung: Wiederholtes Alert im T-Fenster → Übersetzung in Ticket, bis die Wurzel beseitigt ist.
6. Ereigniskorrelation: Ein „Master Alert“ anstelle von Dutzenden von Symptomen (z.B. „DB nicht verfügbar“ jagt 5xx von Microservices).
7. Fenster Wartung: Geplante Arbeiten unterdrücken automatisch die erwarteten Signale.
8. Anomaly + guardrails: Anomalien - nur als Ticket, wenn keine Bestätigung durch ein SLO-Signal erfolgt.

6) Routing und Prioritäten

Prioritäten: P0 (Seite, 15 min Aktualisierung), P1 (Seite, 30 min), P2 (Ticket, 4-8 h), P3 (Beobachtung).
Routing nach den Abkürzungen: service/env/region/tenant → entsprechend on-call.
Eskalationen nach Zeit: kein ack in 5 Minuten → P2 → Duty Manager/IC.
Quiet Hours: Nachtstunden für Unkritische; Die Seite ist für P2/P3 verboten.
Fatigue-Richtlinie: Wenn der Ingenieur> N Pages/Shift - umverteilen auf P2, eskalieren Signalverschmutzung.

7) Qualität der Alert: Vereinbarungen

Actionability ≥ 80%: Die überwiegende Mehrheit der Pages führt zu einer Runbook-Aktion.
False Positive ≤ 5% für Page-Signale.
Time-to-Fix-Alert ≤ 7 Tage - defekte Alert muss repariert/entfernt werden.
Ownership 100% - Jedes Alert hat einen Besitzer und ein Repository mit seiner Definition.

8) Alert-Lebenszyklus (Alert as Code)

1. PR erstellen (Zielbeschreibung, Bedingungen, Runbook, Besitzer, Testplan).
2. Sandbox/Shadow: Shadow-Alert schreibt in Chat/Log, aber nicht Paging.
3. Canary: begrenztes On-Call-Publikum, wir messen FP/TP.
4. Prod: Aufnahme mit Rate-Limit + Beobachtung 2-4 Wochen.
5. Wochenrückblick: Qualitätskennzahlen, Bearbeitungen/Entnahmen.
6. Deprecate: Wenn das Signal eine höhere oder nicht aktivierbare dupliziert.

9) Reifegradmetriken (auf Dashboards anzeigen)

Warnungen pro Rufstunde (Median/95-Perzentil).
% actionable (es werden Schritte ausgeführt) und false-positive rate.
MTTA/MTTR um Pages und page→ticket (sollte nicht hoch sein).
Top-Talker (Dienste/Regeln, die ≥20% des Lärms erzeugen).
Mean time to fix alert (vom ersten FP bis zur Regeländerung).
Burn-Rate-Abdeckung: Anteil der Dienste mit SLO-Alerts in zwei Fenstern.

10) Checkliste „Alert Hygiene“

• Alert ist an SLO/SLI oder Business/Security gebunden.
• Es gibt ein Runbook und einen Besitzer; Kontakt und War-Room-Kanal angegeben.
• Zwei Fenster (kurz/lang) und Quorum der Quellen sind konfiguriert.
• Dedoop, Rate-Limit, Auto-Resolve und Auto-Snooze sind enthalten.
• Angegeben sind die Fenster maintenance und suppression bei Releases/Migrationen.
• Bestanden von Shadow/Canary; FP/TP gemessen.
• Ein Bericht über Alert-Qualitätsmetriken ist enthalten.

11) Mini-Vorlagen

Alert-Spezifikation (YAML-Idee)

yaml id: payments-slo-burn severity: P1 owner: team-payments@sre purpose: "Защитить SLO успеха платежей"
signal:
type: burn_rate sli: payment_success_ratio windows:
short: {duration: 1h, threshold: 5%}
long: {duration: 6h, threshold: 2%}
confirmations:
quorum:
- synthetic_probe: eu,us
- rum: conversion_funnel routing:
page: oncall-payments escalate_after: 5m controls:
dedup_key: "service=payments,region={{region}}"
rate_limit: "1/10m"
auto_snooze_after: "3 pages/1h"
runbook: "rb://payments/slo-burn"
maintenance:
suppress_when: [ "release:payments", "db_migration" ]

Update-Text nach Standard (zur Geräuschreduzierung)

Импакт: падение success_ratio платежей в EU (-3.2% к SLO, 20 мин).
Диагностика: подтвержден кворумом (EU+US синтетика), RUM — рост отказов на 2 шаге.
Действия: переключили 30% трафика на PSP-B, включили degrade-UX, след. апдейт 20:30.

12) Prozesse: wöchentliche „Alert Review“

1. Top-laute Regeln (Top-Talker) → bearbeiten/löschen.

2. FP/TP durch Page-Signale → Anpassen der Schwellenwerte/Fenster/Quorum.

3. Kandidaten für die Absenkung des Kanals (Page→Ticket) und umgekehrt.

4. Status „Time-to-Fix-Alert“ - Verspätungen werden für Servicebesitzer eskaliert.

5. Überprüfung der Abdeckung durch SLO-Alerts und das Vorhandensein von Runbooks.

13) Verknüpfung mit Releases und Operations

Release-Anmerkungen fügen automatisch temporäre Unterdrückungen hinzu.
Windows ändern: In den ersten 30 Minuten nach der Veröffentlichung gibt es nur SLO-Signale.
Playbooks enthalten den Schritt „Senken/Unterdrücken unschlüssiger Alerts“, um sich auf die Wurzel zu konzentrieren.

14) Sicherheit und Compliance

Sicherheitssignale (Hacking/Leck/abnormale Zugriffe) - separate Kanäle, keine Quiet Hours.
Audit-Log aller Unterdrückungen/leisen Fenster: Wer, wann, warum, Deadline.
Unveränderlichkeitsanforderung für kritische Warnungen (Ereignissignatur).

15) Anti-Muster

„Jede Grafik = alert“ → eine Lawine.
Schwelle „! = 0 Fehler“ im Produkt.
Eine Sonde/eine Region als Quelle der Wahrheit.
Seite ohne Runbook/Besitzer.
Ewige „vorübergehende Unterdrückung“ ohne Frist.
„Wir reparieren später“ defekte Alerts - häufen sich seit Jahren.
Vermischung von Release Noise mit Produktereignissen.

16) Umsetzungsfahrplan (4-6 Wochen)

1. Inventar: Entladen Sie alle Alerts, legen Sie Eigentümer und Kanäle.
2. SLO-Kern: Einführung von Burn-Rate-Regeln mit Doppelfenstern für kritische Dienste.
3. Noise Control: Aktivieren Sie Quorum, Dedup und Rate-Limit, führen Sie eine wöchentliche Überprüfung durch.
4. Runbook-Abdeckung: Schließen Sie 100% der Page-Signale mit Playbooks.
5. Fatig-Politik: Paging-Limits/Schicht, Quiet Hours, Lastumverteilung.
6. Automatisierung: Alert-as-Code, Shadow/Canary, Berichterstattung über Qualitätsmetriken.

17) Das Ergebnis

Stille ist kein Mangel an Überwachung, sondern qualitativ gestaltete Signale, die mit SLOs und Prozessen verbunden sind. Quorum, Doppelfenster, Dedup und striktes Routing machen Alerts selten, präzise und durchsetzbar. Das Team ruht, die Nutzer sind zufrieden, die Vorfälle unter Kontrolle.