最近《基础架构部，还有必要吗？》这篇文章大火，作者瑞典马工列举了大量基础架构部存在的问题，标题扬言不需要基础架构部。那么大部分基础架构部现状到底是样子的呢？波吉根据自己的经验，给大家简单做个分类，希望各个企业自己对号入座。
折腾技术的基础架构部
这种基础架构部通常有一个特殊的技术负责人或者 CTO 带领，然后往往这位同志本身又是个技术爱好者，并且内心深处想要打造一个比肩世界顶级（如:Google) 的基础架构团队。他们往往是开源的爱好者，但又不一定都是真正的开源社区的贡献者，他们立志于将一些开源技术拿回公司进行魔改，美其名曰为了解决自身业务的一些场景，但是往往由于人员更迭，这些魔改的软件又无法和主流的版本进行合并，环境中就不断的残留着各种版本，对于后期接手的同学又产生了巨大的维护成本，只留下一篇在历史长河中的技术公众号文章在风中凌乱。
当然这一类基础架构部也并非都是一无是处，如果真的能搞出一些个基础软件并且愿意回赠给上游，能够持续的进行对基础设施的迭代，也能为整个社会培养人才。这种公司一般主流业务发展比较好，公司相对有钱，对这种爱折腾的技术架构部可以听之任之，然后一旦核心业务发生重大变化的时候，当老板意识到这一块重大成本的时候，往往也是调整的重灾区。所以反过头来就又出现了为了所谓 Job Security，有意无意的去做一些魔改，增加公司换人和接手难度。
举个例子：这种魔改MySQL的方案《基于MySQL内核的SQL限流设计与实现｜得物技术》虽然解决了问题，但在我眼里更多的展现的是这家公司真的很有钱，同时基础架构部很爱炫技。只不过第一个苦了运维这个平台的小伙伴（要管理一个非主流的 MySQL）同时如果这位同学离开后，会发生什么。（专业数据库公司看过后一定表示这个同学不错，待在电商公司可惜了，增加了跳槽的筹码，是后文僵尸蜗牛的初级形态）
但是波吉也遇到过创业团队的 CTO 不跑核心业务的 MVP 验证，上来就搞所谓的各种基础设施（最近的部分 AI 创业团队这种现象也不少），结果各种数据库，监控，大数据平台搞了一堆，核心的应用却搞不出来或者没办法快速做商业化验证。最后 CEO 请得所谓技术大神就成了这个创业公司的掘墓人。比如有一位朋友融资能烧一年的钱，做了一个类似 Spring Cloud 的开发框架，花了九个月，然后他们的核心业务是做教育 APP。当然最终结果是 CEO 和 CTO 吵翻，CTO 愤愤的表示 CEO 不尊重技术。
幻想商业化的基础架构部
折腾技术的基础架构部有一个很有趣的进阶版本，就是发现当自己的“得意”作品在内部看起来用得不错的时候，自然而然就想对外输出，当然对外输出的有两种情况：
一种是成立云计算公司，以云计算平台的方式提供服务，让基础架构部不仅仅是公司的基础架构部，还能成为全国的，甚至世界的基础架构部。然后要从市场上获得认可，进入到市场竞争中，这就完全不一样了。如果没有公司真的把这一块作为核心业务，持续的投入烧钱，包括领导者是否真的获得了 CEO 和董事会对这个方向上的认可，那注定是南柯一梦。《滴滴如何基于开源引擎，打造自主可控服务体系》
第二种是把基础架构部把自己的得意产品单体出来商业化，当然路径很多，比如捐给 Apache 基金会，再出来基于这个开源做成商业公司。或者直接拿自己在前任公司的某个东西出来商业化。这条路径上百度应该是中国的翘楚。确实对于公司本身来说，当基础架构的供养成本太高的时候，用这种方式解决一下人力成本问题，也不失为一种比较好的办法。
还是那句话，如果这种商业化是公司本身的战略方向没有问题，如果是创业公司请到了这种给自己留后路的团队，这不禁让我想起了寄生到蜗牛的双盘吸虫，让蜗牛变成了僵尸蜗牛，所有的业务融资就是为了养活这个寄生虫而已。《做美丽的僵尸蜗牛》
蜗牛被一种叫做Leucochloridium paradoxum的双盘吸虫所寄生，这种寄生虫可以进入蜗牛的消化系统，并长成一条长长的管，其中充满了数百只有生殖能力的尾蚴。接下来，长长的管道入侵蜗牛的触角，形成一种怪异、肿胀、跳动的外观，以此来吸引鸟类的注意。鸟类吃下这只蜗牛后，就会变成寄生虫成长第二阶段的宿主。虫卵通过鸟类的粪便排出到植物上后，又会寄生到其他蜗牛身上，继续开始它们的生命轮回。
https://baike.baidu.com/item/僵尸蜗牛/8529898?fr=ge_ala
购买服务的基础架构部
其实云计算本身的兴起，就是将这种基础设施和基础软件通过服务的方式提供更更多的企业，将最好的技术能让更多的企业享受到，那么自然而然基础架构部很重要的工作就是规划选型和管理，让云计算厂商或者外部厂商来提供更好的服务，这种方式其实在全世界绝大多数公司采取的方式。这也是体现社会化分工的最佳形式。
当然这种方式也存在很多挑战，基础架构团队是否能够有足够的能力和技术视野选择正确的符合自己企业诉求的服务方，如何更好的将这些外部服务的价值发挥出来，同时包括成本管理等各方面也变得尤其重要。这种方式有时候比前面的基础架构部的技术视野要求要更高，甚至需要更强的规划能力。
购买服务的基础架构部也不能变成了纯粹的成本驱动的团队，还是要以业务为第一优先级。现在很多公司为了降本增效不断地选择多家云厂商，让业务在不同的基础设施上迁移来迁移去，有的公司甚至一年可以迁移多次，给人一种天天在迁移的感觉，让业务和具体干活的牛马们苦不堪言。
其实是运维的基础架构部
还有一种基础架构部，其实可能就叫运维部，他们往往在公司内部的地位其实是不高的，业务同学不管用服务还是用自己构建的开源软件都无需这个团队统一，他们只是把业务上线的系统管理起来，运维起来，往往视角也大部分集中在主机这个层面，本身这个团队也不一定受公司重视。
其实这就相当于没有基础架构部的状态，业务团队开始无限增生各种各样的基础设施，基础软件，有的用云，有的自己搭 IDC，有的自己搭数据库，有的用 RDS 服务，乱七八糟。
当然如果这个客户是云计算用户，通常是云厂商最喜欢的，业务研发刷刷刷的开服务花钱，大量的浪费，完全控制不住。如果是线下 IDC 的情况则是不管是管理成本，还是安全风险都巨大，而且缺乏统一管理性，导致管理成本奇高。
后台回复“进群”入群讨论。
