信号和通知系统

1）角色和目标

信号系统不是"邮件发送"，而是决策轮廓：它及时突出显示偏差，建议行动，并在及时性和沉默之间保持平衡。

• 通过优先级和明确的花花公子来降低MTTD/MTTR。
• 通过降噪减少警报失误（警报疲劳）。
• 直接从通知中给出动作（ack、snooze、runbook、自动辅助）。
• 遵守隐私和同意（opt-in/opt-out, log存储）。

2）事件分类和级别

2.1事件类型

度量/异常（SRE，产品，财务）。
业务规则（限制，限额，KYC，付款）。
系统（丢弃，退化，许可）。
定制（行为触发器，RG/负责任游戏）。

2.2个重要级别（Severity）

批评-立即反应，损失/安全风险。
High是KPI/SLO的显着恶化。
中部-需要在工作时间内采取行动。
Low/Info-观察/上下文,自动卷积到摘要中。

2.3优先级（优先级）

"Impact Urgency"矩阵 。绑定到通道和SLA反应。

3）体系结构和线程

事件信号制造商→ Shina →规范化（enrich，dedup）→相关性→规则（policy engine）→路由→交付渠道→偏好中心→ Logi/分析。

• Enricher：添加了tenant，角色，区域，对花花公子的引用。
• Deduper：按键分组重复事件。
• Correlator：将相关信号粘贴到事件中。
• 策略引擎：YAML/DSL规则,quiet hours,升级。
• 交付：应用内,电子邮件,推送,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）重复数据消除、相关性、阻止flapping

Dedup："dedup_key=hash（服务'metric' dim）"组标识符；TTL ≥翻转窗口。
相关性：按拓扑（servis→zavisimost）、时间（± N分钟）和上下文（发布、事件）组合相关信号。
Flapping： "N事件在M分钟内"阈值→一个"flapping detected"信号,建议提高滞后或超级压力。

6）路由和RACI

响应：谁收到第一个通知/tusk。
Accountable：谁在SLA之后升级。
咨询：谁在线程/聊天频道中提到。
Informed：谁将获得摘要/结果。
按角色和上下文分配（tenant、区域、产品流）。

7）送货渠道和细微差别

Retrai：5 x/429/taymaut → backoff+jitter；"Retry-After"尊重。等效性：网络包上的"X-Notification-Id"。

8）偏好中心（偏好中心）

Opt-in/Opt-out按事件类型、级别、通道。
沉默图（quiet hours）,手动snooze到15/30/60分钟。
阈值/灵敏度（例如≥ 3 σ异常）。
语言/地方，时间/货币格式。
绑定角色：SRE/Product/Finance的预设。
透明度：显示用户收到信号的原因（规则链接）。

9）内容设计： 信息结构

• 标题：简短,触发："［P1］ ［PSP_TR］ 3 DS故障急剧上升（+12%）"。
• 上下文：受影响的部分/区域周期,数据源。
• 原因/假设："与UTC PSP_X 18：20的发布有关。"
• SLA/截止日期："10分钟后升级。"
• CTA："打开花花公子"，"打开倒退PSP_Y"，"Ack（30分钟）"。
• 链接：图表，事件tred，度量，运行簿。
• 元数据：'trace_id'，'incident_id'，'dedup_key'。

语气：事实，没有戏剧化；数目和单位；避免缩写而不解密。
本地化：变量→播放器，翻译存储在资源中；数字/日期-按地区。

10）通知中的操作（Actionable）

Ack/Snooze具有时间设置。
Assign/Invite进入事件的线程。
运行手册：通过自动完成上下文打开解决方桉步骤。
单击remediation（安全）：切换路线、提高限制、重新启动joba（确认和审核）。
创建带有自动填充字段的tiket （Jira/GitHub）。

11）信号质量： 指标和目标

