编者荐语：

　　倪工认为 IT 团队，在上云之后，不仅要修改工具和流程，也要修改组织架构，以提高组织效率。很自然的，也会对从业者提出新的技能要求。

　　这两天马工关于基础架构部的文章「基础架构部，还有必要吗？」进一步在朋友圈疯转。严格来说，这篇文章更应该被看作前一篇关于多云的文章「多云战略：无奈的现实，危险的选择」的姊妹篇。

　　恰逢这两天笔者也在思考关于「云上安全」的一些话题，其中一部分核心观点其实和这篇文章多少有些类似。之前我们在文章为什么汽车行业正在全面拥抱公有云中从企业决策者视角详细讲述企业上云动机，借此讨论，再展开多聊几句关于用户如何使用云的一些拙见。

　　「云优先」的思维方式

　　马工这篇文章和他这两年的观点是一脉相承的，核心观点只有一个：云正在不经意之间改变着组织架构的构建形态，甚至重新定义职业能力象限。

　　只是文章整体论证多少有些武断，马工通过例举了基础架构部的各种「无能」事迹，甚至不惜将团队妖魔化，去论证团队已经没有存在的必要，笔者认为仅凭借这点是不足以服众的，毕竟组织架构和团队能力这两者本身就要分开来看。

　　但本文并无意纠结于基础架构部到底有没有核心技术，事实上，笔者认为这个话题的讨论重点也根本不是「基础架构部的存在是否利大于弊」。真正在讨论的是，今天我们所处的云时代，行业正不断走向成熟，云早已不再只是资源托管平台。作为一种全新的生产工具，在带来新的生产力之后，在「新的生产关系下，企业组织架构该如何构建」。

　　笔者观点甚至可能比马工更悲观：在今天，但凡企业组织形态没有基于云的特性去做架构思考和设计，即使达到了马工在文章中所讲述的两点：具备「优秀的技术」和「引导使用优秀技术的能力」，最终的结果大部分情况都是令人失望的。关于这点我从令辉兄的另一篇文章基础架构部不死，只是慢慢消逝一文中感受到了同样的情感，老兵不死，他们只是逐渐凋零。

　　基础架构部未来会消失吗？我认为不会。在过去，马车用于运输，但今天却常见于马戏表演，演变成了一种娱乐活动。马车消失了吗？没有，只是它的数量和存在的目的都变了。

　　这两年在和不同行业客户打交道的过程中，总是会遇到各种用云过程中的各种怪相。

　　例如用户虽然使用公有云，但是团队完全按照数据中心时代去构建，从工作职能划分再到技术选型，最好是在迁移上云过程中，连IP地址都不要发生任何变化。

　　甚至于一些用户会提需求说，我们希望能让我云上的架构看起来和线下一样......

　　再比如，一些客户会希望利用公有云去实现K8s架构下的应用及数据冷备......

　　再比如，我此前在多篇文章中所提到的，非要在毫无标准可言的多个云平台之间，基于美好但不切实际的多云管理平台去实现跨云迁移。

　　种种这些，许多人只是惯性的将系统从云下部署到了云上，却又很难讲清应用究竟是否真正的上云，以及和没有上云有什么区别。

　　前两年「Cloud Native」这个词很火，时而被形容架构，时而形容产品，笔者认为在此之前，「Cloud Native」更应该被视作为用户在设计应用及平台架构时的用云观。

　　这两天也看了不少留言和文章极力证明自己团队的技术价值，从而试图论证基础架构有存在的必要，实际上都没有太大的实质意义。

　　「自服务」的去中心化组织

　　其实如果记录下时间轴，我们会看到最早是网络工程师和操作系统管理员、这两年讨论更多的DBA，然后再到基础架构部。而这个顺序刚好是伴随着云计算行业的不断成熟，从IaaS基础设施层，再到PaaS一层层往上走的。

　　在国外，由于用户和云厂商之间所形成的技术共识，这个结果的发生的比国内要早几年，从这两年的行业趋势来看，国内目前也朝着这个方向在发展。

　　如果你所在的组织并没有使用，也永远不会使用公有云，大可不必将马工的文章放在心上，至少眼下你所面临的处境，生产工具和生产关系的矛盾并没有发生。

　　但如果你所在的组织未来计划上云，或是已经用云，从技术选型再到人员能力矩阵的重构，这个时间或早或晚，但一定会在某一天发生。这也就意味着今天许多团队在云上或云下自建的许多基础设施平台的工作，在未来可能都是负价值的。

　　为什么在云架构下，传统技术架构的划分已不再适用？

　　架构的不可持续性

　　过去我们在做基础架构工作时，最常见不过的便是技术山头下的标准化问题。永远不要挑战人性，只要在企业内部团队不是一家独大，大家就一定都想自建一套技术标准和产品体系，最后的结果大概率无法达成共识。大部分情况下，基础架构都成为了为特定业务服务的配套团队。

