Алерттердің артық болуын болдырмау

1) Мәселе және мақсат

Alert fatigue жүйесі тым көп өзекті емес немесе actionable емес хабарламаларды жібергенде пайда болады. Нәтижесі - пейджерлерді елемеу, MTTA/MTTR өсуі және шынайы оқиғаларды өткізіп жіберу.
Мақсаты: сигналдарды SLO және плейбуктерге байлап, сирек, маңызды және орындалатын ету.

2) Сигналдардың таксономиясы (арна = салдары)

Page (P0/P1) - адамды оятады; қазір қолмен әрекет ету қажет болғанда ғана runbook бар.
Ticket (P2) - тәулік/сағат ішіндегі асинхронды жұмыс; оятпайды, бірақ SLA-ға сүйенеді.
Dash-only (P3) - белсенді әрекетсіз бақылау/тренд; шу тудырмайды.
Silent Sentry - бэкграундтағы метрика/аудит (RCA/пост-мортемдер үшін).

3) «Дұрыс» алаңды жобалау

• Мақсат/гипотеза (біз не қорғаймыз: SLO, қауіпсіздік, ақша, комплаенс).
• Іске қосылу шарттары (табалдырық, терезе, көздер кворумы).
• Runbook/Playbook (қадамның қысқаша ID + сілтеме).
• Иесі (команда/рөлдік топ).
• Аяқтау критерийлері (қашан жабу, авто-қорытынды).
• Осалдылық сыныбы (user-impact/platform/security/cost).

4) SLO бағытталған мониторинг

SLI/SLO → бастапқы сигналдар: қолжетімділік, жасырындылық, бизнес-операциялардың табыстылығы.

• Қысқа: 1 сағат ішінде бюджеттің 5% → Page.
• Ұзын: 6 сағат ішінде бюджеттің 2% → Ticket.
• Когортность: өңірлер/провайдерлер/VIP-сегменттер бойынша алерттар - жалған жаһандық дабылдардан аз.

5) Шуды азайту техникасы

1. Зондтар кворумы: егер 2 тәуелсіз көзден ≥ (әртүрлі өңірлер/провайдерлер) проблеманы растаса ғана іске қосылуы.
2. Дедупликация: бірдей оқиғалар топтамасы (aggregation keys: service + region + code).
3. Гистерезис/ұзақтығы: тікенектерді сүзу үшін «қызыл аймақта ≥ N минут».
4. Rate-limit: X ескертуден/сағаттан/сервистен артық емес; асып кеткен жағдайда - бір пейдж + мәлімет.
5. Auto-snooze/зияткерлік басу: T терезесінде қайталанатын қателік → түбірін жойғанға дейін Ticket-ке аудару.
6. Оқиғалардың корреляциясы: ондаған симптомдардың орнына бір «мастер-алерт» (мысалы, «ДБ қол жетімді емес» микросервистерден 5xx өшіреді).
7. Maintenance терезелері: жоспарлы жұмыстар автоматты түрде күтілетін сигналдарды басады.
8. Anomaly + guardrails: SLO сигналы расталмаса, аномалиялар тек Ticket ретінде.

6) Бағыттау және басымдықтар

Басымдықтары: P0 (Page, 15 мин), P1 (Page, 30 мин), P2 (Ticket, 4-8 сағ), P3 (қадағалау).
Таңбалар бойынша роутинг: service/env/region/tenant → on-call сәйкес келеді.
Уақыт бойынша эскалация: 5 минутта ack жоқ → P2 → Duty Manager/IC.
Quiet Hours: критикалық емес үшін түнгі сағат; Page P2/P3 тыйым салынған.
Fatigue-саясат: егер инженерде> N пейджер/ауысым болса - P2-ге қайта бөлу, сигналдардың ластануын күшейту.

7) Тәуекелдердің сапасы: уағдаластықтар

Actionability ≥ 80%: пейджерлердің басым көпшілігі runbook арқылы әрекет етеді.
False Positive ≤ Page сигналдары үшін 5%.
Time-to-Fix-Alert ≤ 7 күн - ақаулы алерт түзетілуі/жойылуы тиіс.
Ownership 100% - әрбір алерт иесі және оны анықтайтын репозиторийі бар.

8) Алертаның тіршілік циклі (Alert as Code)

