平台工程的 2023：助力云原生重构研发组织文化与组织架构

编者按：平台工程并非 2022 年度首次出现，最早可以追溯到 2017 年的技术雷达。经过 6 年多的发展，Gartner 于去年将平台工程列为了 2023 年度 10 大战略技术趋势之一。当我们回头去梳理平台工程相关技术的萌芽、现状以及早期实践者的部分经验和教训时，我们发现国外已经有了不少案例和实践，以及非常浓厚的技术讨论氛围，但从国内视角来看鲜少有相关案例。对于中大型组织而言，要想更加高效稳健地进行软件开发和发布，平台工程是一个非常重要的考虑项，因此我们希望此文能给企业管理者、CTO 及技术 Leader 与技术从业者带来新的思维启示与战略规划参考。本文原标题为“平台工程的 2022：助力云原生重构研发组织文化与组织架构”。

平台工程正当时

随着云计算行业的持续发展，企业内部的业务需求方和研发团队已越来越不满足于对计算、存储、网络资源的可编程封装与服务化，也不再局限于 IaaS、PaaS 和 SaaS，而是在云原生的加速下，包括开发人员在内期待更高程度的自动化和更智能的弹性，尤其是在多云、跨云场景下。基于此趋势，结合当前全球经济与地缘政治形势，大型企业和中小企业都在不同程度上收紧 IT 技术与数字化方面的投入但又要求更高的交付效率和可用性，如何更好有效缓解甚至化解其中的矛盾呢？

咨询公司 Gartner 之前发布过 2023 年 10 大战略技术趋势：

图片来自 https://www.gartner.com/en/articles/gartner-top-10-strategic-technology-trends-for-2023 

Gartner 期望这些趋势将通过使组织能够解决下列四个主题的关键优先事项来影响未来三年的企业战略：

1. 优化弹性、运营或信任

2. 扩展垂直解决方案、产品交付或无处不在

3. 开创性的客户参与、加速响应或机会

4. 寻求可持续的技术解决方案

其中平台工程（Platform Engineering）在细分的优化技术交付和扩展性方面为我们带来了新的启示。Gartner 认为：

• “平台工程旨在提供一组精心设计的工具、功能和流程，经过打包后便于开发人员和最终用户使用。它将提高最终用户的生产力并减轻开发团队的负担。 ”

• “平台工程是为软件交付和生命周期管理而构建和运营自服务的内部开发者平台（IDP）的学科。”

我们再来看看平台工程在技术成熟度曲线中的位置： 

图片来自 https://www.gartner.com/en/articles/what-s-new-in-the-2022-gartner-hype-cycle-for-emerging-technologies  

Gartner 预测，到 2026 年，80% 的软件工程组织将建立平台团队，其中 75% 将包含开发者自助服务门户。

本文将借此机会带领大家回顾平台工程及内部开发者平台相关技术领域的现状和进展，并对未来趋势略予以分析和初判，希望为你和你的团队带来更多启发，助力于未来年度的战略更新和技术规划。

回顾平台工程的发展

平台工程并非 2022 年度首次出现，最早可以追溯到 2017 年的技术雷达；但在此之前也已经有人使用这个词了，即便当时的指代可能与目前并不相同；而且也有很早就关注和讨论关于软件开发团队中的平台和工程效率等话题。

Gartner 在 2022 年度把平台工程列为了 2023 年度 10 大战略技术趋势之一，也不仅说明了这一年大家对它的关注度在上升，也说明了企业对软件交付效率和质量有了更高的追求。于大型企业而言平台工程的 ROI 和绝对收益可能都更高，这也是大型企业成为早期实践者的重要原因之一。让我们把眼光分别放到海外和国内，来关注下企业实践方面的信息以及相关案例的详细情况。

从全球视角来看，国外已经有了不少案例和实践（可参看 PlatformCon 2022 会议）。大型企业如 Google、Amazon、Netflix 等都很热衷于建设自己的企业内部开发者平台（简称为 IDP），这是平台工程落地的典型产物之一。

