企业官网建设流程全解析

有个做技术负责人的朋友前阵子来找我，说他被安排去接手一套跑了十二年的老系统，交接文档三页纸，注释里还留着几任前主人的吐槽。他问我一句话：这玩意儿一年能给公司带来亿元量级的收入，我到底该不该接。我当时没直接回答，先反问了他三个问题——维护这套系统的人现在还剩几个、线上出过的最严重事故是什么、业务方明年打算在这套系统上加多少新功能。他答完，自己就沉默了。

这就是遗留系统的典型处境：它的代码质量和你肉眼看到的混乱程度，跟它实际创造的价值几乎不成正比。标题里那套"祖传"系统年收入过亿、前程序员劝后来者"赶紧退退退"，这种反差不是段子，是很多团队真实会撞上的局面。我想把这件事拆开聊透：为什么烂代码能赚钱、接手前该怎么尽调、什么情况下该退、什么情况下值得接、真接了前三个月该怎么活下来。不管你是刚被点名接盘的开发，还是正在做技术决策的负责人，这篇应该都能给你一点可落地的东西。

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 更换成本被严重低估

大部分"要不要重写"的讨论，只算了开发成本，没算这几块：

把这些加进去，你会发现很多"技术上应该重写"的项目，商业上确实不该现在重写。这不是给烂代码找借口，是承认工程决策必须放进商业约束里做。

3. 接手前的尽调：我通常先看这六件事

如果有人拿着交接文档来找我，说这套系统以后归你了，我会在签字之前做一轮技术尽调。这轮尽调不需要你读懂代码，目的是判断这套系统的"可维护性余量"还有多少。

3.1 代码体量与活跃度：先搞清楚是"死水"还是"活水"

第一步不是读代码，是看仓库的提交历史。几个命令就能拿到关键信息：

# 最近一年的提交频率，判断系统是否还在活跃演进 git log --since="1 year ago" --oneline | wc -l # 最近一年的提交作者分布，看知识集中度 git shortlog -sn --since="1 year ago" # 最近半年改动最频繁的文件，这些是热点，也是风险点 git log --since="6 months ago" --name-only --pretty=format: | 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 status=ok 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 status=error cost_ms=%.1f", request.path, cost ) raise return wrapper

加完之后跑一到两周，你会得到一份真实的调用分布：哪些接口是热路径、哪些接口根本没人调、哪些接口慢得离谱。这份数据是后面所有决策的依据。

这里有个经验：**遗留系统的性能问题，八成集中在不到两成的代码上。**你不需要优化全部，只需要找到那几个热点。而找热点靠的不是读代码，是看数据。

5.3 第五到第八周：给核心逻辑补"特征测试"

这是遗留系统改造里最有效的一招，叫特征测试（characterization test）。它的目的不是验证代码"对不对"，而是把代码"现在的行为"锁住，这样你后续重构时，一旦行为变了就能立刻发现。

做法是：挑出最核心的三到五个业务场景，比如"下单"、"退款"、"结算批处理"，然后针对这些场景写测试。测试的期望值不是你想当然的正确答案，而是你实际跑出来的当前结果。哪怕这个结果看起来很奇怪，你也先把它固化成基线。

举个例子。你发现某个折扣计算函数，输入某个组合会返回一个负数。这明显是个 bug，但你不能直接修，因为你不知道有没有下游系统依赖这个负数。正确做法是：先写测试把这个负数行为记下来，然后去查这个值最终流向哪里。查清楚之后再决定是修还是保留。

这一步的意义在于，它把一个"不敢动"的黑盒，变成了一个"动了会报警"的白盒。后面你每改一次代码，跑一遍这套测试，就知道有没有破坏原有行为。这是接手遗留系统时最划算的投入，没有之一。

5.4 第九十天的分岔口：什么时候可以动核心

三个月后，你手上应该有了这些东西：可复现的构建、基础的监控、核心场景的回归测试、一份真实的调用分布图。这时候才能谈改造。

改造的顺序，我的建议是从外往里剥：

