每个技术团队都会经历这样一个时刻：现有工具不太顺手，自己做一个吧。

理由总是充分得无法反驳——市面上的组件库不支持我们这种交互模式，开源的表单引擎处理不了我们的动态字段逻辑，第三方的配置中心满足不了我们的合规要求。每一条拿出来都是刚需，每一条都指向同一个结论：我们得自己造。

没人会在这个阶段反对。因为反对意味着你要证明"现有的东西够用"，而提出造轮子的人已经把"不够用"的场景摆上了桌面。你没办法反驳一个正在发生的痛点。

于是轮子开始转。第一周，大家很兴奋。第三周，初版出来了，确实比之前好用。第二个月，几个业务接入了。半年后，团队里有一半人的KPI跟这个轮子挂钩。一年后，最初写轮子的人提了离职。

这就是造轮子的故事。但今天我不想聊"该不该造"——这个问题已经被讨论过太多次，而且答案永远是"看情况"。我想聊的是一个更少人关注、却更致命的问题：造轮子最大的代价不是花时间开发，而是你再也走不掉。

开发成本只是首付

大部分人评估"要不要自己造"的时候，脑子里算的是开发成本。两个人做两个月，能搞定，成本就是四个人月。和采购方案比一比，好像更划算。这个算术本身没错，但它只算了首付。

真正的问题是后面几十年的月供。

2018年前后，Serverless在国内技术圈火了一阵。各大云厂商轮番布道，"按需付费"、"零运维"、"自动扩缩容"——每个口号都精准戳中了团队的痛点。我当时也投入了不少精力研究，毕竟谁不想不用管服务器？

几年过去了，当初那些All in Serverless的团队，相当一部分已经在往回走。不是Serverless不好，而是很多人慢慢意识到：当初以为消灭的复杂度，其实只是搬了个家。

那些承诺里没写的小字

Serverless的核心承诺有三条，每一条都有对应的现实版本。

"不用管服务器"——开发者只需写业务逻辑，基础设施平台托管。这对前端团队尤其有吸引力，写完函数丢上去就能跑，不用折腾部署和运维。但现实是，你很快会发现自己需要关注函数的内存配置、超时时间、并发限制、冷启动策略、VPC配置、IAM权限……这些不叫"服务器运维"，但本质上还是在管基础设施，只是换了个仪表盘。

"按需付费"——代码不运行就不收钱，空转成本消失。但下一句没人告诉你的是：按需付费的反面是成本不可预测。一个函数死循环触发重试，一个爬虫突然疯爬你的API，一个配置错误导致无限调用——这些异常场景下的账单，会让你深切怀念固定成本的日子。

每个技术团队都有这个痛点：核心开发离职了，系统没人敢动；某个服务只有一个人能改；新人来了三个月还在问"这个接口谁负责"。然后管理层拍板——写文档！搞知识库！做Wiki！

半年后，知识库变成了数字垃圾场。文档没人读，读了也过时，过时了更没人更新。循环往复。

我的判断可能比较尖锐：文档是知识孤岛的安慰剂，不是解药。真要打破知识孤岛，得从架构设计和组织设计入手，让知识天然不容易集中到某个单点上去。

知识孤岛是怎么长出来的

先得搞清楚，知识孤岛不是"文档没写好"的产物。它是系统架构和组织结构的影子。

当一个微服务只有一个人从设计到上线全程参与，那这个人就是这个服务的知识孤岛。不是因为他不愿意分享——他可能写了很详细的README，但你让另一个人接手，还是要花两周才能上手。因为README里写的是"怎么做"，而脑子里装的是"为什么这么做"以及"哪里会踩坑"。

上周有个做支付系统的朋友跟我吐槽，他们团队每次发版要过六道门禁——代码审查、单元测试覆盖率、集成测试、安全扫描、性能基线、人工审批。听起来很严谨对吧？结果他们每次发布的变更量越来越大的同时，线上故障却没有减少。反而因为每次发布都是"大手术"，一出问题就是大问题。

这不是个例。我观察过不少团队，尤其是金融、支付这类对稳定性要求极高的业务线，都有一个共同的倾向：发布越怕出错，就越加流程；流程越重，发布频率越低；频率越低，每次发布承载的变更越多；变更越多，出错概率越高——然后更怕出错，继续加流程。

这就是发布恐惧怪圈。而最反直觉的地方在于：你加的每一道门禁，都在让下一次发布更危险。

门禁越多，发布越重

这是最直接的后果，也是最容易被人忽视的。

假设一个团队每周发布一次，每次发布平均包含 15 个 commit 的变更。后来因为一次线上事故，决定加强管控：发布前必须经过安全扫描和性能基线验证，流程从一天变成了三天。发布频率自然从每周一次降到了每两周一次。但开发节奏没变，两周的变更量是 30 个 commit。

看到了吗？单次发布的爆炸半径翻倍了。