拿 Google 举例来说，他们的内部平台的开发方认为“关键点在于能够把复杂的问题划分好，每个人都有自己擅长处理的一部分复杂问题，而其他人完全可以忽略这些问题”。内部开发者平台的好处是，能够降低现代软件系统的复杂性，加快软件部署周期，创建更稳定的版本，提高开发人员的满意度和工作效率，同时降低运营负担。IDP 一般有两类用户，分别是平台/运维 SRE/DevOps 团队和开发人员团队，因此与 PaaS 并不完全相同，PaaS 往往由供应商或内部提供方规定开发人员应怎样工作，是基于开发人员团队已经熟悉的工具和流程构建的，但抽象性和一致性更好。而对于如何开始采用 IDP，Puppet 的 Kersten 是谷歌前 SRE，他认为“更大的问题是能够理解用户，并做出文化上的变革”，他与其他很多专家都建议“从小处着手”。

从国内视角来看，缺少但也有公开宣讲的案例。如 2022 年 10 月，蚂蚁金服发表文章总结了他们过去两年在平台工程上的探索和实践，阐述了规模化平台工程实践中的收益和挑战。蚂蚁金服认为 10 多年前提出的 DevOps 理念，在经历虚拟机、容器以及云原生时代后，大部分公司陷入了某种基于对 DevOps 朴素认知的 Anti-Pattern，并分析了企业规模化 DevOps 难以推行的常见原因。基于这些原因，在蚂蚁的实践中，更倾向于鼓励多方合作，从而让 Dev、Ops、SRE、Plat 各方之间形成一个正反馈循环。通过平台工程、专用语言、分治、建模、自动化和协同文化等几个角度的详细介绍，让我们了解到了各维度遇到的挑战及对应收益。最终，平台通过了 500+项目的验证，其中平台研发者及平台 SRE 与应用研发者比例不到 1：9，实现了高效轻量化的交付和发布，并服务了内部的多个运维场景，目前正在持续扩大应用规模来探索更多可能性。

对于国内的软件业而言，其实我们有更好的参照物，那就是我国在大基建方面积累的“大国重器”经验；在看似完全不相同的工程领域，道路、桥梁、建筑、水利、矿藏等行业的工程师们为了更好地交付他们的产品，构建了领先的平台、工具和标准，为一线工程师提供了更好的工作体验和效率，这也是大基建领域的工程文化之一。本文探讨的平台工程，其思路异曲同工，但如果更大程度地发挥软件工程的优势，那么开发人员对软件开发、交付、运行的更高要求和期待，绝不仅仅局限在 DevOps、工具链、流水线层面，而是从基础设施到中间件、微服务、IDE 等不同层次的更大弹性、更好体验，从平台工程的角度，就重点关注在自服务 API、内部开发者平台、开发者体验。

因此，平台工程的价值应当是在简化开发者体验，而不是复杂化；降低对开发人员的全栈知识要求，而不是要求开发人员从业务到代码到容器都要成为专家；通过平台产品来实现知识转移，而不是让知识成为开发人员和平台之间的鸿沟。最终，我们发现平台工程的本质是提倡“Developer First”的文化，这对于一些研发组织而言，可能是一种文化冲击，因此重塑文化可能会成为一个待选项。

在了解完国内外的基本现状之后，我们再来关注下相关的解决方案和产品及其背后的公司团队。 实际上，已经有不少专注在平台工程领域尤其是内部开发者平台或门户方向的创新产品，也有一些是从 PaaS 方向逐步演化而来，如以下几个参考案例（不是所有的）：

• https://mia-platform.eu/ Don’t waste time setting up your platform, just push the code!

• https://humanitec.com/   Powering your Internal Developer Platform

• https://backstage.io/  An open platform for building developer portals

基于现有的解决方案，接下来有一个更重要的问题：我的企业适合开始尝试平台工程的实践吗？ 其实，很难通过某一个简单的标准判断某企业或某团队是否要/正在实践平台工程，因为在现阶段，我们并没有严格的定义和区分标准，甚至也没有太大的必要去区分，重点是企业是如何组织软件开发活动，以及如何分工协作来达成软件交付的目标。

平台工程适合什么样的企业以及什么样的发展阶段和发展规模呢？ 你的团队是否要现在就拥抱平台工程？这取决于你的团队规模、发展阶段，更重要的是你的技术战略和当下的协作模式。 这也决定了早期实践者的经验是否对你能够提供足够的帮助。

