Signal- und Benachrichtigungssystem

1) Rolle und Ziele

Das Signalsystem ist kein „Versenden von Nachrichten“, sondern eine Kontur der Entscheidungsfindung: Es hebt Abweichungen rechtzeitig hervor, schlägt Aktionen vor und hält ein Gleichgewicht zwischen Aktualität und Stille.

• Reduzieren Sie MTTD/MTTR durch Priorisierung und klare Playbooks.
• Reduzieren Sie alert fatigue (Ermüdung durch Warnungen) durch Geräuschunterdrückung.
• Geben Sie Aktionen direkt aus der Benachrichtigung (ack, snooze, runbook, Auto-Aktion).
• Datenschutz und Einwilligungen beachten (Opt-in/Opt-out, Protokollspeicherung).

2) Taxonomie der Ereignisse und Ebenen

2. 1 Arten von Ereignissen

Metriken/Anomalien (SRE, Produkt, Finanzen).
Geschäftsregeln (Limits, Betrug, KYC, Zahlungen).
Systemisch (deploy, degradation, Lizenzen).
Benutzerdefiniert (Verhaltensauslöser, RG/verantwortungsvolles Spielen).

2. 2 Bedeutungsstufen (Severity)

Kritisch - sofortige Reaktion, Verlustrisiko/Sicherheit.
Hoch - signifikante Verschlechterung der KPI/SLO.
Medium - Aktionen während der Arbeitszeit erforderlich.
Low/Info - Beobachtung/Kontext, Auto-Rollup in Digests.

2. 3 Priorität (Priority)

Impact × Urgency → P1..P4 Bindung an Kanäle und SLA der Reaktion.

3) Architektur und Strömungen

Die Hersteller der Signale → der Reifen der Ereignisse → die Normalisierung (enrich, dedup) → die Korrelation → die Regeln (policy engine) → das Routing → die Kanäle der Zustellung → das Zentrum der Präferenzen → die Hohlwege/Analytik.

• Enricher: fügt Tenant, Rolle, Region, Links zu Playbooks hinzu.
• Deduper: Gruppieren Sie wiederkehrende Ereignisse nach Schlüssel.
• Correlator: Verwandte Signale zu einem Vorfall zusammenkleben.
• Policy Engine: YAML/DSL-Regeln, Quiet Hours, Eskalationen.
• Lieferung: In-App, E-Mail, Push, SMS, Webhook, Chat-Integration.

4) Regeln und Richtlinien (Beispiel YAML)

yaml policies:
- id: p_sre_critical match: { domain: "infra", severity: "critical" }
route:
primary: { channel: "pager", targets: ["oncall_sre"] }
fallback: { channel: "sms", delay: "2m" }
suppress:
flapping: {window: "10m," threshold: 5} # suppressing frequent twitching duplicates: {key: ["service, ""cluster,"" error _ code"], ttl: "15m"}
escalate:
after: "10m"
to: ["sre_manager"]
auto_assign: true
- id: p_product_medium match: { domain: "product", severity: "medium", kpi: "conversion" }
route:
primary: { channel: "inapp", audience: "product_owners" }
digest:
window: "1h"
max_items: 10 quiet_hours:
tz: "Europe/Kyiv"
ranges: ["22: 00-07: 00"] # only P1 digests/pager at this time

5) Deduplizierung, Korrelation, Flapping Unterdrückung

Dedup: Gruppenkennung 'dedup _ key = hash (service' metric 'dim)'; TTL ≥ das Flapping-Fenster.
Korrelation: Kombinieren Sie die zugehörigen Signale nach Topologie (servis→zavisimost), Zeit (± N min) und Kontext (Release, Incident).
Flapping: Schwellenwerte für „N Ereignisse pro M Minuten“ → ein einzelnes „Flapping detected“ -Signal mit dem Vorschlag, die Hysterese oder Suppress zu erhöhen.

6) Routing und RACI

Responsible: Wer die erste Benachrichtigung/Tusk erhält.
Accountable: Wer nach dem SLA eskaliert.
Konsultiert: Wen im Thread/Chat-Kanal zu erwähnen.
Informiert: Wer den Digest/die Ergebnisse verlässt.
Weisen Sie nach Rolle und Kontext zu (Tenant, Region, Produkt-Stream).

7) Lieferwege und Nuancen

Retrays: 5xx/429/timeout → backoff + jitter; 'Retry-After' zu respektieren. Idempotenz: „X-Notification-Id“ auf Webhooks.

8) Preferences Center

