Həddindən artıq alertlərin qarşısını almaq

1) Problem və məqsəd

Alert fatigue sistem çox qeyri-aktual və ya actionable bildirişlər göndərir zaman yaranır. Nəticə - peyceklərə məhəl qoymamaq, MTTA/MTTR artımı və real hadisələri qaçırmaq.
Məqsəd: siqnalları SLO və playbuklara bağlayaraq nadir, mənalı və mümkün etmək.

2) Siqnalların taksonomiyası (kanal = nəticələr)

Page (P0/P1) - insanı oyadır; yalnız indi əl hərəkəti tələb olunur və runbook var.
Ticket (P2) - saatlarda/gündə asenxron iş; oyanmır, lakin SLA ilə izləyir.
Dash-only (P3) - aktiv hərəkətsiz müşahidə/trend; səs-küy yaratmır.
Silent Sentry - arxa planda metriklər/audit (RCA/post-mortemlər üçün).

3) «Düzgün» alert dizayn

• Məqsəd/fərziyyə (nə qoruyuruq: SLO, təhlükəsizlik, pul, uyğunluq).
• İş şəraiti (eşik, pəncərə, mənbələrin kvorumu).
• Runbook/Playbook (qısa addım ID + link).
• Sahibi (komanda/rol qrupu).
• Tamamlanma meyarları (nə zaman bağlanacaq, avtomatik rezoll).
• Zəiflik sinfi (user-impact/platform/security/cost).

4) SLO yönümlü monitorinq

SLI/SLO → ilkin siqnallar: əlçatanlıq, gizli, biznes əməliyyatlarının müvəffəqiyyəti.

• Qısa: 1 saat ərzində büdcənin 5% → Page.
• Uzun: 2% büdcə 6 saat → Ticket.
• Kohortluq: regionlar/provayderlər/VIP seqmentlər üzrə alertlər - daha az yalan qlobal narahatlıqlar.

5) Səs-küy azaltma texnikaları

1. Sondaların kvorumu: yalnız ≥ 2 müstəqil mənbə (müxtəlif regionlar/provayderlər) problemi təsdiqlədikdə işə salınır.
2. Deduplikasiya: eyni hadisələrin qruplaşdırılması (aggregation keys: service + region + code).
3. Histerezis/müddəti: «qırmızı zonada ≥ N dəqiqə» tikanları süzmək üçün.
4. Rate-limit: X-dən çox olmayan xəbərdarlıq/saat/xidmət; aşdıqda - bir peyj + xülasə.
5. Auto-snooze/ağıllı boğma: kök aradan qaldırılması əvvəl T → Ticket tərcümə pəncərəsində təkrarlanan alert.
6. Hadisələrin korrelyasiyası: onlarla simptomun əvəzinə bir «master-alert» (məsələn, «DB əlçatmaz» mikroservislərdən 5xx-i söndürür).
7. Maintenance pəncərələri: planlaşdırılan işlər avtomatik olaraq gözlənilən siqnalları yatırır.
8. Anomaly + guardrails: Anomaliyalar yalnız bir SLO siqnalı təsdiqi olmadıqda Ticket kimi.

6) Marşrutlaşdırma və prioritetlər

Prioritetlər: P0 (Page, 15 min yeniləmə), P1 (Page, 30 min), P2 (Ticket, 4-8 saat), P3 (müşahidə).
Routing: service/env/region/tenant → on-call uyğun.
Zaman eskalasiyası: 5 dəq üçün heç bir ack → P2 → Duty Manager/IC.
Quiet Hours: kritik olmayan üçün gecə saatları; Səhifə P2/P3 üçün qadağandır.
Fatigue siyasəti: mühəndis varsa> N gözlük/vardiya - P2 yenidən paylamaq, siqnalların çirklənməsini artırmaq.

7) Alertlərin keyfiyyəti: razılaşmalar

Actionability ≥ 80%: peyceklərin böyük əksəriyyəti runbook ilə hərəkət edir.
False Positive ≤ 5% Page siqnalları üçün.
Time-to-Fix-Alert ≤ 7 gün - qüsurlu alert düzəldilməlidir/silinməlidir.
Ownership 100% - hər bir alert sahibi və onun tərifi ilə bir anbar var.

8) Alert həyat dövrü (Alert as Code)

1. PR yaratmaq (məqsəd təsviri, şərtlər, runbook, sahibi, test planı).
2. Qum qutusu/Shadow: kölgə alert chat/log yazır, lakin peycit deyil.
3. Kanarya: on-call məhdud auditoriya, FP/TP ölçmək.
4. Prod: rate-limit ilə daxil + 2-4 həftə müşahidə.
5. Həftəlik review: keyfiyyət metrikası, düzəliş/geri götürmə.
6. Deprequate: siqnal daha yüksək və ya actionable təkrarlanırsa.