云原生之火烧到了研发组织文化

通过以上回顾和现状的梳理，我们会发现，从工具到平台最终落地依然是围绕着开发者及开发团队之间的协作，这就回归到人和团队本身了。那么今天所讨论的平台工程将如何助力云原生时代的研发团队文化重塑与组织架构重构呢？首先，我们来看下与平台工程有关的几件事：

1. 软件工程  

2. 研发效能  

3. DevOps 

4. SRE 

5. IDP 

6. DevEx   

以上 6 件事情，在我们讨论平台工程时，或多或少都会提到，而且去年已经有不少的文章在讨论平台工程与它们的各种关系。这至少说明，作为新事物出现的平台工程，当前依然没有一个高共识度的确定概念和范围定义，它还在从已有概念中持续进化，这种进化的动力既来自先锋企业的早期实践经验，也来自于对现状不满的企业的多维度探索。

需要明确的是，平台与产品的区别和关系，这决定了所谓平台到底是否需要专业的运营。一般而言本文提到的平台主要局限在企业内部，提供给内部开发者使用的平台。事实上，To D 的产品和服务从来不需要依赖所谓运营推广，这是非常典型的 PLG 场景，用优秀的开发者体验获取内外部用户青睐与认同，要比再多的市场推广更有效。换个角度，我们需要让开发者与平台类产品与服务的的提供者成为 Allyship ，而不是 consumer-producer 关系。这些对于平台以及平台用户的深入洞察和理解，直接影响到我们的团队文化和协作方式。

云原生持续发展，从早期以容器为代表的单点突破，到如今 CNCF 的技术全景图 l.cncf.io ，已覆盖应用定义与开发、编排与管理、运行时、配置、平台、可观测性与分析等。有不少企业已经在产品环境拥抱云原生且从中受益。那么云原生的下一个阶段是什么呢？随着服务网格、不可变基础设施及声明式 API 等越发趋于成熟，有观点认为我们需要重构研发团队的文化和组织架构，通过开发者控制面来加强对开发者体验的重视，以更好地适配云原生，这也可以称为云原生时代的研发文化和组织架构。这意味着什么呢？

如果我们回顾下软件工程的发展历程，可以找到一些信号类型的信息，比如敏捷实践、DevOps、CICD 等，人们对于软件开发过程和软件交付的关注焦点，除了 code、ship、run 之外，还有人的因素，工程师们的岗位类型越来越多，协作方式越来越复杂，以至于有人喊出了“要什么 DevOps，我们开发者根本不想做运维！” 而人的因素，放到组织的环境里面，就上升为文化的因素，人们是否有着相同的使命、共同的愿景，且追求共同的价值观？ 这在技术的不同发展阶段、组织的不同发展阶段，都是需要做出与时俱进的文化重构，而且最终影响到组织架构，因为后者决定了开发团队之间以及开发人员之间如何高效协作。 我们在实践中看到非常典型的现象：业务团队对云原生充满好奇，而又对容器平台团队提供的服务不满意。

因此，对于拥抱云原生的研发团队而言，现在可能是你重视并思考如何重塑研发文化和重构组织架构的最佳时机，对于后者，团队拓扑是被频繁提到的一种理论指导，它定义了 4 中团队类型和 3 中服务关系：

图片出自 https://teamtopologies.com/

实践中很多研发团队已经采纳或部分采纳了这种团队拓扑，但如果结合平台工程的实践，这种组织架构将会让你的团队目标和定位更加清晰，演进也更加贴合需求，从而最大限度持续提升协作效率。

平台工程依然不是尽头 

