信號和通知系統

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一起使用。

為什麼用戶會收到「額外」信件?

檢查規則匹配、安靜時間、「為什麼交付」審核、設置頻道/小時限制和摘要。

底線

強大的信號系統是智能過濾和正確的優先級+單點擊動作。正式化分類和政策、實施去除/相關/滯後、對用戶進行控制（首選、快照）、提供可靠的交付和透明度"；為何我收到"；。然後，信號將成為控制工具而不是噪聲源。