9) Yetkinlik metrikası (dashboard göstərin)

Alerts per on-call hour (mediana/95-persentil).
% actionable (yerinə yetirilmiş addımlar var) və false-positive rate.
MTTA/MTTR peycey ətrafında və pay page → ticket (yüksək olmamalıdır).
Top-talkers (20% səs-küy ≥ yaradan xidmətlər/qaydalar).
Mean time to fix alert (ilk FP-dən qayda dəyişikliyinə qədər).
Burn-rate coverage: SLO-alertli xidmətlərin iki pəncərədə payı.

10) «Həyəcan gigiyenası» yoxlama siyahısı

• Alert SLO/SLI və ya biznes/təhlükəsizlik ilə bağlıdır.
• runbook və sahibi var; əlaqə və war-room kanalı göstərilir.
• İki pəncərə (qısa/uzun) və kvorum mənbələri konfiqurasiya.
• Dedup, rate-limit, auto-resolve və auto-snooze daxildir.
• Relizlər/miqrasiyalar zamanı pəncərələr və suppression maintenance göstərilir.
• Shadow/Canary keçdi; FP/TP ölçülür.
• Alert keyfiyyətinin metrikləri haqqında hesabat daxil edilmişdir.

11) Mini şablonlar

Alert spesifikasiyası (YAML-ideya)

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

Standart yeniləmə mətni (səs-küyün azaldılması üçün)

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

12) Proseslər: həftəlik «Alert Review»

1. Top səs-küylü qaydalar (top-talkers) → düzəliş/silmək.

2. Page siqnalları ilə FP/TP → eşik/pəncərə/kvorum düzəliş.

3. Kanal aşağı iddiaçıları (Page → Ticket) və əksinə.

4. «Time-to-Fix-Alert» statusu - gecikmələr xidmət sahiblərinə eskalasiya olunur.

5. SLO-alertlər tərəfindən coverage yoxlanılması və runbook 'ların mövcudluğu.

13) Relizlər və əməliyyatlar ilə əlaqə

Reliz açıqlamaları avtomatik olaraq müvəqqəti sıxışdırma əlavə edir.
Change windows: buraxıldıqdan sonra ilk 30 dəqiqədə - yalnız SLO siqnalları.
Pleybuklarda kökünə diqqət yetirmək üçün «açar olmayan alertləri aşağı salmaq/sıxışdırmaq» addımı var.

14) Təhlükəsizlik və uyğunluq

Təhlükəsizlik siqnalları (hack/sızma/anormal giriş) - ayrı kanallar, quiet hours olmadan.
Audit-log bütün basqılar/sakit pəncərələr: kim, nə zaman, niyə, son tarix.
Kritik alarmlar üçün dəyişməzlik tələbi (hadisənin imzası).

15) Anti-nümunələr

«Hər qrafik = alert» → uçqun.
Prodda «! = 0 səhv» həddi.
Həqiqət mənbəyi kimi bir zond/bir bölgə.
Runbook/sahibi olmadan Page.
Müddətsiz əbədi «müvəqqəti sıxışdırma».
«Sonra düzəldəcəyik» qüsurlu alertlər illərlə yığılır.
Buraxılış səs-küyünün istehsal hadisələri ilə qarışdırılması.

16) Tətbiqi yol xəritəsi (4-6 həftə)

1. Inventarizasiya: bütün riskləri boşaltmaq, sahibləri və kanalları qoymaq.
2. SLO-core: Kritik xidmətlər üçün ikiqat pəncərələrlə burn-rate qaydaları daxil edin.
3. Səs-küy nəzarəti: kvorum, dedup və rate-limit, weekly review başlayın.
4. Runbook örtük: 100% Page siqnalları playbook ilə bağlayın.
5. Fatig siyasəti: page/smena limitləri, Quiet Hours, yükün yenidən bölüşdürülməsi.
6. Avtomatlaşdırma: Alert-as-Code, Shadow/Canary, keyfiyyət göstəriciləri üzrə hesabat.

17) Yekun

Sükut monitorinqin olmaması deyil, SLO və proseslərlə əlaqəli keyfiyyətli hazırlanmış siqnallardır. Kvorum, ikiqat pəncərələr, dedup və ciddi marşrutlaşdırma alertləri nadir, dəqiq və yerinə yetirilə bilən hala gətirir. Komanda yatır, istifadəçilər xoşbəxtdirlər, hadisələr nəzarət altındadır.