Сигналдар мен хабарламалар жүйесі

1) Рөлі мен мақсаттары

Сигналдар жүйесі - «хабарламаларды жіберу» емес, шешімдерді қабылдау контуры: ол ауытқуларды уақытында көрсетеді, іс-қимылдарды ұсынады және уақтылық пен тыныштық арасындағы теңгерімді сақтайды.

• MTTD/MTTR-ді басымдық беру және айқын плейбуктер есебінен төмендету.
• Шуды азайту арқылы alert fatigue (хабарлаудың шаршауын) азайту.
• Тікелей хабарламадан әрекеттер беру (ack, snooze, runbook, auto әрекет).
• Құпиялылық пен келісімді сақтау (opt-in/opt-out, логты сақтау).

2) Оқиғалар таксономиясы және деңгейлер

2. 1 Оқиға түрлері

Метрика/аномалиялар (SRE, өнім, қаржы).
Бизнес-ережелер (лимиттер, фрод, KYC, төлемдер).
Жүйелік (деплой, тозу, лицензиялар).
Пайдаланушылар (мінез-құлық триггерлері, RG/жауапты ойын).

2. 2 Маңыздылық деңгейлері (Severity)

Critical - шұғыл реакция, жоғалту/қауіпсіздік тәуекелі.
High - KPI/SLO елеулі нашарлауы.
Medium - жұмыс уақытындағы әрекеттер қажет.
Low/Info - бақылау/контекст, дайджестерге авто-орау.

2. 3 Басымдық (Priority)

'Impact × Urgency' → P1..P4 матрицасы. Арналарға және SLA реакцияларына байланыстыру.

3) Сәулет және ағындар

Сигнал өндірушілер → Оқиғалар шинасы → Қалыпқа келтіру (enrich, дедуп) → Корреляция → Ережелер (policy engine) → Маршруттау → Жеткізу арналары → Таңдау орталығы → Логи/аналитика.

• Enricher: тенантты, рөлді, аймақты, playbook сілтемелерін қосады.
• Deduper: қайталанатын оқиғаларды кілт бойынша топтау.
• Correlator: ұқсас сигналдарды оқиғаға жабыстыру.
• Policy Engine: YAML/DSL ережелері, quiet hours, эскалация.
• Delivery: in-app, email, push, SMS, webhook, чат-интеграция.

4) Ережелер мен саясат (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) Дедупликация, корреляция, флаппингті басу

Дедуп: топ идентификаторы 'dedup _ key = hash (service' metric 'dim)'; TTL ≥ флаппинг терезесі.
Корреляция: топология (қызмет → тәуелділік), уақыт (± N мин) және контекст (релиз, инцидент) бойынша байланысты сигналдарды біріктіріңіз.
Флаппинг: «M минут ішінде оқиғалар N» табалдырығы → гистерезис немесе suppress көтеру ұсынысымен бір «flapping detected» сигналы.

6) Маршруттау және RACI

Responsible: бірінші хабарламаны кім алады/таск.
Accountable: SLA-дан кейін кім өршиді.
Consulted: тред/чат арнасында кімді атау керек.
Informed: дайджест/қорытындылар кімге кетеді.
Рөлі мен контексті бойынша тағайындаңыз (тенант, өңір, өнім-ағым).

7) Жеткізу арналары және нюанстар

Ретраи: 5хх/429/таймаут → backoff + jitter; 'Retry-After' құрметтеу. Ұқсастығы: вебхуктарда 'X-Notification-Id'.

8) Артықшылықтар орталығы (Preferences Center)

Оқиға түрлері, деңгейлер, арналар бойынша Opt-in/Opt-out.
Тыныштық кестесі (quiet hours), 15/30/60 минутқа қол snooze.
Шекті/сезімталдық (мысалы, аномалия ≥ 3 σ).
Тіл/локаль, уақыт/валюта пішімі.
Рөлдерге байланыстыру: SRE/Product/Finance үшін пресеттер.
Ашықтық: пайдаланушының неге сигнал алғанын көрсету (ережеге сілтеме).

