瑞典马工昨天的文章《基础架构部，还有必要吗？》里面点名质疑了基础架构部存在的必要性。我自己从事基础架构工作多年，希望可以从相对客观的角度来回答这篇文章提出的问题。也谨以此文致敬基础架构的老兵们。
正如马工文中所说，基础架构部是为了向业务单位交付技术，并且要具备两个前提：
但是，“优秀”不是有唯一标准的，什么算优秀的技术？技术都是有 tradeoff 的，比如某一种技术能获取最高的性能，但是它对于很多公司来说并没有意义，因为它的功能太简单，成本太高。
而每个业务场景下的优秀的标准就是不同的，公司和公司之间并不是在同一个领域进行竞争，所以服务于公司业务的基础架构部当然也不应该有统一的目标，比如追求最高并发服务能力。
比如 SaaS 世界第一股 Salesforce 长期以来用的技术都是互联网喊着去 IOE 里的 Oracle 作为底层存储，上面的并发数也很低，你能说 Salesforce 的技术不优秀么？只能说在它的领域里它的技术很不错，但是不符合你的领域的要求。你一个猫为什么要和企鹅比赛跑步呢？人家企鹅是游泳游的好啊。
基础架构部大概率作为一个横向部门存在，它减少部门间的重复建设或者错误建设。实际上过去互联网时代和移动互联网时代，互联网公司都以增长为核心指标，过程里会大量引入没有那么合格的程序员来快速试错新的业务领域。如果没有一个横向部门去进行“引导”和“规约”，业务确实有可能过于“野蛮”生长。
马工的文章讨论了基础架构部有没有核心技术，里面把工程师分成了“调参”师傅，“魔改”师傅，和”仿造”师傅。
这点我是完全同意的，但是so what？中国互联网公司几乎都有美国对标，和美国同行几乎从事完全一样的业务，那么用和美国同行几乎一样的技术也就无可厚非了，这可能就是确定性最高，风险性最小的技术选型了，C2C 本来的意思就是摸着美国过河，商业模式可以 Copy，技术栈有什么问题？
而且，美国硅谷公司的非业务公司，比如 twitter （现在的 X），facebook （现在的Meta），airbnb 等巨头基本都是基于开源技术起家的，然后在发展的过程里遇到问题解决问题，这个过程就是”调参“和”魔改“。不过，“仿造”其实是大公司病的体现
当公司大了，公司对个人晋升和嘉奖的“维度”就开始变了，从贡献变成了贡献✖️难度，但是公司大了，业务稳定了，大部分贡献就变成了统一的“微不足道”，就开始有打工人为了获得更好的绩效和晋升机会，开始通过强行提高难度来刷个人存在感。
“仿造“ 这种病来源于公司大了后每个团队的目标和公司整体目标脱节，不管公司用 KPI 还是 OKR 都不能阻挡它的出现。现实里，”仿造”一般会找一个较好的立项原因，总能找到一些可以通过“仿造”解决的点。是仿造还是超越，存乎一心，但是如果完全不存在这种灰度，可能创新也无从谈起，因为很多东西在你仿造一遍之前，你都掌握不了它的关键所在。魔鬼在细节里，不动手亲力亲为，你永远不知道谁是无足轻重的细节，而谁是魔鬼。