屎山的鲁棒性：为什么烂代码反而更稳定？

“这系统烂得跟屎一样，但稳得一批。”

这句话我听过无数次，自己也说过无数次。在座各位但凡在大厂待过，或者在一家有一定历史的中小公司里做过核心系统的维护，大概率都有类似的体验。新来的同事翻着祖传代码眉头紧锁，一边骂一边改，改完上线就炸，炸完回滚，然后大家达成一个默契——这块儿谁也别碰。讽刺的是，恰恰是这种“谁也别碰”的状态，让这套屎山系统在线上稳定运行了好几年，任凭业务流量怎么波动、服务器怎么迁移、上游接口怎么调整，它都像一个老僧入定一样，岿然不动。

这就是我今天想聊的话题：屎山的鲁棒性。

鲁棒性这个热词，英文是 robustness，在系统设计里指的是系统在面对异常输入、外部扰动、内部故障时，依然能维持核心功能的能力。按理说，一套代码混乱、结构腐化、文档缺失的屎山系统，应该是鲁棒性的反面教材才对。但现实给了我们一记响亮的耳光——屎山往往比精心设计的绿地系统更“结实”。这篇文章就想把这个反直觉的现象拆开揉碎了讲讲，聊聊屎山的鲁棒性到底从哪来，它靠什么机制维持稳定，这种稳定有什么代价，以及我们这些常年跟屎山打交道的人，该怎么在夹缝里求生存、甚至反过来利用这种稳定性。

不管你是刚入职就要维护老系统的萌新，还是已经跟遗留系统缠斗多年的老油条，这篇文章都值得你花十分钟读完。不敢说能帮你把屎山铲平，但至少能让你们重新认识脚下这座山，知道它为什么这么扛揍，也知道它什么时候会真的塌。

1. 屎山为什么“烂而不倒”：鲁棒性的本质

一提到屎山，大家脑子里浮现的都是什么？面条一样的代码、几百行的大方法、全局变量满天飞、没有任何测试、部署靠手工、监控靠玄学。任何一个受过专业训练的程序员看到这些东西，第一反应都是“这玩意儿不配存在”，第二反应是“我要重写它”。但如果你真的把这座山推翻重来，大概率会死得很惨。为什么？因为屎山有一种反直觉的稳定机制。

1.1 屎山的第一重鲁棒性：耦合带来的“静态稳定”

屎山系统最大的特点就是耦合度高。模块之间没有清晰的边界，A模块直接访问B模块的全局变量，B模块又去改C模块的数据库表，C模块还顺带调用了一下A模块的静态方法。这种代码，任何人看了都会血压升高。但恰恰是这种高耦合，造就了一种特殊的“静态稳定”。

打个比方，一栋违章搭建的楼房，钢筋乱接、承重墙被砸了改门洞、阳台往外飘出去两米。你让结构工程师来看，他会告诉你这楼随时可能塌。但实际上这楼可能住了一二十年了，除了偶尔掉点墙皮，屁事没有。因为每一根乱接的钢筋都在互相拉扯，形成了一种微妙的受力平衡。你要是真按规范去“加固”某一根柱子，反而可能导致整体受力重新分布，让楼瞬间垮掉。

屎山就是这样。那个几百行的大方法，虽然读了想吐，但它内部的所有局部变量、分支条件、异常处理都是互相咬合的。你看着某个 if 条件很蠢，删掉之后才发现，原来那个条件在某个远古的业务场景里兜住过一个你不知道的坑。你试图把一个大方法拆成几个小方法，结果发现在拆的过程中，你处理的不是代码逻辑，而是一张几十个变量在手写作用域里互相纠缠的关系网。这种系统，你不去动它，它就能一直跑下去。

我印象特别深的一件事，是有一次我接手一个老系统，发现一个方法有四百多行，里面嵌套了八层 if，但这个方法稳定运行了六年，零事故。后来因为业务调整，需要在这个方法里加一个分支，我小心翼翼地加完，自测通过，提测，结果测试环境直接崩溃。查了半天，原来是这个方法内部对某个全局变量的修改顺序有着隐性的依赖，我的新分支提前触发了一个本该在最后才执行的赋值。你说这代码烂吗？烂。但你敢说它不稳定吗？它在它的运行环境里，有着极其精确的执行顺序，动一步就崩。