9) Контент-дизайн: хабарлама құрылымы

• Тақырып: қысқаша, триггермен: «[P1] [PSP _ TR] 3DS (+ 12%) істен шығудың күрт өсуі».
• Контексті: кезең, қозғалған сегменттер/өңір, деректер көзі.
• Себебі/гипотеза: «18:20 UTC PSP_X релизімен байланысты».
• SLA/мерзім: «10 минуттан кейін эскалация».
• CTA: "Плейбук ашу", "Fallback қосу PSP_Y", "Ack (30 мин)".
• Сілтемелер: график, инцидент-тред, метрика, runbook.
• Метадеректер: 'trace _ id', 'incident _ id', 'dedup _ key'.

Тон: фактілер, драмасыз; сандар мен өлшем бірліктері; аббревиатуралардың толық жазылмауын болдырмау.
Локализация: айнымалы → плейсхолдерлер, аудармалар ресурстарда сақталады; күндер/күндер - жергілікті жер бойынша.

10) Хабарламалардағы әрекеттер (Actionable)

Уақыт параметрлерімен Ack/Snooze.
Assign/Invite оқиғасы.
Runbook: мәтінмәнді автотолтыру шешімінің қадамдарын ашу.
One-click remediation (қауіпсіз жерде): маршрутты ауыстырып қосу, лимитті көтеру, джобаны қайта іске қосу (растау және аудит).
Өрістерді автотолтырумен (Jira/GitHub) тикет жасау.

11) Сигналдардың сапасы: метрика және мақсаттар

Precision (жіберілгендердің арасында релеванттық үлесі) ≥ үшін 80% P1/P2.
Recall (барлық оқыс оқиғалардың арасында анықталған үлесі) ≥ 70%.
Noise: пайдаланушыға орташа сигналдар/сағат (мақсатты төбе).
Ack-time p50/p95, Escalation rate, Snooze rate (шу индикаторы ретінде).
MTTD/MTTA/MTTR (домендер мен арналар бөлінісінде).
Silenced-but-should-alert (ережеге байланысты ауытқулар) - жеке дашборд.

12) Шуды басқару: тәсілдер

Гистерезис және табалдырыққа арналған «сырғымалы терезелер».
Детекциялау алдында тегістеу (EWMA).
Агрегация: 30 ұсақ орнына - топ-контрибьюторлары бар бір батч/дайджест.
Контекст лимиттері: N хабарлама/сағат/арна/пайдаланушы.
Автоматты кері байланыс: егер пайдаланушы қатарынан 3 × Snooze басса → табалдырығын көтеруді/арнаны өзгертуді ұсынады.

13) Қауіпсіздік, құпиялылық, комплаенс

HMAC-вебхуктар үшін қолтаңба, құпияларды ротациялау, 'X-Key-Id'.
RBAC/ABAC: рольдер/тенанттар бойынша сигналдардың көрінуі.
PII-ықшамдау, журналдағы маскалар, әрекеттер аудиті (ack/assign/runbook).
Келісімдер (consent) және хабарлау себептері (ереже/саясат) - payload.
Retention/TTL хабарламалар, оқиғалар бойынша Legal Hold.

14) Схемалар мен payload 'лар

Оқиға (ішкі)

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

Хабарлама (канал-агностик)

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) Өнімдегі UX-үлгілер

Инбокстар: Critical/High/Other қойындылары, сан бейдждері.
Инцидент таспасы: байланыстырылған сигналдар, таймлайн әрекеттер, «не істелді».
Сүзгілер: рөлі, домені, аймағы, уақыты, «тек жауапсыз».
Тізімдегі жылдам әрекеттер (ack/snooze/assign).
Explain: «неліктен оны көресіз» (ереже, табалдырықтар, деректер).
Дайджесттер: таңертеңгі/кешкі, TZ бойынша оқшауланған.

