Alertlarning ortiqcha bo’lishining oldini olish

1) Muammo va maqsad

Alert fatigue tizimi juda ko’p asossiz yoki actionable bo’lmagan xabarlarni yuborganda paydo bo’ladi. Natija - peyjlarni e’tiborsiz qoldirish, MTTA/MTTR o’sishi va haqiqiy hodisalarni o’tkazib yuborish.
Maqsad: signallarni SLO va pleybuklarga bog’lab, ularni noyob, ahamiyatli va bajariladigan qilish.

2) Signallar taksonomiyasi (kanal = oqibatlar)

Page (P0/P1) - odamni uyg’otadi; faqat qo’lda harakat talab qilinganda va runbook mavjud bo’lsa.
Ticket (P2) - soatiga/kuniga asinxron ish; uyg’otmaydi, lekin SLA bo’yicha yoritadi.
Dash-only (P3) - faol harakatsiz kuzatish/trend; shovqin hosil qilmaydi.
Silent Sentry - metrika/audit (RCA/post-mortemlar uchun).

3) "To’g" ri "alertni loyihalash

• Maqsad/faraz (biz nimani himoya qilamiz: SLO, xavfsizlik, pul, komplayens).
• Ishga tushirish shartlari (ostona, deraza, manbalar kvorumi).
• Runbook/Playbook (qisqa qadam ID + havola).
• Egasi (jamoa/rol guruhi).
• Yakunlash mezonlari (qachon yopish, avto-rezolv).
• Zaiflik klassi (user-impact/platform/security/cost).

4) SLO-yo’naltirilgan monitoring

SLI/SLO → birlamchi signallar: foydalanish imkoniyati, yashirin, biznes operatsiyalarining muvaffaqiyati.

• Qisqa: 1 soat ichida byudjetning 5% → Page.
• Uzoq: 6 soat ichida byudjetning 2% → Ticket.
• Kogortlik: mintaqalar/provayderlar/VIP-segmentlar bo’yicha alertlar - yolg’on global tashvishlardan kamroq.

5) Shovqinni kamaytirish texnikasi

1. Kvorum zondlari: agar 2 ta mustaqil manba (turli hududlar/provayderlar) ≥ muammoni tasdiqlasa, ishga tushiriladi.
2. Deduplikatsiya: bir xil hodisalarni guruhlash (aggregation keys: service + region + code).
3. Gisterezis/davomiyligi: tikanlarni filtrlash uchun "N daqiqa ≥ qizil zonada.
4. Rate-limit: X dan ortiq bo’lmagan ogohlantirish/soat/servis; oshganda - bitta peyj + ma’lumot.
5. Auto-snooze/intellektual bostirish: T oynasida takrorlanadigan alert → ildiz bartaraf etilgunga qadar Ticketga tarjima qilinadi.
6. Hodisalarning korrelyatsiyasi: o’nlab alomatlar o’rniga bitta «master-alert» (masalan, «BD mavjud emas» mikroservislardan 5xxni o’chirib qo’yadi).
7. Maintenance oynalari: rejalashtirilgan ishlar kutilgan signallarni avtomatik ravishda bostiradi.
8. Anomaly + guardrails: anomaliyalar faqat Ticket kabi, agar SLO signali tasdiqlanmasa.

6) Yo’naltirish va ustuvorliklar

Ustuvorliklari: P0 (Page, 15 min apdeyt), P1 (Page, 30 min), P2 (Ticket, 4-8 soat), P3 (kuzatuv).
Yorliqlar bo’yicha routing: service/env/region/tenant → mos on-call.
Vaqt boʻyicha eskalatsiyalar: 5 daqiqada ack yoʻq → P2 → Duty Manager/IC.
Quiet Hours: nekritik uchun tungi soatlar; Page P2/P3 uchun taqiqlangan.
Fatigue siyosati: agar muhandisda> N peyj/smena bo’lsa - signallarning ifloslanishini P2 ga qayta taqsimlash, eskalatsiya qilish.

7) Alertlarning sifati: kelishuvlar

Actionability ≥ 80%: ko’pchilik peyjerlar runbook dasturiga olib keladi.
False Positive ≤ Page signallari uchun 5%.
Time-to-Fix-Alert ≤ 7 kun - nuqsonli alert tuzatilishi/olib tashlanishi kerak.
Ownership 100% - har bir alert egasi va uning ta’rifiga ega bo’lgan repozitoriyaga ega.

8) Alertning hayot sikli (Alert as Code)