回头看看去年平台工程成为年度热门技术话题之一，中文技术圈最典型的代表当属这篇 “DevOps 已死，平台工程才是未来” ，霸榜 InfoQ 热点 3 个月以上，加上自媒体传播引起多方广泛关注，并且带来了后续一波又一波的热烈讨论。为什么人们如此关注平台工程？可否解释为天下苦 DevOps 久矣？非也。恰恰是 DevOps 的持续实践为平台工程创造了契机，开发和运维并不想对工作边界非要争来争去的了，也并不认为一个人/一个角色能对软件的全生命周期负责。云原生时代的微服务规模将越来越大，关系也越来越复杂，平台产品将成为大规模微服务稳健运行、随时更新的有力保障。这就好像一艘现代化的超大吨位舰船，人们已经不再去争论到底这艘船由哪一个人或哪一个角色来掌舵，而是大家按照约定的分工，通过一套“自动驾驶平台”来协作完成对整个舰船的操控，确保始终正确且稳定运行。

展望平台工程在未来一两年内的发展，笔者认为平台工程不会成为谁的尽头，它只是研发团队和研发工程师持续追求高效、体验更佳的软件交付过程路上的一个站点。当然，平台工程的趋势也不可阻挡，尽管在当下，依然缺乏一套体系化的逻辑清晰的定义和边界，所以 Field CTO at Puppet 在接受InfoQ的采访时指出平台工程需要有一套发展愿景和蓝图，以避免 DevOps 等实践踩过的一些坑。

Daniel Bryant 作为  Ambassador Labs 的开发者关系负责人，也分享了他眼中 2023 年的平台工程及其发展趋势，他认为开发者平台并不会干掉 DevOps，而是提倡升开发者体验优先，并做出的 4 大预测：

• Prediction 1: The Growth of Developer-First Kubernetes

• Prediction 2: Developer Platforms to Unlock Developer Productivity

• Prediction 3: Developers Coexist with DevOps; DevOps Is Not Dead

• Prediction 4: The API Strikes Back – Microservices Testing

写在最后

对于一项新技术、新实践或新趋势来说，鼓吹和唱衰都会显得过于鲁莽，笔者更倾向于基于事实和案例来做出理性的分析与判断，并基于个人认知和观点做出感性的建议或倡导。对于平台工程来说，基于上文的信息，2022 年度无疑是在一个冉冉上升的起始阶段，它显示出研发组织和团队对于当下软件开发模式和实践的更高要求和预期。

随着云计算尤其是云原生的持续发展与进化，开发者希望更加灵活、便捷且弹性地使用基础设施，而这种希望现在开始不局限于传统的基础设施，也上升且涉及到了工程、架构、中间件，甚至更进一步，希望一切都可以服务化，按需按量去调用、组装，召之即来挥之即去！

如果我们把这种期望当作愿景的话，首要难题就是研发工程师对于这个愿景的共识度，这就不可避免地涉及到研发文化和组织架构。基于敏捷、DevOps 等实践的发展经验，从今天回看过往，我们不必重复走弯路和踩坑，而是以更高视角总结经验，吸取教训，不必纠结谁对 code、ship、run 等环节负责，而是借助新技术、新实践、新趋势，与时俱进地重构与之匹配的组织文化和组织架构，从而完成研发组织自身的同步进化和适配。

通过本文的内容，在面对平台工程时，希望给读者带来下列启示：

1. 结合团队发展阶段和当下现状，大胆尝试，谨慎入局；

2. 文化先行，重视开发者体验，从人的角度平衡长期主义和当下挑战 ；

3. 让组织和技术相互适配，开放心态，根据国内外发展动态和行业案例经验，适时重构组织架构。

拥抱云原生，不只是一个技术战略和技术规划问题，更是一个研发组织持续进化的问题。对于中大型组织而言，要想更加高效稳健地进行软件开发和发布，平台工程是一个非常重要的考虑项。让我们共同期待平台工程的 2023 。

作者简介：

杨振涛，vivo 互联网研发总监，目前关注开源治理、技术社区与工程文化建设。具有 15 年多个领域的软件研发经验，此前先后从事生物信息与基因测序领域的科研工作、电商与 IM 架构以及搜索引擎研发。开源技术与技术传播爱好者，先后参与和负责 Circos、Redis、Jenkins、Elasticsearch 等社区的本土化，也是 TED Translator & Reviewer。为了更加系统地收集并记录平台工程主题的技术趋势及发展历程，我整理并创建了一个 awesome list 供大家参考，欢迎各位参与贡献和维护。Github 地址：https://github.com/toptechevangelist/awesome-platform-engineering