2. 变更窗口定义
变更窗口（Change Window）是 SRE 体系中用于约束变更操作时间范围的策略性概念。它定义了“允许执行变更”与“不允许执行变更”的时间边界，是平衡变更速度与系统稳定性的核心机制。变更窗口与 Error Budget 的联动，决定了变更能否在特定时间窗口内执行。
2.1 变更窗口的概念
变更窗口本质上是一个时间策略，它规定了变更操作可以安全执行的时段。其核心目标包括：
- 风险控制：将变更限制在低风险时段，避免在业务高峰期或关键维护窗口外执行变更。
- 可预测性：为团队提供明确的变更执行时间表，便于资源协调和回滚准备。
- 合规性：满足审计和合规要求，确保变更操作有据可查。
实践要点：变更窗口不是“禁止变更”，而是“在正确的时间做正确的事”。窗口外执行变更需要经过特殊审批，且必须确保 Error Budget 充足。
2.2 变更窗口的类型
根据时间策略的不同，变更窗口主要分为固定窗口和滚动窗口两种类型。下表对比了它们的核心差异：
| 特性 | 固定窗口 | 滚动窗口 |
|---|---|---|
| 时间定义 | 预定义的固定时间段（如每周二 14:00-16:00） | 基于当前时间动态计算的滑动时间段（如过去 7 天） |
| 可预测性 | 高，团队可提前规划 | 中，窗口边界随当前时间变化 |
| 灵活性 | 低，错过窗口需等待下一周期 | 高，窗口持续滑动，总有可用时段 |
| 适用场景 | 计划性变更、重大发布、合规要求严格的系统 | 持续交付、紧急修复、DevOps 成熟度高的团队 |
| 与 Error Budget 联动 | 窗口内检查 Error Budget 是否充足 | 窗口边界动态计算 Error Budget 消耗率 |
2.2.1 固定窗口
固定窗口是最传统的变更窗口模式。它预先定义好每周或每月的特定时间段，只有在这个时间段内才允许执行变更。例如：
- 每周二 14:00-16:00：常规变更窗口
- 每月第一个周六 02:00-06:00：重大版本发布窗口
- 季度末最后一周：合规性变更窗口
固定窗口的优点是计划性强，便于跨团队协调；缺点是灵活性差，紧急变更可能被迫等待。
2.2.2 滚动窗口
滚动窗口是一种更灵活的变更窗口模式。它不依赖固定的日历时间，而是基于当前时间向前或向后滑动一个固定长度的时间段。例如：
- 过去 7 天滚动窗口：允许执行变更的时间段是“从当前时间往前推 7 天”到“当前时间”。
- 未来 24 小时滚动窗口：允许执行变更的时间段是“当前时间”到“未来 24 小时”。
滚动窗口的优点是持续可用，适合高频变更场景；缺点是窗口边界动态变化，需要自动化工具支持。
2.3 变更窗口与 Error Budget 的联动
变更窗口与 Error Budget 的联动是 SRE 实践中的关键决策点。其核心逻辑是：只有 Error Budget 充足时，变更窗口才真正“开放”。如果 Error Budget 已耗尽，即使处于变更窗口内，变更也会被自动阻止。
下图展示了变更窗口与 Error Budget 的联动决策流程：
2.4 联动策略详解
变更窗口与 Error Budget 的联动策略可以归纳为以下三种典型场景：
| 场景 | 变更窗口状态 | Error Budget 状态 | 决策结果 | 说明 |
|---|---|---|---|---|
| 正常变更 | 开放 | 充足（> 阈值） | 允许执行 | 标准变更流程，自动审批 |
| 紧急变更 | 开放 | 不足（< 阈值） | 拒绝执行 | 需人工审批，评估风险后决定是否豁免 |
| 窗口外变更 | 关闭 | 任意状态 | 拒绝执行 | 需特殊审批，且必须提供充分的回滚预案 |
重要提醒：Error Budget 不足时，即使处于变更窗口内，系统也应自动阻止变更。这是 SRE 的核心纪律之一，旨在防止“用稳定性换速度”的恶性循环。如果团队需要频繁豁免此规则，说明 Error Budget 的阈值或变更窗口的定义需要重新评估。
2.5 联动实现示例
以下是一个简单的伪代码示例，展示了变更窗口与 Error Budget 联动的核心逻辑：
def can_execute_change(change_request):
# 1. 检查变更窗口
if not is_in_change_window(change_request.time):
return False, "变更不在窗口内"
# 2. 检查 Error Budget
error_budget_remaining = get_error_budget_remaining()
error_budget_threshold = get_error_budget_threshold()
if error_budget_remaining < error_budget_threshold:
return False, f"Error Budget 不足 (剩余: {error_budget_remaining:.2%})"
# 3. 通过检查
return True, "变更允许执行"在实际系统中，这个逻辑通常集成在 CI/CD 管道的门禁（Gate）阶段，作为变更执行的强制性前置检查。
2.6 最佳实践建议
- 窗口定义要明确：固定窗口应精确到分钟，滚动窗口应明确滑动步长（如 1 小时、1 天）。
- 阈值设置要合理：Error Budget 的阈值通常设置为 70%-80%，预留缓冲空间应对突发情况。
- 自动化检查：将联动逻辑集成到变更管理工具中，避免人工判断的延迟和错误。
- 定期复盘：每季度回顾变更窗口与 Error Budget 的联动效果，根据实际故障率调整参数。