坑一：只看机器
CPU、内存、磁盘都正常，回答却全是兜底话术。为什么常见：基础设施监控是现成的，业务指标要单独埋点。改法：至少补三项业务指标——空回答比例、兜底触发比例、人工接管比例，并与基线对比设告警。
坑二：阈值照抄
直接套用模板阈值又没设持续时间，结果每天上百条通知，值班人很快麻木，真正的问题被埋掉。怎么改：先用一到两周基线确定波动区间，再按影响面分级，把必须叫人的告警压缩到少数几条。
坑三与坑四：无升级、无上下文
告警只发邮件，夜间无人看，也没有升级路径；通知里只有一句服务异常，没有链路标识、影响面与最近变更。两条叠加，等于把排查成本都转给被叫醒的人，恢复时间自然被拉长，怎么优化流程都补不回来。
坑五：从不演练
告警配置写完就再没验证过，真故障时才发现通知渠道失效、值班表过期、手册打不开。怎么改：每季度做一次故障注入，随机停掉一段依赖，记录告警到达时间与升级路径，再按结果修订配置。
别考核告警数量
把告警数量当成考核指标，会逼出两种坏行为：随手调高阈值与互相静默。做法：考核处置质量而非数量，看有效告警占比、响应时长与漏报情况；阈值调整要留记录与原因，静默必须设到期时间。真正该追的是漏报与长期无人处置的告警，而不是每晚响了多少次，也不是谁少报了几条。
适用与不适用
适合谁
- 告警噪音大、值班人麻木的团队与部门
- 刚上线缺少业务指标的应用与部门及其实施团队
- 需要向管理层证明监控有效与部门及其实施团队
不适合谁
- 单机部署、无用户感知的内部工具或演示原型
典型场景
某零售企业的门店助手在促销日出现大量空回答，监控面板全绿，直到门店反馈才发现模型调用被限流。排查确认只监控了服务器指标。团队随后补上兜底比例与限流错误两项告警，并把通知绑定到值班群与电话升级。
可执行步骤
- 盘点现有告警，标出只覆盖机器指标的部分并补业务指标，完成后归档。
- 用两周的基线数据重新设定阈值，并为每条告警补上持续时间条件。
- 按影响面重新分级，明确哪些走电话通知、哪些只进日报汇总，并同步值班人。
- 为每条告警补上下文：链路标识、影响面与最近一次变更，由责任人确认。
- 每季度做一次故障注入演练，验证通知渠道与升级路径，结果纳入验收。
常见坑
- 机器指标全绿而业务已经不可用，用户先发现故障，团队事后才知道发生了什么，信任上的损失更大。
- 告警风暴让值班人麻木，真正的一级告警被淹在几百条通知里没人处理，排查成本明显上升。
- 通知里没有链路标识与影响面，被叫醒的人要从头排查，恢复时间翻倍，责任边界难以界定。
自检与验收清单
- 是否监控空回答与兜底触发比例，并有书面确认
- 阈值是否基于自身基线而非模板默认值，并有记录
- 告警是否分级并绑定明确的升级路径，可现场抽查
- 通知是否包含链路标识与影响面，并有可核查的记录
- 是否每季度做故障注入演练，并在验收时逐项核对
常见问题
五个坑里哪个最先改？
先改通知上下文与升级路径。这两项不需要新埋点，改造成本低，却能立刻缩短恢复时间；业务指标与阈值调整需要数据积累，可以并行推进，但不要让它们拖住前两项。
业务指标怎么选？
从用户能感知的结果倒推：回答为空、被转人工、响应超时、明确报错。每一项都要能在面板上看到趋势，并能与版本变更对照；指标太多反而没人看，三到五项足够覆盖主要故障形态。
演练会不会影响生产？
先在测试环境做，生产环境只在低峰窗口并有人值守。演练前明确中止条件与回滚步骤，演练后把告警到达时间、通知对象与升级路径记录成表，作为下一轮配置调整的依据。