Opt-in/Opt-out nach Ereignistypen, Ebenen, Kanälen.
Zeitplan der Stille (quiet hours), manuelle snooze für 15/30/60 min.
Schwelle/Empfindlichkeit (z. B. Anomalie ≥ 3 σ).
Sprache/Ort, Zeit-/Währungsformat.
Rollenbindung: Voreinstellungen für SRE/Product/Finance.
Transparenz: Zeigen Sie, warum der Benutzer das Signal erhalten hat (Link zur Regel).

9) Content Design: Struktur der Botschaft

• Headline: kurz, mit Trigger: „[P1] [PSP _ TR] Starker Anstieg der 3DS-Ausfälle (+ 12%)“.
• Kontext: Zeitraum, betroffene Segmente/Region, Datenquelle.
• Ursache/Hypothese: „Verbunden mit der Veröffentlichung von PSP_X 18:20 UTC“.
• SLA/Deadline: „Eskalation nach 10 min“.
• CTA: "Playbook öffnen", "Fallback aktivieren PSP_Y", "Ack (30 min)".
• Referenzen: Chart, Incident-Thread, Metriken, Runbook.
• Metadaten: 'trace _ id', 'incident _ id', 'dedup _ key'.

Ton: Fakten, keine Dramatisierung; Zahlen und Einheiten; Vermeiden Sie Abkürzungen ohne Entschlüsselung.
Lokalisierung: Variablen → Platzhalter, Übersetzungen werden in Ressourcen gespeichert; Zahlen/Daten - nach Ort.

10) Aktionen aus Benachrichtigungen (Actionable)

Ack/Snooze mit Zeitparametern.
Assign/Invite im Thread des Vorfalls.
Runbook: Öffnen Sie Lösungsschritte mit Auto-Complete-Kontext.
One-Click-Remediation (wo es sicher ist): Route wechseln, Limit anheben, Jobu neu starten (mit Bestätigung und Audit).
Erstellen Sie ein Ticket (Jira/GitHub) mit AutoVervollständigen der Felder.

11) Signalqualität: Metriken und Ziele

Precision (der Anteil der relevanten unter den gesendeten) ≥ 80% für P1/P2.
Recall (der Anteil der entdeckten unter allen Vorfällen) ≥ 70%.
Rauschen: durchschnittliche Signale/Stunde pro Benutzer (Zieldecke).
Ack-time p50/p95, Escalation rate, Snooze rate (als Rauschanzeige).
MTTD/MTTA/MTTR (im Rahmen von Domains und Kanälen).
Silenced-but-should-alert (Auslassungen aufgrund von Regeln) ist ein separates Dashboard.

12) Geräuschmanagement: Techniken

Hysterese und „Schiebefenster“ für Schwellen.
Glättung (EWMA) vor der Detektion.
Aggregation: Statt 30 klein - ein Batch/Digest mit Top-Beitragsleistern.
Kontextgrenzen: max. N Benachrichtigungen/Stunde/Kanal/Benutzer.
Auto-Feedback: Wenn der Benutzer 3 × hintereinander auf Snooze klickt → bietet an, die Schwelle zu erhöhen/den Kanal zu ändern.

13) Sicherheit, Privatsphäre, Compliance

HMAC-Signatur für Webhooks, Rotation der Geheimnisse, 'X-Key-Id'.
RBAC/ABAC: Sichtbarkeit der Signale nach Rolle/Tenant.
PII-Minimierung, Masken in Logs, Action Audit (ack/assign/runbook).
Einwilligungen (consent) und Gründe für die Mitteilung (Regel/Politik) sind in payload.
Retention/TTL Benachrichtigungsprotokolle, Legal Hold für Vorfälle.

14) Schemata und payload's

Ereignis (intern)

json
{
"id": "sig_01HX",
"domain": "payments",
"severity": "high",
"priority": "P2",
"title": "The 3DS failure graph has grown to 8. 2% (+3. 1 pp), "
"occurred_at": "2025-11-03T17:55:00Z",
"context": { "psp": "PSP_X", "country": "TR", "release_id": "rel_241103_1820" },
"metrics": { "baseline": 5. 1, "current": 8. 2, "delta_pp": 3. 1 },
"dedup_key": "payments    PSP_X    TR    3DS_FAILURE",
"runbook": "rbk_psp_3ds_spike",
"slo": { "ack_deadline_sec": 600 }
}

Benachrichtigung (Kanal-Agnostiker)

json
{
"notification_id": "ntf_91ab",
"signal_id": "sig_01HX",
"targets": ["oncall_payments"],
"channels": ["inapp","slack","webhook"],
"cta": [
{"id": "ack," "label": "Confirm (30 min)," "payload": {"ttl ":" 30m"}},
{"id": "runbook," "label": "Open playbook," "payload": {"id ": "rbk _ psp _ 3ds _ spike"}},
{"id": "fallback," "label": "Enable fallback, PSP_Y" "confirm": true}
],
"hmac": "sha256=AbCd..."
}

