【背景】
做了 5 年运维，我见过太多团队在"什么时候能往生产上推东西"这件事上，规则要么是"祖传的没人解释过为什么"，要么是"每次出事之后临时加的"。
我印象最深的一次：某团队规定"工作日 10:00-16:00 禁止任何变更"，理由是"业务高峰期别动"。结果有一次凌晨 3 点一个配置错误导致流量全打到一台机器上，值班的人想改配置，但按流程得等早上 10 点"窗口"才能动——硬扛了 7 个小时，P1 事故。
反过来我也见过一个团队"随时可以发布"，结果周五下午 5:50 有人推了一个"小改动"，周六凌晨炸了，周五晚上值班的兄弟背了一周的锅。
所以我想认真问一句：你的团队，生产变更窗口到底是怎么定的？定这条线的依据是什么？谁有最终否决权？
【几种我见过的做法】
做法 A：硬窗口（时间驱动） "只有凌晨 2:00-6:00 能变更，其他时间一律封网。"
- 优点：规则简单，值班的人不用做判断，"不是窗口时间"就是最佳挡箭牌。
- 缺点：凌晨 3 点出紧急故障时，变更流程反而成了最大瓶颈；而且"凌晨"这个时间窗口是拍脑袋定的，并没有数据支撑"凌晨 2 点比下午 3 点更安全"。
- 我观察到的一个隐性代价：所有变更都挤在同一个 4 小时窗口里，一次发布排 20 分钟，一天最多发 12 次，发布队列经常排到第二天。
做法 B：随时可发（灰度 + 快速回滚兜底） "没有固定窗口，但必须走灰度：1% → 10% → 50% → 100%，每级观察 5-10 分钟。"
- 优点：不阻塞紧急修复，发布节奏和开发节奏解耦。
- 缺点：对灰度基础设施要求极高——如果你的灰度只是"先发一台机器"而不是"按流量比例切"，那这个灰度约等于没有；另外"随时可发"在实践里往往会退化成"周五下午 5 点也能发"，因为没人真的在 5:50 说"不，今天不发了"。
- 我见过一个团队搞了半年"随时灰度发布"，最后发现 80% 的事故都集中在周五下午和节假日前——不是技术不行，是"随时"两个字在组织里被理解成了"没人在管"。
做法 C：风险分级（变更驱动） "低风险变更（配置项、文档、监控规则）随时可以推；中风险（代码发布、DB schema）需要窗口 + 双人确认；高风险（核心链路重构、存储迁移）需要变更评审 + 回滚预案 + 专人值守。"
- 优点：最灵活，把"安全"和"效率"的矛盾按风险等级拆开。
- 缺点：最大的坑是**"谁来判断风险等级"**。我见过一个团队让开发自己标风险等级，结果 90% 的变更都标了"低风险"——因为标"高风险"意味着要多等一个评审会，没人愿意。最后"风险分级"退化成了"风险自我豁免"。
【我的倾向与理由】
我个人偏向做法 C（风险分级），但加两条硬约束：
- "低风险"的定义不是开发自己说的，而是由变更的 blast radius 决定的。 比如：改一个只影响内部运维面板的配置 = 低风险；改一个影响用户下单链路的超时参数 = 中风险，不管代码改没改。判断标准不是"我改了什么"，而是"这个变更炸了会炸多大"。
- 必须有"紧急通道"，但紧急通道本身要有事后复盘。 凌晨 3 点出 P1 故障，值班的人不应该被流程卡住。我的做法是：允许"先斩后奏"，但事后 24 小时内必须补一份变更说明（改了什么、为什么紧急、有没有回滚）。没有这条，"紧急通道"就会变成"常规通道"。
但说实话，我到现在也没想清楚一个问题：风险分级的"分级"本身，谁来定？ 是 SRE 团队定？是业务 owner 定？还是每次变更前临时拉个会定？我见过的所有团队在这个问题上都没有一个让我信服的机制。
【想听大家聊聊】
- 你的团队现在用哪种做法？是"祖传规矩"还是真的有人论证过？
- 如果让你重新设计变更窗口，你会怎么定"风险等级"的判定标准？有没有可操作的具体规则（而不是"根据经验判断"）？
- "紧急通道"在你的团队里是真存在还是名义存在？有没有因为走紧急通道反而出更大事故的经历？
- 周五下午 5 点这个"危险时段"，你的团队有没有什么特别的规则？（我猜很多团队的规则是"没规则"——这才是最危险的。）
这个话题没有标准答案，但我相信每个运维人都被"变更窗口"坑过，也都被"不该发的时候发了"或者"该发的时候不让发"折磨过。想听听大家团队的真实做法，尤其是踩过的坑。