Zapobieganie nadmiernej ilości wpisów

1) Problem i cel

Alert zmęczenie występuje, gdy system wysyła zbyt wiele nieistotnych lub niedziałających powiadomień. Najważniejsze jest ignorowanie stron, rosnące MTTA/MTTR i pomijanie prawdziwych incydentów.
Cel: aby sygnały rzadkie, znaczące i wykonywalne, łącząc je ze SLO i playbooks.

2) Taksonomia sygnału (kanał = konsekwencje)

Strona (P0/P1) - budzi osobę; tylko wtedy, gdy wymagana jest ręczna akcja teraz i tam jest runbook.
Bilet (P2) - asynchroniczna praca w godzinach/dzień; nie budzi się, ale jest śledzony przez SLA.
Tylko kreska (P3) - obserwacja/trend bez aktywnych działań; nie tworzy hałasu.
Silent Sentry - mierniki/audyt w tle (dla RCA/pośmiertnych).

3) Zaprojektowanie „poprawnego” wpisu

• Cel/hipoteza (co chronimy: SLO, bezpieczeństwo, pieniądze, zgodność).
• Warunki spustowe (próg, okno, kworum źródłowe).
• Runbook/Playbook (krótki krok ID + link).
• Właściciel (zespół/grupa ról).
• Kryteria zakończenia (kiedy zamknąć, automatyczna rozdzielczość).
• Klasa podatności (wpływ użytkownika/platforma/bezpieczeństwo/koszt).

4) Monitorowanie ukierunkowane na SLO

SLI/SLO → sygnały podstawowe: dostępność, opóźnienie, sukces operacji biznesowych.

• Krótki: 5% budżetu w ciągu 1 godziny → Strona.
• Długi: 2% budżetu w 6 godzin → Bilet.
• Kohorta: Alerts by Region/Provider/VIP Segment - mniej fałszywych alarmów globalnych.

5) Techniki redukcji hałasu

1. Sondy kworum: uruchomione tylko wtedy, gdy ≥ 2 niezależne źródła (różne regiony/dostawcy) potwierdzają problem.
2. Deduplicacja - klucze agregacji: usługa + region + kod.
3. Histereza/czas trwania: „w czerwonej strefie ≥ N minut”, aby odfiltrować kolce.
4. Limit stawek: nie więcej niż X wpisy/godzinę/usługę; w przypadku przekroczenia, jedna strona + podsumowanie.
5. Auto-snooze/inteligentne tłumienie: powtarzający się alert w oknie T → tłumaczenie na Ticket aż do wyeliminowania korzenia.
6. Korelacja zdarzeń: jeden „master alert” zamiast dziesiątek objawów (np. „DB niedostępne” zagłuszanie 5xx z mikroservices).
7. Okna konserwacji: zaplanowana praca automatycznie tłumi oczekiwane sygnały.
8. Anomalia + barierki: anomalie - tylko jako bilet, jeśli nie ma potwierdzenia przez sygnał SLO.

6) Routing i priorytety

Priorytety: P0 (Strona, 15 aktualizacji min), P1 (Strona, 30 min), P2 (Bilet, 4-8 h), P3 (obserwacja).
Routing według etykiet: service//region/najemca → odpowiadający dyżurowi.
Eskalacja czasu: nie ack w 5 min → P2 → Duty Manager/IC.
Ciche godziny: Godziny nocne dla Non-Critical; Strona nie jest dozwolona dla P2/P3.
Polityka zmęczenia: jeśli inżynier ma> strony N/przesunięcie - redystrybucja do P2, eskaluj zanieczyszczenie sygnału.

7) Jakość wpisów: ustalenia

Aktywność ≥ 80%: zdecydowana większość stron prowadzi do działania runbooka.
False Positive ≤ 5% dla sygnałów Page.
Czas do Fix-Alert ≤ 7 dni - wadliwy alarm musi zostać skorygowany/usunięty.
Własność 100% - każdy wpis ma właściciela i repozytorium z jego definicją.

8) Alert jako kod cyklu życia

1. Utwórz PR (opis celu, warunki, runbook, właściciel, plan testów).
2. Sandbox/Shadow: shadow alert pisze do czatu/dziennika, ale nie ma strony.
3. Kanaryjski: ograniczona liczba odbiorców dyżurujących, środek FP/TP.
4. Prod: włączenie z limitem stawki + obserwacja 2-4 tygodnie.
5. Przegląd tygodniowy: wskaźniki jakości, edycje/wypłaty.
6. Deprecate: jeśli sygnał powiela wyższy lub nie jest aktywny.