15) UX-Muster im Produkt

Inboxen: Critical/High/Other Tabs, Mengenabzeichen.
Das Band des Vorfalls: korrelierte Signale, Zeitlinie von Aktionen, „was getan wurde“.
Filter: Rolle, Domäne, Region, Zeit, „nur unbeantwortet“.
Schnelle Aktionen in der Liste (ack/snooze/assign).
Explain: „Warum sehen Sie es“ (Regel, Schwellenwerte, Daten).
Digests: Morgen/Abend, lokalisiert durch TZ.

16) Testplan

Einheit: Dedup-Schlüssel, Hysterese, Flapping, Payload-Serialisierung.
Integration: Routing, Quiet Hours, Eskalationen, Channel Retrays.
E2E: Szenario P1 von der Anomalie bis zum Schließen des Tickets; P2 in quiet hours → digest.
Chaos: Kanalverlust (SMTP/SMS), Verzögerungen, Signallawine, Clock-Skew.
A11y/i18n: screen-readers, keyboard ack/snooze, number/date localization.

17) Qualität Dashboards

Precision/Recall nach Domains.
Ack-Zeit p50/p95 und der Anteil der rechtzeitig Bestätigten.
Noise per user/hour und top laute Regeln.
Escalation Rate und „falsche Eskalationen“.
Suppressed vs Delivered (wie viel ist unterdrückt/in Digest reduziert).
Benutzerfeedback :/Beiträge, Kommentare zum Rauschen.

18) Checklisten

Projektierung

• Ereignistaxonomie und Ebenen sind konsistent
• Richtlinien für Quiet Hours/Eskalationen werden beschrieben
• Dedup/Korrelation/Flapping konfiguriert
• Kanäle, Retrays, Idempotenz von Webhooks
• Preference Center (opt-in/out, snooze)
• Inhaltsvorlagen und Lokalisierung
• Playbooks und One-Click-Aktionen (mit Audit)
• Qualitätsmetriken und Dashboards

Betrieb

• Vierteljährliche Schwellenoptimierung
• A/B-Regeln (Schwelle, Fenster, Digest)
• Regelmäßige Überprüfungen von „Top Noise“ und CAPA
• Rotation von Kanalgeheimnissen (HMAC, SMTP, SMS)
• Alarmprüfung (Spieltage) nach Zeitplan

19) Implementierungsplan (3 Iterationen)

Iteration 1 - Grundkontur (2-3 Wochen)

Taxonomie, severity/priority, Preference Center (in-app + email).
Dedup, einfache Korrelation nach Schlüssel/Zeit, quiet hours.
Nachrichtenvorlagen, Playbooks, ack/snooze/assign.

Iteration 2 - Zuverlässigkeit und Rauschunterdrückung (3-4 Wochen)

Flapping/Hysterese, Digests, Chat-Integrationen und Webhooks (HMAC, Retrays).
Eskalationen durch SLA, Qualitäts-Dashboards (Precision/Recall, Noise).
One-Click-Remediation (mit Bestätigung und Audit).

Iteration 3 - Optimierung und Skalierung (kontinuierlich)

Korrelation nach Topologie/Releases, Auto-Vorschläge von Schwellenwerten.
A/B-Regeln, Prognose „wenn die Schwelle funktioniert“.
Lärmüberprüfungen und regelmäßige Spieletage.

20) Mini-FAQ

Wie gehe ich mit Alert Fatigue um?
Dedup, Korrelation, Hysterese, Digests und Präferenzzentren + regelmäßige Überprüfung von Lärm und A/B-Schwellenwerten.

Brauche ich ML für Anomalien?
Nützlich, aber beginnen Sie mit deterministischen Regeln und erklärbaren Schwellenwerten. ML ist wie ein Add-on, unbedingt mit Explain.

Warum erhalten Nutzer „überflüssige“ Mails?
Überprüfen Sie Regelmatches, Quiet Hours, Warum-geliefert-Audit, Kanal-/Stundenbegrenzungen und Digests.

Summe

Ein starkes Signalsystem ist intelligente Filterung und korrekte Priorisierung + Ein-Klick-Aktionen. Formalisieren Sie Taxonomie und Richtlinien, implementieren Sie Dedup/Korrelation/Hysterese, geben Sie Benutzern die Kontrolle (Präferenzen, Snooze), stellen Sie eine zuverlässige Lieferung und Transparenz sicher, „warum ich es bekommen habe“. Die Signale werden dann zu einem Steuerungsinstrument und nicht zu einer Geräuschquelle.