DevOps 已死，平台工程才是未来？ ｜ QCon 闭门会

在 5 月 26 日，QCon全球开发者大会（广州站）顺利落地，在现场，InfoQ 特别策划了五场闭门会，主题分别为《企业在 LLM、AIGC 浪潮下的研发探索》《DevOps vs 平台工程，必要性和 ROI 探讨》《破解成本优化后的稳定性问题》《业务出海之架构、合规、运营》《金融行业数据治理经验分享》，本文为《DevOps vs 平台工程，必要性和 ROI 探讨》研讨纪要整理～

参与嘉宾

主持人：李忠良 InfoQ 会议编辑 

1. William Yang，HashiCorp 资深 SA，讲师

2. 金李东，涂鸦智能（技术总监）

3. 杨振兴，东软瑞驰大连研发团队负责人

4. 汪维敏，华为云 PaaS 产品总监 

5. 李大元，蚂蚁技术专家，KusionStack 子项目负责人

6. 周玄，小红书 Android 架构负责人

7. 刘星辰，众安保险工程效能高级专家

8. 江鹏，数澈科技联合创始人

9. 彭伟国，解决方案架构师

研讨话题：

• 讨论话题一：你如何看待 DevOps 与平台工程的关系

• 讨论话题二：你认为是否有必要上平台工程？投入产出比怎么样？

• 讨论话题三：平台工程的落地难点

精彩观点

你如何看待 DevOps 与平台工程的关系

李大元：前段时间有“DevOps 已死，平台工程才是未来”，我不认同，我认为平台工程是 DevOps 的延伸。

汪维敏：我在平台工程领域的经历中，发现以下要点值得分享。首先，仅仅开发工具是不够的，我们需要将其以商业化的方式进行开发，以实现产品的精品化。其次，了解方法论对于成功开发受人接受的工具至关重要。平台工程与 DevOps 相互关联，共同推动研发效能的提升。商业化是取得出色成果的关键，仅在公司内部提供工具服务的平台工程组织很难实现优质用户体验。同时，平台工程在落地过程中面临各种挑战，如工具集成、权限系统整合、多租户问题以及可靠性和安全性等。通过持续努力和创新，我们能够推动研发效能的提升，实现产品的精品化，并为用户提供优质体验。

刘星辰：众安保险在研发运维方面建立了一套完善的体系，并通过科技公司的商业化输出来扩大影响。在内部和外部的研发运维中存在一些差异，外部客户更注重第三方解决方案，而内部则受到一些限制。DevOps 与平台工程的关系是相互补充的，DevOps 关注整个从需求到上线的流程，而平台工程则为开发者提供自动化和产品化的服务。在平台工程阶段，通过标准化和服务化，开发者可以屏蔽底层基础设施并获得赋能服务。这个阶段是横向和纵向结合的过程，能够产生协同效应。

彭伟国：我从事 IBM Rational 产品的实施大约十几年，期间接触到了 IBM 的一些 DevOps 产品。在实施 DevOps 时，面临着客户项目的多样性，涉及不同的价格和语言，起初推广 DevOps 非常困难。然而，在过去的两年里，大家形成了共识，推广变得更加容易，我认为这与平台工程密切相关。

过去，我在公司内部有各种语言和架构，想要实施 DevOps 非常困难，尤其是面对部门的限制。比如当我在广发银行工作时，首先，我们需要一个统一的开发框架，所有产品都基于同一平台的架构开发。有了这样的情况，推广 DevOps 就变得非常快速。我记得起初花了大约半年时间推广到广发银行的 6 个系统，但后来仅仅花了半年时间推广到 200 多个应用系统。

平台工程与此密切相关，因为在这种情况下，可以快速复制，DevOps 快速推出。所以我认为 DevOps 和平台工程是相辅相成的。在平台工程中，你需要有一个团队进行研发，在这个过程中，你如何管理需求？如何进行配置管理和持续集成？这些都需要 DevOps 来指导。但是，如果你公司内部所有系统都是通过统一的平台工程整合和开发的，推广会更顺利。

杨振兴：过去我们作为 DevOps 需求方，在实现过程中遇到了许多场景。我们希望 OpenAI 团队能够为我们提供帮助，提升整个研发效能。现在我更加偏向于 ToB，我们可以通过从需求到持续集成，持续交付等多种开源工具的组合来实现。但是每个行业都有其特有的东西，这些标准工具无法替代。因此，我们将整合这些东西，并结合行业特点，打包成一个完整的产品体系，然后将其推广给特定行业的客户。

