别只盯CPU了，好的监控告警得能讲出业务故事
3
0
0
0
凌晨三点，钉钉群炸了。一条告警写着：“订单服务节点 CPU 使用率突破 92%，持续 5 分钟。”运维切了流量，研发查了慢 SQL，产品还在睡觉。第二天复盘才发现，真正受影响的是“海外信用卡支付通道”，成功率掉了 8%，但没人第一时间把 CPU 飙升和掉单联系起来。
这就是典型的技术指标与业务健康度脱节。我们花大价钱上了 Prometheus、Grafana、ELK，屏幕上一片红绿，但跨部门沟通依然靠猜。告警如果只报“机器病了”，不报“业务伤了”，它就是噪音，不是资产。
为什么纯技术告警救不了协作效率？
- 认知壁垒：产品经理看转化率，研发看 QPS 和 GC 耗时，运维看磁盘 IO。同一场故障，三方语言不通。
- 响应错配：CPU 90% 可能只是定时任务跑批，而某个边缘接口的 500 错误却在悄悄流失高净值用户。
- 归因滞后：技术指标是结果，业务影响才是原因。等日志翻完，用户已经去竞品那里注册了。
把告警变成“业务翻译器”
有效的监控体系不是堆砌图表，而是建立一套技术指标 → 业务场景 → 决策动作的映射协议。SLI（服务等级指标）和 SLO（服务等级目标）不是 SRE 的专属黑话，它们是产品、研发、运维的共同语言。
| 技术指标（底层） | 业务场景映射 | 告警话术模板（翻译后） | 响应等级 |
|---|---|---|---|
| API P99 延迟 > 2s | 用户提交表单/支付 | “支付页加载延迟升高，预计影响转化率 3%-5%” | P1（立即） |
| DB 连接池耗尽 | 核心交易链路 | “订单创建成功率跌至 98.2%，触发降级策略” | P1（立即） |
| 消息队列积压 > 10w | 异步通知/对账 | “退款通知延迟超 15 分钟，客诉风险上升” | P2（30min内） |
| CDN 回源率突增 | 静态资源访问 | “首页图片加载变慢，首屏体验评分下降” | P3（2h内） |
告警文案必须包含三个要素：现象（发生了什么）+ 业务影响（谁受损/损多少）+ 建议动作（现在该干嘛）。去掉“请排查”，换成“建议切备用通道并同步客服话术”。
落地四步法：从埋点到协同 SOP
- 圈定核心链路：别全量监控。挑出直接影响营收或用户留存的前 20% 接口（登录、下单、支付、核心内容加载）。
- 定义业务 SLI：用用户视角重写指标。把
HTTP 200 率改成完整下单成功率，把接口耗时改成首屏可交互时间。 - 动态阈值替代死线：CPU 90% 在半夜可能是正常备份，但在晚高峰就是灾难。引入基线算法或同环比检测，按业务周期自动调整阈值。
- 建立告警路由与复盘机制：P1 告警直接拉群，附带预设的 Runbook（操作手册）。故障结束后 24 小时内输出 COE（Correction of Error），重点不是追责，而是更新 SLI 权重和告警规则。
避坑清单（血泪经验）
- ❌ 过度绑定：不是每个技术指标都要硬凑业务影响。底层中间件抖动如果未穿透到用户端，静默处理或降级告警级别即可。
- ❌ 数据延迟陷阱：业务指标依赖数仓或日志聚合，往往有 1-3 分钟延迟。告警系统必须标注“数据时效性”，避免基于过期数据做紧急决策。
- ❌ 告警风暴：一个底层故障引发上百条衍生告警。务必做事件收敛（Event Correlation），只保留根因告警，其余折叠为“关联事件”。
- ✅ 验收标准：上线新规则前，问自己三个问题：这条告警能否在 1 分钟内判断优先级？能否指导非技术角色采取行动？历史相似故障是否曾被它提前捕获？
监控从来不是给机器看的体检报告，而是给团队用的导航仪。当每条告警都能清晰回答“业务正在失去什么”和“我们现在该做什么”时，产品、研发、运维才能真正坐在同一张桌子前。少一点“CPU 红了”，多一点“支付通道受阻”，你的系统才真正具备韧性。