Système de signaux et de notifications

1) Rôle et objectifs

Le système de signaux n'est pas un « envoi de messages », mais une boucle de décision : il met en évidence les écarts à temps, propose des actions et respecte l'équilibre entre l'actualité et le silence.

• Réduire le MTTD/MTTR grâce à la hiérarchisation et à des playbacks clairs.
• Réduire l'alert fatigue (fatigue des alertes) grâce à la réduction du bruit.
• Donner des actions directement à partir de la notification (ack, snooze, runbook, auto).
• Respecter la vie privée et les consentements (opt-in/opt-out, stockage de logs).

2) Taxonomie des événements et niveaux

2. 1 Types d'événements

Métriques/anomalies (SRE, produit, finance).
Règles commerciales (limites, fred, KYC, paiements).
Système (dégagement, dégradation, licences).
Personnalisé (déclencheurs comportementaux, RG/jeu responsable).

2. 2 Niveaux d'importance (Severity)

Critique - réaction immédiate, risque de perte/sécurité.
High est une détérioration significative du KPI/SLO.
Medium - des actions sont nécessaires pendant les heures de travail.
Low/Info - observation/contexte, auto-convolution dans les condensés.

2. 3 Priorité (Priorité)

Matrice 'Impact × Urgency' → P1..P4. Liaison aux canaux et à la réaction SLA.

3) Architecture et flux

Producteurs de signaux → Bus d'événements → Normalisation (enrich, dédup) → Corrélation → Règles (policy engine) → Routage → Canaux de livraison → Centre de préférences → Logi/Analysis.

• Enricher : ajoute le tenant, le rôle, la région, les liens vers les playbooks.
• Deduper : regroupez les événements récurrents par clé.
• Correlator : coller des signaux apparentés dans un incident.
• Moteur de politique : Règles YAML/DSL, quiet hours, escalade.
• Livraison : in-app, email, push, SMS, webhook, intégration de chat.

4) Règles et politiques (exemple 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) Déduplication, corrélation, suppression de flapping

Dedup : identifiant du groupe 'dedup _ key = hash (service'metric 'bou)' ; TTL ≥ la fenêtre de flapping.
Corrélation : combinez les signaux associés selon la topologie (servis→zavisimost), le temps (± N min) et le contexte (sortie, incident).
Flapping : les seuils « N événements en M minutes » → un signal « flapping detected » proposant de lever l'hystérésis ou la suppresse.

6) Routage et RACI

Responsible : qui reçoit le premier avis/task.
Comptable : qui escalade après l'ALS.
Consulted : qui mentionner dans le canal tred/chat.
Informed : Qui va avoir un résumé/résultats.
Assigner par rôle et par contexte (tenant, région, produit stream).

7) Canaux de livraison et nuances

Retrai : 5xx/429/Temporout → backoff + jitter ; « Retry-After » à respecter. Idempotence : 'X-Notification-Id'sur le Web.

8) Centre de préférences

Opt-in/Opt-out par type d'événement, niveaux, canaux.
Graphique de silence (quiet hours), snooze manuel de 15/30/60 min.
Seuil/sensibilité (par exemple anomalie ≥ 3 σ).
Langue/local, format heure/monnaie.
Ancrage aux rôles : presets pour SRE/Product/Finance.
Transparence : montrer pourquoi l'utilisateur a reçu le signal (référence à la règle).

9) Conception de contenu : structure du message

• Titre : Bref, avec déclencheur : « [P1] [PSP _ TR] Forte augmentation des pannes 3DS (+ 12 %) ».
• Contexte : période, segments/région touchés, source de données.
• Cause/hypothèse : « Lié à la sortie de la PSP_X 18:20 UTC ».
• SLA/debline : « Escalade dans 10 min ».
• CTA : "Ouvrir плейбук", "Insérer fallback PSP_Y", "Ack (30 mines)".
• Liens : graphique, incident, métriques, runbook.
• Métadonnées : 'trace _ id', 'incident _ id', 'dedup _ key'.

Ton : faits, pas de dramatisation ; les nombres et les unités ; éviter les abréviations sans décryptage.
Localisation : variables → playsholders, les traductions sont stockées dans les ressources ; les nombres/dates sont localisés.

10) Actions des notifications (Activable)

Ack/Snooze avec des paramètres temporels.
Assigne/Invite dans l'incident.
Runbook : ouvre les étapes de la solution en remplissant automatiquement le contexte.
Remediation en un clic (où c'est sûr) : changer d'itinéraire, relever la limite, redémarrer le jobu (avec confirmation et audit).
Créer un tiquet (Jira/GitHub) avec remplissage automatique des champs.

11) Qualité du signal : métriques et objectifs

Precision (proportion pertinente parmi les envois) ≥ 80 % pour les P1/P2.
Recall (proportion de tous les incidents détectés) ≥ 70 %.
Noise : signaux moyens/heure par utilisateur (plafond cible).
Ack-time p50/p95, taux d'escalade, taux de snooze (comme indicateur de bruit).
MTTD/MTTA/MTR (en coupe des domaines et des canaux).
Silenced-but-should-alert (passe à cause des règles) est un dashboard distinct.

