灰度、回滚与兼容窗口
Category
production / 发布安全。节点定位：灰度、回滚、兼容窗口三根支柱——发布体系默认线上会暴露未知问题，目标是可控地发现、限制、回退。
Definition
稳定发布并不意味着“这次肯定没问题”，而意味着一旦有问题，系统能在可控范围内被发现、被限制、被回退。灰度、回滚和兼容窗口正是围绕这个目标建立起来的三根支柱。缺其中任何一个，发布体系都很难算成熟。
很多团队把灰度理解成百分比放量，把回滚理解成重新发一个旧包，把兼容窗口理解成“最近这几天先兼容着”。这三个理解都太浅。它们真正解决的，是线上未知问题的隔离与恢复能力。
Problem
稳定发布不等于「这次没问题」，而是问题出现时能被限制在可控范围。缺灰度，问题按全量爆发；缺回滚（回滚的是稳定组合不是旧代码），问题只能靠修；兼容窗口拍脑袋（过短炸存量、过长背双倍维护），问题在版本交界处集中兑现。
为什么发布体系必须默认线上会暴露未知问题
无论测试做得多认真，线上始终存在测试前无法穷尽的变量：
- 机型和系统版本组合
- 历史包和补丁链差异
- 平台 SDK 或渠道环境差异
- 用户真实路径和极端操作
- 老缓存、新资源和新配置的组合
所以发布体系不能建立在“测试已经覆盖全部情况”的假设上，而要建立在“未知问题一定还会继续出现”的假设上。
灰度真正值钱的地方是什么
灰度不是“先给 5% 用户试试”这么简单，它更像一种风险切片能力。真正有价值的灰度，通常能按这些维度切：
- 用户分组
- 渠道和平台
- 地区和网络环境
- 客户端包版本
- 功能开关和资源批次
这样做的意义在于，一旦问题出现，团队能更快知道影响面在哪，而不是只能在“全量用户都可能受影响”和“完全不知道谁受影响”之间盲猜。
回滚不是回到旧代码，而是回到旧的稳定组合
这是很多团队最容易低估的点。线上问题往往不是单个构件出错，而是一组构件组合不兼容。所以真正可用的回滚，必须能回答：
- 要回滚的是客户端包、资源、配置、脚本还是服务端逻辑
- 回滚目标是否仍然彼此兼容
- 玩家当前状态和缓存是否需要清理或迁移
- 服务端是否知道哪些客户端仍然停留在旧组合上
如果这些问题没有被提前设计，所谓回滚通常只是“快速再发一次”，并不是真正恢复到稳定态。
兼容窗口为什么不是越短越好，也不是越长越好
兼容窗口指的是旧版本仍被允许与新系统共存的时间范围。它太短，会带来这些问题：
- 渠道审核没过完，旧客户端已无法接入
- 玩家升级分布还没收敛，新版本强切导致大量失败
- 服务端来不及平稳迁移协议和数据结构
它太长，又会带来另一组问题：
- 服务端和配置长期背着双向兼容负担
- 新能力无法快速清理旧逻辑
- 测试矩阵和排障复杂度持续上升
所以兼容窗口不是拍脑袋决定的，而是必须结合审核周期、升级分布、风险等级和运维能力来定。
一个更稳妥的发布安全模型
比较稳妥的做法通常会把三件事一起设计：
- 用灰度控制新变化的暴露面
- 用回滚保证问题出现后能回到已知稳定组合
- 用兼容窗口保证灰度与回滚期间系统仍然可运行
这三者必须同时存在。只有灰度没有回滚，发现问题也难止损；只有回滚没有兼容窗口，回去以后系统可能依然跑不稳；只有兼容窗口没有灰度，风险还是会一次性全量暴露。
最容易做坏的地方
只有放量开关，没有状态恢复设计
很多系统能做到“停发新版本”，却做不到“让已受影响用户恢复到正确状态”。
只对代码做回滚，不对配置和资源做回滚
这会导致表面看似回滚成功，实际线上仍然跑着不兼容组合。
兼容窗口全靠经验和口头约定
没有升级分布和平台周期支撑的兼容窗口，最终往往不是太短就是太长，长期都在用猜。
常见误区
最常见的错误，是把灰度理解成简单百分比放量，而不是风险切片工具。第二类错误，是把回滚理解成重新发布旧版本，而不是恢复到一组兼容稳定的版本组合。第三类错误，是兼容窗口完全靠经验决定，既不看平台审核周期，也不看玩家真实升级分布，最终让演进和稳定性同时受损。
Used By
发布安全模型设计（灰度分层、回滚演练、兼容窗口口径）；大版本与热更的发布评审；事故止损流程。
Related
关系链：默认会出问题 → 灰度（限制爆炸半径）→ 回滚（回到稳定组合）→ 兼容窗口 → 安全模型。上游：版本拆分（02，回滚的组合单位）。下游：运营侧灰度观察（operation 树的 observability）。
Reference
本页为工程经验归纳。