1. 阈值复测概述
1.1 阈值复测的定义
阈值复测（Threshold Retest）是指在事故（Incident）发生后，SRE 团队对触发该事故的告警阈值进行系统性重新评估、验证与调整的过程。它不同于日常的阈值调优，而是以事故复盘为驱动，对阈值合理性、告警有效性以及业务影响进行深度审查。
阈值复测的核心目标包括：
- 验证阈值准确性：确认当前阈值是否真实反映了系统异常状态，而非误报或漏报。
- 消除告警疲劳：通过复测剔除无效或低价值的告警规则，减少不必要的告警噪音。
- 提升 MTTR：优化阈值灵敏度，确保关键事故能被及时、准确地发现。
- 形成闭环改进：将复测结果沉淀为可复用的阈值基线，避免同类事故重复发生。
💡 关键认知：阈值复测不是一次性的“修复动作”，而是事故管理生命周期中持续改进的环节。每次事故都应触发一次阈值复测，形成“事故 → 复测 → 优化 → 验证”的闭环。
1.2 阈值复测在事故管理中的重要性
在事故管理流程中，阈值复测扮演着承上启下的关键角色。它连接了事故响应与系统稳定性改进，是避免“救火式”运维的核心手段。下表总结了阈值复测在事故管理各阶段的价值：
| 事故管理阶段 | 阈值复测的作用 | 典型产出 |
|---|---|---|
| 事故发现 | 评估告警阈值是否在事故发生时及时触发，是否存在延迟或遗漏 | 告警触发时间线、延迟分析 |
| 事故响应 | 判断阈值是否导致告警风暴或告警淹没，影响响应效率 | 告警聚合策略调整建议 |
| 事故复盘 | 分析阈值设置与事故根因的关联性，识别阈值盲区 | 阈值偏差报告、根因关联矩阵 |
| 改进跟踪 | 验证调整后的阈值是否有效，防止事故复发 | 复测验证报告、阈值基线更新 |
阈值复测在事故管理中的重要性还体现在以下三个方面：
- 防止事故复发：通过复测发现阈值设置与业务负载、系统架构之间的不匹配，从根源上消除告警盲区。
- 降低告警运维成本：减少无效告警对值班人员的干扰，让团队聚焦于真正需要人工介入的事故。
- 支撑 SLA/SLO 达成：合理的阈值是衡量服务等级目标（SLO）的基础，复测确保告警阈值与 SLO 目标对齐。
⚠️ 常见误区：不要将阈值复测等同于“调高阈值来减少告警”。复测的核心是“合理性”而非“安静度”。盲目调高阈值可能导致关键事故漏报，造成更大的业务损失。
1.3 阈值复测与常规告警阈值的区别
常规告警阈值设置与阈值复测在目标、触发条件、执行频率和输出结果上存在本质差异。下表从多个维度进行对比：
| 对比维度 | 常规告警阈值 | 阈值复测 |
|---|---|---|
| 触发条件 | 基于历史基线、容量规划或默认经验值 | 由具体事故或重大变更触发 |
| 执行频率 | 定期（如每周/每月）或随系统变更调整 | 事故驱动，每次事故后必须执行 |
| 评估范围 | 单个指标或单条告警规则 | 关联事故的完整告警链路（指标、规则、聚合、通知） |
| 数据来源 | 历史监控数据、容量模型 | 事故时间线数据、告警日志、值班人员反馈、业务影响数据 |
| 输出结果 | 阈值调整建议、告警规则更新 | 阈值复测报告、事故根因关联分析、告警策略优化方案 |
| 参与角色 | SRE 工程师、监控运维 | SRE 团队、事故响应人、业务 owner、研发代表 |
| 风险等级 | 低（影响告警灵敏度） | 高（直接影响事故发现能力和业务稳定性） |
下图直观展示了阈值复测在事故管理流程中的位置及其与常规阈值调整的关系：
从流程图中可以清晰看到：常规阈值调整是日常运维的持续活动，而阈值复测是事故管理流程中的强制节点。复测的结果会反馈到常规阈值调整中，形成持续改进的闭环。
1.4 阈值复测的核心原则
在执行阈值复测时，SRE 团队应遵循以下核心原则，确保复测过程科学、结果可靠：
- 数据驱动：所有阈值调整必须基于事故时间线数据、监控指标趋势和业务影响数据，避免主观判断。
- 业务对齐：阈值设置必须与业务关键指标（KPI）和服务等级目标（SLO）保持一致，不能脱离业务上下文。
- 可追溯：每次复测的输入、分析过程、调整结果和验证结论都必须记录在案，形成可审计的复测报告。
- 渐进调整：阈值调整应遵循小步快跑原则，避免一次性大幅修改导致新的告警盲区。
- 团队协作：复测需要 SRE、研发、业务方共同参与，确保阈值调整兼顾技术可行性和业务容忍度。
📌 实践要点：在 Alertmanager 环境中，阈值复测不仅涉及 Prometheus 告警规则中的
expr 表达式调整，还需要同步审查 group_by、group_wait、repeat_interval 等告警聚合参数，确保告警通知的时效性和准确性。