先动那些"没人调用"的接口和页面，直接下线，减少维护面。再动"独立性强"的边缘模块，把它抽出来单独部署，风险可控。最后才动核心链路，而且必须是渐进式的——先做双写、再做流量灰度、再切读、最后切写，每一步都要有回滚预案。

千万不要一上来就做"架构升级"或者"框架替换"。框架替换在遗留系统上是最容易翻车的操作，因为它会同时改变几百个文件的依赖关系，而你根本不知道哪些地方踩了旧框架的坑。等你发现的时候，业务已经停了两小时。

6. 劝退的声音里，哪些是清醒的哪些是情绪

6.1 那些确实该听的警告

"赶紧退"这句话，有些时候是对的，而且理由很硬。

第一种情况是你被要求承接不属于你的责任。比如系统原本就不稳定，让你接手的同时还压一个"三个月内不能出事故"的指标，但资源不给你加。这种局面下，出事只是时间问题，而责任在你。

第二种情况是单点知识且无法转移。整个系统只有一个人能改，这个人还不愿意配合交接，或者公司没打算让他配合。你接手等于接了个定时炸弹。

第三种情况是投入产出明显不划算。系统年收入已经很有限，维护成本却居高不下，业务方也没打算继续投入。这种系统最好的归宿是下线或者冻结，接它纯属消耗自己。

第四种情况是技术栈已经彻底断供。运行环境依赖的组件连官方安全更新都没了，机器坏了都修不了，这种情况下维护成本会随时间指数上升。这已经不是技术债，是技术资产在贬值。

这四种情况，我会明确建议不要接，或者接之前把条件谈清楚。谈条件的重点不是涨薪，是明确"我要什么资源、什么权限、什么时间"。

6.2 那些其实是情绪的抱怨

但也有很多"劝退"是情绪驱动的，具体表现是：把"代码写得丑"等同于"系统没救"。

代码丑和系统不可维护，是两件事。我见过格式混乱、命名随意的代码库，但它的模块边界其实很清楚，改起来并不难；也见过写得非常工整、注释齐全的系统，但各个模块之间通过数据库表强耦合，一改就全崩。

判断可维护性，看的是耦合度和可观测性，不是代码风格。风格问题你花两周统一格式化就能解决，耦合问题要花半年。

还有一种情绪是"前人写的都是错的"。这种心态很危险，因为你会不自觉地想推翻重来。而遗留系统里那些看起来莫名其妙的代码，往往对应着某个你不了解的业务约束。你在没搞清楚原因之前就删掉它，下一周可能就会收到一个线上问题单。

我自己的习惯是：看到一段奇怪的代码，先假设它是有原因的，然后去查它为什么存在。查清楚之后，如果确认是历史遗留的无效逻辑，再删。这个习惯帮我避免过好几次事故。

6.3 我自己的取舍标准

踩过几次坑之后，我形成了一个比较简单的判断框架，三句话：

看这套系统还能不能赚钱，如果还能，它就有维护价值；看这套系统还能不能改，如果不能，先解决可维护性再谈其他；看这套系统出事之后谁会疼，如果没人疼，那它就该被砍掉。

第一句是商业判断，第二句是技术判断，第三句是组织判断。三个判断都通过，才值得投入。任何一个不通过，都要重新考虑。

至于"屎山"这个说法，我现在的理解是：它描述的是代码的形态，不是系统的价值。一座山能不能爬，不取决于它难不难看，取决于你有没有装备、有没有路线、有没有队友。装备是工具链，路线是改造方案，队友是团队。这三样齐了，再丑的山也能上去。

最后分享一个我自己一直在用的小技巧：接手任何老系统，先花半天时间把它的"数据流"画出来，不用画架构图，就画数据从哪儿进、经过哪几张表、从哪儿出。画完之后你会发现，很多看起来复杂的系统，核心链路其实只有四五条。搞清楚这几条，你对这套系统的掌控感会立刻不一样，至少半夜被叫起来的时候，你知道该看哪张表。