200万的监控系统，两万就能搞定

你的团队有没有干过这种事？

四个工程师，埋头苦干六个月，自研了一套监控系统。从数据采集到告警规则，从仪表盘到日志查询，每一行代码都是自己写的。上线那天，全组聚餐庆祝，CTO在群里发了一句”自主可控，核心能力”。

然后某天，一个新来的实习生问了一句：“这个…跟Grafana+Prometheus有什么区别？”

全场安静了三秒。

那六个月乘以四个工程师的人力成本，保守估计200万。而Grafana Cloud的企业版年费，大约两万块。这中间差了100倍。更扎心的是，那套自研系统上线三个月后就开始出各种小毛病——因为没人愿意维护一个”别人的孩子”，而当初主导开发的那个架构师，已经跳槽了。

你可能觉得这是个极端案例。但我告诉你一个数据：企业IT项目中有45%属于”重复造轮子”——自研了市场上已有成熟方案的功能。 这不是我编的，McKinsey的研究白纸黑字写着。

问题来了：既然这么多人踩过坑，为什么大家还是前赴后继地选择自研？

NIH综合征：工程师的”原罪”

答案藏在一个心理学概念里——Not Invented Here综合征，简称NIH。

翻译成人话就是：不是我写的代码，我就觉得不靠谱。

这不是个别现象，这是工程师群体的集体本能。你回忆一下，是不是每次看到一个开源方案，脑子里的第一反应都是”这个我也能写”、”它那个实现方式太蠢了”、”我们的场景特殊，通用方案肯定不行”？

“我们的场景特殊”——这句话是自研决策的万能通行证。十个CTO里有九个半用过这个理由，但真正去验证过”到底哪里特殊”的，不到一个。

我见过一个团队，花了八个月自研消息队列。理由是”我们的消息量太大，RabbitMQ扛不住”。后来复盘发现，他们日均消息量是200万条。RabbitMQ单机就能轻松处理1000万条。所谓的”扛不住”，压根没测过，纯靠直觉。

自研的第一大陷阱：用直觉代替调研。 在写第一行代码之前，你花了多少时间研究现有方案？如果答案少于两天，那这个自研决策大概率是错的。

你算过维护成本吗？

自研最大的骗局不在开发阶段，而在上线之后。

大多数技术管理者在做Build vs Buy决策的时候，脑子里只有一个数字：开发成本。”这个功能我们三个人做两个月就能上线”——听起来很划算对吧？

但他们漏算了一笔账：维护成本。

一个自研系统上线那天，你以为故事结束了。错，那才是噩梦的开始。用户会用你想象不到的姿势触发bug，CVE漏洞不会因为你是自研的就绕道走，产品经理下周又有新需求了，上一个维护的人离职了——留下的代码注释只有一句”// don’t touch this”。

这些隐性成本加起来有多少？自研项目的3年维护成本，平均是初始开发成本的4倍。 行业共识，不是我瞎说。

也就是说，那个”三个人做两个月”的功能，开发成本算它50万。三年维护下来，总成本是250万。而同样功能的SaaS方案，三年总费用可能就30万。

自研的第二大陷阱：只算了”做出来”的钱，没算”养活它”的钱。

决策矩阵：一张餐巾纸就够了

别慌，我不是要你去读什么《技术战略与组织决策》。你只需要一张餐巾纸和一支笔。

画两条线，十字交叉。横轴写”是不是核心竞争力”，纵轴写”技术复杂度高不高”。四个格子，四种命运：

右上角：核心 + 高复杂度 → 砸锅卖铁也要自研

Google的搜索排序算法交给外包公司做？字节跳动的推荐系统用开源套件凑合？你去跟投资人说说看，他们的咖啡能喷你一脸。这些是命根子，是护城河，是你跟竞争对手之间唯一的差距。这个格子里的东西，值得你最好的工程师去死磕。

右下角：核心 + 低复杂度 → 自己做，但管住手

