防止過量過剩

1）問題與目標

當系統發出過多的無關或不可操作的通知時，會發生警報。結果是忽略了分頁，MTTA/MTTR的增長以及錯過了實際事件。
目的：通過將信號綁在SLO和花花公子上，使信號稀有，有意義和可執行。

2）信號分類法（通道=後果）

Page（P0/P1）-喚醒人類；僅當現在需要手動操作並且有運行手冊時。
Ticket（P2）-每小時/每天的異步操作；不叫醒，但在SLA上徘徊。
僅達什（P3）-觀察/趨勢而沒有積極行動；不會產生噪音。
Silent Sentry-背景中的度量/審計（對於RCA/後驗屍程序）。

3）設計「正確」的同行

• 目的/假設（我們保護：SLO，安全，金錢，合規性）。
• 觸發條件（閾值，窗口，源法定人數）。
• Runbook/Playbook（簡短的ID步驟+鏈接）。
• 所有者（命令/角色組）。
• 完成標準（何時關閉，自動修復）。
• 漏洞類（user-impact/platform/security/cost）。

4）以SLO為中心的監控

SLI/SLO →主要信號：可用性，潛在性，業務運營成功率。

• 簡稱：1小時預算的5% → Page。
• 長：6小時預算的2% →門票。
• 隊列：按地區/提供商/VIP細分市場劃分的差額-減少虛假的全球焦慮。

5）降噪技術

1.探頭法定人數：只有在獨立源（不同區域/提供者）的≥2確認問題時才會觸發。
2.重復數據消除：分組相同的事件（aggregation keys： service+region+code）。
3.滯後/持續時間：「在紅色區域≥ N分鐘」以過濾尖峰。
4.限額：最多X警報/小時/服務；超過時-一個頁面+摘要。
5.Auto-snooze/智能抑制： T窗口中的重復警報 →轉換為Ticket直到根消除。
6.事件相關性：一個「主警報」而不是數十種癥狀（例如，「DB不可用」會幹擾來自微服務的5xx）。
7.窗口維護：計劃工作會自動抑制預期信號。
8.Anomaly+guardrails：異常-僅作為Ticket，除非通過SLO信號確認。

6）路由和優先事項

優先事項：P0（Page，15分鐘）、P1（Page，30分鐘）、P2（Ticket，4-8小時）、P3（觀察）。
路由快捷方式：service/env/region/tenant →對應的呼叫。
時間升級：5分鐘內沒有ack → P2 → Duty Manager/IC。
安靜的時光：非關鍵性的夜晚；Page禁止P2/P3。
Fatigue策略：如果工程師>N Page/Shift-重新分配到P2,則會升級信號汙染。

7） Alert質量： 安排

Actionability ≥ 80%：絕大多數分頁導致運行簿行動。
False Positive ≤ Page信號的5％。
Time-to-Fix-Alert ≤ 7天-必須修復/刪除有缺陷的警報。
Ownership 100%-每個警報都有所有者和存儲庫及其定義。

8）警報作為代碼的生命周期)

1.創建公關（目標說明、條件、運行簿、所有者、測試計劃）。
2.沙箱/影子：影子同行寫成聊天/日誌，但不寫成分頁。
3.金絲雀：受眾人數有限,我們測量FP/TP。
4.Prod：包含從rate-limit+觀察2-4周。
5.每周審查：質量指標，編輯/刪除。
6.Deprekate：如果信號復制更高或不可操作。

9）成熟度量（在dashboard上顯示）

按通話時鐘（中位數/95 percentile）。
%actionable（有已執行的步驟）和false-positive rate。
佩奇周圍的MTTA/MTTR和page→ticket比例（不得高）。
Top-talkers（產生噪音≥20％的服務/規則）。
要求時間到修復警報（從第一個FP到規則更改）。
Burn-rate coverage：在兩個窗口中使用SLO Alert的服務份額。

10）「Alerts的衛生」支票清單"

• Alert與SLO/SLI或商業/安全相關。
• 有運行簿和所有者；指定了戰爭室的聯系人和通道。
• 配置了兩個窗口（短/長）和源的法定數量。
• 包括dedup，rate-limit，auto-resolve和auto-snooze。
• 在發布/遷移時指定窗口維護和支持。
• 通過Shadow/Canary；由FP/TP測量。
• 包含有關差分質量指標的報告。

11）迷你模板

Alert規範（YAML想法）

yaml id: payments-slo-burn severity: P1 owner: team-payments@sre purpose: "Защитить SLO успеха платежей"
signal:
type: burn_rate sli: payment_success_ratio windows:
short: {duration: 1h, threshold: 5%}
long: {duration: 6h, threshold: 2%}
confirmations:
quorum:
- synthetic_probe: eu,us
- rum: conversion_funnel routing:
page: oncall-payments escalate_after: 5m controls:
dedup_key: "service=payments,region={{region}}"
rate_limit: "1/10m"
auto_snooze_after: "3 pages/1h"
runbook: "rb://payments/slo-burn"
maintenance:
suppress_when: [ "release:payments", "db_migration" ]

標準升級文本（用於減少噪音）

Импакт: падение success_ratio платежей в EU (-3.2% к SLO, 20 мин).
Диагностика: подтвержден кворумом (EU+US синтетика), RUM — рост отказов на 2 шаге.
Действия: переключили 30% трафика на PSP-B, включили degrade-UX, след. апдейт 20:30.

12）過程： 每周「警報評論」

1.最高噪音規則（top-talkers）→正確/刪除。

2.通過頁面信號的FP/TP →調整閾值/窗口/法定人數。

3.頻道降級的競爭者（Page→Ticket），反之亦然。

4.「Time-to-Fix-Alert」狀態-延遲升級到服務所有者。

5.檢查SLO的覆蓋範圍以及是否存在運行手冊。

13）與發行和運營的聯系

發布註釋會自動添加臨時抑制。
更改窗口：在發布後的前30分鐘,只有SLO信號。
花花公子包含「降級/抑制非官僚」的步驟，以專註於根。

14）安全和合規性

安全信號（黑客/泄漏/異常訪問）-單獨的通道，沒有安靜的時間。
所有壓制/安靜窗口的審核日誌：誰,何時,為什麼,截止日期。
關鍵警報的不變性要求（事件簽名）。

15）反模式

「每個圖形=alert」 →雪崩。
銷售中的閾值「！=0錯誤」。
一個探針/一個區域作為真理的來源。
沒有運行簿/所有者的頁面。
永恒的「臨時鎮壓」沒有最後期限。
「以後修補」有缺陷的Alertes-復制多年。
將發布噪音與生產事件混合。

16）實施路線圖（4-6周）

1.庫存：卸下所有的Alerta，放置所有者和渠道。
2.SLO內核：在關鍵服務中引入帶有雙窗口的burn-rate規則。
3.噪音控制：包括法定人數、滯後和限額,進行每周審查。
4.Runbook覆蓋範圍：用花花公子關閉100% Page信號。
5.Fatig policy：分頁/班次限制,安靜小時,負載重新分配。
6.自動化：警報即代碼，影子/金絲雀，質量指標報告。

17）結果

沈默不是缺乏監控，而是與SLO和過程相關的定性設計信號。法定人數，雙窗口，滯後和嚴格的路由使Alertes變得罕見，準確和可執行。團隊睡覺，用戶滿意，事件得到控制。