静默为什么要审计
静默是临时关掉通知的手段，用久了就会变成盲区。治理的核心是让每条静默都有账可查：创建人、原因说明、到期时间三要素齐全，定期导出活动静默逐条核对，把无主的长期静默限期整改，把变更类静默与变更单对账。
导出与核对
导出与核对
# 活动静默数量
amtool silence query --alertmanager.url=http://127.0.0.1:9093 --output=json | jq 'length'
# 列表核对：创建人 / 说明 / 到期时间
amtool silence query --alertmanager.url=http://127.0.0.1:9093 --output=json \
| jq -r '.[] | [.createdBy, .comment, .endsAt] | @tsv'
# 找出没有填写说明的静默
amtool silence query --alertmanager.url=http://127.0.0.1:9093 --output=json \
| jq -r '.[] | select(.comment == "" or .comment == null) | .id'健康检查项
| 检查项 | 合格标准 | 不合格后果 |
|---|---|---|
| 是否有说明 | comment 写清原因与关联变更单 | 事后没人敢撤销，只能一直留着 |
| 是否有主 | createdBy 可追溯到人或自动化系统 | 无主静默到期无人续期也无人撤销 |
| 到期时间 | 与实际维护窗口匹配，通常不超过数小时 | 设成一年等于长期盲区 |
| 覆盖范围 | matchers 精确到服务或实例 | 范围过大把无关告警一起压掉 |
长期静默要转为显式的接受风险条目，记录负责人与复查日期，而不是无限续期；每次续期都应视为一次重新决策。
审计与整改路径
- 每月导出活动静默清单，按创建人分组发给对应团队确认是否仍需要
- 无说明的静默限期补注释，逾期未补的一律撤销，先让告警恢复可见
- 超过一个维护周期的静默逐条复核，能靠改阈值或修报警噪音解决的优先改规则
- 被压制的告警在窗口结束后逐条核对影响，确认窗口内没有真实故障
- 把静默数量与时长纳入值班周报，趋势上升时专项排查创建来源
- 静默审批写进变更规范，谁批准谁负责，避免随手静默后无人担责
自动化脚本创建的静默也要带上可识别的注释与来源标记，否则审计时无法区分人为操作与流水线行为。