Precision（发件人中的相关比例）≥ P1/P2的80％。
Recall（在所有事件中发现的百分比）≥ 70％。
噪音：每个用户的平均信号/小时（目标天花板）。
Ack-time p50/p95，Escalation rate，Snooze rate（作为噪声指示器）。
MTTD/MTTA/MTTR（跨域和通道）。
Silenced-but-sould-alert（由于规则而通过）是单独的行车记录仪。

12）噪音管理： 技术

阈值的滞后和"滑动窗口"。
检测前的平滑化（EWMA）。
聚合：而不是30个小型-一个带有顶级补偿器的战斗/摘要。
上下文限制：最多N通知/小时/频道/用户。
自动反馈：如果用户连续3 ×单击Snooze →建议提高阈值/更改通道。

13）安全、隐私、合规性

Webhook的HMAC签名，秘密轮换，"X-Key-Id"。
RBAC/ABAC：按角色/隐性显示信号。
PII最小化，逻辑中的掩码，操作审核（ack/assign/runbook）。
同意（同意）和通知理由（规则/政策）-在付费中。

Retention/TTL通知日志,法律保留事件.

14）方案和薪水

事件（内部）

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模式

Inboxs： Critical/High/Other选项卡,数量徽章。
事件提要：相关信号，行动时间线，"做了什么"。
过滤器：角色，域，区域，时间，"仅无响应"。
列表中的快速操作（ack/snooze/assign）。
Explain："为什么你看到它"（规则，阈值，数据）。
摘要：早上/晚上，通过TZ本地化。

16）测试计划

单位： 滞后键,滞后,flapping,序列化付费.

整合：路由、安静时间、升级、链路转发。
E2E：P1情景从异常到滴答声关闭；P2在安静的时间→摘要。
溷乱：频道丢失（SMTP/SMS）、延迟、信号雪崩、时钟滑行。
A11y/i18n：屏幕阅读器，键盘ack/snooze，数字/日期本地化。

17）质量的Dashbords

Precision/Recall跨域。
Ack time p50/p95和及时确认的比例。
噪音每个用户/小时和顶级噪音规则。
逃逸率和"虚假升级"。
Suppressed vs Delivered（多少被抑制/混入摘要）。
用户反馈：/消息,噪音注释。

18）支票单

设计

• 事件分类法和级别一致
• quiet hours/升级策略描述
• dedup/相关/flapping设置
• Webhook的频道，retrai，等效性
• 偏好中心（opt-in/out, snooze）
• 内容模板和本地化
• 花花公子和点击动作（带审计）
• 质量指标和dashbords

运营

• 每季度一次阈值优化
• A/B规则（阈值、窗口、摘要）
• 定期评论"顶级噪音"和CAPA
• 频道机密轮换（HMAC，SMTP，SMS）
• 按计划进行警报测试（游戏日）

19）实施计划（3次迭代）

迭代1-基本轮廓（2-3周）

分类法，severity/priority，首选中心（in-app+email）。
Dedup，按键/时间简单相关性，quiet小时。
消息模板，花花公子，ack/snooze/assign。

迭代2-可靠性和降噪功能（3-4周）

Flapping/滞后，摘要，聊天集成和webhooks（HMAC，retrai）。
通过SLA，质量仪表板进行升级（precision/recall，noise）。
单击remediation（带确认和审计）。

迭代3-优化和缩放（连续）

拓扑/版本，阈值自动子句的相关性。
A/B规则，"阈值何时起作用"的预测。
噪音评论和常规比赛日。

20）迷你常见问题

如何对抗警报狂热？
Dedup，相关性，滞后性，摘要和偏好中心+定期噪声和A/B阈值评论。

ML是否需要异常?

有用，但从确定性规则和可解释的阈值开始。ML-作为上层建筑，必须与Explain一起使用。

为什么用户会收到"额外"信件?

检查规则匹配、安静时间、"为什么交付"审核、设置频道/小时限制和摘要。

底线

强大的信号系统是智能过滤和正确的优先级+单点击动作。正式化分类和政策、实施去除/相关/滞后、对用户进行控制（首选、快照）、提供可靠的交付和透明度"；为何我收到"；。然后，信号将成为控制工具而不是噪声源。