Система сигналів і повідомлень

1) Роль і цілі

Система сигналів - не «розсилка повідомлень», а контур прийняття рішень: вона вчасно підсвічує відхилення, пропонує дії і дотримується балансу між своєчасністю і тишею.

• Знизити MTTD/MTTR за рахунок пріоритизації і чітких плейбуків.
• Зменшити alert fatigue (втома від сповіщень) через шумозаглушення.
• Дати дії прямо з повідомлення (ack, snooze, runbook, автодействие).
• Дотримуватися приватності та згоди (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: додає тенант, роль, регіон, посилання на плейбуки.
• 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 ≥ вікно флапінгу.
Кореляція: об'єднуйте пов'язані сигнали по топології (servis→zavisimost), часу (± N хв) і контексту (реліз, інцидент).
Флапінг: пороги «N подій за M хвилин» → один сигнал «flapping detected» з пропозицією підняти гістерезис або suppress.

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), ручний snooze на 15/30/60 хв.
Поріг/чутливість (наприклад, аномалія ≥ 3 σ).
Мова/локаль, формат часу/валюти.
Прив'язка до ролей: пресети для SRE/Product/Finance.
Прозорість: показати, чому користувач отримав сигнал (посилання на правило).

9) Контент-дизайн: структура повідомлення

• Заголовок: коротко, з тригером: «[P1] [PSP _ TR] Різке зростання відмов 3DS (+ 12%)».
• Контекст: період, порушені сегменти/регіон, джерело даних.
• Причина/гіпотеза: "Пов'язано з релізом PSP_X 18:20 UTC».
• 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'ів.
Integration: маршрутизація, quiet hours, ескалації, ретраї каналів.
E2E: сценарій P1 від аномалії до закриття тікету; 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) Міні-FAQ

Як боротися з alert fatigue?
Дедуп, кореляція, гістерезис, дайджести і центри переваг + регулярні огляди шуму і A/B порогів.

Чи потрібен ML для аномалій?
Корисний, але починайте з детермінованих правил і пояснюваних порогів. ML - як надбудова, обов'язково з Explain.

Чому користувачі отримують «зайві» листи?
Перевірте матчі правил, quiet hours, аудит «чому доставлено», налаштуйте ліміти на канал/годину і дайджести.

Підсумок

Сильна система сигналів - це розумна фільтрація і коректна пріоритизація + дії в один клік. Формалізуйте таксономію і політики, впровадьте дедуп/кореляцію/гістерезис, дайте користувачам контроль (preferences, snooze), забезпечте надійну доставку і прозорість «чому я це отримав». Тоді сигнали стануть інструментом управління, а не джерелом шуму.