蹲过机房后我懂了遗留系统改造的真实代价

上周在徐庄软件园蹲到晚上九点，某金融公司的运维张哥把半盒烟抽完，扔给我一张皱巴巴的打印纸。

上面是他们跑了11年的核心交易系统的部署清单。纸边黄得发脆，落款还是2012年的版本。

我见过太多上来就喊”全量重构”的团队，对着这份清单看都不看，张嘴就要把老系统拆成微服务，全量上云。

先别吹微服务，你先摸透老系统的底

真蹲过机房的人都知道，你面对的根本不是一堆代码。是连文档都凑不齐的历史遗留。

之前接触过一个制造企业的系统，2008年上线，用的是早就停更的自研轻量框架。存文档的U盘坏了三个，剩下的半本Word还是当时的实习生成的，连个字段说明都没有。要改系统？你得先把代码逐行读，才能知道哪个分支是给某个特定供应商的特殊接口，哪个判断是当年为了应付某次监管要求临时加的。

很多人上来就拿行业最佳实践说事，说微服务好，说云原生成本低。可你连老系统里藏了多少”见不得光”的临时逻辑都不知道，拿什么拆？

你总不能拆完了才发现，原来有个给老客户的特殊折扣逻辑，被你当成没用的废代码删了吧？

所谓的改造，一半是给老系统擦屁股

说实话，我见过太多改造项目的翻车现场。

某电商平台当初拍脑袋决定全量重写老的订单系统，上线第一天就把十年前的老会员积分规则搞混了。客服电话被打爆，赔了小半年的利润才把事平了。

大部分遗留系统改造的核心，不是技术升级，是把藏在代码里的业务隐性规则挖出来。这些规则从来不会写在正式的业务文档里，都是当年的开发和业务部门对着需求改了又改，最后揉进代码里的。你要是不把这些规则挨个找出来核对，就算把代码写得再优雅，上线也是灾难。

麻烦在于，当年参与写这些规则的人，早就不在公司了。你得找现在还在的老员工，对着代码一段段问，这个逻辑是啥意思，那个判断当初为啥要加。有时候问三个人，能得到三个完全不一样的答案，你还得拉着大家一起对着历史数据倒推，才能把规则捋顺。

这事没那么玄。你不是在做什么技术创新，就是在给十几年前的前辈擦屁股。擦干净了，才能谈后面的升级。

没人愿意说的改造成本账

很多公司算改造预算，只算开发人力和新服务器的钱，根本不算隐性成本。

你要找原来的老开发回来做顾问，人家早就跳去别的公司当技术专家了，一天的顾问费比现在的初级开发一个月工资还高。你要协调业务部门抽人核对规则，人家自己的日常业务都忙不完，能抽出来给你半天时间都算给面子。你要做系统割接，还得挑凌晨两三点没人用的窗口，运维团队连轴转熬大夜，万一出点错，业务停半小时，产生的损失比你改造省的钱还多。

我见过最离谱的一个项目，当初立项的时候批了两千万预算，最后光梳理老系统的业务规则就花了一千二，剩下的钱连买新的云服务器都不够。最后只能边改边凑，硬生生拖了两年才上线。

从来没有”一步到位”的遗留系统改造，所有想一口吃成胖子的项目，最后基本都在填之前挖的坑。

现在越来越多的团队开始用那种慢方法——就是在老系统外面套个流量网关，新的业务模块先放在新平台上，老的模块一块一块替换，等全部换完了，老系统自然就下线了。这种方法慢是慢，但是稳。上次在软件谷见的一个政务系统改造团队，就是这么干的，花了三年时间一点点替换，中间从来没出过大规模的业务中断，最后算下来的总成本，比当初拍脑袋要全量重写的预算还低了三分之一。

昨天又收到张哥的微信。

说他们的老系统已经替换了三分之一，下周要把核心的交易模块迁到新的云平台上。他说终于不用再半夜爬起来，打车去机房重启那台老掉牙的服务器了。