互联网团队讲究"一天发十次"，券商核心系统的节奏是"一个月发一次，只在周六晚上"。这套看似笨拙的节奏背后，每一条限制都能落到具体的技术或业务事实上。这篇讲变更管理是怎么运作的。
窗口为什么是周六晚
三个硬约束把窗口钉死在周末：
- 交易日不可中断。交易时段每天 4 小时，盘中任何升级动作都是不可接受的风险暴露——不是不能做到不停机，是没人敢为一次常规发版承担盘中出事的合规后果。
- 升级之夜就是清算之夜。周日晚上不跑批，真正的批量验证要等到周一清算夜。所以窗口设计必须留出"周日凌晨发现问题、来得及回滚"的余量，这是选周六晚而不是周日晚上线的原因。
- 交易所测试日。涉及交易所接口的变更，必须先在交易所测试环境联测通过——联测环境只在周六开放。新接口、新规则不经过测试日验证，生产不敢上。
变更分级：不是所有变更都要走完整流程
按风险把变更分三档，流程重量和审批层级随之变化：
- 紧急变更：交易中断、资金风险类。走应急通道，当晚评估、当晚执行，但必须有值班领导签字和事后补审——通道是快的，不是免审的；
- 常规变更：功能迭代、缺陷修复。周二前提交变更方案，周四评审，周六窗口执行。评审看四样东西：影响面、操作步骤（精确到命令）、验证脚本（升完跑什么确认正常）、回滚步骤；
- 参数变更：费率、白名单、风控阈值。这类走参数热更新平台（《风控参数的热更新》篇），不占用发布窗口，因为不动代码。
实际生产里变更导致的事故，一半以上是把本该走参数通道或常规通道的东西临时塞进了应急通道——急字当头，验证省略。
回滚预案写到什么程度
"出问题回滚"四个字不算预案。合格的回滚预案要具体到：回滚包放在哪、执行哪几条命令、数据库怎么退。数据库回滚是最难的部分，原则是在设计变更时就给回滚留路：
- DDL 向前兼容：只加列不改列、只加表不删表、新索引先建后切；变更表结构用"新表双写过渡、追平历史、切读、停写旧表"的四步法，每一步都可独立回退；
- 回滚演练：预案里的关键命令在测试环境真跑过一遍。没跑过的回滚预案约等于没有；
- 值守表：升级当晚谁操作、谁复核、谁决策回滚，写清楚并且人在线。
灰度的层次：核心交易没有用户灰度
灰度发布在券商系统里要分层理解。APP、官网这类 C 端系统，可以按用户群灰度——这是互联网行业熟悉的玩法。管理系统可以按营业部灰度：先切几家营业部跑一周，没问题再全量。但核心交易链路不存在灰度：一笔委托要么按新逻辑处理要么按旧逻辑，按用户灰度意味着同一时段两套账务逻辑并行，对账和审计直接爆炸。
核心系统真正的"灰度"是同《同城双活与异地灾备》那套：双活两端先升一端，观察一个完整清算夜（含周一的日终批量），确认无差异再升另一端。粒度是机房不是用户，周期是天不是分钟。
变更冻结期：业务日历说了算
还有两个时间段常规变更直接冻结：财报披露期和长假前。逻辑一致——业务高峰期任何非必要变更的风险收益比都是负的。监管现场检查期间也会临时冻结，这不是技术决定，是对检查的配合姿态。变更日历要和业务日历联动， freeze 名单每年初就排出来。
度量：把发版从战役做成日常
衡量变更管理成熟度的指标很朴素：变更导致事故率、回滚率、每次事故有没有 postmortem 并落到流程修补。目标不是"零事故"这种口号，而是每次发版都从容——步骤是跑过的脚本，回滚是验证过的命令，值班的是睡过觉的人。DevOps 在核心系统里的正确形态不是天天发版，而是每次发版都不慌。
变更管理本质是用流程的确定性对冲上线的风险。窗口、评审、演练看起来都是成本，摊到全年事故率上，是券商系统里回报最高的投资之一。