指标依赖埋点
没有埋点就没有指标，告警阈值也无从谈起。怎么做：把指标埋点与功能开发放在同一批任务里，联调时验证指标能取到数；上线后再补埋点，等于让系统在无监控状态下运行一段时间，风险最高。
通知渠道提前开通
短信、电话与即时消息的通知渠道通常要客户方申请账号与白名单，属于外部依赖。为什么容易卡：审批与开通需要时间，测试时又常被忽略；上线前一天才发现电话通知发不出去，告警等于没有。
阈值需要基线
阈值要覆盖一个完整业务周期才有意义，包含周末与月末的高峰低谷。怎么做：先以观察模式运行两到四周，记录分位数与波动区间，再设定阈值与持续时间，比照抄默认值可靠得多。
演练窗口要审批
故障注入演练要申请窗口，生产环境还需值守与回滚预案。怎么排：先在测试环境演练通知链路，再在低峰窗口做一次生产演练；窗口与影响范围由客户方批准，演练前明确中止条件。
值班人力要预留
告警上线不等于有人值班，人力与培训往往是最晚到位的一环。做法：排期时把值班表、通知账号开通与两次值班培训写成客户方待办，提前两周启动；培训覆盖告警含义、处置手册位置与升级路径，培训后做一次模拟处置确认能走通。人力未到位的，先只开启日报级告警，避免夜间无人响应。
适用与不适用
适合谁
- 准备上线监控的 AI 应用与部门
- 通知渠道尚未开通的项目与部门及其实施团队
- 需要向管理层解释监控工期的负责人
不适合谁
- 无用户感知、无需通知的内部脚本或演示原型
典型场景
某制造企业的设备知识助手计划四周上线监控。第一周随功能补指标埋点，第二周申请短信与电话通知账号，第三至四周以观察模式收集基线，第五周设阈值并做一次低峰演练。通知账号审批慢了一周，是主要影响告警上线的依赖。
可执行步骤
- 随功能开发同步完成指标埋点，并在联调时验证可取数，完成后归档。
- 提前申请短信、电话与即时消息的通知账号，并完成对应的白名单配置。
- 以观察模式运行两到四周，收集分位数与波动区间，作为阈值基线数据。
- 基于基线设定阈值与持续时间，并按影响面完成分级，由责任人确认。
- 在获批的低峰窗口做一次故障注入演练，记录告警到达的时间与对象。
常见坑
- 上线前才补指标埋点，系统在无监控状态下运行，第一批故障只能靠用户反馈，事后难以补救。
- 通知渠道审批滞后，告警配置齐全却发不出去，一级故障夜里无人知晓，排查成本明显上升。
- 阈值照模板直接设，上线首周全是误报，值班人很快开始忽略通知，事后追溯与定责都很困难。
自检与验收清单
- 指标埋点是否与功能开发同批完成，并有书面确认
- 通知账号与白名单是否提前申请，并有可核查的记录
- 是否以观察模式收集过完整周期基线，可现场抽查
- 阈值是否结合持续时间设定，并在验收时逐项核对
- 演练窗口是否提前获批，并留存完整的验收记录
常见问题
观察期能不能省？
不建议省。没有基线就只能猜阈值，误报与漏报同时增加，值班人的信任很快耗尽。两到四周的观察期成本不高，却能换来相对可靠的阈值；业务波动大的场景还应覆盖月末或大促等特殊时段。
通知渠道为什么难批？
往往涉及运营商短信签名、电话外呼白名单与企业账号权限，需要走行政与采购流程。规避方式是启动会上就把渠道需求列成清单，指定客户方对接人，每周同步进度，而不是等到快上线才提。
阈值之后还会改吗？
会，而且应该改。业务量变化、模型版本更新、依赖调整都会改变正常区间；建议每季度复核一次阈值与分级，修改留记录并同步给值班人，避免有人按旧规则判断新告警。