你是电商平台，商品详情页当然自己做。但拜托，别搞出一个”高度可配置的跨端动态化页面渲染引擎”——你只是需要一个能显示商品图片和价格的页面而已。过度设计是一种对简单问题的暴力美学，很酷，但很贵。

左上角：非核心 + 高复杂度 → 闭眼买SaaS

这是翻车重灾区。监控系统、支付网关、身份认证、邮件服务——技术上每个都是深坑，但跟你的核心业务半毛钱关系没有。你自研一套支付系统的时间，支付宝的工程师已经帮你把风控、对账、退款全搞定了，每笔交易收你千分之六，你还嫌贵？你的竞争对手不是支付宝，别在别人的主场打仗。

左下角：非核心 + 低复杂度 → 开源拿来主义

日志库、HTTP客户端、JSON解析——有人花了几千个小时写好了，单元测试覆盖率95%，每周有人帮你修bug。你要是还自己写一个，那不叫工匠精神，叫跟自己过不去。npm install 敲完收工。

沉没成本：写了三个月的代码，你舍得删吗？

矩阵画出来了，答案明摆着该用第三方。但你猜怎么着？大多数人看完矩阵，默默把餐巾纸揉成一团扔进了垃圾桶——因为他们已经写了三个月代码了。

最典型的就是沉没成本陷阱。

“这个系统我们已经做了三个月了，现在换方案不是白干了吗？”

白干怎么了？你已经花掉的三个月是沉没成本，不管你继续做还是停下来，那三个月都回不来了。真正该问的问题是：从现在开始，继续自研和切换方案，哪个总成本更低？

但人不是理性动物。程序员对自己写的代码有感情，Leader对自己主导的项目有面子，CTO对自己批准的方案有执念。停下来意味着承认错误，而承认错误比浪费钱更痛苦。 所以大家选择继续往坑里填人、填时间、填预算，直到这个项目变成一个谁都不想碰但谁都不敢停的”僵尸系统”。

我的建议很简单：每三个月做一次”假设我们今天从零开始，还会选自研吗？”的复盘。 如果答案是”不会”，那就止损。今天停下来，永远是损失最小的一天。

做决策之前，先回答三个问题

下次你的团队又在讨论”这个功能是自己做还是买现成的”时，别急着表态。先问三个问题：

第一问：这功能做得比竞品差20%，用户会跑吗？

不会跑？那就别自研。”够用”是工程世界里被严重低估的策略。没有用户会因为你的监控仪表盘比Grafana好看10%，就掏钱买你的产品。

第二问：拿出计算器，把3年总账算一遍。

开发成本只是冰山露出水面的那一角。加上维护、安全更新、功能迭代、人员流动带来的知识断层——50万的开发预算，三年后账单是250万。同类SaaS？30万全包。差了8倍的钱，差了三年的机会窗口。

第三问：这个系统，离了谁都能活吗？

团队里只有一个人搞得懂？那他不是工程师，是人质。他请假你心慌，他离职你崩盘。一个只有一个人能维护的系统，不叫技术资产，叫定时炸弹。

三个问题，有一个答不上来，就老老实实选Buy或Open Source。

200万的教训，2天就能避免

回到开头那个故事。

那套200万的自研监控系统，如果当初花两天时间做技术选型调研，结论大概率是：用Grafana+Prometheus免费套件，再花两万块升级个Grafana Cloud企业版搞定。

省下来的198万和六个月人力能干什么？足够做一个真正有差异化价值的产品功能——那种你竞争对手抄都抄不来的东西。

技术决策的最高境界，不是”我们能不能做”，而是”我们该不该做”。 能做和该做之间，隔着一道200万的坑。

下次在白板前讨论架构方案的时候，把那个2x2矩阵画出来。右边的格子才是你该花心思的地方。左边的？交给别人吧。

最贵的代码不是写出来的，是不该写却写了的。