年入过亿遗留系统：技术债尽调与90天接手策略

有个做技术负责人的朋友前阵子来找我说他被安排去接手一套跑了十二年的老系统交接文档三页纸注释里还留着几任前主人的吐槽。他问我一句话这玩意儿一年能给公司带来亿元量级的收入我到底该不该接。我当时没直接回答先反问了他三个问题——维护这套系统的人现在还剩几个、线上出过的最严重事故是什么、业务方明年打算在这套系统上加多少新功能。他答完自己就沉默了。这就是遗留系统的典型处境它的代码质量和你肉眼看到的混乱程度跟它实际创造的价值几乎不成正比。标题里那套祖传系统年收入过亿、前程序员劝后来者赶紧退退退这种反差不是段子是很多团队真实会撞上的局面。我想把这件事拆开聊透为什么烂代码能赚钱、接手前该怎么尽调、什么情况下该退、什么情况下值得接、真接了前三个月该怎么活下来。不管你是刚被点名接盘的开发还是正在做技术决策的负责人这篇应该都能给你一点可落地的东西。1. 先别急着骂屎山跑了十二年的系统到底长什么样1.1 代码质量与商业价值从来不是一条曲线很多人脑子里的默认假设是代码烂系统就该烂业务就该垮。现实中这套系统活了十二年每年还在稳定产生亿元级收入说明它的烂是局部的、结构性的而不是全域崩溃。我见过的这类系统通常长这样主干是一个没人敢动的单体应用部署在两三台配置老旧的机器上数据库里有四百多张表其中一半以上的表名带_bak、_old、_tmp2这类后缀还有若干存储过程承担着核心的结算逻辑。前端页面用的是十年前那套模板引擎样式表里能翻出已经下线的浏览器前缀。CI 早就废了发布靠人手 scp 加上一份口口相传的清单。但另一边它每天处理着几万笔订单跟七八个外部系统对接里面沉淀了十二年积累下来的业务规则——哪个客户在什么条件下享受什么折扣、哪类订单在什么时点触发什么补偿、哪些字段的历史值是财务对账的唯一依据。这些东西大部分没有文档只存在于代码和那两三个老员工脑子里。所以评价这类系统得把代码可读性和业务承载能力分开看。代码可读性是工程师视角业务承载能力是商业视角。前者差到极致后者可能依然很强。你接手的是一个商业上已经被验证过的东西而不是一份需要重新评审的作业。1.2 那个1.4 亿背后system 处在什么位置收入数字本身不说明问题关键是这套系统在现金流链条上的位置。同样是年收入过亿系统可能处在三种完全不同的位置接手的难度天差地别。第一种是收单主链路钱直接从这个系统流过去它是收入的必经之路。这种系统动一行代码都要评估影响面任何改造都得走灰度、可回滚、双写比对风险最高但也最不能死。第二种是支撑系统它不直接收钱但支撑着收钱的业务比如订单履约、结算对账、客户资料。这类系统的价值在于它的数据是唯一真相源一旦出错会在几天后以财务差异的形式暴露出来排查成本极高。第三种是历史包袱业务早就迁走了只剩几个老客户还在用但因为合同或者数据合规的原因不能下线每年维护成本几十万收入贡献接近于零。这种才是真的该劝退。判断标准很朴素把这套系统的域名解析切走一小时看看有多少人打电话来找你。如果电话被打爆那它就在主链路上如果一整天没人发现那它多半是第三种。我一般建议在接手前做这个小实验当然要挑低峰期并且提前跟业务方打招呼但这个信息量比读一百页交接文档都大。1.3 为什么能跑就别动在商业上是理性选择工程视角看能跑就别动是懒惰商业视角看它是风险定价的结果。假设这套系统年收入一亿日活用户十万全年在线率 99.9%。你想做一次架构重写行业里常见的重写项目平均超期 50% 以上期间还要双跑两套系统人力投入翻倍。更关键的是重写期间你不能停业务意味着所有新需求还得在老系统上做两头都要人。很多公司算完这笔账结论就是维护成本哪怕每年五百万也比重写便宜。这不是技术判断是财务判断。你可以不认同但你得理解决策者的算盘。真正让工程师憋屈的地方在于明明是技术债最后承担风险的是写代码的人做决策的人却不用半夜起来处理告警。这个错位才是劝退情绪的根源而不是代码本身有多难看。2. 这类系统能活十二年的三个真实原因2.1 它把业务规则焊死在了代码里遗留系统最值钱的资产往往不是代码结构而是那些从来没被写进需求文档的隐性规则。举个具体例子。一套跑了多年的结算系统里有个字段叫adjust_flag类型是字符串取值有Y、N、1、空字符串四种。新人一看就懵问为什么不用布尔。老员工告诉你Y是正常调整N是不调整1是当年某个大客户要求的特殊标记空字符串代表这条记录是补录的不参与本期结算。这四种状态的组合还对应着财务系统里四种不同的凭证类型。这种东西你在任何设计文档里都找不到它是十二年间一次次业务谈判、一次次临时补丁堆出来的。重写的时候如果你不知道这些规则存在新系统上线第一天就会出错而且是财务级的错误几万条记录对不上账。所以我评价一个遗留系统会特别关注这类语义密度高的地方字段枚举值、异常分支、硬编码的常量、被注释掉的代码块往往注释里写着临时方案勿删。这些地方既是地雷也是地图。谁能读懂它们谁就掌握了这套系统的真正知识。2.2 数据资产比代码更难迁移代码可以重写数据不能重来。一套跑了十二年的系统数据库里通常有几千万到几亿条业务记录这些记录之间形成了大量隐性关联订单和退款通过某个中间表关联、客户等级是根据历史消费额实时算出来的、某些统计报表依赖特定时间点的快照数据。这些关联没有外键约束全靠代码逻辑维持。你想迁移数据会立刻遇到几个问题字段语义不明status有 27 种取值每种代表什么没人说得全、历史数据不完整某些年份的记录有缺失、脏数据需要清洗手机号字段里混着身份证号。更麻烦的是业务方会要求迁移后所有历史报表数字必须完全一致一分钱都不能差。我见过一个团队做数据迁移前后花了八个月最后卡在三年前的某张报表对不上两毛钱上查了两周发现是老系统有个四舍五入的 bug一直没人发现但报表早就按这个错的值发出去了。这种坑不亲自趟一遍根本想不到。2.3 更换成本被严重低估大部分要不要重写的讨论只算了开发成本没算这几块成本项常见低估程度说明双跑期的运维成本低估 2 到 3 倍两套系统同时跑数据要双向同步出问题要判断是哪边的锅业务方的适应成本几乎完全忽略界面变了、操作流程变了一线人员会抵触培训成本高停机窗口的协调成本低估核心系统停机需要跨部门审批窗口往往只有几小时过渡期的口径解释成本几乎完全忽略新旧系统算出来的数字不一致时需要有人向财务和客户解释团队的机会成本低估重写期间没法做新业务竞争对手在往前跑把这些加进去你会发现很多技术上应该重写的项目商业上确实不该现在重写。这不是给烂代码找借口是承认工程决策必须放进商业约束里做。3. 接手前的尽调我通常先看这六件事如果有人拿着交接文档来找我说这套系统以后归你了我会在签字之前做一轮技术尽调。这轮尽调不需要你读懂代码目的是判断这套系统的可维护性余量还有多少。3.1 代码体量与活跃度先搞清楚是死水还是活水第一步不是读代码是看仓库的提交历史。几个命令就能拿到关键信息# 最近一年的提交频率判断系统是否还在活跃演进 git log --since1 year ago --oneline | wc -l # 最近一年的提交作者分布看知识集中度 git shortlog -sn --since1 year ago # 最近半年改动最频繁的文件这些是热点也是风险点 git log --since6 months ago --name-only --prettyformat: | sort | uniq -c | sort -rn | head -30如果最近一年提交数在三五百次作者集中在两三个人身上那这套系统是活的但知识高度集中那两三个人一走你就抓瞎。如果最近一年提交数不到二十次基本是死水维护成本低但改造风险高因为没人验证过它。如果提交数上千但作者有十几个人那要小心可能是在打补丁式地救火。代码量用tokei或cloc统计一下重点看单个文件的平均行数和最大文件行数。一个五千行的单文件类基本可以判断当年是赶工出来的。这不是为了鄙视前人是为了预估你改动时的影响面。3.2 构建链路能不能复现这一步过不了后面全是空谈这是我最看重的一环也是最容易被忽略的。简单说就是给你一台干净的机器你能不能把系统跑起来。很多遗留系统的构建链路是断的依赖的某个内部库已经找不到源码了、包管理器的源已经下架了、某个编译工具只支持旧版操作系统、配置文件散落在各台服务器的/home目录下。我一般会要求对方当着我的面做一次完整构建。如果做不到那就要问清楚现在的生产包是怎么打出来的。如果答案是某某的电脑上打那这就是最大的风险点——那个人休假的时候整个团队都没法发版。这一步的判断很干脆构建不可复现就不要接手或者接手后第一件事就是把它变成可复现的。这不是技术洁癖是生存底线。3.3 数据库的黑盒程度四百张表里有多少是活的数据库是遗留系统里最难搞的部分。我会直接连上去看几个指标表的总数以及最近半年有过写入的表数量对比一下就知道有多少僵尸表存储过程和触发器的数量超过五十个就要警惕业务逻辑藏在数据库里是最难维护的形态定时任务的数量和调度方式是 crontab 还是数据库作业有没有监控主从复制和备份策略有没有验证过恢复多久做一次演练还要问一个关键问题有没有人能在测试环境把生产数据脱敏后导入复现一个线上问题。这个能力如果没有那你排查问题就只能靠猜和加日志效率差好几倍。3.4 人谁是这套系统的人形文档技术尽调里最容易被忽视、但权重最高的一项是人的因素也就是知识分布。我会列一份名单把能改动这套系统的人按熟悉程度排个序然后看两件事第一排序第一的人离职后系统还能不能维护第二这套知识有没有可能在一个月内传递给新人。如果答案是只有某一个人能改核心模块那这套系统的实际价值要打个折。因为这个人一旦离开系统就从年入过亿的资产变成随时可能停摆的风险源。这时候你要做的不是接手代码是接手人。3.5 线上事故记录过去踩过的坑就是未来的坑让对方把最近两年的一级、二级事故记录调出来重点看三件事事故的根因分布、平均恢复时长、有没有重复发生的事故。重复发生的事故最能说明问题。同一类问题一年出三次说明根本不是技术难题是流程或者责任心的问题你接手后大概率还会继续出。根因集中在配置错误、人为操作这类说明缺少自动化和防护集中在容量、性能这类说明架构确实到了瓶颈集中在数据不一致那就是前面说的隐性业务规则没被理解透。3.6 业务方的真实诉求他们到底想让你干什么这一项经常被工程师忽略但它决定了你接手后的日子好不好过。你要搞清楚业务方是想让这套系统稳定别出事还是想让它支撑新业务。这两个诉求对应完全不同的技术策略。前者你只需要加监控、做防护、小步修复后者你必须做架构改造风险和投入都是数量级的差别。很多劝退帖里说的接盘就等着背锅本质上是接盘的人被要求既要稳定又要快速迭代而资源只够做其中一件。这种矛盾在你签字前就该摆到桌面上。4. 该接还是该退一张判断表把上面六项尽调的结果整理一下我一般会用这张表做最后的判断。每一项给一个粗粒度的评级然后看整体分布。判断维度绿灯值得接黄灯谨慎接红灯赶紧退系统在现金流中的位置主链路收入贡献明确支撑系统间接受益已无业务价值只剩合同约束构建可复现性一条命令能构建需要手工步骤但有人会依赖已丢失只能在某台机器上打知识分布至少三人熟悉核心模块两人其中一个准备转岗只有一人且此人已提离职事故记录近两年无重复性事故有零星事故但根因清晰同类事故一年内重复三次以上测试与监控有基础监控和回归手段只有监控没有自动化测试两者皆无靠用户反馈发现问题业务诉求稳定优先节奏可控稳定加少量新功能要求同时稳定和快速迭代资源不变代码体量能定位到具体模块混乱但有边界单文件数千行无模块划分无版本管理看这张表的方法不是数绿灯数量而是看有没有红灯。只要出现两个以上红灯我的建议都是不要接或者接了之后先谈条件。红灯的意义在于它代表的不是难而是你无法控制的风险。比如构建不可复现意味着你连发版都做不到知识只有一人意味着你一接手就处在单点故障上业务要求既稳定又快速意味着你注定要在某一边背锅。这些不是靠努力能解决的是结构性的。反过来如果一张表里全是黄灯、没有红灯那这套系统其实是可救的。它的痛点很明确改造路径也清晰反而是能做出成绩的地方。我见过好几个团队就是在这种系统上做出名声的——因为烂得明显改好一点点都是肉眼可见的收益。有个反直觉的经验**越是骂声一片的系统越可能是个好机会。**因为预期已经被拉到最低你只要能把它从随时可能挂变成基本稳定在业务方眼里就是天大的功劳。而那些本来就跑得不错的系统你接过去不出事是应该的出了事就是你的问题。5. 真接了前九十天的降温式做法假设你评估完决定接或者没得选只能接。那前三个月的策略非常关键走错一步可能就直接背锅。我的建议是前九十天不改业务逻辑只做降温和加固。5.1 第一周把运行环境钉死让系统可以被重建第一件事不是读代码是让这套系统变得可以重新搭建出来。具体做法先在虚拟化层面做一次完整快照把生产环境的所有配置、依赖版本、环境变量、证书、定时任务清单全部导出存到版本库里。注意是存到版本库不是存在某个人的电脑上。然后用容器或者配置管理工具把这套环境描述成代码。哪怕你只是写一个Dockerfile把旧版本的运行时、依赖包版本、启动脚本固化下来价值也极大。这一步的核心目标是任何一个人拿到这个仓库能在一台新机器上把系统跑起来。这一步听起来基础但很多遗留系统做不到。而它一旦做到后面所有的改造才有了立足点。我见过一个团队光做这一步就花了两周但做完之后发版时间从半天加两个人变成二十分钟一个人。配套还要做一件事把所有只在某个人脑子里的操作步骤写下来包括怎么发版、怎么回滚、怎么重启、怎么清理缓存。写成文档最好写成脚本。这份文档的价值比任何架构图都高。5.2 第二到第四周先加观测别急着改代码接下来不是重构是加观测。你需要先看清这套系统在干什么。最低限度要加三样东西访问日志、错误日志、关键业务指标的监控。访问日志记录每个请求的入口、耗时、结果错误日志要把异常堆栈完整打出来并集中收集业务指标则要盯着最核心的那几个数字比如每分钟订单数、支付成功率、结算批处理的完成时间。# 一个最小可用的请求埋点示例思路比代码重要 import time import logging logger logging.getLogger(legacy.access) def timed(handler): def wrapper(request): start time.time() try: result handler(request) cost (time.time() - start) * 1000 logger.info( path%s statusok cost_ms%.1f user%s, request.path, cost, request.user_id ) return result except Exception as exc: cost (time.time() - start) * 1000 logger.exception( path%s statuserror cost_ms%.1f, request.path, cost ) raise return wrapper加完之后跑一到两周你会得到一份真实的调用分布哪些接口是热路径、哪些接口根本没人调、哪些接口慢得离谱。这份数据是后面所有决策的依据。这里有个经验**遗留系统的性能问题八成集中在不到两成的代码上。**你不需要优化全部只需要找到那几个热点。而找热点靠的不是读代码是看数据。5.3 第五到第八周给核心逻辑补特征测试这是遗留系统改造里最有效的一招叫特征测试characterization test。它的目的不是验证代码对不对而是把代码现在的行为锁住这样你后续重构时一旦行为变了就能立刻发现。做法是挑出最核心的三到五个业务场景比如下单、退款、结算批处理然后针对这些场景写测试。测试的期望值不是你想当然的正确答案而是你实际跑出来的当前结果。哪怕这个结果看起来很奇怪你也先把它固化成基线。举个例子。你发现某个折扣计算函数输入某个组合会返回一个负数。这明显是个 bug但你不能直接修因为你不知道有没有下游系统依赖这个负数。正确做法是先写测试把这个负数行为记下来然后去查这个值最终流向哪里。查清楚之后再决定是修还是保留。这一步的意义在于它把一个不敢动的黑盒变成了一个动了会报警的白盒。后面你每改一次代码跑一遍这套测试就知道有没有破坏原有行为。这是接手遗留系统时最划算的投入没有之一。5.4 第九十天的分岔口什么时候可以动核心三个月后你手上应该有了这些东西可复现的构建、基础的监控、核心场景的回归测试、一份真实的调用分布图。这时候才能谈改造。改造的顺序我的建议是从外往里剥先动那些没人调用的接口和页面直接下线减少维护面。再动独立性强的边缘模块把它抽出来单独部署风险可控。最后才动核心链路而且必须是渐进式的——先做双写、再做流量灰度、再切读、最后切写每一步都要有回滚预案。千万不要一上来就做架构升级或者框架替换。框架替换在遗留系统上是最容易翻车的操作因为它会同时改变几百个文件的依赖关系而你根本不知道哪些地方踩了旧框架的坑。等你发现的时候业务已经停了两小时。6. 劝退的声音里哪些是清醒的哪些是情绪6.1 那些确实该听的警告赶紧退这句话有些时候是对的而且理由很硬。第一种情况是你被要求承接不属于你的责任。比如系统原本就不稳定让你接手的同时还压一个三个月内不能出事故的指标但资源不给你加。这种局面下出事只是时间问题而责任在你。第二种情况是单点知识且无法转移。整个系统只有一个人能改这个人还不愿意配合交接或者公司没打算让他配合。你接手等于接了个定时炸弹。第三种情况是投入产出明显不划算。系统年收入已经很有限维护成本却居高不下业务方也没打算继续投入。这种系统最好的归宿是下线或者冻结接它纯属消耗自己。第四种情况是技术栈已经彻底断供。运行环境依赖的组件连官方安全更新都没了机器坏了都修不了这种情况下维护成本会随时间指数上升。这已经不是技术债是技术资产在贬值。这四种情况我会明确建议不要接或者接之前把条件谈清楚。谈条件的重点不是涨薪是明确我要什么资源、什么权限、什么时间。6.2 那些其实是情绪的抱怨但也有很多劝退是情绪驱动的具体表现是把代码写得丑等同于系统没救。代码丑和系统不可维护是两件事。我见过格式混乱、命名随意的代码库但它的模块边界其实很清楚改起来并不难也见过写得非常工整、注释齐全的系统但各个模块之间通过数据库表强耦合一改就全崩。判断可维护性看的是耦合度和可观测性不是代码风格。风格问题你花两周统一格式化就能解决耦合问题要花半年。还有一种情绪是前人写的都是错的。这种心态很危险因为你会不自觉地想推翻重来。而遗留系统里那些看起来莫名其妙的代码往往对应着某个你不了解的业务约束。你在没搞清楚原因之前就删掉它下一周可能就会收到一个线上问题单。我自己的习惯是看到一段奇怪的代码先假设它是有原因的然后去查它为什么存在。查清楚之后如果确认是历史遗留的无效逻辑再删。这个习惯帮我避免过好几次事故。6.3 我自己的取舍标准踩过几次坑之后我形成了一个比较简单的判断框架三句话看这套系统还能不能赚钱如果还能它就有维护价值看这套系统还能不能改如果不能先解决可维护性再谈其他看这套系统出事之后谁会疼如果没人疼那它就该被砍掉。第一句是商业判断第二句是技术判断第三句是组织判断。三个判断都通过才值得投入。任何一个不通过都要重新考虑。至于屎山这个说法我现在的理解是它描述的是代码的形态不是系统的价值。一座山能不能爬不取决于它难不难看取决于你有没有装备、有没有路线、有没有队友。装备是工具链路线是改造方案队友是团队。这三样齐了再丑的山也能上去。最后分享一个我自己一直在用的小技巧接手任何老系统先花半天时间把它的数据流画出来不用画架构图就画数据从哪儿进、经过哪几张表、从哪儿出。画完之后你会发现很多看起来复杂的系统核心链路其实只有四五条。搞清楚这几条你对这套系统的掌控感会立刻不一样至少半夜被叫起来的时候你知道该看哪张表。