遗留系统改造别上来就全量重写

上周在南京软件大道的咖啡店坐了俩小时，对面是干了12年城商行核心系统运维的老周。他刚把手里的冰美式捏出印子，说上周领导拍板要做遗留系统改造，上来就报了八位数的预算，要把跑了18年的核心交易系统全量换成云原生的新平台。

老周当时没敢当场反驳。

他太知道那套系统的分量了。

没人敢碰的系统，才是改造的真正起点

那套核心系统现在全公司能说清楚完整交易链路逻辑的人，加上退休返聘的98年入职的老架构师，拢共三个。上次想加个新的跨境支付字段，三个开发轮流转了三天代码才找到埋点，上线的时候碰了个没人注意的老逻辑，凌晨三点压垮了同城交易的链路，停了47分钟的柜面交易，赔了客户快二十万的手续费。

遗留系统最恐怖的地方从来不是技术老，是没人知道它到底在跑什么。

当年写代码的那批开发早就跳槽去了互联网公司，谁也不会回来给你补文档，更不会为你当年图方便加的逻辑负责。很多藏在代码缝隙里的功能，是当年为了应对某次监管检查加的临时补丁，是为了帮某个大客户开的特殊权限，是运维半夜救火的时候临时加的兜底逻辑——这些东西从来不会出现在正式的项目文档里，只存在于老员工的聊天记录里，存在于十年前的运维值班日志里。

很多公司做遗留系统改造，第一步就错了。上来就找厂商报方案，比报价，选最先进的技术栈，完全不管现在的系统到底承担了多少隐性的业务逻辑。老周说上次有个厂商过来做调研，翻了俩小时官方文档，张嘴就说你们这个系统架构太老了，要全量替换，根本没注意到系统里嵌了一段1998年写的批处理逻辑，是给当地人民银行做数据上报的固定格式。那个格式二十年没变过，换了新系统根本对接不上，到时候数据报不上去，挨骂的是自己。

拆系统比写新系统难十倍

老周他们去年试过一次小范围的改造，把原来系统里的交易查询模块拆出来放到新的微服务上。本来以为一周就能搞定，结果上线之后发现，老系统每次查交易记录的时候，会顺手把客户的历史欠费字段写到内存缓存里，给后面的风控校验模块用。

这个逻辑根本没写在任何文档里，是当年写代码的开发图方便加的。

结果新模块把查询拆走之后，老的风控模块拿不到缓存值，把所有正常交易都判定成了高风险，拦了快三千笔个人转账。那天整个运维团队在机房熬了一整夜，才把那段藏在查询接口里的缓存逻辑补回到新模块里。

做遗留系统改造，你写的每一行新代码，本质上都是在给一堆没写说明书的老机器做适配。

你不能要求老的业务流程跟着新系统改，毕竟一线柜员用了十几年的操作习惯，改起来的代价比改代码还大；你也不能要求老的硬件设备兼容新的系统接口，毕竟很多车间里的传感器还是十年前买的，换一套的成本比整个软件改造还高。很多人对改造的想象是，旧系统拆完，新系统上线，大家都用新的，效率提升多少。但真实的情况是，你拆完的每一块，都要在原来的老系统上留个转接的桩，要保证老用户进来的时候，能无缝走到新模块，新模块返回的数据，还要符合老系统的格式要求，不然老的报表系统读不出来。老周团队光做这个格式适配的桩，就花了三周时间，比写新模块的功能代码时间还长。

别追求一步到位的完美

领导报的那个八位数的全量替换方案，老周算过账。从调研到上线，至少要两年时间，中间还要停三次核心系统做数据迁移，每次停系统的损失，都够把整个团队的工资发两年。关键是就算花了这么多钱，换了新系统，也未必能比老系统好用。

他们现在换了思路，不搞全量重写了。

先把最影响日常开发效率的模块拆出来。比如原来每次改个前端页面，要走老系统的编译流程，要等两个半小时才能出包，现在把前端层拆出来，新的前端直接接老的后端接口，改代码的编译时间从两个半小时压到三分钟。就这一个小改动，开发团队的迭代效率直接提了六成，一线柜员不用再每次等版本等一周。

遗留系统改造从来不是技术升级的项目，是帮一线干活的人减少麻烦的项目。

之前听一个做制造行业的朋友说，他们的MES系统跑了15年，之前想全换，算下来要花三年时间，还要停两次生产线，损失快一个亿。后来他们就拆，先把原来系统里的设备数据采集模块拆出来，接到新的物联网平台上，生产线不停，新的平台慢慢把原来的报表、告警功能一个个补上。花了两年时间，现在老系统就剩个最核心的排产模块在跑，根本没人急着拆它。

说实话，很多公司把遗留系统改造做成了形象工程。找一堆专家来论证，上最时髦的技术栈，写几十页的项目汇报，根本不管一线的人用着顺不顺。等项目上线了，大家发现新系统还没老系统好用，又得花时间在新系统上做各种补丁，最后老系统没拆完，新系统又变成了新的遗留系统。

不过话说回来，这事真的没那么玄。

你别上来就想着把整个系统推倒重来，先去一线问。问柜员平时办业务最烦哪个按钮，问开发改代码最头疼哪个环节，问运维半夜报警最常碰到哪个老bug。把这些最痛的点一个个拆出来，慢慢换，慢慢挪，比你上来就砸钱搞全量替换靠谱多了。