例如我们现在正在与一家汽车制造商合作，对于车联网而言，每当我们将解决方案成功应用于一家汽车系列后，我们就可以将其作为一个整体产品引入到另一家汽车系列的新项目中。这样，我们实际上就是利用了 DevOps 工具，打造了一个特定领域的完整产品，并作为一个平台工程来提供服务。不管是产业互联网还是其他领域，借助 DevOps 的方式结合行业特点，推出平台工程是可行的方式。

金李东：平台工程与 DevOps 密切相关，它在支持 DevOps 实施方面起到关键作用。在我们公司的发展过程中，我们经历了快速膨胀，并尝试了多种 DevOps 工具，却未能满足特定的需求。团队的扩张速度、节奏、人员能力和文化体系等方面存在差距，使得推动 DevOps 变得困难。

为了处理全球不同数据中心和节点的流量以及配置问题，我们尝试了公有云和私有化部署，但发现每个云和数据中心的配置需求各不相同。为了解决这些问题，我们决定将研发团队与平台工程结合起来，以处理不同云、数据中心和版本的配置，并根据规模确定适当的支撑能力。尽管曾尝试将开发和运维分开管理，但目前还未取得成功。

江鹏：对于 Devops 的理解在不同公司和行业之间存在差异。个人认为，Devops 更像是一种文化，旨在推动研发和运维部门之间的协作，提高交付应用业务价值的速度。在实际落地时，个人经验是，不同公司的形态可能不太相同。传统企业很难让研发完全掌控应用的部署和生产环境，因此可能会设立所谓的 Devops 团队或工程师，作为技术架构和运维之间的桥梁。

然而，也有一些规模较小的公司，每个工程师都精通研发和技术架构知识，并能够负责从产品开发到应用发布的整个流程。因此，对于如何实施 Devops，并没有一个统一的标准和规范。

对于大型企业来说，不可能每个研发人员都精通各种基础设施知识，完全驱动应用的开发和部署。因此，平台工程的作用在于建设一个平台，通过屏蔽复杂性，为开发和产品团队提供可复用的能力，以降低他们的认知负担，实现产品的交付。个人理解中，这需要建立一些方法论，并构建相应的平台。

你认为是否有必要上平台工程？投入产出比怎么样？

江鹏：是否需要引入平台工程：个人观点认为，是否需要引入平台工程与团队情况和公司规模有关。对于创业公司等规模较小、研发人员都懂得容器和 Kubernetes 等技术的公司来说，暂时可能没有必要引入平台工程。至于投入产出比：在考虑是否引入平台工程时，需要关注投入产出比。海外案例显示，引入平台工程可以提升运维和 Devops 功能支撑的研发数量，并加快交付速度。

然而，一个广州的大型银行客户的案例显示，他们已经引入了平台工程，包括内部开发者门户和使用 Git、GCP 和 AWS 等工具来实现整个流水线。该银行通过试用平台工程并比较原有方式的时间和成本差距，说服研发团队使用该平台工程，因为投入产出比明显提高。

汪维敏：平台工程的建设需要大量资金支持，而华为作为一个投入较大且拥有众多研发人员的公司，通过从各个产品线预算中拨出一部分资金来支持平台工程。随着团队规模和研发组织复杂度的增加，以及内部使用的工具增多，统一语言、环境和工具的重要性变得更加突出，以提升沟通和效率。

对于公司而言，投入产出比是决定是否愿意持续投资于平台工程的关键因素，当产品线或部门能够通过平台工程解决问题并实现成本节省时，公司会有更大的动力投入资金，无论是通过整个公司直接拨款还是通过各个产品线的预算汇总来支持公共的平台工程部门。

William Yang：从工具提供商原厂的角度来看，我们经常遇到一个情况，即客户对 DevOps 的理解和需求不同，导致他们在开发平台工程方面采取不同的方法。有些人可能基于成熟产品如 IBM，有些人可能选择 GitLab，而我们 Hashcop 则根据自己的理解开发了 Telephone Enterprise 和 Clock Operation Model，并将其与我们的产品集成。

因此，根据企业规模和业务需求的不同，选择基于成熟产品模式还是完全自研的方式来构建平台工程会有所偏向。前面提到的企业规模和业务差异都会影响人们在选择和实施时的倾向。

