先画关键链路
把一次真实请求拆成网关、检索、模型调用、后处理与存储几段，每段标出依赖与超时。为什么先画链路：告警要能定位到具体环节，只报系统不可用，值班人还要从头排查，故障时长会被拉长，影响面也跟着扩大。
业务结果也要盯
除机器指标，还要看业务结果：回答是否为空、是否大量回落兜底话术、转人工比例是否异常。为什么：机器一切正常而答案全是兜底，是最容易漏掉的故障形态，用户已经在投诉，监控面板却一片绿色。
分级与阈值
按影响面分级，明确哪些告警打电话、哪些进群、哪些只进日报；阈值要结合持续时间，避免瞬时抖动触发。怎么做：先用一到两周的基线数据确定正常波动区间，再设阈值，比照抄默认值可靠得多。
通知与处置手册
每条告警都要绑定处置手册：看哪个面板、查哪段日志、先做哪一步、找谁升级。为什么重要：凌晨被叫醒的人往往不是系统作者，没有手册只能凭经验试错；通知里带链路标识与影响面，能省掉一半沟通时间。
每条告警有主人
没有归属人的告警，最终会变成谁都不看的群消息。做法：规则表里每条告警都要写明业务归属人与技术处置人，附值班表与升级顺序；上线前逐条确认，找不到归属人的规则直接删掉或合并，宁少勿滥。人员变动时同步更新归属，避免接手的人收到自己不认识的告警而误判。
适用与不适用
适合谁
- 准备上线的 AI 应用与部门及其实施团队
- 已有监控但告警噪音大的团队与部门
- 承担值班职责的运维与开发与部门及其实施团队
不适合谁
- 纯离线、无对外服务的内部脚本或演示原型
典型场景
某银行的知识问答助手上线前，团队画出五段关键链路，为每段设置时延与错误率指标，并补上回答为空与兜底比例两项业务指标。告警分三级，一级直接电话通知，每条告警关联一页处置手册。上线首周一次检索超时被提前发现。
可执行步骤
- 画出一次请求经过的所有环节，标注依赖、超时与失败时的表现，完成后归档。
- 为每个环节选定指标，并补上回答为空、兜底比例等业务结果类指标。
- 按影响面分级，结合持续时间设定阈值，避免瞬时抖动带来的误报。
- 配置通知路由与值班表，每条告警绑定一页可执行的处置手册，由责任人确认。
- 每季度做一次故障注入演练，检验告警是否按时到达并升级，结果纳入验收。
常见坑
- 只监控服务器 CPU 与内存，业务已经无法回答，面板仍是绿色，用户先发现故障，事后难以补救。
- 阈值照抄默认值又没设持续时间，告警风暴每天上百条，值班人很快麻木，真故障时反而没人响应。
- 告警只有邮件没有升级路径，夜间无人响应，第二天上班才发现故障仍在持续，返工成本会上升。
自检与验收清单
- 是否画出关键链路并标注依赖与超时，可现场抽查
- 是否监控业务结果而非只监控机器指标，并有记录
- 告警是否分级并绑定明确的通知对象，可逐项核对
- 每条告警是否关联可执行的处置手册，并有书面确认
- 是否定期做故障注入演练并记录结果，并有验收记录
常见问题
告警太多怎么办？
先合并再删。同一根因引发的多条告警应聚合为一条，保留影响面最大的那条；长期无人处理又无后果的告警直接下线。目标是每条告警都有人会为它起身处理，而不是数量多显得监控严密。
要不要做自动处置？
可以，但要限幅并留人工确认。自动扩容、自动切模型这类动作影响面大，应先以只记录不执行的方式跑一段时间，确认判断准确后再开启，并设置单次与累计上限，随时可关。
小系统也需要值班吗？
至少要有明确的响应人和响应时间。没有全天值守，就把告警分级，只对影响业务的一级告警设置电话通知，其余进群或日报；关键是有人认领，而不是制度写得很全却没人看。