31天内354条告警，87.9%自动恢复且无人处理。在下一次事故发生前，我们需要根治这个问题。
2026/04/25 - 2026/05/25 | 31天，354条告警
90.1%的告警被标记为'严重'，但只有2.5%真正需要人工响应。这导致工程师忽略所有'严重'告警，包括真正的紧急情况。
Top 4告警类型占据86.7%的噪音
| 告警内容 | 次数 | 自动恢复 | 处理 | 判定 |
|---|---|---|---|---|
| EIP 47.101.222.52 流入带宽 >=90% | 178 | 100% | None | Noise |
| ECI eci-uf6hw7ayo5h1wjaz0z0b 磁盘 >=90% | 60 | 100% | None | Noise |
| ECI eci-uf62jtm1h4r84twtsh4c 内存 >=90% | 27 | 100% | None | Noise |
| EIP 47.101.222.52 流出带宽 >=90% | 8 | 100% | None | Noise |
| 云监控配额不足提醒 | 8 | 0% | Planned | Info |
| WAF新增回源网段通知 | 6 | 0% | Planned | Info |
| RDS a-sha-prd-cdp-rds-1 CPU >=90% | 4 | 100% | None | Noise |
识别出三类噪音来源
告警触发后无人干预即自动恢复，说明阈值设置过于敏感。
产品升级公告、配额提醒、欠费通知等，并非真正的紧急事件。
同一资源反复触发同类告警，缺少去重和聚合机制。
带宽阈值设为>=90%，每次业务高峰都触发。EIP 47.101.222.52 平均每天触发5.7次，全部自动恢复。
容器/ECI环境的磁盘和CPU指标天然波动。一个ECI触发60次磁盘告警全部自动恢复，该指标对业务影响微乎其微。
告警在阈值被突破的单点瞬间触发。如果持续时间<5分钟就自动恢复，那只是瞬时峰值而非持续问题。
6大策略针对不同噪音来源
5分钟内自动恢复的告警直接降噪。7天内自动恢复>=3次的资源加入观察列表不再实时通知。
将邮件渠道告警（升级、配额、欠费）分流到独立'通知群'，不再与严重告警混在一起。
同一资源+同类告警15分钟内聚合为一条消息，显示触发次数和最新值。
带宽阈值从90%提升到95%，增加'持续时间>=3分钟'条件。可过滤99%的瞬时峰值。
维护窗口期间静默非关键告警。非工作时间延迟自动恢复类告警到次日工作时间。
建立P0/P1/P2/P3分级。P2级（自动恢复）改为每日摘要而非实时通知。
| 告警类型 | 当前分级 | 建议分级 | 理由 |
|---|---|---|---|
| Bandwidth >=90% | Critical | P2 | 100% auto-recovered, transient peaks |
| Disk >=90% | Critical | P2 | 95.5% auto-recovered |
| Memory >=90% | Critical | P2 | 90% auto-recovered |
| CPU >=90% | Critical | P2 | 100% auto-recovered |
| ALB Unhealthy >=1 | Critical | P1 | 66.7% auto-recovered but needs attention |
| Quota/Billing/Upgrade | Info | P3 | Notification only, not urgent |
从快速见效到长期治理的三阶段计划
自动恢复过滤
5分钟内自动恢复 -> 不发送通知
邮件渠道分流
将通知类告警移到独立'通知群'
Top3告警聚合
EIP带宽、ECI磁盘、ECI内存：15分钟内聚合
阈值调优
带宽90% -> 95%，增加持续时间>=3分钟
告警分级
建立P0/P1/P2/P3分级，P2改为每日摘要
维护窗口
配置维护窗口静默非关键告警
AIOps平台
考虑阿里云智能降噪或PagerDuty
月度告警Review
定期review告警模式和阈值有效性
告警疲劳KPI
将误报率作为SRE团队的考核指标
工程师关心的降噪问题
A：不会。数据显示311条自动恢复告警中没有任何人进行过处理。如果告警在5分钟内自动恢复，那只是瞬时峰值而非真正的问题。为了安全，我们只抑制同时满足两个条件的告警：(1) 5分钟内自动恢复，且 (2) 该资源7天内>=3次同类自动恢复。持续存在的问题仍然会触发不会自动恢复的告警。
A：EIP 47.101.222.52在31天内触发了178次带宽告警，全部自动恢复，平均每天5.7次。90%的阈值意味着正常业务高峰都会触发误报。提升到95%并加上3分钟持续时间条件，可以捕捉到持续的带宽问题，同时过滤掉瞬时峰值。如果95%经过监控后证明过高，可以再调整。
A：在CloudCare（或告警网关层）增加去重键 = 资源ID + 告警类型。在15分钟窗口期内，每个去重键只发送一次通知。通知内容包含：'该告警过去15分钟内触发X次，最新值Y%。' 如果15分钟内触发超过3次，则升级到团队负责人。
A：维护窗口静默只作用于P2/P3级告警（自动恢复类、资源使用率类）。P0/P1级告警（服务不可用、安全事件）永远不会被静默。这确保了真正的紧急情况始终会立即通知，而常规维护噪音被过滤。
A：每月跟踪以下KPI：(1) 月告警总量 - 目标<50条。(2) 自动恢复率 - 目标<30%。(3) 有效告警占比（需要人工处理的告警/总告警）- 目标>70%。(4) 真实事件的平均响应时间(MTTR) - 应该下降。(5) 工程师告警疲劳度调研 - 1-5分制，目标>4分。
A：最佳实践是在告警网关层实现（CloudCare和钉钉之间）。这样：(1) 所有告警仍会在CloudCare中记录供审计。(2) 抑制规则集中管理且可版本控制。(3) 不同团队可以有不同的路由规则。如果你的网关不支持，可以作为中间件服务实现：接收CloudCare webhook，应用过滤规则，再转发到钉钉。
模拟告警过滤过程
This alert fired 5 times in the last 15 minutes
First: 09:00, Latest: 09:15
Highest value: 93%
Current status: Auto-recovered