3. on-call 阈值策略基础：阈值定义、告警级别划分、静默与升级机制
on-call 阈值策略是 Runbook 自动化与值班体系之间的“信号翻译层”。没有合理的阈值，自动化要么沦为“告警风暴”的帮凶，要么因过度静默而错过真实故障。本章从三个核心维度展开：阈值定义（什么算异常）、告警级别划分（异常有多严重）、静默与升级机制（异常如何被响应）。
3.1 阈值定义：从原始指标到可触发动作的边界
阈值不是拍脑袋的数字，而是基于业务容忍度与系统容量基线的量化边界。常见的阈值定义方式包括：
| 定义方式 | 适用场景 | 典型示例 |
|---|---|---|
| 静态阈值 | 资源水位、硬件限制 | CPU 使用率 > 90% 持续 5 分钟 |
| 动态基线 | 周期性业务流量 | 请求延迟超过过去 7 天同时间段的 3 倍标准差 |
| 复合阈值 | 多指标联合判断 | 错误率 > 1% 且 P99 延迟 > 500ms |
| 预测阈值 | 容量规划、慢速增长 | 磁盘使用率预计在 24 小时内达到 95% |
实践要点：阈值定义必须包含“持续时间”维度。例如“CPU > 90% 持续 5 分钟”比“CPU > 90%”更能过滤瞬时毛刺。建议为每个阈值设置
for 或 duration 参数，避免 on-call 被抖动唤醒。
3.2 告警级别划分：P0–P4 分级模型
告警级别决定了响应速度、升级路径和自动化动作的激进程度。业界通用的五级模型如下：
| 级别 | 定义 | 响应 SLA | 典型触发条件 |
|---|---|---|---|
| P0 | 核心服务完全不可用，影响全部用户 | 5 分钟内确认，15 分钟内恢复 | 支付链路 100% 失败、数据库主库宕机 |
| P1 | 核心服务严重降级，影响大量用户 | 15 分钟内确认，1 小时内恢复 | API 错误率 > 5%、缓存集群大面积故障 |
| P2 | 非核心功能受损，或核心功能部分降级 | 1 小时内确认，4 小时内恢复 | 单个可用区实例异常、报表延迟超过 30 分钟 |
| P3 | 不影响用户，但需运维关注 | 下一个工作日处理 | 磁盘使用率 > 80%、证书即将过期 |
| P4 | 信息性通知，无需立即处理 | 记录即可 | 部署完成通知、例行健康检查通过 |
分级与自动化联动：P0/P1 告警应直接触发 Runbook 中的“紧急恢复”工作流（如自动切换流量、重启核心进程）；P2/P3 告警可触发“诊断收集”工作流，为值班人员提供上下文；P4 告警仅写入事件日志，不产生 on-call 通知。
3.3 静默机制：避免告警疲劳的“降噪层”
静默（Silence）不是简单地关闭告警，而是有策略地抑制已知、预期或重复的告警。常见的静默策略包括：
- 维护窗口静默：在计划内变更、升级、迁移期间，自动抑制相关组件的告警。静默规则应包含时间范围、目标标签和静默原因。
- 依赖静默：当上游服务故障时，自动抑制下游因“级联效应”产生的告警。例如数据库宕机时，抑制所有依赖该数据库的应用告警。
- 重复告警抑制：同一故障在短时间内多次触发时，只发送一次通知，后续告警进入“已抑制”状态，直到故障恢复或升级。
- 速率限制：对同一告警源，限制每分钟/每小时的最大通知次数，防止告警风暴淹没值班人员。
静默陷阱：过度静默可能导致真实故障被掩盖。建议为每个静默规则设置“最大静默时长”，超过时长后即使条件未变也强制解除静默，重新评估告警状态。同时，所有静默操作必须记录审计日志，便于事后复盘。
3.4 升级机制：当值班人员未响应时的“安”
升级（Escalation）确保告警不会因个人失联、处理超时或能力不足而被遗漏。一个健壮的升级机制包含以下要素：
| 升级层级 | 响应角色 | 触发条件 | 通知方式 |
|---|---|---|---|
| L1 | 初级值班工程师 | 告警触发 | 即时消息 + 电话 |
| L2 | 高级工程师 / 技术负责人 | L1 在 10 分钟内未确认 | 电话 + 短信 |
| L3 | 架构师 / 部门经理 | L2 在 20 分钟内未确认，或 P0 告警持续 30 分钟 | 电话 + 紧急广播 |
| L4 | 应急指挥中心 / 管理层 | P0 告警超过 1 小时未恢复 | 电话 + 邮件 + 管理层汇报 |
升级机制必须与 Runbook 自动化深度绑定：当告警升级时，Runbook 应自动执行更激进的恢复动作（如从“自动重试”升级为“自动切换流量”），同时将当前故障上下文（时间线、已执行动作、诊断数据）打包传递给下一级响应人。
3.5 阈值、静默与升级的融合流程
下图展示了从指标采集到告警升级的完整融合流程，其中 Runbook 自动化在每个决策点介入：
3.6 阈值策略与 Runbook 的“契约”设计
阈值策略不是孤立配置，它必须与 Runbook 自动化形成明确的“输入-输出”契约：
- 输入契约：Runbook 接收告警时，必须携带
severity（P0-P4）、silence_key（静默去重键）、escalation_level（当前升级层级）等元数据。这些字段由告警系统在阈值判定阶段填充。 - 输出契约：Runbook 执行完毕后，必须向告警系统返回执行状态（成功/失败/部分成功）、恢复时间、以及是否需要继续升级。例如，Runbook 自动重启服务后，若指标在 2 分钟内未恢复，应触发 L2 升级。
- 反馈闭环：Runbook 的执行结果应反向影响阈值。例如，若 Runbook 连续 3 次自动恢复成功，可考虑将对应告警的级别从 P1 降为 P2，减少人工介入频率。
关键指标：衡量阈值策略与 Runbook 融合效果的核心指标包括：MTTA（平均确认时间）、MTTR（平均恢复时间）、告警噪声比（有效告警 / 总告警）、升级率（需要升级的告警占比）。理想状态下，P0/P1 告警的升级率应低于 20%，告警噪声比应高于 70%。
3.7 实践案例：电商大促期间的阈值策略
以电商平台“双十一”大促为例，阈值策略需要动态调整：
| 指标 | 日常阈值 | 大促阈值 | 调整原因 |
|---|---|---|---|
| CPU 使用率 | > 90% 持续 5 分钟 → P2 | > 95% 持续 10 分钟 → P2 | 大促期间 CPU 高负载是预期行为，放宽阈值减少误报 |
| 订单错误率 | > 1% 持续 2 分钟 → P1 | > 0.5% 持续 1 分钟 → P0 | 大促期间订单错误影响巨大，收紧阈值并提升级别 |
| 支付超时 | > 500ms 持续 5 分钟 → P2 | > 300ms 持续 2 分钟 → P1 | 用户支付体验敏感，降低延迟容忍度 |
同时，大促期间启用批量静默规则：对“库存查询”等非核心链路的告警进行 24 小时静默，仅记录日志；对“支付网关”等核心链路的告警，将升级计时缩短 50%，确保故障在 2 分钟内被响应。
自动化联动：大促阈值切换可通过 Runbook 自动化完成。Runbook 接收“大促开始”事件后，自动更新告警系统的阈值配置、静默规则和升级策略；大促结束后，Runbook 自动回滚至日常配置，无需人工介入。