后来我想明白了一个事儿：屎山的“鲁棒性”，本质上是复杂度够高之后，任何微小的改动都难以正确落地，所以系统被“冻结”在了当前的状态。改动进不来，问题自然也就不增加，线上自然就稳定。这是一种以“不可能再变坏”为代价的“稳定”，我管它叫“静态稳定”。

1.2 屎山的第二重鲁棒性：隐性知识的分布式存储

屎山能运行，往往不是因为代码写得对，而是因为有一群“知道它哪里不对但不知道怎么改对”的人，用脑子里的经验把它给“喂”住了。

这类系统最大的特点是文档基本为零，代码里的注释少得可怜，有注释的地方也全是“不要动这个”“神奇，别改”这类毫无信息量的话。但系统就是能跑。为什么？因为运维这套系统的人，脑子里装着一张完整的地图。他知道这个定时任务每个小时跑一次，偶尔会重复执行导致数据重复，所以每次跑完之后要去数据库里手工清理一下；他知道那个接口偶尔会超时，超时之后重试就能成功，因为对方系统的缓存刚好过期；他知道某个配置文件千万不能动，因为里面有个值一旦改了，整个报表模块都会算错。

我把这种知识称为“隐性知识”。它不在代码里，不在文档里，也不在任何人能轻易访问的地方，它分布在每一个维护过这套系统的人的脑子里、聊天记录里、甚至某一个离职同事留下的一个便签上。

这种分布式存储的隐性知识，反而形成了一种鲁棒性。只要还有老人在这，系统出任何问题，都能在几分钟内被定位到“哦，肯定又是那个老毛病，去把那张表的数据清一下就好”。新人虽然不懂原理，但他会照着老人说的做。于是系统就像一个黑盒，外面的人看不懂，但里面的人知道怎么伺候它。

但这里有个巨大的隐患——这种鲁棒性是脆弱的。它不是系统本身的鲁棒性，而是“人肉运维”的鲁棒性。一旦老人离职、聊天记录清空、便签丢失，这套系统的“知识库”就出现了黑洞，届时它就会从“稳定的屎山”变成“随时爆炸的屎山”。我后面会详细讲怎么应对这个问题。

1.3 屎山的第三重鲁棒性：业务压力的反向筛选

还有一个角度很多人忽略：屎山能活到今天，本来就是被业务反复筛选过的结果。

你想啊，一个系统如果能长期运行，说明它经过了业务高峰期、低峰期，经历了数据量的增长、功能的迭代、人员的流动。在这个过程中，所有特别烂的功能、特别容易挂的模块，大概率早就被重写或者下线了。还留在屎山里的，往往是“虽然烂，但扛得住现有关键业务”的部分。

换句话说，屎山的鲁棒性不是设计出来的，是业务倒逼出来的。就像自然选择一样，那些设计得漂亮但扛不住真实压力的模块，早就在线上事故中被干掉了；剩下这些丑陋但耐操的模块，才是经过真实流量考验的幸存者。

举一个很简单的例子：我们系统里有一个老旧的导入功能，代码写得一团糟，逻辑各种绕，但是它能导入单表几十万行数据的 Excel，而且不依赖任何第三方组件。后来有人看不下去，用新的框架重写了一个导入模块，界面漂亮、代码优雅、测试全覆盖，结果一上线，几千行的文件就内存溢出，折腾了两周都没搞定。最后大家发现，老模块虽然丑，但它在多年迭代中，早就对各种奇葩格式、脏数据、超大文件做过隐式处理，只是这些处理逻辑都埋在那坨乱码里，没人理得清而已。

所以，屎山的鲁棒性，其实是一种真实的、接地气的鲁棒性。它不是什么高深的架构设计，纯粹是一堆人花了无数个日夜，在线上事故、临时抢救、紧急修复中，用血肉之躯给系统打满了补丁，最终让系统变得“耐揍”。漂亮的新系统没有经历这些，反而一碰就碎。

这种反差，每一次都让我觉得特别微妙。它提醒我，评价一套系统的时候，真的不能只看代码质量，更要看它承载了多少看不见的历史和教训。

2. 拆解屎山鲁棒性的来源：四个关键机制

