业务定不可接受
哪些业务结果不可接受、能容忍多久，必须由业务负责人定。技术团队只能定时延与错误率，无法判断一次空回答对门店意味着什么。为什么：缺这一方，告警级别会按技术直觉划分，重要的不叫，不重要的天天叫。
运维定指标值班
指标口径、采集方式、值班表与升级链由运维或站点可靠性岗位牵头。为什么：他们最清楚现有监控体系与人力边界，也承担被叫醒的后果；让不值班的人设计告警，很容易做出无人能执行的方案。
开发算法定降级
开发负责埋点与处置手册，算法或模型负责人定降级策略：模型超时切备用、置信度低转人工、检索为空时的兜底话术。边界：降级策略影响业务结果，需业务负责人确认后才可自动执行。
一线与安全补盲
客服与一线是最早感知异常的群体，应有一条把用户反馈转成告警的通道；安全团队则关心异常调用与越权访问类告警。为什么重要：两方常被忽略，结果是监控覆盖了机器，却没覆盖真实体验与攻击面。
升级由谁拍板
告警升级到哪一级、要不要停服或降级，最终由客户方值班负责人拍板。做法：约定三级升级路径与每一级的响应时限、可采取的动作上限，我方提供判断依据与建议方案，不替代客户方作业务决策；涉及对外停服、赔付或舆情处置的，由客户方按其内部流程上报，我方按指定动作执行并留记录。
适用与不适用
适合谁
- 多角色共用的企业 AI 应用与部门
- 已有告警但误报多的团队与部门及其实施团队
- 由多方协作交付运维的项目与部门及其实施团队
不适合谁
- 单人使用、无值班要求的工具或演示原型
典型场景
某物流企业的调度问答助手上线前，由业务定三类不可接受结果，运维定指标与值班表，开发写处置手册，算法定模型超时后的降级顺序，客服提供用户反馈入口。上线后第一次限流故障由客服工单先发现，促成了新的告警项。
可执行步骤
- 业务负责人列出不可接受的业务结果，并逐项给出可容忍的时长与判定口径。
- 运维确定指标口径、采集方式、值班表与升级链，记录执行人与时间。
- 开发编写埋点与逐条告警对应的处置手册，由责任人逐项核对后归档。
- 算法负责人确定模型超时与低置信度时的降级顺序，并写入配置项。
- 客服与安全各提供一条异常反馈通道并入告警体系，由责任人确认。
常见坑
- 只由技术团队定告警级别，业务上不可接受的结果没有对应告警，出事才补，事后难以补救。
- 让不值班的人设计通知策略，方案在纸面成立，夜里却没人能执行，事后追溯与定责都很困难。
- 降级策略由算法单方决定并自动执行，业务结果被悄悄改变，事后难以解释，追责时也无从谈起。
自检与验收清单
- 业务是否列出不可接受结果与容忍时长，并有记录
- 运维是否确定指标口径与值班升级链，可现场抽查
- 每条告警是否有对应的处置手册，并有书面确认
- 降级策略是否经业务负责人确认，并有可核查的记录
- 一线与安全是否各有反馈通道，并在验收时逐项核对
常见问题
业务负责人要参与多深？
参与两次即可：一次在上线前，确认哪些结果不可接受、各级告警叫谁；一次在上线后首月，复盘误报与漏报。不需要参与技术细节，但必须对级别划分签字，否则夜里叫人的规则没人认账。
算法负责人管什么？
管降级与恢复的判断逻辑：什么条件下切备用模型、什么条件下转人工、恢复后如何回切。这些策略会改变业务结果，所以要写成可评审的规则，而不是藏在代码里的分支，改一次要有人复核。
客服的反馈怎么进告警？
设一条轻量通道即可：把重复出现的用户投诉按类型汇总，超过阈值就触发人工核查。关键是有固定入口与责任人，不要让反馈散落在聊天记录里，否则永远进不了监控体系。