9) Wskaźniki dojrzałości (pokaż na desce rozdzielczej)

Ostrzeżenia na godzinę dyżuru (mediana/95-percentyl).
% aktywny (są wykonane kroki) i fałszywie dodatni wskaźnik.
MTTA/MTTR wokół stron i strony → stawka biletu (nie powinna być wysoka).
Gadżety (usługi/zasady generujące ≥ 20% hałasu).
Czas naprawić alarm.
Zasięg oparzeń: udział usług z wpisami SLO w dwóch oknach.

10) Lista kontrolna „Higiena wpisów”

• Alert jest powiązany z SLO/SLI lub biznesem/bezpieczeństwem.
• Istnieje książka startowa i właściciel; kanał kontaktowy i wojenny są określone.
• Skonfigurowane są dwa okna (krótkie/długie) oraz kworum źródeł.
• Dedup, rate-limit, auto-resolve i auto-snooze są zawarte.
• Konserwacja i tłumienie systemu Windows są określone dla zwolnień/migracji.
• Przeszedł cień/Kanaryjczyk; zmierzone FP/TP.
• Sprawozdanie z pomiarów jakości alarmu zawarte.

11) Mini szablony

Specyfikacja alertu (idea YAML)

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" ]

Standardowy tekst aktualizacji (w celu zmniejszenia hałasu)

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

12) Procesy: Tygodniowy „przegląd alarmowy”

1. Top-talkers → edytuj/usuń.

2. FP/TP na Sygnały strony → dostosować progi/okna/kworum.

3. Osoby ubiegające się o obniżenie oceny (Strona → Bilet) i na odwrót.

4. Czas-do-Fix-Alert status - opóźnienia są przekształcane do właścicieli usług.

5. Sprawdzanie zasięgu za pomocą wpisów SLO i obecności książek startowych.

13) Link do zwolnień i operacji

Zwolnij adnotacje automatycznie dodaj tymczasowe tłumienia.
Zmień okna: w pierwszych 30 minutach po wydaniu - tylko sygnały SLO.
Playbooks zawierają krok „lower/suppress non-key alert”, aby skoncentrować się na korzeniu.

14) Bezpieczeństwo i zgodność

Sygnały bezpieczeństwa (hakowanie/wyciek/nieprawidłowe dostęp) - oddzielne kanały, bez cichych godzin.
Dziennik audytu wszystkich tłumień/cichych okien: kto, kiedy, dlaczego, termin.
Wymóg niezmienności dla wpisów krytycznych (podpis zdarzenia).

15) Anty-wzory

„Każdy wykres = alert” → lawina.
Próg „! = 0 błędów” w sprzedaży.
Jedna sonda/jeden region jako źródło prawdy.
Strona bez runbooka/właściciela.
Wieczyste „tymczasowe tłumienie” bez określenia.
„Napraw to później” wadliwe wpisy - gromadzą się przez lata.
Mieszanie hałasu uwalniania z incydentami produkcyjnymi.

16) Plan działania na rzecz realizacji (4-6 tygodni)

1. Inwentaryzacja: rozładuj wszystkie wpisy, odłóż właścicieli i kanały.
2. Jądro SLO: wprowadzenie reguł spalania z podwójnymi oknami dla usług krytycznych.
3. Kontrola hałasu: umożliwia kworum, terminy i ograniczenie tempa, rozpocząć cotygodniową recenzję.
4. Zasięg książki startowej: zamknij 100% sygnałów strony za pomocą odtwarzaczy.
5. Polityka Fatig: limity/przesunięcie strony, ciche godziny, redystrybucja obciążenia.
6. Automatyzacja: Alert-as-Code, Shadow/Canary, raportowanie na temat mierników jakości.

17) Sedno sprawy

Cisza to nie brak monitoringu, ale dobrze zaprojektowane sygnały związane z SLO i procesami. Kworum, podwójne okna, dedup i ścisłe routing zmieniają wpisy w rzadkie, dokładne i wykonywalne. Zespół śpi, użytkownicy są szczęśliwi, incydenty są pod kontrolą.