　　而上面这种已经算是比较好的技术归宿，事实证明「以“大神”为中心」构建的技术平台永远都是不可持续的。更多的情况是当业务系统接入之后，因人员变动缺乏维护的基础组件，留给业务团队的只能是一地鸡毛。

　　这种试错和重构所带来的额外技术成本，几乎成为了企业在基础架构发展过程中的阿格琉斯之踵。但基于云优先理念，情况可能完全不同，不同业务部门基于同一套云托管服务很容易在团队之间达成技术共识，在标准的平台界面上各方都是一致的，同时也能够基于各自的实际业务场景，选择不同的技术实现方式。而在过去以资源为中心的技术架构形态之下，这种情况是不存在的。

　　因为上述的诸多原因，从这两年的云上趋势来看，头部玩家也在逐渐拥抱云上PaaS。从跨越时间周期更长远的视角来看技术演进之路，基于云平台技术架构的可持续性是经得起时间验证的。

　　DevOps挑战

　　另一方面，笔者并不想要挑战基础架构的技术能力，但事实上基于云仍会比技术自建要高效的多。

　　过去十余年，国内在实践DevOps工程的过程中，其组织形态往往是运维来主导，因此自动化便成为了首要业务关键指标。但自动化其实只是过程，经过这些年的尝试，我们很容易发现DevOps的最大挑战其实并不能通过自动化彻底解决，甚至可以说是占比极小的一部分。除非今天你所面临的业务场景足够简单，同时业务又很少发生变化，否则真实世界一定会有大量的corner case是需要依靠人工变更去完成的。

　　在人员架构复杂的大型组织，DevOps真正要解决的问题是跨职能团队之间的信息衰减，而想要达到消除信息衰减，关键在于如何将组织形态尽可能地扁平化和去中心化。因此许多时候，组织寄希望于靠一套自动化工具平台去解决跨职能团队的协同问题，效果往往是很差的。

　　还有比将所有基础架构完全交由云厂商管理，由研发人员所主导「开发自服务」更优雅的DevOps工程实践吗？

　　由于部门墙的存在，企业内部的许多团队被无形的保护了起来，以至于很多事情组织并不是以最高效的方式去运作的，而在另一些主营业务是云上代运维服务提供商的企业，在真实商业环境你死我活的竞争下，他们能够更快察觉到开发自服务所带来的全新业务挑战。

　　曾经，当软件提供商给客户开发交付一套核心系统时，他们需要和企业内的运维、基础架构等团队一起协同；如今，他们完全可以基于Serverless、IaC等工程实践，彻底屏蔽并绕开组织内的所有人，拿走项目中最大的那块蛋糕。最后，还可以正大光明的讲述一个在技术领先性的架构理念下如何提升人效的故事。

　　马工一直在讲国内云用户其实不怎么懂云，仅仅将其作为资源托管平台的IDC2.0。其实关于这点笔者是有信心的，从最近这两年和客户在各种场景和项目中的交流来看，仍然有越来越多的客户是在正视这些现象的，从资源运维到平台治理，从ClickOps到IaC，这种趋势的转变更多的只是时间问题。

　　写在最后

　　回到本文最初的讨论，基础架构团队在未来仍然会存在，但他们的数量必然也会像更多企业的DBA一样被极大的减少，从企业的技术建设者转向云实践下的工程布道者。

　　云计算作为技术平权的开放平台，在研发流程中极大的消除了不同管理角色的工作职能，但生产关系的改变同时也在创造新的机会，未来的中心化团队建设重心也将转向从「精细化」管理到「精确化」运营的平台工程的体系建设。

　　不仅如此，如果再向上看一步，云并不仅仅是解决了技术人员的统一语言问题，甚至包括财务人员在内的非技术人员同样收益，今天如果要做预算规划，财务人员完全能够基于云账号实现「财务自服务」，最终使得FinOps成为可能。

　　如果认为云计算最终只会卷到甲方的，可能真的只是一种错觉。这几年，能够明显感觉到随着行业走向成熟，对于从业人员的能力矩阵也在发生着改变。

　　最近这段时间，笔者的大部分精力都放在了技术服务岗的面试工作。在此过程中也发现一些有趣的现象。一些愿意主动投递简历做云技术服务的，大部分是以过往以运维工程师相关背景的技术人员。

　　而一些研发背景的人员会觉得云计算和他们的职业成长规划似乎并没有太大的关系，在过往的工作中，他们也很少会真正由他们去创建、配置、操作云服务，有类似经历的其实在行业中不在少数。

　　作为普通职场人，每个人都或多或少会面临不同程度的职业危机。许多时候我们总是会苛责自己没有努力做到更好，又或是时常抱怨自己自己没有得到更多的机会，但外部环境的变化从不以人的喜好和意志为转移，绝大多数情况下，普通人能做到的极限往往也只是顺势而为。