16) Тест-жоспар

Unit: дедуп-кілттер, гистерезис, флаппинг, сериализация payload's.
Integration: маршруттау, quiet hours, эскалациялар, арналар ретрайлері.
E2E: аномалиядан тикеттің жабылуына дейінгі Р1 сценарийі; P2 quiet hours → дайджест.
Chaos: арнаның жоғалуы (SMTP/SMS), кідірістер, сигналдардың көшкіні, clock-skew.
A11y/i18n: screen-readers, пернетақталық ack/snooze, сандарды/күндерді оқшаулау.

17) Сапа дашбордтары

Домендер бойынша Precision/Recall.
Ack time p50/p95 және уақтылы расталған үлесі.
Noise per user/hour және жоғары шулы ережелер.
Escalation rate және «жалған эскалациялар».
Suppressed vs Delivered (дайджестке қанша басылған/жинақталған).
User feedback :/хабарлар, шу түсініктемелері.

18) Чек парақтары

Жобалау

• Оқиғалар таксономиясы мен деңгейлері келісілген
• quiet hours/эскалация саясаты сипатталған
• Дедуп/корреляция/флаппинг теңшелген
• Арналар, ретрайлер, вебхуктардың ұқсастығы
• Артықшылықтар орталығы (opt-in/out, snooze)
• Мазмұн үлгілері және локализация
• Ойнатқыштар және one-click әрекеттері (аудитпен)
• Сапа өлшемдері және дашбордтар

Пайдалану

• Тоқсанына бір рет шекті оңтайландыру
• A/B ережелері (табалдырық, терезе, digest)
• «Топ-шу» және CAPA тұрақты шолулары
• Арналар құпияларын ротациялау (HMAC, SMTP, SMS)
• Кесте бойынша дабыл тесті (game days)

19) Енгізу жоспары (3 итерация)

Итерация 1 - Базалық контур (2-3 апта)

Таксономия, severity/priority, артықшылықтар орталығы (in-app + email).
Дедуп, кілт/уақыт бойынша қарапайым корреляция, quiet hours.
Хабарлар үлгілері, ойнатқыштар, ack/snooze/assign.

Итерация 2 - Сенімділік және шуды азайту (3-4 апта)

Флаппинг/гистерезис, дайджесттер, чат-интеграциялары және вебхукилер (HMAC, ретраилер).
SLA бойынша эскалациялар, сапа дашбордтары (precision/recall, noise).
One-click remediation (растау және аудитпен).

Итерация 3 - Оңтайландыру және масштаб (үздіксіз)

Топология/релиздер бойынша корреляция, авто-ұсыныстар табалдырықтары.
A/B ережелері, «шегі қашан іске қосылады» болжамы.
Шуға шолулар және тұрақты game days.

20) Mini-FAQ

alert fatigue-мен қалай күресуге болады?
Дедуп, корреляция, гистерезис, дайджесттер және артықшылық орталықтары + шудың және A/B шектерінің тұрақты шолулары.

Аномалиялар үшін ML қажет пе?
Пайдалы, бірақ детерминирленген ережелерден және түсіндірілетін шектерден бастаңыз. ML - Explain-мен міндетті түрде қондырма ретінде.

Неліктен пайдаланушылар «артық» хаттарды алады?
Ереже матчтарын, quiet hours, «неге жеткізілді» аудитін тексеріңіз, арнаға/сағатқа лимиттерді және дайджесттерді теңшеңіз.

Жиынтығы

Күшті дабыл жүйесі - бұл ақылды сүзгілеу және дұрыс басымдық + бір басу арқылы әрекет ету. Таксономияны және саясатты ресімдеңіз, дедуп/корреляцияны/гистерезисті енгізіңіз, пайдаланушыларға бақылау (preferences, snooze) беріңіз, сенімді жеткізуді және «неге мен оны алдым» деген ашықтықты қамтамасыз етіңіз. Сонда дабылдар шу көзі емес, басқару құралы болады.