前面聊了屎山鲁棒性的整体感受，这一节我想更系统一点，把支撑这种鲁棒性的底层机制拆开来看。我会从测试缺失、兼容性约束、康威定律和冗余备份四个角度来说，这样大家在真实工作里，能更快地识别“哪块儿屎山是宝，哪块儿又确实该拆”。

2.1 测试缺失与改动的“风险溢价”

屎山系统里最普遍的现象就是没有自动化测试。一个模块几十个接口，可能只有最初上线时写过一个冒烟脚本，之后六年再也没动过。

按理说，没测试的系统应该更脆弱、更容易挂才对。但换个角度看，没有测试，意味着没有人敢改这块代码。不改，就不会引入新的问题。这在很多老系统里，反而成了维持稳定的一个重要因素。

这就形成了一种“风险溢价”机制：如果你想动屎山里的某段逻辑，你不能只评估改动本身的影响，你还要付出“没有测试兜底”这个额外的风险成本。改动带来的收益，必须显著大于这笔风险溢价，才有合理理由去碰它。大多数情况下，收益根本覆盖不了风险，于是大家选择不动。

这套机制虽然是无奈之举，但它确实过滤掉了大量低质量的改动。试想一下，如果屎山有一套完整的单元测试，那么任何程序员都可以在一个下午之内把某个业务逻辑改得面目全非，只要测试全绿就敢上线。改动成本低了，改动数量就会增加，出错的概率反而会上升。屎山没有测试，反而是给所有改动加了一道无形的闸门——你必须真的搞清楚自己在干什么，才敢动手。

当然，我这么说不是鼓励大家不写测试。我只是想说，屎山系统的“无测试”状态，实际上已经和它自身的高复杂度形成了一种诡异的平衡。如果你贸然打破这个平衡（比如强行补了一套测试），却没能理解系统真实的行为逻辑，测试反而会给你虚假的安全感，让你敢改那些不该改的东西。

2.2 兼容性负担积累的“反向保险”

屎山系统还有一个特点：它背负着沉重的兼容性负担。对各种历史数据格式兼容、对老版本接口兼容、对上游某个已经淘汰的系统的兼容……这些东西在代码里留下了大量“看起来没必要存在”的分支。

但从鲁棒性角度讲，这些兼容性分支，反而是系统“活得久”的关键。

举个例子：我们系统里有一个接口，接收一个报文，报文头里有一个字段叫 version，取值范围从 1.0 到 5.2。代码里针对每个版本都有单独的处理逻辑，特别冗长，完全看不到重构的希望。但从业务角度讲，如果哪天某个上游老系统突然又发出 2.0 版本的报文，这套接口依然能正确处理。这在功能迭代如此快的行业里，简直是一个奇迹。

这些兼容性逻辑，本质上是系统对“历史不确定性”的缓冲。它没有设计文档，没有统一规范，但它在真实运行中，确确实实地兜住了各种过时、异常、不标准的输入。用工程化的语言说，这套系统具备非常强的向后兼容性，而这种向后兼容性，就是它的鲁棒性的一部分。

新系统通常不背这些历史包袱，所以它们更简洁、更高效。但一旦遇到不在预期之内的数据形态，就很容易出问题。屎山呢？它什么都见过，什么都不挑，所以它几乎不会被“意外”击倒。

2.3 组织结构与系统的“镜像效应”

康威定律说得很清楚：系统设计的结构，最终会等同于创造它的组织的沟通结构。屎山的混乱，很多时候就是组织混乱的投射。

一个团队换了好几拨人，每拨人都有自己的编程风格和架构理念；几个部门共用一个系统，每个部门的需求都在往里面塞；外包团队开发完之后直接交付，没有任何知识转移；新来的领导执着于某个技术栈，于是遗留代码和新技术栈并行存在……这些组织层面的因素，最终都会一丝不苟地反映在系统代码上。

但有趣的是，这种混乱的组织结构，反而会让系统的“政治生态”变得非常稳定。

部门A的代码，部门B不敢动；外包团队留下的模块，正式的同事不愿意碰；某个元老写的核心逻辑，新人没有胆量重构。正因为每个模块都有它的“主人”，每次改动都需要跨团队协调，所以系统内部的模块边界反而变得非常清晰——虽然不是按架构划分的，但按“谁碰谁负责”划分的。这种边界，虽然丑陋，但很稳定。

