「项目 X」上线复盘

背景

项目 X 是一次为期六周的改造：把一个跑了两年的单机同步脚本，换成可以水平扩容的服务。旧脚本每天凌晨跑一次，失败了只能人工重跑；业务量翻倍之后，四个小时的处理窗口越来越紧，上线的目标很朴素——不停机、不出数错、随时能回。

做得好的

• 灰度按数据分片切，而不是按流量切。 每次只把一个分片切到新服务，对比新旧两侧的输出哈希，一致再切下一个。整个灰度期没有出现过「一半数据走新逻辑、一半走旧逻辑」的中间态。
• 双写对账跑了整整一周。 上线前对了一万多条抽样，灰度期继续全量对账，发现异常的时间从「天」缩短到「分钟」。对账是我们这六周里最便宜的保险。
• 上线节奏有人守。 每次切分片都安排两个人：一个操作，一个只负责看指标和喊停。规则提前写死：喊停不需要理由，停下来再讨论。

踩了的坑

• 回滚预案写在文档里，但没演练过。 第八个分片灰度时真的回滚了一次，实际花了二十五分钟，是预案预估的三倍——因为配置回退依赖一个只有一个人会改的开关。演练不是仪式，是把「以为能回」变成「确认能回」。
• 灰度指标是临时拼的。 第一天盯的几个指标里，最关键的输出延迟反而不在面板上，靠人肉翻日志才发现一次小抖动。事后补了面板，但顺序反了：面板应该先于灰度存在。
• 六周排期没有留缓冲。 最后一周的联调全靠周末补上。结果能接受，方式不可持续，下次不能这么排。

如果重来一次

把对账和监控面板当作上线的第一张票，而不是上线前一周的补丁；回滚演练放进灰度第一天；排期砍掉一个「顺手优化」，留出整周的缓冲。

结论

上线本身是顺利的：全量切换后处理窗口从三小时四十分缩到五十分钟，零数据差错。但「顺利」里有一半是运气——回滚没演练、监控不齐全，任何一个被放大一点都会变成事故。下一次上线，把运气换成流程。