3. 告警确认流程设计：手动确认、自动确认、半自动确认、确认超时与升级策略
告警确认是 On-Call 值班流程中承上启下的关键环节。确认动作不仅代表“有人看到了”，更意味着“有人正在处理”。设计不当的确认流程会导致告警被反复确认却无人真正跟进，或确认超时后仍无升级动作，最终引发故障响应延迟。
本章围绕四种确认模式（手动、自动、半自动、确认超时与升级）展开，重点分析每种模式的适用场景、实现要点及阈值调优的关联策略。
3.1 四种确认模式对比
| 确认模式 | 触发条件 | 响应时效 | 适用场景 | 风险等级 |
|---|---|---|---|---|
| 手动确认 | 值班人员通过 UI/API 主动点击确认 | 秒级～分钟级（依赖人） | 高优先级告警、需人工研判的复杂故障 | 低（确认即承诺） |
| 自动确认 | 告警匹配预设规则（如恢复、抑制、重复） | 毫秒级～秒级 | 已知模式、自动化恢复、低优先级告警 | 中（可能掩盖真实问题） |
| 半自动确认 | 系统自动确认 + 人工二次确认窗口 | 秒级 + 人工窗口（如 5 分钟） | 中优先级告警、需快速响应但保留人工复核 | 低～中 |
| 确认超时与升级 | 确认窗口内无人确认或自动确认失败 | 按策略阶梯升级（如 5min→10min→15min） | 所有未确认告警的兜底机制 | 高（必须触发） |
实践建议： 不要对所有告警使用同一种确认模式。建议按告警优先级（P0～P4）分别配置确认策略，P0 强制手动确认 + 短超时升级，P3/P4 可优先使用自动确认。
3.2 手动确认流程设计
手动确认是最传统也最可靠的确认方式。核心流程如下：
- 告警触发 → 通知发送至值班人（电话/短信/IM）。
- 值班人查看 → 打开告警详情页，确认告警内容、影响范围、关联指标。
- 执行确认 → 点击“确认”按钮，系统记录确认人、确认时间、确认备注。
- 状态变更 → 告警状态从
firing变为acknowledged，停止重复通知。 - 处理中 → 值班人开始排查，可关联事件、创建工单、执行预案。
关键阈值参数：
ack_timeout：手动确认超时时间（如 5 分钟），超时未确认则触发升级。max_ack_count：同一告警允许的最大确认次数（防止反复确认不处理）。ack_required_role：确认人角色限制（如仅 SRE 可确认 P0 告警）。
3.3 自动确认流程设计
自动确认用于减少人工干预，适用于已知模式或自动化恢复场景。常见触发条件：
- 恢复确认：告警指标恢复至阈值以下，系统自动确认并关闭告警。
- 抑制确认：告警被更高优先级告警抑制，自动确认以避免重复通知。
- 重复确认：相同告警在短时间内重复触发，自动确认历史告警。
- 自动化动作确认：告警触发后自动执行恢复脚本，脚本成功则自动确认。
# 自动确认规则示例（YAML 格式）
auto_ack_rules:
- name: "恢复自动确认"
condition: "alert.status == 'resolved'"
action: "auto_ack"
ttl: 60s
- name: "抑制自动确认"
condition: "alert.severity <= 'P2' AND alert.inhibited_by != ''"
action: "auto_ack"
ttl: 0s
- name: "自动化恢复确认"
condition: "alert.runbook_execution.status == 'success'"
action: "auto_ack"
ttl: 30s
风险提示： 自动确认可能掩盖真实问题。建议对自动确认的告警设置“自动确认后观察期”（如 15 分钟），观察期内指标再次异常则自动升级为手动确认。
3.4 半自动确认流程设计
半自动确认是手动与自动的折中方案：系统先自动确认告警，停止重复通知，同时开启一个人工确认窗口。窗口期内值班人可复核并决定是否转为手动确认或关闭告警。
典型流程：
- 告警触发 → 系统自动确认（状态变为
auto_acknowledged）。 - 通知发送至值班人（仅一次，不重复）。
- 值班人收到通知后，在窗口期（如 5 分钟）内查看告警。
- 若值班人手动确认 → 状态变为
acknowledged，进入正常处理流程。 - 若窗口期结束无人操作 → 状态自动转为
acknowledged，但标记为auto_ack_expired，触发轻度升级（如通知值班组长）。
适用场景：
- P2/P3 告警，需要快速停止通知但保留人工复核能力。
- 夜间告警，自动确认可避免频繁打扰，但白天需人工确认。
- 已知模式告警（如例行抖动），自动确认后人工确认即可关闭。
3.5 确认超时与升级策略
确认超时是告警确认流程的最后一道防线。当告警在指定时间内未被确认（无论手动还是自动），系统必须执行升级策略，确保告警不被遗漏。
升级策略通常采用阶梯式设计：
| 阶梯 | 超时时间 | 升级动作 | 通知对象 |
|---|---|---|---|
| L1 | 5 分钟 | 重复通知当前值班人（升级通知频率） | 当前值班人 |
| L2 | 10 分钟 | 通知值班组长 / 备份值班人 | 值班组长 + 备份值班人 |
| L3 | 15 分钟 | 通知 SRE 团队负责人 + 创建紧急工单 | 团队负责人 + 工单系统 |
| L4 | 30 分钟 | 通知部门负责人 + 触发 War Room | 部门负责人 + War Room 流程 |
调优建议： 升级时间应与告警严重程度联动。P0 告警的 L1 超时可缩短至 2 分钟，L4 超时可缩短至 15 分钟；P3 告警的 L1 超时可延长至 15 分钟，甚至不配置升级。
3.6 确认流程与阈值策略的联动
确认流程不是孤立的，它与阈值策略存在双向影响：
- 阈值灵敏度影响确认频率：阈值越敏感，告警越多，手动确认压力越大。此时应增加自动确认比例。
- 确认超时率反映阈值合理性：如果某告警的确认超时率超过 30%，说明阈值可能过于敏感或值班人已产生告警疲劳。
- 确认后处理时长用于调优阈值：统计确认后到告警恢复的平均时长（MTTA），若 MTTA 过长，可考虑收紧阈值以更早触发告警。
# 确认流程与阈值联动指标示例
metrics:
- name: "ack_timeout_rate"
description: "确认超时率"
formula: "ack_timeout_count / total_alert_count"
threshold: "< 10%"
- name: "auto_ack_ratio"
description: "自动确认占比"
formula: "auto_ack_count / total_ack_count"
threshold: "40% ~ 60%"
- name: "ack_to_resolved_time"
description: "确认到恢复平均时长"
unit: "分钟"
threshold: "P0 < 15min, P1 < 30min"
3.7 确认流程状态机
下图展示了告警确认的完整状态流转，包含手动确认、自动确认、半自动确认及超时升级路径：
3.8 确认流程的监控与调优
确认流程上线后，需要持续监控以下指标，并据此调优阈值与确认策略：
- 确认超时率：超过 10% 说明值班人负载过高或阈值过敏感。
- 自动确认占比：建议控制在 40%～60%，过低则人工压力大，过高则可能遗漏问题。
- 确认后重复告警率：确认后 5 分钟内再次触发相同告警，说明阈值或恢复策略需要调整。
- 升级触发率：超过 5% 说明确认流程设计存在缺陷，需缩短超时时间或增加值班人手。
调优案例： 某团队发现 P2 告警的确认超时率高达 25%，分析后发现阈值过于敏感导致告警量激增。他们将自动确认占比从 20% 提升至 50%，并将确认超时时间从 10 分钟缩短至 5 分钟，超时率降至 8%，值班人满意度显著提升。