12) Gestion du bruit : Techniques

Hystérésis et « fenêtres coulissantes » pour les seuils.
Lissage (EWMA) avant la détection.
Agrégation : Au lieu de 30 petites - un batch/condensé avec les meilleurs compensateurs.
Limites contextuelles : pas plus de N notifications/heure/canal/utilisateur.
Auto-feedback : si l'utilisateur appuie sur Snooze 3 × de suite → lui suggérer d'augmenter le seuil/modifier le canal.

13) Sécurité, vie privée, conformité

Signature HMAC pour webhooks, rotation des secrets, "X-Key-Id'.
RBAC/ABAC : visibilité des signaux par rôle/tenants.
Minimisation PII, masques dans les logs, audit des actions (ack/assign/runbook).
Le consentement (consent) et les raisons de la notification (règle/politique) sont dans payload.
Retentation/TTL des logs de notification, Legal Hold par incident.

14) Schémas et payload's

Événement (interne)

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 }
}

Notification (canal-agnostique)

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) modèles UX dans le produit

Inbox : onglets Critical/High/Other, quantités de badges.
Bande d'incident : signaux corrélés, temps d'action, « ce qui a été fait ».
Filtres : rôle, domaine, région, heure, « sans réponse ».
Actions rapides dans la liste (ack/snooze/assign).
Explain : « pourquoi le voyez-vous » (règle, seuils, données).
Résumés : matin/soir, localisés par TZ.

16) Plan d'essai

Unité : clés de déduplication, hystérésis, flapping, sérialisation payload's.
Intégration : routage, quiet hours, escalade, retraits de canaux.
E2E : scénario P1 de l'anomalie à la fermeture du tiquet ; P2 en quiet hours → condensé.
Chaos : perte de canal (SMTP/SMS), retards, avalanche de signaux, clock-skew.
A11y/i18n : screen-readers, clavier ack/snooze, localisation des nombres/dates.

17) Dashboards de qualité

Precision/Recall par domaine.
Temps Ack p50/p95 et proportion confirmée à temps.
Noise per user/hour et les meilleures règles bruyantes.
Taux d'escalade et « fausses escalade ».
Suppressed vs Delivered (combien supprimé/réduit en condensé).
User feedback :/messages, commentaires sur le bruit.

18) Chèques-feuilles

Conception

• La taxonomie des événements et les niveaux sont harmonisés
• Les politiques de quiet hours/escalade sont décrites
• Dédup/corrélation/flapping personnalisés
• Canaux, retraits, idempotence des webhooks
• Centre de préférences (opt-in/out, snooze)
• Modèles de contenu et localisation
• Activités Pleybooks et one-click (avec audit)
• Métriques de qualité et dashboards

Exploitation

• Optimisation seuil une fois par trimestre
• Règles A/B (seuil, fenêtres, digest)
• Revues régulières « top bruit » et CAPA
• Rotation des secrets des canaux (HMAC, SMTP, SMS)
• Test d'alarme (game days) programmé

19) Plan de mise en oeuvre (3 itérations)

Itération 1 - Contour de base (2-3 semaines)

Taxonomie, severity/priority, centre de préférences (in-app + email).
Dedup, corrélation simple par clé/temps, quiet hours.
Modèles de message, playbooks, ack/snooze/assign.

Itération 2 - Fiabilité et réduction du bruit (3-4 semaines)

Flapping/hystérésis, digests, intégrations de chat et webhooks (HMAC, retraits).
Escalade par SLA, dashboards de qualité (precision/recall, noise).
One-click remediation (avec confirmation et audit).

Itération 3 - Optimisation et échelle (en continu)

Corrélation par topologie/release, auto-offre de seuils.
A/B des règles, prédiction « quand le seuil est déclenché ».
Avis de bruit et jours de jeu réguliers.

20) Mini-FAQ

Comment lutter contre alert fatigue ?
Dedup, corrélation, hystérésis, condensés et centres de préférence + examens réguliers du bruit et seuils A/B.

Avez-vous besoin de ML pour les anomalies ?
Utile, mais commencez par des règles déterministes et des seuils explicables. ML est comme un complément, forcément avec Explain.

Pourquoi les utilisateurs reçoivent-ils des e-mails « superflus » ?
Vérifiez les matchs de règles, les heures de quiet, l'audit « pourquoi livré », ajustez les limites de canal/heure et les résumés.

Résultat

Un système de signal fort est un filtrage intelligent et une priorité correcte + actions en un clic. Formalisez la taxonomie et les politiques, mettez en place la déduplication/corrélation/hystérésis, donnez aux utilisateurs le contrôle (préférences, snooze), assurez une livraison fiable et une transparence « pourquoi je l'ai eu ». Les signaux deviendront alors un outil de commande et non une source de bruit.