我见过一个极端的例子：一个系统里有三个模块，分别由三个不同的部门负责。这三个部门之间几乎没有技术沟通，各自在自己的代码库里做修改，中间靠消息队列和数据库表偶合在一起。有一次，一个部门想重构自己的模块，但因为会影响另外两个部门的数据格式，沟通了三个月也没谈拢，最后只能放弃。当时我们都觉得这是巨大的内耗，但现在回头看，正是因为这种“谁也别想动别人的地盘”的格局，系统在过去五年里没有出现过一次跨部门引发的生产事故。

所以，当你觉得一套屎山的模块边界烂得一塌糊涂时，不妨想想它背后的组织结构。往往不是代码乱造成了混乱，而是组织本身就处在一种“此乱彼不乱”的状态。这种状态下的稳定性，不是偶然的，它是组织利益的平衡点在系统层面的投影。

2.4 冗余备份与“双保险”运作

屎山里还有一种容易被忽视的鲁棒性来源：大量的冗余和重复实现。

同一个业务逻辑，可能在系统中存在三份完全不同的实现。一份是最早的版本，一份是后来自研的版本，还有一份是第三方供应商做的版本。从代码质量角度，这是灾难；从鲁棒性角度，这反而是三重保险。

比如我们系统里有一个功能是理财产品的利息计算。最早的实现是银企直连接口返回结果，后来自研了一套本地计算逻辑，再后来为了合规做了一套新的余额计算中心。这三套逻辑并存，如果中间任何一套挂了，只要做一次开关切换，系统就能继续运行。虽然在需要维护三套逻辑时痛苦得要死，但它确实提供了极高的容错能力。

这种冗余的鲁棒性，在现实里的体验就是：系统偶尔出问题，但往往不会全挂，总有另一条路能走通。就像人体有两个肾脏，少了其中一个还能活；屎山系统也是这样，同一个功能有好几套“器官”，坏了一个，还有备胎顶上。

关键是，这种冗余不是谁刻意设计的，完全是业务发展过程中各种历史原因叠加的结果。从这个角度看，屎山虽然丑，但它无意中实现了“多活架构”的雏形。我们在维护系统时，要留心识别这些冗余实现。它们不一定全该砍掉，有些关键路径上的冗余，恰恰是系统的保命符。贸然去重，反而可能把系统从“多重保险”变成“单点故障”。

3. 在屎山里生存：实操经验分享

聊完了原理，咱们说点接地气的。毕竟大部分人没那个能力也没那个权限去推倒重来，我们就是要在屎山旁边讨生活。这一节分享的方法，我全都在真实项目里试过，踩过坑，也赚到过，希望能给面临同样处境的你一点帮助。

3.1 先画地图，再动手术：依赖关系可视化

第一步永远是搞清楚系统到底长什么样。这个过程我称之为“画地图”。

很多人一上来就翻源码，一头扎进某个具体方法里，结果是只见树木不见森林，改了半天发现自己改的这条路径根本不在主链路上。正确做法是先从上往下梳理系统的外部依赖和内部模块关系。

我会先拉一份系统所有接口的清单，然后逐个看每个接口的核心逻辑，记录它们访问了哪些数据库表、调用了哪些第三方服务、有没有定时任务在操作这些表。这些信息汇总起来，就能画出一张系统的简化版“地图”。有了地图之后，你才知道哪些区域是核心经络，哪些区域是可以断臂求生的冗余系统。

我自己的习惯是，在系统上线的前两周，不写任何业务代码，就是读代码、画图、整理文档。这两周看似没有产出，但后面每次改动，都能帮我至少省出一倍的时间。拿到一个任务，我只需要在地图上定位一下影响边界，就知道该碰哪些文件，不该碰哪些文件。

画地图的时候，建议用简单的文本、表格或者画图工具记录，不要用那种特别复杂的架构图工具，画出来没人维护，很快就过期了。我自己一般用 Markdown 文件维护一张“影响范围清单”，每次出问题或者改完需求，就更新一遍，时间长了，这就是一套比谁讲都靠谱的系统说明书。

