Appearance
企业SLA与值班体系专题
版本：
v1.4最后更新：
2026-07-09适用对象：正在建设企业 AI 生产运行体系、设计 SLO / SLA、组织 on-call、定义值班分层与告警升级路径，以及需要把“服务承诺、告警响应、人工接管和恢复责任”真正落实到团队机制里的产品、平台、SRE 与管理同学
AI 系统只要进入企业场景，团队迟早会碰到一个现实问题：
- 服务不是“有人看着就行”
- 而是要承诺可用性、响应时效和恢复责任
这时候就需要把：
- SLA
- SLO
- 告警
- 值班
- Runbook
- 升级链
真正接起来。
这篇专题的重点不是解释 SLA 这个缩写，而是说明：
- AI 系统的服务承诺为什么必须把质量、风险和人工接管一起纳入
根据 2026-07-09 可访问的 Google SRE On-Call / Alerting on SLOs / Incident Response / Implementing SLOs、OpenAI Production best practices / Safety best practices、以及 Anthropic 关于高风险工具与人工确认的资料，一个更贴近现实的共识是：
AI 系统的运行承诺不只包括“接口活着”，还包括“关键行为是否稳定、异常是否能被及时发现、人工接管是否能在承诺时间内完成”。
1. AI 系统里的 SLA 为什么不该只写 uptime
传统系统里，SLA 常常首先围绕：
- 可用性百分比
- 响应时间
- 恢复时间
但 AI 系统仅写这些通常是不够的，因为“服务活着”不代表：
- 结果可靠
- 权限正确
- 审批有效
- 风险可控
企业 AI 服务更适合同时考虑：
- 可用性
- 关键质量稳定性
- 告警与响应时效
- 人工接管时效
- 高风险链路恢复能力
2. 更实用地理解 SLA、SLO 和告警的关系
更适合工程落地的理解通常是：
SLA：对业务和用户的承诺SLO：内部运行目标Alerting：当偏离目标时触发行动
也就是说：
- 没有可观测的 SLO，SLA 很容易沦为口号
- 没有可行动的告警，值班体系很快会失效
Google SRE 当前关于 Alerting on SLOs 和 On-call 的资料都在强调：
- 告警应该可行动
- 告警应该尽量围绕用户影响
这对 AI 系统尤其重要。
3. 为什么 AI 系统的 SLA 更复杂
因为 AI 系统的异常不只是一种：
- 服务挂了
还可能是：
- 模型响应变慢
- 检索质量失真
- 工具链局部故障
- 审批链积压
- 人工接管量暴增
- 成本暴涨触发限流
- guardrails 误拦或漏拦
也就是说，AI 系统的运行承诺往往同时覆盖：
- 可用性
- 质量稳定性
- 风险控制能力
4. 哪些能力最适合优先写进 SLA / SLO
建议优先从关键链路开始，不要一开始追求全覆盖。
更值得优先明确的通常包括：
- 核心问答 / 推理服务可用性
- 检索服务延迟和成功率
- 高风险审批链可用性
- 人工接管响应时效
- 长任务完成时效
- 关键工具链恢复时效
对高风险企业场景，还经常值得额外明确：
- 审批积压上限
- 误放行与误拦截风险目标
5. AI 场景里更值得定义的运行目标
5.1 可用性目标
- 服务可用率
- 核心工作流完成率
5.2 延迟目标
- P95 / P99 响应时间
- 检索阶段延迟
- 工具调用延迟
- 审批等待时长
5.3 质量目标
- 高频场景通过率
- 引用正确率
- 空检索率
5.4 风险目标
- 高风险样例漏放率
- 权限误召回率
- 审批遗漏率
5.5 运营目标
- 人工接管响应时长
- 值班确认时长
- 事故恢复时长
如果这些完全没有量化，值班体系就很难知道到底什么时候该行动。
5.6 Error budget 最好和 AI 发布节奏绑在一起
Google SRE 当前 Implementing SLOs 与 Alerting on SLOs 的核心心智里，一个非常值得借鉴的点是：
- SLO 不只是看板指标
- 它还应该反过来约束发布节奏
放到 AI 系统里，更稳的做法通常是：
- 先定义核心链路的 error budget
- 再决定模型升级、Prompt 迭代、检索切换和工具放量是否还能继续
例如当下面这些问题持续消耗 budget 时：
- 核心问答完成率下降
- 人工接管超时
- 审批积压持续上升
- 高风险漏放接近红线
更合理的动作往往不是继续追发新版本，而是：
- 暂停高风险变更
- 冻结 Prompt 和路由策略
- 先修复当前生产问题
这样 SLA / SLO 才不只是“看起来很专业的承诺”，而是真正进入了发布治理。
6. 值班体系真正解决的不是排班，而是责任闭环
值班体系的目标不只是：
- 晚上有人在
更是确保：
- 问题有人发现
- 告警有人响应
- 升级有人拍板
- 故障有人收口
没有值班体系，再好的告警也可能只是：
- 静静地响着
而没有人做有效动作。
7. 更可执行的值班分层应该怎么拆
很多团队更适合按职责分层，而不是所有问题都压给同一批人。
7.1 一线值班
负责：
- 看告警
- 做初步分流
- 执行标准 runbook
7.2 二线支持
负责：
- 处理模型、检索、工具链、工作流等复杂问题
- 判断是否需要降级、切流、回滚或暂停高风险功能
7.3 决策 owner
负责：
- 做关键业务与安全决策
- 决定是否触发对外沟通、业务升级、人工接管扩容
这种分层能显著降低：
- 一线值班在高压下无法拍板
- 所有问题都直接压到少数核心同学身上
8. 为什么值班体系必须和告警分级一起设计
Google SRE 当前关于 Incident Response 与 Alerting on SLOs 的实践非常明确：
- 告警要可行动
- 告警要和用户影响关联
- 告警不应该淹没值班人
如果没有分级，最常见结果是：
- 小问题打扰所有人
- 大问题反而没人快速拍板
更实用的做法通常是：
- 按影响面分级
- 按级别决定通知范围
- 按级别决定升级路径
8.1 burn rate 告警通常比固定阈值更适合做 page 决策
Google SRE 当前 Alerting on SLOs 的实践非常强调：
- 告警应围绕 error budget burn rate 设计
这对 AI 系统尤其有用，因为很多 AI 异常并不是：
- 某个单点指标瞬间暴涨
而是：
- 一段时间里持续慢性退化
例如：
- 空检索率持续走高
- 审批积压持续扩大
- 工具成功率缓慢下降
- 人工接管量连续增加
如果只看固定阈值，很容易出现：
- 小退化长期没人理
- 或者轻微波动把值班人反复叫醒
更稳的做法通常是：
- 用 burn rate 决定是否 page
- 用趋势窗口决定是否升级
8.2 page、ticket、dashboard 三层信号最好分开
很多团队告警噪声大的根源，不是指标太多，而是：
- 所有异常都走同一个通知通道
更稳的做法通常会把信号分成三层：
page需要立刻叫醒或立即接手的问题。ticket需要尽快处理，但不值得立即打断值班人的问题。dashboard / watch需要观察趋势、辅助判断，但本身不该触发强通知。
放到 AI 系统里，通常更适合 page 的是：
- 核心工作流不可用
- 高风险动作漏拦
- 审批链完全阻塞
- 人工接管无法接入
更适合 ticket 的是：
- 某个非核心桶质量下降
- 成本异常但未超红线
- 某个长任务 lane 排队上升
这样值班体系才不会被“所有问题都很重要”的幻觉拖垮。
9. AI on-call 到底该盯哪些信号
除了基础可用性，AI 值班更建议重点看：
- P95 / P99 延迟
- 检索空结果率
- 引用错误率
- guardrail 命中异常
- 审批积压时长
- 人工接管次数
- 单任务成本异常
- 长任务失败或排队积压
如果只盯：
- 接口是不是 200
很多 AI 故障会被误判成：
- “服务正常”
10. 为什么 AI 系统的 Runbook 比很多传统系统更关键
因为 AI 故障往往不是一个维度，而是跨层问题。
例如：
- 模型没挂，但回答质量断崖下降
- 工具还能调，但参数结构错了
- 检索还能查，但引用全偏了
- 人工接管流程还在，但积压已不可控
这类问题如果没有清晰的 runbook，很容易出现：
- 大家都知道不对
- 但没人知道先做哪一步
11. 一份 AI on-call runbook 最少应该写什么
建议至少包含：
- 触发信号
- 影响判断
- 对应级别
- 可执行止损动作
- 升级路径
- 回滚条件
- 恢复验证动作
其中最关键的是：
- 止损动作必须真实可执行，而不是写原则
11.1 runbook 最好显式区分“立即止血动作”和“根因修复动作”
很多 runbook 写得很长，但在事故现场并不好用，原因通常是：
- 值班人分不清第一步该做什么
更稳的写法通常会先分两层：
stabilize now先止血、降级、切流、暂停高风险动作、扩容人工接管。repair root cause再去定位模型、Prompt、检索、工具、审批链或数据面问题。
这样做的价值很大，因为 AI 故障现场最需要优先回答的往往是：
- 先把用户影响压住
而不是：
- 先把所有根因都找全
12. 为什么人工接管时效也应该进入 SLA / SLO
很多企业 AI 场景一旦自动链路失控，最终还是要靠人工接管。
如果人工接管没有明确时效目标，就会出现：
- 自动化失效了
- 但人工接手依旧过慢
这会让“有人工兜底”变成一种错觉。
所以对高风险场景，值得明确：
- 首次人工响应时长
- 人工完成接管时长
- 接管后恢复稳定时长
13. 为什么审批链积压本身就是运行风险
很多团队只把审批看成业务流程，不把它当运行指标。
但在 AI 系统里，审批积压通常意味着：
- 高风险动作堆积
- 人工判断能力透支
- 用户体验与业务处理时效下降
因此对审批型系统，建议单独跟踪：
- 审批等待中位时长
- 审批积压数量
- 超时升级比例
14. 为什么成本异常也要进入 on-call 视角
AI 系统的成本问题常常不是月底财务问题，而是实时运行风险。
例如：
- 模型路由异常导致成本飙升
- 推理长度失控
- 长任务重试风暴
- 检索 top-k 过大拖高整体链路成本
如果不把成本异常纳入运行观测，系统可能：
- 功能没挂
- 但已经不可持续
15. 一种更可执行的告警分层方式
可以用一个简单的分层：
15.1 页面级告警
适合：
- 大面积不可用
- 高风险动作误放
- 核心链路超时
15.2 工单级告警
适合：
- 持续退化
- 审批积压
- 成本异常
- 特定租户或场景异常
15.3 观察级信号
适合：
- 轻微漂移
- 样例分布变化
- 需要后续 review 的异常趋势
这样值班人不至于被所有波动都叫醒。
15.4 AI on-call 最好额外补一层“人工接管压力信号”
很多传统系统告警分层里不会特别强调这个维度，但 AI 系统里很值得单独看：
- 人工接管队列长度
- 人工接管平均等待时长
- 单位时间内升级给人工的比例
- 某一类风险动作的人工确认量
因为很多 AI 故障在表面上看，服务还活着，但真实用户体验已经在恶化：
- 模型没挂
- 接口没挂
- 但人工兜底已经快扛不住
如果这类信号不进入值班分层，团队很容易直到人工侧已经爆仓才意识到问题。
16. 为什么值班体系要和故障演练绑定
很多团队的 on-call 机制在真实事故里会暴露问题，原因不是排班没排，而是：
- runbook 没演过
- 升级链没走过
- 回滚权限没人真用过
所以值班体系如果不做演练，通常只是：
- 写在表上的制度
而不是可执行机制。
16.1 incident command 角色最好预先定义，而不是事故里现组
Google SRE 当前 Incident Response 的实践里，一个非常稳的做法是把指挥角色显式化。
放到 AI 系统里，很多事故更适合预先定义至少这几类角色：
- incident commander
- communications owner
- technical lead
- business / risk approver
因为 AI 事故往往跨多层：
- 模型与 Prompt
- 检索与工具
- guardrails 与审批
- 业务风险与对外沟通
如果这些角色不提前约定，事故里最常见的情况就是：
- 大家都在干活
- 但没人真正负责定优先级和做最终决策
17. 为什么 SLO 最好围绕用户影响设计
Google SRE 当前关于 SLO 的方法强调：
- 指标应该尽量映射用户体验和服务结果
放到 AI 系统里，这意味着别只看：
- CPU、QPS、HTTP 200
更该看：
- 核心任务完成率
- 关键问答质量
- 风险漏放
- 人工接管是否及时
18. 一个适合企业 AI 的最小 SLA / 值班方案
如果团队现在运行体系还比较早期，建议至少先做到下面这些事：
- 为核心链路定义 3 到 5 个 SLO。
- 建一线 / 二线 / 决策 owner 的值班分层。
- 给高风险功能定义人工接管与回滚时限。
- 把审批积压、guardrail 异常、成本异常纳入运行观测。
- 至少做一次值班 + 回滚 + 演练联动验证。
19. 常见反模式
- SLA 只写 uptime，不写质量与风险
- 只做排班，不做 runbook
- 告警很多，但没有一个是可行动的
- 审批积压长期存在却没人当事故看
- 值班人看到问题，但没有权限降级或回滚
- 有人工兜底，但没有承诺人工接管时效
- 所有异常都 page，结果真正的大问题被告警噪声淹没
- 只设 SLO，不把 error budget 用到变更冻结和发布节奏里
- 只管模型接口，不看人工接管侧是否已经过载
20. 推荐搭配阅读
21. 重点官方资源
以下资源已按 2026-07-09 复核到当前正式入口；其中少数站点对脚本探测可能受限，但浏览器入口仍可正常打开：
- What it Means Being On-Call?
- Prometheus Alerting: Turn SLOs into Alerts
- Implementing SLOs
- Incident Response
- Production best practices
- Safety best practices
- Computer use tool - Claude Platform Docs
22. 落地检查清单
- 是否把质量、风险和人工接管一并纳入服务承诺
- 是否为一线、二线、决策 owner 定义了明确职责
- 是否让告警围绕用户影响和可行动性设计
- 是否把审批积压、guardrail 异常和成本异常纳入值班视角
- 是否能在值班现场真实执行降级、回滚和人工接管