把手游发布从 1.5 小时压到 30 分钟

问题

《魔法战旗》海外服和《决胜巅峰》国服的一次常规发布要占掉 1.5 小时。最初的判断是构建和分发慢，但把每个阶段的耗时拆出来之后，结论反了：

真正的时间都花在串行的人工确认上。发布是分批次的，每批之间要等人工核对上一批的监控指标是否正常，确认了才敢继续。核对本身只要几分钟，但等人从别的事情里切回来、打开几个看板、逐个确认，中间的空档累积起来比所有机器操作的总和还长。

这是一个典型的「优化错了对象」的陷阱——如果按最初的判断去优化构建速度，就算把构建做到零耗时，总时长也只能降到一小时出头。

做法

思路是把人工确认变成机器判定，人只在判定不通过时介入。

第一步：把「正常」写成可执行的判定条件。 原来的核对是经验性的——老手看一眼看板就知道对不对。要自动化，就得先把这份经验落成明确的指标阈值和判定逻辑：哪几个指标、看哪个时间窗、超过多少算异常、哪些波动是发布本身必然带来的正常抖动。这一步花的时间最长，也最容易被低估：它本质上是在给一群人的隐性判断做知识提取。

第二步：批次间的等待改成自动观测窗口。 每批发布完成后自动进入固定时长的观测期，期间持续拉取判定指标。全绿则自动继续下一批，任一条不满足则暂停并推送告警，附带具体是哪条指标、当前值、阈值。人被叫来的时候看到的是结论，不是一堆看板。

第三步：把回滚也做成一条命令。 自动化推进的前提是出错时能快速退回。回滚路径不可靠的话，没人敢让流程自己往下走——这一点比自动化本身更影响推进意愿。

结果

• 单次发布耗时从 1.5 小时降到 30 分钟。
• 发布窗口不再必须占用一个完整的人力时段，值班同学可以并行处理别的事。
• 判定条件被写成了配置，新项目接入时是填表而不是重新攒经验。

事后看，值得记下来的

「慢」的归因经常是错的。 大家凭直觉认为是机器慢，因为机器耗时是可见的、有日志的；人工等待是不可见的，没有人记录「我什么时候被叫来的」和「我什么时候真正开始看的」。要先把不可见的部分量化出来，才谈得上优化。

自动化的阻力不在技术，在信任。 判定逻辑写好之后，还跑了一段时间的「影子模式」——机器给判定，人照旧手工确认，两边比对。跑到人发现机器的判定和自己一致，才愿意把控制权交出去。这段并行成本是必要的，跳过它换来的是流程上线后没人敢用。

隐性经验的显式化，本身就是交付物。 阈值和判定逻辑写下来之后，价值不只是给自动化用——新人 onboarding 时不用再靠师傅带着看看板了。