3.2 黄金路径与绞杀者模式：不推翻的渐进重构

说句实话，屎山最大的问题不是代码烂，而是没人说得清“全部逻辑到底是什么”。所以任何想一次性搞定的重构，都是在赌博。我更推荐的是“绞杀者模式”——新建一个独立的服务/模块，慢慢把老系统里的逻辑一条一条迁移过去，每迁一条，老系统的对应功能就下线一条。整个过程像藤蔓绞杀大树，新系统在老系统旁边慢慢长大，最终取而代之。

这个模式最关键的一步，是找到系统的“黄金路径”。所谓黄金路径，就是业务最核心、使用频率最高、出问题影响最大的那几条主链路。先把这些主链路的逻辑吃得透透的，然后把它们逐个迁移到新系统。迁移的顺序应该是从风险最低的开始，逐步积累对新系统的信心，最后才碰那些最复杂、最核心的模块。

千万别一上来就迁最核心的模块。我刚入行时吃过这个亏，上来就想动支付链路，结果出了问题，差点成为事故责任人。后来学乖了，先挑一个边缘的报表模块试水，跑了一个月，稳定了，再往中间走。这个过程没有捷径，就是“小步快跑，每步都要稳”。

在迁移过程中，最好做“双写双读”的灰度验证：新老逻辑并行跑一段时间，对两边的结果做比对。如果结果一致，说明迁移正确；如果不一致，多半是细节没吃透，赶紧回头补课。这个过程很慢，但能保证迁移的过程中系统始终是稳的。

3.3 为老系统补测试：从“冒烟测试”到“特征测试”

前面我说过，屎山没有测试，反而形成了一种“静态稳定”。但这不代表我们真的就永远不碰屎山里的代码。当业务需要我们必须修改某块老逻辑时，最稳妥的做法是“先补测试，再动手改”。

补什么样的测试？不建议一上来就写单元测试。屎山的方法内部逻辑乱成一团，依赖又多，Mock 成本极高，写完的测试也非常脆弱，稍微动一下就红。我建议先写“冒烟测试/特征测试”。

所谓特征测试，就是把你关心的那段逻辑，放到一个可控的测试环境里，塞进去一组样本数据，记录下它实际产出的结果。这组“输入-输出”对，就成了这段逻辑的“行为契约”。之后你改动代码时，只要跑一遍这些特征测试，确认输出没有变，说明行为没被破坏。

这个思路有一个非常巧妙的地方：它不需要你理解代码内部的逻辑，只需要你记录“它现在做了什么”。哪怕它现在的行为是错的，你也先把这种“错”固化下来，保证你改完代码之后，它依然“错得一模一样”。等到你彻底搞懂了这段上下文，再考虑把这个“错”纠正过来。

工具上，如果你用的是 Java，可以用 Approval Tests 这类基于“批准/快照”的测试框架，Python 的话有 pytest 自带的快照功能，或者直接用 Syrupy。核心思路都一样：第一次运行，把结果存成快照文件；之后每次运行，系统自动比对当前结果和快照是否一致。

这个方案我实测下来非常稳。很多看起来一碰就碎的屎山逻辑，只要我先铺一层特征测试，改动的时候就特别踏实，再也不用担心“改一个字段引发另一个模块的隐性变化”了。

3.4 修改老代码的“止血钳”操作法

如果你最终还是要直接改屎山的老代码，我这里有一套“止血钳”操作法，能最大程度降低风险。

第一步，操作前先拍快照。改代码之前，把涉及到的相关接口、数据库表、配置文件都做一份备份。尤其是数据库表，直接把要改的数据导出一份 SQL 放本地，如果出问题可以随时恢复。

第二步，改动范围最小化。能不改的就不改。如果你想重构某个方法，先把方法原封不动地拷出来，改一个新名字，然后让旧方法调用新方法。旧方法留一个日志，观察一段时间，确认新方法的行为完全一致之后再切流量。千万不要想着“顺手把这里也优化了”。在屎山里，每一次顺手都是一次安全事故。

第三步，全链路验证。改完代码，不只看本接口的返回结果，还要看它影响的下游表、下游服务。怎么验证？把改动前和改动后的全链路日志拉出来对比，看有没有数值偏差。这一步能发现很多“看起来没变，实际上变了”的隐性影响。

