Система сигналов и уведомлений

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 ≥ окно флаппинга.
Корреляция: объединяйте связанные сигналы по топологии (сервис→зависимость), времени (±N мин) и контексту (релиз, инцидент).
Флаппинг: пороги «N событий за M минут» → один сигнал «flapping detected» с предложением поднять гистерезис или suppress.

6) Маршрутизация и RACI

Responsible: кто получает первое уведомление/таск.
Accountable: кто эскалируется после SLA.
Consulted: кого упомянуть в треде/чат-канале.
Informed: кому уйдет дайджест/итоги.
Назначайте по роли и контексту (тенант, регион, продукт-стрим).

7) Каналы доставки и нюансы

Ретраи: 5xx/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), обеспечьте надежную доставку и прозрачность «почему я это получил». Тогда сигналы станут инструментом управления, а не источником шума.