2. 升级窗口概念
升级窗口（Upgrade Window）是云原生网关灰度发布中第一个需要明确定义的概念。它指代一组经过审批、具备回退预案、在特定时间范围内执行网关版本变更的操作时段。没有明确的升级窗口，灰度批次将失去节奏控制，回归报告也无法对齐时间基线。
2.1 升级窗口的定义
升级窗口由三个核心要素构成：
| 要素 | 定义 | 示例 |
|---|---|---|
| 时间范围 | 变更操作允许执行的起止时刻 | 2025-04-15 02:00 ~ 04:00 UTC+8 |
| 变更范围 | 本次窗口内允许操作的网关实例集合 | 生产集群 A 的 3 个 Pod |
| 准入条件 | 窗口开启前必须满足的检查项 | 监控告警已静默、回滚脚本就绪 |
关键原则：升级窗口一旦关闭，无论灰度批次进行到哪一步，都必须停止变更操作，进入观察或回退状态。这是 SRE 纪律的底线。
2.2 为什么需要升级窗口
在云原生网关的灰度升级场景中，升级窗口不是流程负担，而是风险控制的核心手段。其必要性体现在以下四个方面：
- 风险隔离：将变更操作限制在可控时间段内，避免全天候随意操作导致的连锁故障。
- 可观测性对齐：回归报告中的指标（延迟、错误率、吞吐量）必须与窗口内的基线数据对齐，否则报告失去对比意义。
- 团队协同：明确窗口时间后，开发、测试、运维、安全团队可以集中资源值守，避免跨时区沟通断层。
- 合规审计：金融、医疗等合规要求严格的行业，升级窗口是变更管理审计的必查项。
常见误区：不要将“升级窗口”等同于“发布窗口”。升级窗口特指网关实例的版本变更操作时段；而发布窗口可能包含配置下发、流量切换等更宽泛的操作。两者在回归报告留痕中需要分别记录。
2.3 升级窗口的典型时间策略
根据业务场景和 SRE 成熟度，升级窗口通常采用以下三种时间策略：
2.3.1 业务低峰期窗口
选择业务流量处于全天最低谷的时间段执行升级。这是最通用、最安全的策略。
| 业务类型 | 典型低峰时段 | 窗口时长建议 |
|---|---|---|
| 电商（C端） | 02:00 ~ 06:00 | ≤ 2 小时 |
| 金融交易 | 00:00 ~ 04:00 | ≤ 1.5 小时 |
| 企业内部系统 | 12:00 ~ 14:00 或 22:00 ~ 06:00 | ≤ 3 小时 |
| 全球化 SaaS | 按区域错峰，如亚太区 13:00 ~ 15:00 UTC | ≤ 1 小时 |
2.3.2 固定窗口策略
无论业务流量高低，在每周或每月的固定时间窗口执行升级。适用于变更频率低、流程成熟度高的团队。
- 每周固定窗口：例如每周三 03:00 ~ 05:00，配合周变更评审会。
- 每月固定窗口：例如每月第一个周六 02:00 ~ 06:00，用于大版本升级。
- 双周滚动窗口：例如每两周的周二和周四凌晨，配合灰度批次节奏。
2.3.3 事件驱动窗口
由特定事件（如安全漏洞修复、紧急故障恢复）触发的非周期性升级窗口。此类窗口需要更严格的审批和更短的回归报告周期。
实践建议：在灰度批次演练中，优先使用“业务低峰期 + 固定窗口”的组合策略。例如：每周二、周四凌晨 02:00~04:00 作为标准升级窗口，同时预留每月一次的大版本固定窗口。回归报告留痕时，必须记录窗口类型和实际起止时间。
2.4 升级窗口决策流程
以下 SVG 图展示了从窗口需求提出到窗口关闭的完整决策流程，帮助团队在灰度批次演练前对齐窗口选择逻辑。
2.5 升级窗口与灰度批次的映射关系
在灰度批次演练中，升级窗口不是一次性概念，而是与每个灰度批次一一对应。以下表格展示了典型映射关系：
| 灰度批次 | 升级窗口时间 | 窗口类型 | 回归报告基线 |
|---|---|---|---|
| 批次 1（金丝雀 1 个 Pod） | 2025-04-15 02:00 ~ 02:30 | 业务低峰期 | 窗口前 15 分钟指标 |
| 批次 2（扩大至 3 个 Pod） | 2025-04-16 02:00 ~ 02:30 | 业务低峰期 | 批次 1 稳定后指标 |
| 批次 3（全量 10 个 Pod） | 2025-04-17 02:00 ~ 03:00 | 固定窗口（周三） | 批次 2 稳定后指标 |
留痕要点：回归报告必须记录每个灰度批次对应的升级窗口 ID、实际起止时间、窗口类型以及窗口内是否发生异常事件。这些信息是后续故障回溯和合规审计的关键证据。