第四步，回滚预案。所有上线变更，必须提前写好回滚方案。一个足够简单的回滚操作，有时候比任何测试都管用。屎山系统出问题的恢复时间，很大程度上取决于回滚速度，而不是修复速度。

这些操作听起来平平无奇，但真到屎山这种险恶环境里，每一条都是保命符。我自己靠这套方法，在无数个“改一个字段就全盘崩溃”的夜里，都稳稳地把线上系统保住了。

4. 屎山鲁棒性的边界：什么时候它真的会塌

前面讲了屎山为什么这么稳，又讲了在屎山里怎么小心翼翼地活着。但大家心里都有数，屎山鲁棒性是有边界的，它不是永动机。一味地吹捧屎山的稳定，是一种幸存者偏差。这一节我们聊聊，屎山在什么情况下会真正地、不可逆地塌掉。

4.1 触发屎山雪崩的几种典型场景

第一种，是系统的外部环境发生不可逆变化。比如上游系统彻底下线，而屎山里面那堆兼容性分支完全依赖上游的某个特定返回值；又比如操作系统升级，旧代码依赖的某个底层库在新环境里行为完全变了。这种外部变化往往没有商量余地，当天通知，第二天就生效，屎山内部那些“静态稳定”的平衡被粗暴打破，根本没有时间做灰度迁移。

第二种，是隐性知识的拥有者集体流失。前面说了，屎山的运行严重依赖一群人脑中的地图。如果这批老人集中流失（比如整个小组被裁员、跳槽），而曾经的那些“聊天记录”早就无处可寻，新来的人面对这座山，完全不知道从何下手。任何一个小故障都会被放大成重大事故，因为他们没有能力区分“这是常见老毛病”和“这是新的致命问题”。

第三种，是组织架构剧烈变动。比如原来维持微妙平衡的两个部门合并了，原本属于两个系统的模块被迫整合成一个，双写双读的冗余结构被迫改造成单活结构。一旦组织平衡线被打破，模块边界就得跟着变，改动量会呈几何级数增长，屎山内部那股“互相拉扯的力”就绷不住了。

这几种场景的共同特点是：外部力量强制改变了屎山的生存环境，而屎山没有任何“自适应”能力。它之所以稳，是因为它从不适应，也就是说，它靠着拒绝变化来维持稳定。一旦变化不可拒绝，稳定也就烟消云散了。

4.2 重写还是维护：做决策的框架

既然屎山终有一天会塌，那“要不要重写”就成了绕不开的问题。我的建议是，不要被“重写”这个词诱惑，先用一个框架判断清楚，再决策。

先把系统的核心价值和非核心价值拆开。如果一套系统虽然历史包袱重，但它所在业务领域变化缓慢、逻辑稳定，那维护比重写划算得多。屎山在这种环境里，就是一种非常高效的资产——它虽然丑，但不会给你添太多新麻烦。

反过来，如果系统所在的业务领域正在快速变化，每周都有新需求、新玩法，而旧代码的逻辑已经完全跟不上趟，每加一个小功能都要付出极大的时间成本，那么重写的诉求就是合理的。但也要注意，重写不能是“从零开始”，最好沿着前面说的“绞杀者模式”逐步蚕食，而不是推倒重来。

我见过太多“推倒重来”的惨案。两三个技术骨干拍着胸脯说半年之内搞定，结果一年过去了还没上线，而上线的那一天，老系统就因为一个没人会修的定时任务出了问题，挂了。最后不得不把新系统里的数据迁回老系统，重新把屎山供起来。这种故事在行业里轮番上演，每次都以巨大的时间、金钱和士气损失告终。

所以我的看法很明确：除非你有一个非常了解老系统全部逻辑的团队，并且业务领域已经足够稳定、你有一整套完善的迁移计划和回滚方案，否则不要轻易动“重写”的念头。与其挖一座新山，不如骑稳你脚下的这座旧山。

5. 向屎山学习：把鲁棒性转化为工程能力

很多人读到这儿可能觉得，我这是要给屎山洗白。其实不是，屎山就是屎山，它的技术债是真的，维护成本是真的，团队的崩溃感也是真的。我只是想提醒大家，别再简单粗暴地把“代码质量差”等同于“系统不可靠”了。屎山身上有一些真实的、值得借鉴的工程能力，如果我们能把这些能力提炼出来，用到新系统的设计上，那才是真正的“以屎为鉴”。

