# 基础架构部，真的没有必要了么？

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

---

> 原作者：程序员 Aike · [微信公众号转载页](https://mp.weixin.qq.com/s/HFKWZqE9jwMhf5X_yjb13A)

今天一篇[基础架构部，还有必要吗？](/misc/need-infra-team/)的文章刷屏了，作为一名资深的基础架构从业者，浅谈下自己的看法，期望引发广大基础架构从业者、业务开发、测试人员等相关从业者更多的思考和判断！

01 基础架构部的定位

不同公司对基础架构部的定位不同，以下是可能的几个方面：

1、通过技术和工程手段、运维手段，保障线上服务稳定性。比如运维人员保障业务核心指标健康，网络、服务器等基础设施组件能承受业务压力等。

2、构建统一的基础服务，比如数据库、消息中间件、微服务框架，或者中台服务，减少各业务重复的轮子，降本增效。

3、提供技术平台给内部开发、测试人员使用，比如CI/CD平台等，提效研发，推广并引导业务部门使用优秀的技术，提高业务开发的质量和效率。

02 基础架构部的技术

基础架构的技术是先进的、也是Low的。对于不了解这些技术的人来说，可能是先进的，但是对于在基础架构领域摸爬滚打几年的老兵来说，可能也玩不出花儿来。

微服务架构包括如微服务与注册中心、远程调用、可观测性等等，三高架构包括高并发、高可用、高性能的各类成熟解决方案，网络、数据库等服务各云厂商也有成熟、合规、安全的方案，大数据技术不断演进，CI/CD系统开源的框架也有很多。

基础架构的解决方案确实很多是缝合开源或者魔改，大多情况下也确实没有核心技术。但是也不应该完全否定魔改的价值，毕竟我们要站在巨人的肩膀上前行，而不是闭门造车。

改造的同时必须结合当前问题去优化，提出自己的解决方案，不能完全照搬。比如，Apisix 相比 Kong、Kong相比OpenResty、OpenResty相比Nginx，每次都是优化一两个关键点，这样可以加速技术进步，我们也能更快享受到云原生网关的便捷。\

基础架构更需要做到：源于开源、强于开源、回馈开源。

03 基础架构部的业务价值

基础架构是业务研发的中后台，其业务价值是相对模糊的，包括以下三个方面：

1、直接服务于业务稳定。

我们的软件产品运行在基础架构部维护的服务器设备或者云服务上，使用基础架构部提供的数据库等基础服务，调用基础架构部提供的中后台服务，保障其稳定性至关重要。

2、提升效率。

通过构建各业务线通用的基础服务、中后台服务、CI/CD平台工具，提效日常研发交付。

3、降低成本。

通过收敛各业务线独立维护服务器或云服务、数据库、网关等微服务基础组件、中后台服务，减少各业务线重复开发造成的成本浪费。

04 基础架构部五宗罪？

也正是由于这些收敛，造成了基础架构被各业务开发部门诟病，包括以下突出问题，我们尝试逐一剖析下：

4.1 基础架构部对线上服务器、基础组件的权限管控

只有基础架构人员对线上服务器、线上基础组件才有操作权限。开发人员需要配置一条路由，提工单；开发人员需要新创建数据库，提工单；开发人员需要开通网络限制，提工单；开发人员需要看下服务器配置，提工单。

基础架构为什么这么限制？因为要保障线上服务稳定。怎么做才能更稳定？尽量不去动它。所以，就来了懒政，不管动了有没有风险，都限制别人不能修改。

如何改善呢？当然要放开权限管控，但是要关注放开后系统稳定性是否会降低，关注权责对等，对能承担起责任的人开放权限，并通过平台化、自助化的理念把这些功能线上化，开放给开发人员，这也是“平台工程”的核心理念之一。

但做好很不容易，尤其是各公司的基础架构人员很少，还不愿意投入。

4.2 基础架构部阻塞DevOps和生产效率

质量和效率的均衡是门哲学，自己大部分都在做DevOps相关的流程、平台和工具。基础架构部阻塞DevOps的原因是：工具真难用，开发者体验太差！CD非得走个审批，还是半自动的。放着ArgoCD等先进的工具不用，因为不敢用、没投入资源去持续建设。

毕竟业务至上是肯定的。业务都不赚钱，优化个发布流程减少10分钟有啥用。。。系统越来越糟糕。。。还没人管。。。

4.3 基础架构部自研IM等系统

不是重复造轮子，而是要自主可控。公司每天聊了啥，给别人都看到了，完全不放心啊。万一公司搞点小九九，岂不暴露了。每天打卡时间控制、员工在干啥，那叫一个自主可控。

代码管理平台，自己的代码是核心资产（毕竟可能也没别的竞争力了），自建数据库也是，交给其他公司管理，虽然你有保密协议，但是实在无法放心。

4.4 基础架构部和业务单元的关系

DevOps提倡特性团队，大家都是为最终的业务目标服务的。基础架构开发和运维人员是专业的，对于不契合的场景还是坚决说不；业务开发人员也是专业的，对于不合理的设计要拿出持续重构的精神和勇气。否则系统到后面越来越不稳定，难以迭代下去了。

![图片](01.webp)

4.5 基础架构部的守旧心态

守旧无关基础架构和业务开发人员，守旧是心态，是惰性，是人性。变革者永远是少数，基础架构和业务开发人员都需要变革者带领着向前走，大家都走过来了，守旧变成了从众，就完成了演进了。

![图片](02.webp)

05 基础架构部的路在何方？

我自己是DevOps和研发效能的支持者、践行者，从DevOps的理念出发，相信就会有所改善：

1、特性团队：基础架构部和业务部门不是对立的，都为具体业务交付结果、为特性负责，基础架构BP去业务部门，与业务开发肩并肩，解决业务问题。

2、平台工程：高层舍得投入DevOps流程建设和平台建设，让基础架构去构建平台工程，服务业务，服务开发人员。

3、持续改进：不要期望一次投入就能解决所有问题，基于公司现阶段实际问题持续改进，并随着公司发展持续发现新问题并解决。

期望此文能引发大家对基础架构更多的思考和评论，也盼望广大从业者的批评指正。

点击关注我，交个朋友！