# 基础架构部不死，只是慢慢消逝

LLMS 索引： [llms.txt](/llms.txt)

---

> 原作者：李令辉 · [微信公众号转载页](https://mp.weixin.qq.com/s/E1T4jnvcTIINFel6baYeJg)

瑞典马工昨天的文章[《基础架构部，还有必要吗？》](https://mp.weixin.qq.com/s?__biz=MzkwODMyMDE2NQ==&mid=2247484429&idx=1&sn=e8c96fc5d2bd5058dfcfb58592488422&scene=21#wechat_redirect)里面点名质疑了基础架构部存在的必要性。我自己从事基础架构工作多年，希望可以从相对客观的角度来回答这篇文章提出的问题。也谨以此文致敬基础架构的老兵们。

### 基础架构部的价值是什么？

正如马工文中所说，基础架构部是为了向业务单位交付技术，并且要具备两个前提：

1.  自己有优秀的技术

2.  要能引导业务部门使用优秀的技术

#### 技术的“优秀”与否要看场景

但是，“优秀”不是有唯一标准的，什么算优秀的技术？技术都是有 tradeoff 的，比如某一种技术能获取最高的性能，但是它对于很多公司来说并没有意义，因为它的功能太简单，成本太高。

而每个业务场景下的优秀的标准就是不同的，公司和公司之间并不是在同一个领域进行竞争，所以服务于公司业务的基础架构部当然也不应该有统一的目标，比如追求最高并发服务能力。

比如 SaaS 世界第一股 Salesforce 长期以来用的技术都是互联网喊着去 IOE 里的 Oracle 作为底层存储，上面的并发数也很低，你能说 Salesforce 的技术不优秀么？只能说在它的领域里它的技术很不错，但是不符合你的领域的要求。你一个猫为什么要和企鹅比赛跑步呢？人家企鹅是游泳游的好啊。

#### “引导”业务部门？

基础架构部大概率作为一个横向部门存在，它减少部门间的重复建设或者错误建设。实际上过去互联网时代和移动互联网时代，互联网公司都以增长为核心指标，过程里会大量引入没有那么合格的程序员来快速试错新的业务领域。如果没有一个横向部门去进行“引导”和“规约”，业务确实有可能过于“野蛮”生长。

### 基础架构部有没有核心技术？

#### 真的是“调参”，“魔改”，“仿造“师傅么？

马工的文章讨论了基础架构部有没有核心技术，里面把工程师分成了“调参”师傅，“魔改”师傅，和”仿造”师傅。

这点我是完全同意的，但是so what？中国互联网公司几乎都有美国对标，和美国同行几乎从事完全一样的业务，那么用和美国同行几乎一样的技术也就无可厚非了，这可能就是确定性最高，风险性最小的技术选型了，C2C 本来的意思就是摸着美国过河，商业模式可以 Copy，技术栈有什么问题？

而且，美国硅谷公司的非业务公司，比如 twitter （现在的 X），facebook （现在的Meta），airbnb 等巨头基本都是基于开源技术起家的，然后在发展的过程里遇到问题解决问题，这个过程就是”调参“和”魔改“。不过，“仿造”其实是大公司病的体现

#### “仿造”是大公司病

当公司大了，公司对个人晋升和嘉奖的“维度”就开始变了，从贡献变成了贡献✖️难度，但是公司大了，业务稳定了，大部分贡献就变成了统一的“微不足道”，就开始有打工人为了获得更好的绩效和晋升机会，开始通过强行提高难度来刷个人存在感。

“仿造“ 这种病来源于公司大了后每个团队的目标和公司整体目标脱节，不管公司用 KPI 还是 OKR 都不能阻挡它的出现。现实里，”仿造”一般会找一个较好的立项原因，总能找到一些可以通过“仿造”解决的点。是仿造还是超越，存乎一心，但是如果完全不存在这种灰度，可能创新也无从谈起，因为很多东西在你仿造一遍之前，你都掌握不了它的关键所在。魔鬼在细节里，不动手亲力亲为，你永远不知道谁是无足轻重的细节，而谁是魔鬼。

总而言之，大公司病不见得是坏事，可能也是大公司的资源和利润给了创新一定的宽松的空间，但是**投资不一定有回报，不投资一定没有回报。**

#### 改开源软件怎么了？

我们知道开源软件一般来自几种开发者：

1.  大公司为了自己的商业目的开源的，为了抢占市场打击竞争对手，不靠软件赚钱（Android、chrome、kubernetes，vscode 都是此类）

2.  商业化公司经营的开源软件，通过开源转化付费客户（ElasticSearch，Nginx，MySql，Cassandra）

3.  有开源基金会开源的软件（来自 GNU 的软件，linux）

一般来说，1 会按照自己的 roadmap 前进，不会太在乎冷门的需求；2 会故意弱化企业级功能（要不是商业版怎么收费？）；3 的话，一般都是 welcome to your PR，而不是商业软件的服务感。

全球的互联网公司一般都鼓励员工修改（魔改）开源软件，但是 Facebook 能把 HBASE 的主导权拿到公司内来主导，Google 可以对 Linux 上游提交 cgroup 的 patch。可见魔改开源不是原罪，“菜”才是原罪。

### 基础架构部是如何交付业务价值的？

基础架构部一般以一个横向部门的角色出现，并没有自己可以计算 ROI 的业务收入，但是基础架构部实际是通过一些更通用的指标来体现价值的，比如可用性，伸缩性，以及业务迭代速度。能抓到老鼠就是好猫，即使这个猫没有涂最先进的指甲油。在互联网公司里技术是服务于业务的，而大部分公司不是 FAANG。要求一个普通公司的保安发明出星球大战的装备这不公平也不现实。

### 技术理念落后

落后与否是相对的，Apple 在服务端技术上也没有啥创新，也是 Copy from Google Or 其他公司，那么 Apple 是否是一个落后的公司呢？每个公司都有自己擅长的领域，在自己的细分领域里（比如送餐/卖票/电商/营销）技术不落后就可以了。相反，每个公司都卷 Proxy 或者 K8S 的部署情况。才不利于整个技术大环境的整体发展和氛围

#### 为什么我们会执迷于 scalability？

因为基础架构部负责的工作就是可用性，伸缩性。说别的显得不务正业了。

### 基础架构部已经变成阻碍技术进步的恶龙了么？

对于任何团队来说，在组织里体现自己的价值都是必不可少的工作，横向部门殊为不易，往往只有背锅的时候才能体现。所以整个研发体系的底座趋向于保守，很正常，因为这符合它的定位和存在的意义。基础架构团队往往要规约业务团队的需求和行为，所以显得颇有出力不讨好之嫌。但是这也是公司内不可缺少的制衡之力。

#### 组织惯性

而且这是历史上所有的组织的惯性，几乎没有组织会从内部进步和革新，都是要靠外力驱动的。比如苏联红军在遭遇德军的坦克前还是对哥萨克骑兵寄予厚望。基础架构团队和任何团队没有区别，它的使命是托举住公司的业务，如果他完成了这个使命，大概率不会有自我革新的动力。但是这也不是哥萨克骑兵的错。

#### 非技术公司的竞争壁垒并非技术

我国市场上大部分的互联网公司并不是技术驱动，所以也不需要一个不断进化的基础架构部。相反在业务没有实现高速增长的前提下，控制成本才更现实。

#### 基础架构部为什么会排斥外部技术提供商呢？

基础架构部很多时候就是内部技术提供商，排斥外部竞争对手符合人性。毕竟大部分外部供应商采取的方式和基础架构部几乎一样（本来就是同行），也是基于开源系统都魔改和调参，甚至临摹。你让基础架构部怎么放下手里的枪，去采购别人的枪呢？甲方乙方都有各自的问题。

### Fade Away

> Old soldiers never die，simply fade away。

新的生产力一定会催生新的生产关系。

基础架构团队本身是上一个时代的互联网公司的缩影：愿意用超配的资源去实现增长。但是任何时代都有落幕的时候，基础架构部也会如其他高增长所超配的资源一样被减配。互联网公司都会从高投入转向高 ROI 导向的理性投入。从一定要自主可控转向用更合理的成本去实现可控。

基础架构团队会走向如下几个方向：

1.  拥抱云，降低人员成本。

2.  拥抱市场，提供产品到市场上参与竞争。

从 ROI 的角度重新对基础架构这个角色估值和定位，会把滥竽充数的东郭先生们从队伍里拖出去。时代的产物当然会跟随时代的步伐去发展。

### 广告

我们的核心团队都有基础架构团队的背景，关于基础架构我有一大堆内容可以输出，但是用产品和技术说话更符合我们的做事风格。

我们推出的 **ClapDB<sup>[1]</sup>** 完全基于云的特性从零开发（并不是开源魔改），通过更好的发挥云上新硬件的潜力，可以用最少的钱执行最丰富的查询。无论是用于 BI、还是用于 RAG、亦或者用于实时监控领域。它都是你最佳的选择。请点击原文访问我们的官网。

#### 参考资料

[1]

ClapDB: https://clapdb.com