5.1 屎山教会我们的“反脆弱”思维

纳西姆·塔勒布在《反脆弱》里提过一个观点：有些系统能从冲击、波动和混乱中获益，而不是受损。屎山在一定程度上就表现出了这种“反脆弱”特质——它经历了无数次线上事故，然后通过打补丁的方式修复，修改一次，就强化一次。每当系统“差点挂掉”之后，它都会变得更难挂。

我们从这个现象里能提炼出什么经验？我觉得最重要的，是“拥抱故障，而不是回避故障”。在新系统设计里，我们可以主动地制造故障、进行混沌工程演练，让系统在可控的小规模故障中积累“如何在故障中存活”的经验。我见过一些非常优秀的团队，每个季度都会在预发环境里做一次全链路故障演练，故意把某个核心依赖杀掉，观察系统的降级能力。而这个能力，正好就是屎山在无数次真实事故中被动锻炼出来的。

我们没法把屎山清空重来，但可以把屎山的进化方式学过来：小步快走，持续迭代，把每一次真实故障都变成一次系统加固的机会。

5.2 在团队里推动“有管理的腐烂”

说到“管理屎山”，有一个概念我特别推荐：有管理的腐烂（Managed Rot）。来源是《Software Engineering at Google》这本书，它主张技术债不一定要彻底偿还，但一定要被“记录在案、量化跟踪、定期审视”。换句话说，你别骗自己说“这块代码很完美，只是没时间优化”，而是要诚实地记录“这块代码已经烂到根了，但短期不值得动它，长期需要替换”，并且把这个状态纳入到团队的技术规划中。

我在团队里的具体做法是这样的：建一份技术债清单，每个季度开一次会，把所有已知的屎山模块列出来，按“维护成本”“事故概率”“业务影响”三个维度打分。得分最高的模块，进入下一季度的重构候选池。如果某个模块连续三个季度都排在前面，那就值得认真评估是否要投入人力做专项治理。

这个机制的意义不在于消灭屎山（那是不可能的），而在于让屎山的存在从“不可见、不可控”变成“可见、可控”。当领导问“这个系统还能撑多久”的时候，你至少能拿出一份有理有据的评估报告，而不是拍脑袋说“应该还能撑一年吧”。

5.3 构建“地基”与“脚手架”：向屎山学习弹性设计

最后聊聊新系统怎么从屎山身上取经。我总结了三条非常实在的经验。

第一条，给系统留足“兼容性冗余”。不要为了追求代码的整洁，把所有历史版本的分支全部删掉。尤其是对外接口，最好保证至少兼容上一代或上两代的数据格式。你可以把这些兼容逻辑放到专门的适配层里，但不要轻易砍掉它们。因为没人知道你的下游客户会在什么时候，还在使用一个两年前的旧版本。

第二条，把“关键路径”和“非关键路径”彻底分离。屎山之所以一崩就全崩，是因为它的关键路径和非关键路径纠缠在一起。新系统设计时，要动用一切手段把这两者分离。比如，支付流程不要依赖报表模块的数据库；用户登录链路不要和推荐算法的中间件耦合。这样，即便某个非关键模块炸了，也不会影响核心业务。

第三条，用“开关”代替“删除”。屎山里那些危险的逻辑，最好的处理方式不是直接删掉，而是在外面套一层开关。遇到线上问题，一键切换；需要灰度验证，一键放量。这些开关虽然技术上不优雅，但它们在关键时刻的反应速度，比任何“优雅的修复”都要快得多。

这些都是我从屎山身上学到的。它没有给我任何一份设计文档，但它用无数个线上事故，教会了我什么叫做真正的“工程韧性”。

以后再看到某个老系统，别再急着说“这代码烂得不行了”。试着问一句：它为什么这么烂还能活这么多年？它靠什么机制在扛住每天的真实流量？如果我要动它，怎么做才能不打破它现有的稳定？把这些问题想清楚了，你就真正理解了鲁棒性这个词的深层含义。工程世界里的“好”，从来都不只有一种标准。