1. PR yaratish (maqsad, shartlar, runbook, egasi, sinov rejasi).
2. Qum qutisi/Shadow: soya-alert chat/jurnalga yozadi, lekin peyjit emas.
3. Kanareyka: on-call cheklangan auditoriya, biz FP/TP o’lchaymiz.
4. Prod: rate-limit bilan qo’shish + 2-4 hafta kuzatish.
5. Haftalik review: sifat metrikasi, tuzatish/olib qo’yish.
6. Deprekeyt: agar signal yuqoriroq boʻlsa yoki actionable boʻlmasa.

9) Etuklik metrikasi (dashbordda ko’rsating)

Alerts per on-call hour (mediana/95-percentil).
% actionable (bajarilgan qadamlar mavjud) va false-positive rate.
MTTA/MTTR peyjlar atrofida va page → ticket ulushi (yuqori bo’lmasligi kerak).
Top-talkers (20% ≥ shovqin hosil qiluvchi servislar/qoidalar).
Mean time to fix alert (birinchi FP dan qoidani oʻzgartirishgacha).
Burn-rate coverage: ikki oynada SLO-alertli xizmatlar ulushi.

10) «Alertlar gigiyenasi» chek-varaqasi

• Alert SLO/SLI yoki biznes/xavfsizlik bilan bog’langan.
• Runbook va egasi bor; aloqa va war-room kanali koʻrsatilgan.
• Ikkita oyna (qisqa/uzun) va kvorum manbalari sozlangan.
• Dedup, rate-limit, auto-resolve va auto-snooze kiritilgan.
• Reliz/migratsiyada maintenance oynasi va suppression koʻrsatilgan.
• Shadow/Canary tugadi; FP/TP oʻlchangan.
• Alertlarning sifat ko’rsatkichlari bo’yicha hisobot kiritilgan.

11) Mini-shablonlar

Alert spetsifikatsiyasi (YAML g’oyasi)

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 bo’yicha yangilangan matn (shovqinni kamaytirish uchun)

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

12) Jarayonlar: haftalik «Alert Review»

1. Top-shovqinli qoidalar (top-talkers) → o’zgartirish/o’chirish.

2. FP/TP Page signallari bo’yicha → ostonalarni/oynalarni/kvorumni tuzatish.

3. Kanalni pasaytirishga da’vogarlar (Page → Ticket) va aksincha.

4. «Time-to-Fix-Alert» maqomi - kechikishlar servis egalariga eskalatsiya qilinadi.

5. coverage SLO-alertlar va runbook’lar mavjudligini tekshirish.

13) Relizlar va operatsiyalar bilan aloqa

Relizlarning izohlari avtomatik ravishda vaqtinchalik bostirishlarni qoʻshadi.
Change windows: chiqarilgandan keyingi birinchi 30 daqiqada - faqat SLO signallari.
Pleybuklarda ildizdan diqqatni jamlash uchun «kalitsiz alertlarni pasaytirish/bostirish» qadami mavjud.

14) Xavfsizlik va komplayens

Security-signallar (buzish/oqish/g’ayritabiiy kirish) - alohida kanallar, quiet hours.
Barcha bostirishlar/jim oynalarning audit-jurnali: kim, qachon, nima uchun, muddat.
Tanqidiy alarmlar uchun o’zgarmaslikni talab qilish (voqea imzosi).

15) Anti-patternlar

«Har bir jadval = alert» → ko’chki.
Prodda «! = 0 xato» chegarasi.
Haqiqat manbai sifatida bitta zond/bitta hudud.
Runbook/egasiz page.
Muddatsiz abadiy «vaqtinchalik bostirish».
«Keyinchalik tuzatamiz» deganda, nuqsonli alertlar yillar davomida to’planadi.
Reliz shovqinini mahsulot hodisalari bilan aralashtirish.

16) Joriy etish yo’l xaritasi (4-6 hafta)

1. Xatlovdan o’tkazish: barcha alertlarni tushirish, egalari va kanallarini qo’yish.
2. SLO-yadro: burn-rate qoidalarini tanqidiy xizmatlar bo’yicha ikki oynali kiriting.
3. Shovqin-nazorat: kvorum, dedup va rate-limit, weekly review.
4. Runbook qoplamasi: 100% Page signallarini pleybuklar bilan yopish.
5. Fatig siyosati: peyj/smena limitlari, Quiet Hours, yukni qayta taqsimlash.
6. Avtomatlashtirish: Alert-as-Code, Shadow/Canary, sifat ko’rsatkichlari bo’yicha hisobot.

17) Jami

Sukunat - bu monitoring yo’qligi emas, balki SLO va jarayonlar bilan bog’liq sifatli loyihalashtirilgan signallardir. Kvorum, ikki oynali derazalar, dedup va qatʼiy marshrutlash alertlarni nodir, aniq va bajariladigan holatga aylantiradi. Jamoa uxlamoqda, foydalanuvchilar xursand, hodisalar nazorat ostida.