System alarmowy i powiadamiania

1) Rola i cele

System sygnału nie jest „wysyłaniem wiadomości”, ale obwód decyzyjny: podkreśla odchylenia w czasie, oferuje działania i zachowuje równowagę między aktualnością a milczeniem.

• Zmniejszyć MTTD/MTTR poprzez priorytetyzację i jasne playbooks.
• Zmniejszyć zmęczenie alarmowe poprzez odwołanie hałasu.
• Podaj działania bezpośrednio z powiadomienia (ack, snooze, runbook, auto-action).
• Przestrzegaj prywatności i zgody (opt-in/opt-out, log storage).

2) Taksonomia zdarzeń i poziomów

2. 1 Typy zdarzeń

Wskaźniki/anomalie (SRE, produkt, finanse).
Zasady działalności gospodarczej (limity, oszustwa, KYC, płatności).
System (rozmieszczenie, degradacja, licencje).
Użytkownik (wyzwalacze behawioralne, RG/gra odpowiedzialna).

2. 2 Poziomy nasilenia

Krytyczna - natychmiastowa odpowiedź, ryzyko utraty/bezpieczeństwa.
Wysokie - znaczące pogorszenie KPI/SLO.
Medium - Działanie wymagane w godzinach pracy.
Low/Info - obserwacja/kontekst, automatyczna konwolekcja w trawienie.

2. 3 Priorytet

"Impact × Urgency 'matrix → P1..P4. Link do kanałów i reakcji SLA.

3) Architektura i wątki

Producenci sygnałów → Sheena wydarzeń → Normalizacja (wzbogacony, dedup) → Korelacja → Poprawiony (silnik polityki) → Routing → Dostawy kanałów → Centrum preferencji → Dzienniki/analizy.

• Enricher: dodaje najemcę, rolę, region, linki playbook.
• Deduper-Group powtarzające się zdarzenia według klucza.
• Korelator: Sygnały związane z klejem w incydencie.
• Silnik polityki: Zasady YAML/DSL, ciche godziny, eskalacje.
• Dostawa: in-app, e-mail, push, SMS, webhook, integracja czatu.

4) Zasady i polityki (przykład 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) Deduplicacja, korelacja, tłumienie klapowania

Dedup: ID grupy 'dedup _ key = hash (service' metric 'dim)'; TTL ≥ Okno klapowania.
Korelacja: łączyć powiązane sygnały według topologii (servis → zavisimost), czasu (± N min) i kontekstu (zwolnienie, incydent).
Klapowanie: progi „N zdarzenia na M minut” → jeden sygnał „klapowanie wykryte” z propozycją podniesienia histerezy lub tłumienia.

6) Routing i RACI

Odpowiedzialny: kto otrzymuje pierwsze powiadomienie/przeciągnij.
Odpowiedzialność: kto eskaluje po SLA.
Konsultowane: kto wspomnieć w kanale wątku/czatu.
Poinformowany: kto zostawi trawienie/wyniki.
Przypisanie według roli i kontekstu (najemca, region, strumień produktów).

7) Kanały dostawy i niuanse

Retrai: 5xx/429/timeout → backoff + jitter; Szacunek dla „Retry-After”. Idempotencja: 'X-Notification-Id' na hakach internetowych.

8) Centrum preferencji

Opt-in/Opt-out według typu zdarzenia, poziomu, kanału.
Ciche godziny, ręczny snooze na 15/30/60 min.
Próg/czułość (np. ≥ 3 „anomalia”).
Język/lokalizacja, format czasu/waluty.
Wiążąca rola: ustawienia wstępne dla SRE/Product/Finance.
Przejrzystość: pokaż dlaczego użytkownik otrzymał sygnał (link do reguły).

9) Projekt treści: struktura wiadomości

• Tytuł: Krótki, ze spustem: „[P1] [PSP _ TR] Gwałtowny wzrost awarii 3DS (+ 12%)”.
• Kontekst: okres, dotknięte segmenty/region, źródło danych.
• Powód/hipoteza: „Związane z uwolnieniem PSP_X 18:20 UTC”.
• SLA/termin: „Eskalacja w 10 min”.
• CTA: "Open playbook", "Enable fallback PSP_Y," Ack (30 min) ".
• Linki: wykres, incydent-thread, mierniki, runbook.
• Metadane: 'trace _ id',' incident _ id', 'dedup _ key'.

Ton: fakty, brak dramatyzacji; Numery i jednostki unikają skrótów bez dekodowania.
Lokalizacja: zmienne → znaczniki, tłumaczenia są przechowywane w zasobach; numery/daty - według lokalizacji.

10) Działania wynikające z powiadomień (działające)

Ack/Snooze z parametrami czasu.
Przypisz/Zapraszamy do wątku incydentu.
Runbook-Otwarte kroki rozwiązania z autocomplete kontekstu.
1-kliknięcie remediacji (gdzie bezpieczne): przełączanie trasy, podnoszenie limitu, ponowne uruchamianie zadania (z potwierdzeniem i audytem).
Utwórz bilet (Jira/GitHub) z pól autokompletnych.

11) Jakość sygnału: wskaźniki i cele

Precyzja ≥ 80% dla P1/P2.
Przypomnieć (odsetek wykrytych incydentów wśród wszystkich incydentów) ≥ 70%.
Hałas: średnie sygnały/godzinę na użytkownika (pułap docelowy).
Ack-time p50/p95, szybkość eskalacji, szybkość snooze (jako wskaźnik hałasu).
MTTD/MTTA/MTTR (pod względem domen i kanałów).
Uciszony, ale powinien-alert (luki ze względu na zasady) jest oddzielną deską rozdzielczą.