1. PR құру (мақсаты, шарттары, runbook, иесі, тестілеу жоспары).
2. Құмсалғыш/Shadow: көлеңке-алерт чат/лог жазады, бірақ пейджит емес.
3. Канарейка: on-call шектеулі аудиториясы, FP/TP өлшейміз.
4. Өнім: rate-limit қосу + 2-4 апта бақылау.
5. Апта сайынғы review: сапа өлшемдері, түзету/алу.
6. Депрекейт: егер сигнал неғұрлым жоғары болса немесе actionable болмаса.

9) Жетілу метрикасы (дашбордта көрсетіңіз)

Alerts per on-call hour (медиана/95-перцентиль).
% actionable (орындалған қадамдар бар) және false-positive rate.
MTTA/MTTR пейджер айналасында және page → ticket үлесі (жоғары болмауы тиіс).
Top-talkers (20% -дан ≥ шу шығаратын қызметтер/ережелер).
Mean time to fix alert (бірінші FP-ден ережені өзгертуге дейін).
Burn-rate coverage: екі терезеде SLO-алерті бар сервистердің үлесі.

10) «Аллергия гигиенасы» чек-парағы

• Алерт SLO/SLI немесе бизнес/қауіпсіздікке байланысты.
• runbook және иесі бар; war-room байланысы мен арнасы көрсетілген.
• Екі терезе (қысқа/ұзын) және көздер кворумы теңшелген.
• Дедуп, rate-limit, auto-resolve және auto-snooze қосылған.
• Релиздер/көшірулер кезінде терезе maintenance және suppression көрсетілген.
• Shadow/Canary өтті; FP/TP өлшенді.
• Алерт сапасының метрикасы бойынша есеп қосылған.

11) Шағын үлгілер

Алерт ерекшелігі (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" ]

Стандарт бойынша апдейт мәтіні (шуды азайту үшін)

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

12) Процестер: апта сайынғы «Alert Review»

1. Ең шулы ережелер (top-talkers) → түзету/жою.

2. Page-сигналдары бойынша FP/TP → табалдырығын/терезесін/кворумын түзетеміз.

3. Арна төмендеуіне үміткерлер (Page → Ticket) және керісінше.

4. «Time-to-Fix-Alert» мәртебесі - кешіктірулер сервис иелеріне үдетіледі.

5. SLO-алерталарымен coverage және runbook 'дардың болуын тексеру.

13) Релиздермен және операциялармен байланыс

Релиздер аңдатпалары автоматты түрде уақытша басуды қосады.
Change windows: шығарылғаннан кейінгі алғашқы 30 минутта - тек SLO сигналдары.
Плейбуктарда түбіріне шоғырлану үшін «кілт емес алерталарды төмендету/басу» қадамы бар.

14) Қауіпсіздік және комплаенс

Security-сигналдары (бұзып алу/ағып кету/аномальды қол жеткізу) - quiet hours жоқ жеке арналар.
Барлық басу/тыныш терезелердің аудит-журналы: кім, қашан, неге, мерзім.
Сындарлы алармдар үшін өзгермейтіндігін талап ету (оқиғаның қолы).

15) Қарсы үлгілер

«Әрбір кесте = алерт» → көшкін.
Сынамадағы «! = 0 қате» шегі.
Бір зонд/бір аймақ ақиқат көзі ретінде.
Runbook/иесі жоқ Page.
Мерзімсіз мәңгілік «уақытша басу».
«Кейін жөндейміз» деген кемшіліктер - жылдар бойы жинақталып келеді.
Релиздік шуды өнімдік инциденттермен араластыру.

16) Енгізу жол картасы (4-6 апта)

1. Түгендеу: барлық алаңдарды түсіру, иелері мен арналарын қою.
2. SLO-ядро: сындарлы сервистер бойынша қос терезелі burn-rate ережелерін енгізу.
3. Шу-бақылау: кворумды, дедупты және rate-limit қосу, weekly review бастау.
4. Runbook-жабу: 100% Page-сигналдарын ойнатқыштармен жабу.
5. Фатиг-саясат: пейдж/ауысым лимиттері, Quiet Hours, жүктемені қайта бөлу.
6. Автоматтандыру: Alert-as-Code, Shadow/Canary, сапа өлшемдері бойынша есептілік.

17) Жиынтық

Тыныштық - бұл мониторингтің жоқтығы емес, SLO және процестерге байланысты сапалы жобаланған сигналдар. Кворум, қос терезе, дедуп және қатаң маршруттау алерттерді сирек, дәл және орындалатын күйге айналдырады. Команда ұйықтап жатыр, пайдаланушылар риза, оқиғалар бақылауда.