3. 事故阈值复测触发条件：何时需要复测
阈值复测并非周期性任务，而是由特定事件驱动的验证行为。错误的触发时机（过早或过晚）会导致告警覆盖不足或运维资源浪费。根据生产环境经验，阈值复测必须在以下三类场景中强制执行。
3.1 事故发生后（Post-Incident Review 驱动）
这是最直接的触发条件。当线上服务因告警未触发、告警延迟或误报导致故障时，必须对相关阈值进行复测。复测的核心目标是验证现有阈值能否在类似故障场景下正确、及时地发出告警。
| 事故类型 | 阈值复测重点 | 典型复测指标 |
|---|---|---|
| 告警未触发（漏报） | 检查阈值是否过高，或聚合窗口是否过长 | 降低阈值至故障实际水位，缩短评估周期 |
| 告警延迟（晚报） | 检查 for 语句的持续时间设置是否过长 | 缩短 for 持续时间，或增加基于速率的即时告警 |
| 告警风暴（误报） | 检查阈值是否过低，或缺乏抖动抑制 | 提高阈值，增加波动容忍度，引入静默规则 |
| 告警恢复失败 | 检查恢复阈值与触发阈值之间的回差（Hysteresis） | 设置合理的回差区间，避免阈值抖动 |
最佳实践：事故复盘（PIR）会议中必须包含“阈值有效性”检查项。如果事故根因与监控阈值直接相关，则复测结果需作为事故关闭的前置条件。
3.2 业务变更后（Deployment & Configuration Change）
任何对系统架构、代码逻辑或基础设施的变更，都可能改变服务的性能基线。原有阈值在新环境下可能完全失效。以下变更必须触发阈值复测：
- 代码发布：新版本引入了缓存、异步处理或数据库查询优化，导致响应时间或错误率基线偏移。
- 基础设施扩缩容：Pod 副本数增加、实例规格升级或降级，CPU/内存使用率基线会随之变化。
- 第三方依赖变更：数据库版本升级、中间件配置修改、外部 API 超时时间调整。
- 流量入口调整：CDN 规则变更、负载均衡算法切换、限流阈值调整。
常见误区：变更上线后立即复测。建议等待至少 30 分钟（或一个完整的业务周期），让系统水位稳定后再进行阈值验证，避免因部署抖动导致误判。
3.3 周期性审查（Scheduled Review）
即使没有事故和变更，阈值也会因业务增长、季节性流量变化而逐渐失效。周期性审查是主动发现阈值漂移的关键手段。
| 审查周期 | 适用场景 | 审查内容 |
|---|---|---|
| 每周 | 核心服务（支付、登录、搜索） | 检查过去 7 天告警触发率、误报率、平均响应时间基线 |
| 每月 | 所有生产服务 | 对比本月与上月 P99/P95 延迟、错误率、资源使用率变化 |
| 每季度 | 全量告警规则 | 全面审查阈值合理性，清理冗余规则，更新告警接收人 |
3.4 触发条件决策矩阵
以下矩阵帮助 SRE 快速判断当前场景是否需要立即执行阈值复测：
| 场景 | 是否触发复测 | 优先级 | 执行窗口 |
|---|---|---|---|
| P0/P1 事故（漏报/延迟） | 是 | P0 | 事故恢复后 2 小时内 |
| P2 事故（误报/恢复失败） | 是 | P1 | 事故恢复后 24 小时内 |
| 核心服务代码发布 | 是 | P1 | 发布后 1 小时内 |
| 非核心服务基础设施变更 | 是 | P2 | 变更后 4 小时内 |
| 第三方依赖版本升级 | 是 | P2 | 升级后 8 小时内 |
| 月度周期性审查 | 是 | P3 | 审查窗口内完成 |
| 配置变更（仅告警接收人） | 否 | - | 无需复测 |
核心原则：任何可能改变服务性能基线的事件，都应视为阈值复测的候选触发条件。当不确定是否需要复测时，执行一次轻量级验证（如对比最近 1 小时指标与阈值的关系），成本远低于事故再次发生的代价。