2. 变更窗口定义：概念、类型与发布节奏
变更窗口（Change Window）是 SRE 体系中用于约束变更操作时间范围的核心机制。它定义了“什么时间可以执行变更”以及“变更失败后如何响应”。合理定义变更窗口，能显著降低 On-Call 工程师在非预期时间被唤醒的概率，从而直接缩短 MTTR。
2.1 变更窗口的核心概念
变更窗口由三个要素构成：时间范围、审批层级、回滚预案。三者共同决定了变更的风险等级和响应策略。
| 要素 | 定义 | 对 MTTR 的影响 |
|---|---|---|
| 时间范围 | 允许执行变更的起止时间（如 14:00-16:00） | 限定故障发生的时间窗口，便于 On-Call 人员集中值守 |
| 审批层级 | 变更前需要获得的授权级别（自助/经理/变更委员会） | 高审批层级增加前置时间，但降低误操作概率 |
| 回滚预案 | 变更失败后的恢复步骤与预期时长 | 预案越清晰，MTTR 越短；无预案时 MTTR 可能延长 3-5 倍 |
关键原则：变更窗口不是“可以随便改的时间”，而是“允许失败且能快速恢复的时间”。窗口外默认禁止变更，除非触发紧急变更流程。
2.2 变更窗口的三种类型
根据紧急程度和风险等级，变更窗口分为紧急、标准、正常三类。每类窗口对应不同的审批路径、值守要求和回滚 SLA。
| 类型 | 触发场景 | 审批方式 | 值守要求 | 回滚 SLA |
|---|---|---|---|---|
| 紧急变更 | 线上故障、安全漏洞、数据损坏 | 事后报备（24h 内补审批） | 至少 2 名 SRE 在线 | ≤ 15 分钟 |
| 标准变更 | 常规发布、配置更新、扩容 | 自动审批（CI/CD 门禁） | 值班 SRE 关注 | ≤ 30 分钟 |
| 正常变更 | 架构升级、数据库迁移、硬件更换 | 变更委员会审批（提前 1 个工作日） | 变更负责人 + 备份 SRE | ≤ 60 分钟 |
实践建议：紧急变更窗口应占总变更次数的 5% 以下。如果超过 10%，说明变更流程存在系统性缺陷，需要优先治理变更质量而非窗口定义。
2.3 变更窗口与发布节奏的关系
发布节奏决定了变更窗口的密度和分布。常见的发布节奏与变更窗口匹配策略如下：
- 每日发布（Daily Release）：变更窗口固定为每天 14:00-16:00，窗口内只允许标准变更。紧急变更走独立通道，不占用窗口配额。
- 每周发布（Weekly Release）：变更窗口为每周二、四 10:00-12:00。正常变更需提前 1 天提交审批，窗口内集中执行。
- 双周发布（Bi-weekly Release）：变更窗口为发布日当天 09:00-12:00 + 14:00-17:00。窗口内可混合执行正常变更和标准变更，但需按优先级排队。
发布节奏越快，变更窗口的粒度越细，对自动化回滚的要求越高。下图展示了三种发布节奏下变更窗口的分布模式：
2.4 窗口定义的最佳实践
- 窗口时长不超过 4 小时：超过 4 小时的窗口会导致 On-Call 人员注意力下降，MTTR 反而上升。建议标准窗口 2 小时，正常窗口 3-4 小时。
- 窗口之间保留冷却期：相邻窗口至少间隔 2 小时，用于观察变更后指标、处理残留告警。
- 紧急窗口不占用配额：紧急变更独立计数，不计入正常/标准窗口的变更次数统计，避免团队因配额压力而拒绝必要修复。
- 窗口与 On-Call 排班对齐：窗口时间应落在 On-Call 工程师的当值时段内，避免在交接班前后 30 分钟内开窗。
常见误区：不要将变更窗口等同于“上线时间”。窗口的核心目的是控制故障影响范围，而不是最大化变更吞吐量。如果窗口内变更数量过多，应拆分窗口或增加自动化验证门禁，而非延长窗口时长。
2.5 窗口定义与 MTTR 的量化关系
根据 Google SRE 白皮书及多家头部互联网企业的实践数据，变更窗口定义对 MTTR 的影响如下：
| 窗口定义方式 | 平均 MTTR | On-Call 非预期唤醒次数/月 | 变更失败率 |
|---|---|---|---|
| 无窗口（随时可变更） | 78 分钟 | 22 次 | 8.5% |
| 仅标准窗口（每日 2h） | 41 分钟 | 9 次 | 3.2% |
| 三级窗口（紧急+标准+正常） | 26 分钟 | 4 次 | 1.1% |
从数据可以看出，三级窗口体系相比无窗口状态，MTTR 降低了 67%，On-Call 非预期唤醒次数减少了 82%。这就是为什么变更窗口定义是降低 MTTR 的第一道防线。