我注意到有时候基于自研方式可能会导致过多功能的堆积，最终无法完全实现这些功能。我不清楚这种自研方式在安全性和效率方面的表现如何，特别是投入产出比方面的投入情况，以及后续维护成本的变化，例如员工离职和核心团队流失等。维护成本会随着业务的变化而不断更新。

因此，我们会看到一些成功的案例，也有一些自研方式的失败案例。有些案例刚开始做得很好，但最终发现投入的成本过高，无法持续下去，因为缺乏业务驱动。因此，基于已经成熟的产品来构建平台工程仍然是一个值得考虑的选择。在这方面，我们已经看到了许多成功的案例。

彭伟国：大家刚才提到了是否需要进行平台工程，实际上在我实施的几个客户项目中，像 XX 银行，当时并不是从头开始构建平台工程。他们首先基于一些工具来开发了整体框架，其中还没有包括用户管理和权限管理等功能，但他们提供了一个基础平台。这涉及到一个投入产出比的问题，即如果你在运维和维护团队方面投入大量精力，最后的投入是否划算。所以 XX 银行当时只是基于这个框架提供了一些基础服务，其他方面如客户管理则由业务团队开发，平台团队提供基础的开发工具。因此，在考虑投入产出比时，首先要看团队的规模，如果你的团队规模较大，比如上千人的开发团队，我认为是有必要进行平台工程的。

李大元：平台工程是一项工程化的任务，需要规模才能实现收益。对于规模庞大的团队来说，是否进行平台工程取决于技术投资的问题。技术投资意味着解决当前架构和技术无法解决的问题。在云原生时代，基础设施的多样性增加，平台团队无法成倍增加。因此，通过技术手段和进化来保证团队在人数不变的情况下，仍能管理更多的基础设施是必要的。进行平台工程的决策应基于实际问题和投资回报率（ROI）的价值判断。如果认为投资值得，就应该进行平台工程；如果认为不值得，即使团队规模庞大，也可能不需要。

周玄：过去两年，我们经历了快速增长的阶段，业务和研发团队都翻了倍。然而，我们面临了一个问题，尽管我们依然保持高标准的招聘要求，但由于产品增多，整个迭代速度并未放缓。我们发现业务产品和研发团队的需求吞吐量正在下降，交付质量也在下降。因此，我们开始意识到，产品和研发团队的增长不是突然跃升，而是一个持续迭代的过程。

现在，我们面临着一个增长过程，需要讨论的是，是基于我们已有的 DevOps 工具进行迭代和需求收集，还是引入一套成熟且产品化的解决方案。目前，我们可能暂时选择前者，因为后者的投入存在不确定性，并且公司目前还没有形成一个专门的团队来考虑投入和产出的具体过程。我们认为维持一个小团队可以解决当前的问题。然而，从这个阶段来看，这可能是一个从量变到质变的过程。我不太相信在未来一年中，我们的规模再翻倍后，仅通过迭代从第一版到第二版，再到第三版就能解决问题。

杨振兴：公司规模和产研能力是其中的重要考虑因素。我认为还有几个点也值得讨论。首先，公司处于不同的阶段，特别是在快速扩张阶段，很可能会出现混乱的情况。不同团队在技术栈和技术理念上可能存在差异，很难统一起来。因此，在不同阶段需要进行整合和规范化。

另一个要考虑的问题是是否需要采用平台化的公司架构。我有过两种不同公司的经历，感受差别很大。对于像整个技术内部一体化的公司来说，一个重要的指标是研发人员的效率。比如，在短时间内能否交付小需求，以及交付后的反馈速度。对于 ToB 领域来说，这涉及到项目回款的算法。在我们的场景中，关键问题是能在多长时间内收到项目回款。如果公司的盈利指标与项目回款有关，那么根据这个指标来决定是否采用平台化架构将是一个重要的决策因素。

金李东：根据业务团队的预算来计算 DevOps 或基础支持团队的存在和体现的价值。我们的目标是解决研发项目的问题。对比涂鸦和小红书，涂鸦在几年内扩张到了几千人规模，但我们的 DevOps 团队的比例是根据业务团队的需求同步扩招。