12) Kontrola hałasu: techniki

Histereza i przesuwne okna dla progów.
Anty-aliasing (EWMA) przed wykryciem.
Agregacja: zamiast 30 małych - jedna partia/strawa z górnymi składnikami.
Limity kontekstowe: maksymalne powiadomienia N/godzina/kanał/użytkownik.
Automatyczne sprzężenie zwrotne: jeśli użytkownik klika Snooze za 3 × z rzędu → sugeruje podniesienie progu/zmianę kanału.

13) Bezpieczeństwo, prywatność, zgodność

Podpis HMAC dla haków internetowych, obrót tajemnic, 'X-Key-Id'.
RBAC/ABAC: widoczność sygnału według roli/najemcy.
Minimalizacja PII, maski w dziennikach, akcje audytu (ack/assign/runbook).
Zgoda i powody powiadomienia (zasada/polityka) - w ładunku.
Dzienniki powiadomień o zatrzymaniu/TTL, Legalne wstrzymanie incydentów.

14) Systemy i ładunki użytkowe

Zdarzenie (wewnętrzne)

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

Powiadomienie (kanał agnostyczny)

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) Wzory UX w produkcie

Skrzynki wejściowe: Krytyczne/Wysokie/Inne zakładki, odznaki ilościowe.
Pasze incydentalne: skorelowane sygnały, harmonogram działań, „co zostało zrobione”.
Filtry: rola, domena, region, czas, „tylko bez odpowiedzi”.
Szybkie działania na liście (ack/snooze/assign).
Wyjaśnij: „dlaczego to widzisz” (reguła, progi, dane).
Trawienie: rano/wieczorem, zlokalizowane przez TZ.

16) Plan badania

Jednostka: klucze dedup, histereza, klapki, serializacja ładunków.
Integracja: routing, ciche godziny, eskalacje, przekaźniki kanałów.
E2E: scenariusz P1 od anomalii do zamknięcia biletu; P2 w cichych godzinach → trawienie.
Chaos: utrata łącza (SMTP/SMS), opóźnienia, lawina sygnału, skew zegara.
A11y/i18n: czytniki ekranu, ack/snooze klawiatury, lokalizacja numerów/dat.

17) Deski rozdzielcze jakości

Precyzja/Wycofanie według domeny.
Czas ack p50/p95 i udział terminowo potwierdzone.
Hałas na użytkownika/godzinę i najwyższy poziom hałasu.
Wskaźnik eskalacji i „fałszywe eskalacje”.
Tłumione vs Dostarczone (ile jest tłumione/strawione).
Opinie użytkowników :/wiadomości, komentarze na temat hałasu.

18) Listy kontrolne

Projekt

• Taksonomia zdarzeń i poziomy są spójne
• Opisano ciche godziny/politykę eskalacji
• Dedup/Correlation/Flapping configured
• Kanały, Retras, Webhook Idempotency
• Centrum preferencji (opt-in/out, snooze)
• Szablony treści i lokalizacja
• Playbooks i działania z jednym kliknięciem (skontrolowane)
• Wskaźniki jakości i deski rozdzielcze

Operacja

• Kwartalnik optymalizacji progów
• Zasady A/B (próg, okna, trawienie)
• Regularne „najwyższy poziom hałasu” i opinie CAPA
• Kanał secret rotation (HMAC, SMTP, SMS)
• Zaplanowany test dni gry

19) Plan realizacji (3 iteracje)

Iteracja 1 - wartość wyjściowa (2-3 tygodnie)

Taksonomia, stopień/priorytet, centrum preferencji (w-app + e-mail).
Dedup, prosty klucz/korelacja czasu, ciche godziny.
Szablony wiadomości, playbooks, ack/snooze/przypisać.

Iteration 2 - niezawodność i redukcja hałasu (3-4 tygodnie)

Klapowanie/histereza, trawienie, integracja czatu i haki internetowe (HMAC, przekładki).
Eskalacja zgodnie z SLA, deski rozdzielcze jakości (precyzja/wycofanie, hałas).
1-kliknij remediację (z potwierdzeniem i audytem).

Iteracja 3 - Optymalizacja i skala (ciągła)

Korelacja przez topologię/wydania, auto-sugestie progów.
Zasady A/B, prognoza „kiedy próg zadziała”.
Opinie hałasu i regularne dni gry.

20) Mini-FAQ

Jak radzić sobie ze zmęczeniem alarmowym?
Dedup, korelacja, histereza, trawienie i centra preferencji + regularne oceny hałasu i progu A/B.

Czy ML jest potrzebny do nieprawidłowości?
Przydatne, ale zacząć od deterministycznych zasad i wyjaśnionych progów. ML jest jak dodatek, zawsze z wyjaśnieniem.

Dlaczego użytkownicy otrzymują „dodatkowe” e-maile?
Sprawdź zasady, ciche godziny, „dlaczego dostarczone” audyty, ustawić limity kanału/godziny i trawienia.

Razem

Silny system sygnału to inteligentne filtrowanie i poprawne ustalanie priorytetów + działania z jednym kliknięciem. Formalizuj taksonomię i politykę, wdrażaj dedup/korelację/histerezę, daj użytkownikom kontrolę (preferencje, snooze), zapewniaj niezawodną dostawę i przejrzystość "dlaczego ją dostałem. "Wtedy sygnały staną się narzędziem sterującym, a nie źródłem szumów.