我们使用了许多云服务，包括海外和国内的云服务。每个云平台的特性和适配要求都不同，但我们的人员资源有限。因此，ROI（投资回报率）成为体现价值的重要指标。当然，对于平台的工程建设，可能会有一个节点，当平台的数据稳定时，我们需要评估现有的人力资源支持情况。这时，我们可以根据 ROI 来评估整个团队的价值。

平台工程的落地难点？

汪维敏：当构建一个开源平台时，有几个关键问题需要解决。首先是整合账户和权限体系，确保各个工具之间的账户和权限可以通用。其次是要考虑平台的开放性，采用全插件化的架构，以兼容各种开源工具。数据一致性也是一个重要挑战，因为每个工具都有自己的数据模型和数据库，需要统一数据架构模型来实现数据的集中存储。另外，可靠性问题也需要被关注，因为开源工具可能存在限制和性能瓶颈，需要技术能力来解决并确保系统的稳定性和安全性。

另外，开发者通常缺乏忠诚度，他们对新技术和工具的期望极高，迅速抛弃旧有解决方案。因此，在开发工具时，我们必须采用产品化思维，确保立项阶段明确资源投入和功能场景化设计。此外，内部开发团队应当以产品化思维为导向，设立产品经理来管理和开发工具，而不仅依赖开发人员。

杨振兴：推进平台工程需要综合考虑公司的业务架构、组织架构和技术架构。首先要了解使用平台的各方用户，包括研发、运维、产品、运营和客户等，以及整个公司的技术架构。对于技术架构较为分散的公司，需要从公司的线索中进行思考，确定优先满足的需求，并逐步推广给其他用户。在组织架构方面，可以通过扁平化结构和开放心态促进工具的使用，同时解决组织层面的问题。在 ToB 领域中，若公司习惯难以改变，引进外部人才并借鉴他们的经验和思想，有助于推动工具的接受和落地。沟通和协作也是解决组织架构问题的重要因素。

刘星辰： 首先，需要确定团队的定位和服务角色，并在短期内展示比现有工具更好的表现，同时说服用户相信未来会有更好的发展。其次，落地过程中需要借助技巧和说明产品的价值，不论是面向甲方还是乙方团队，都要明确产品相对于现有工具的优势。接着，以产品化的思路进行工作，制定明确的目标和路线图，迭代过程要渐进进行，周期内的替换和升级是对内部用户的承诺，同时促使研发资源跟进以实现承诺的目标。最后，要注意系统化的替换和演进是一项艰巨的任务，需要整个体系的全面支持，企业内部可能存在赛马机制和团队间的竞争，也会采用开源等方式，通过最佳实践的形成来推动落地过程。

江鹏：我分享三方面，首先是开发者体验：平台工程需要提升开发者的体验，让他们更高效地工作。同时，设计要屏蔽基础设施的复杂性，通过抽象和定义新的模型来实现。关键是确保设计能够提供比现有工具更好的开发者体验，而不需要用户花费高成本学习使用平台；

其次是产品的差异化：当推出一个新工具时，需要让用户明白为什么要使用你的工具而不是已经存在的工具。根据"十倍理论"，你的产品必须比现有方案更好 10 倍，才能打动用户。平台功能可能是基于现有工具进行改良，所以要结合类似工具并创造差异化；

最后是自服务与安全管控的权衡：平台工程追求开发人员自服务的同时，企业也需要安全管控。需要权衡如何让开发人员自服务的同时满足企业的合规要求。底层需提供足够的能力支撑，例如在部署前进行合规检查，确保拦截不合规的情况。

金李东：我们团队开发了 VPA 和 HPA 解决方案，旨在降低成本并提高效率，改善整体可用性。起初，在管理周会上，我向团队提出了推广的建议，所有的团队负责人都认可这个方案。然而，当我们最终推广方案时，只有大约 10%不到的应用选择开启这两个功能。团队负责人不愿意强制要求各个团队负责人或应用的负责人开启这些功能。我们首先选择了一些小规模试点，经过一段时间的运行，没有出现任何问题，我们随后强制性地开启了所有线上应用的 VPA 和 HPA 功能。现在，所有的自动弹性伸缩功能都已经开启，并且没有遇到任何问题。通过柔性和硬性相结合的方法，我们最终取得了成功。

活动推荐：

2023 年 9 月 3 - 5 日，在北京·富力万丽酒店， QCon 全球软件开发大会（北京站）已开启，现已开启售票，提前订票，可享受 7 折早鸟价，购票参会可以直接电话 / 微信联系票务经理 18514549229。