提升字节规模化效能的平台化思路｜字节跳动平台工程实践

如今，在 Kubernetes 上构建应用程序的开发人员，不仅要写代码还要负责交付和运维等。而 CNCF 云原生的 Landscape 已经有 1000+ 张卡片，覆盖应用定义与开发、编排与管理、运行时、配置、平台、可观测性与分析等，开发人员“认知负担”越来越重，所以企业需要从 2023 年开始更关注开发者体验，去聚焦开发者平台的相关建设，提供好用的工具集合或平台工程。

于是，InfoQ 发起了一场《极客有约》特别栏目《云原生趋势下的平台工程》。在本期节目中，我们邀请了字节跳动效能技术专家姚志坤，以《提升字节规模化效能的平台化思路》为主题，和大家一起聊聊大规模微服务实践条件下，字节是如何通过平台工程协同数万研发人员的？字节内部开发者平台是如何演进的？传统意义上的运维岗位，未来会被平台替代掉?

以下是访谈实录，完整视频参看：https://www.infoq.cn/video/IMEjWQl3zS66Eb6uCOXL

杨振涛：欢迎收看今天晚上的 InfoQ 直播栏目《极客有约》，我是今晚的主持人杨振涛，本期我们有幸请到的嘉宾是字节跳动效能技术专家姚志坤老师。我们一起探讨的话题是《提升字节规模化效能的平台化思路》。下面我们请志坤老师跟大家打一个招呼。

姚志坤：大家晚上好，我很荣幸今天能与杨老师一起探讨内部平台工程的建设思路。我是姚志坤，来自字节开发者服务团队。在字节，我主导了服务端效能平台的构建，从零开始建立了各大业务的 CI/CD 解决方案，并拥有 10 多年的内部工具链和平台经验。我的职业生涯一直围绕着软件工程展开，探索软件工具的体系迭代过程以及精益 DevOps 研发效能等方面。今天我们讨论的平台工程是相对较新的理念之一，我将结合字节规模化效能落地的经验分享对这个概念的理解，希望能为大家提供一些参考和帮助。

姚志坤：我是从字节效能这个方向开始出发，见证了字节技术团队从千人到数万人的发展历程。在研发效能方面，业界提倡的是提高业务价值、提升交付效率和降低成本等目标。这几年这个方向也变得越来越热门。随着业务和团队不断发展，我们的效能体系也经历了三个阶段：探索期、成长期和成熟期。每个阶段我们都遇到不同的问题并采取不同的策略来应对。下面我将分别讲述这几个阶段的支持方式。

首先是业务探索阶段，这时人较少，工作量较大，系统还不太复杂。在这个阶段，一线研发的关注点主要在业务逻辑实践上，对工具的关注不多，选择也不多。当时使用的工具链版本基本是开源系统加一些定制，包括 GitLab、Gerrit、Jenkins、Jira 等，对一线研发较透明，社招同学的学习成本也不高。主要矛盾在于工具品质问题，开源工具往往针对小型团队设计，性能和优化程度不够，而且开源工具数量也较多，互相之间没有打通。因此，早期效能的思路偏向于 CI/CD 工具链的标准化，尽量避免选择过多。通过 CI/CD 效能平台打通一些数据接口，以及基础流程的标准化，可以实现效能提升和自动化，满足早期业务的需求。

第二阶段是业务的扩展阶段，人员和系统管理变得更加复杂，对测试工具、流程管理和发布过程监控的要求也更高。此时，更多的自研工具得以建立。此外，字节跨行业、跨应用进行探索，每个领域对效能的要求不同。例如，ToC 领域的业务需要更高频的交付，希望测试右移，即通过在线反馈调整产品策略。而 ToB 商业化业务则需要更高质量的要求，希望测试左移。这时的矛盾在于单一的标准化流程无法支持多样化业务的需求。在这个阶段，我们的整体思路是基于统一的中台化平台进行生态共建，分为生态和共建两个方面。生态的主要目的是构建一些像开源插件一样的体系，以低成本的方式将业务场景集成起来。共建的工作涉及不同的业务场景与自身资源结合的解决方案，以应对业务当前急需处理的问题。

在第三阶段，随着业务进入成熟期，从管理者的角度来看，他们更加关注价值产出。这些挑战包括业务增长放缓和管理成本增加的矛盾，即降本增效。从平台和业务两个方面来看，解决这些问题需要更加精细化的解决方案。从平台角度来看，经过第二阶段的共建，短期诉求得到了满足。但长期来看，生态的维持和多样性也需要高成本的维护。这会导致人力资源的分散和重复的建设。因此，需要更加精细化地解决过度的个性化带来的维护成本高的问题，集中力量去优化核心链路。从业务角度来看，随着研发效能的增长，更加关注端到端的投入产出价值。因此，对需求和技术的评估会更加严格，也会控制好投入产出比。为了实现这一目标，希望有更加细粒度的效能度量来进行优化。同时，也需要采用一些一致性或标准来落实规范，降低一些随机性的流程失控。此外，安全合规、发布管控以及内部质量红线也是第三阶段的支持重点。

姚志坤：先来说一下平台工程的概念。我在去年初开始接触这个概念，感觉软件行业正在从规模化的手工业向工业化进程转变。平台工程通常指设计或构建工具链和工作流程的学科。它会构建一个内部集成化的平台，用于衔接业务和基础设施。我的理解是，首先我们需要明确“平台”这个概念，因为它可能在公司内部被过度泛化，导致很多误解，特别是大公司内部有无数个平台。但实际上，许多平台只能做到一个工具或系统的层次。平台需要具备除了功能之外的更多特性，如可运维性、可扩展性，以解决领域问题。例如，外卖平台或打车平台，它们需要提供足够的闭环和标准化的服务，才能真正成为交易平台。而内部部门的一些开发者门户网站，如测试门户，仅仅是一堆工具的堆叠，还不能算作平台。

“工程”是将构建平台作为一个复杂系统进行开发。就像交付一个完整的软件工程一样，开发内部开发者平台也需要进行目标分析、用户分析、建模实施以及最终的推广运营。但是，我认为“平台工程”仍然是一个没有完整定义的术语，因为它缺乏目标范围。在不同的公司或领域中，它的规模可大可小。例如，将研发过程从战略规划到实际收益整合在一起，可以形成整个业务的价值流，也可以仅仅是一个软件或运维交付。

今天，我们先预设平台工程服务于产研团队。在产研中，高效能永远是追求的目标，而通过平台工程的方式来提升研发效能是新趋势。平台工程的目标是作为中间层来衔接研发和技术设施。和之前强调的 DevOps 文化和协作不同，平台工程更加强调流程和工具的重要性，这可能需要依赖于认知能力。因此，产研的开发者、负责人需要考虑问题的复杂性，我们需要系统地构建产研平台。对于大公司而言，工具链越复杂，业务流程越多样化，构建平台的难度就越大。因此，我们需要拥有工程思维，并提高该领域的专业性水平。

许多公司都采用一体化平台来封装工具并引入领先的技术来提高代码生产力。例如，最近比较流行的 AIGC 技术可以提高代码生产力的局部效率，同时过程管理工具也可以提高整体协作效率。对于开发者来说，云原生和 DevOps 带来的基础设施变化意味着工具链基础设施越来越复杂，使用的技术栈也越来越高级，但是使用难度却越来越低。DevOps 的技术发展旨在让开发者更专注于业务本身，去实现需求，将操作降至最低。比如与 20 年前相比，现在很少有工程师关注编译技术。此外，像 AIGC 这样的 AI 编程可能是未来的一种新的编译领域，可以通过自然语言生成代码。最终，开发者需要完全理解云基础栈的学习成本越来越高，但使用成本却降低了。

姚志坤：我从平台设计者的角度看谈谈如何实施平台工程。这里有三个关键点需要考虑：第一点是技术层面的积累，第二点是产研层面的理解，第三点是产品思维。

在技术层面的理解上，基础架构、SaaS 层、组件和工具链等系统，是一个逐层集成的分层结构。一般来说，越靠近一线研发人员的系统，尤其是 PaaS 内层的发布系统和编译系统，越需要丰富的使用经验。例如，在云原生领域，Cloud ID 和 IaC（Infrastructure as Code）模型、测试和监控框架等都是重要的部分，需要掌握对应的原理，才能更好地提供给一线用户使用，降低他们的认知负担。好的一面是，现在许多云原生技术都采用标准的 API 和声明式结构，更易于集成。相比之下，传统工具需要更多的适配和定制。如果技术水平不够专业，可能会导致底层构建的不稳定。如果集成的工具越多，平台的复杂度也会越高，最终可能会失控。因此，平台工程师需要在平衡工具和复杂性之间找到一个合适的平衡点，并确保系统的稳定性和可靠性。

在产研层面理解，就是需要有懂软件工程，需要有专家将工程改进沉淀到系统中，使得研发人员能够更好地利用这个平台来提高效率。对于研发人员来说，他们不需要关心研发效能或者 DevOps，只需要将平台使用好就能达到目标。如果没有专家，很可能会引入更多不符合时宜的规范或流程，导致管理成本高和价值产出不清晰等问题。

产品思维的理解，是一个常常被忽视的方面。虽然我们可能已经理解了业务和技术的集成，但是如何在现有企业的情况下设计一个前瞻性且有利于企业长期发展的平台，并推广它，需要一些具备产品思维的专业人员来更好地完成。这包括设计产品里程碑、推广、运营以及搞清楚平台中的每一个主要场景以及它如何解决业务用户的问题。例如，在平台研发过程中，有很多不同的业务输入需求，但是我们需要考虑哪些需求做，哪些不做，哪些需要进行前期的试点验证才能进行大规模的投入。这都是产品策略需要考虑的。

姚志坤：在字节内部的开发者平台和工具中，大部分都是自主研发的，但是也有一些工具是基于开源社区的版本进行二次开发的。我们的效能平台完全源于自主研发，而代码仓库则基于一些开源版本进行了一些内部定制。在考虑开源或自主研发时，我们需要在业界开源标准和我们内部问题域之间进行权衡。如果业界的开源标准已经涵盖了现有和未来的问题，那么我们会优先选择开源。因为这样就可以重用许多工具和插件，例如我们的代码仓库，我们的内核核心并没有改变，但是我们可以使用开源的工具和插件来赋能，并增强分布式能力、大仓的能力、稳定性和性能等指标以及容灾能力。

另外，工具链是分层的，就像许多大公司一样，我们内部的底层技术栈可能或多或少有一些历史背景。例如，字节内部的技术体系与标准的云原生标准存在一定的差异。因此，越上层的平台上，例如效能平台，越难找到一个标准化的开源系统，只有一些解决方案，这就需要大公司去自行研发并将这些通用的解决方案落实到自建系统中。此外，规模化问题也是导致字节需要自研的一个因素。

姚志坤：在字节的平台化过程中，我们认识到 CI/CD 是非常关键的一个环节。我们将流水线引擎置于较高的优先级位置。现在看来，我们按照平台工程的逻辑来实现 CI/CD，并希望通过高度灵活的流水线引擎来串联或封装所有内部工具，包括常规的测试发布以外的需求相关的流转能力、代码操作、评审和后续监控能力，将其整合到字节的 CI/CD 流水线中。

这个流水线的理念是基于价值流的概念，识别增值流程和工具的集成，超出了通常意义上的 CI/CD 流水线范畴。我们可以在 流水线上直接进行对合码和评审的需求或代码操作，并在流水线上进行应用的创建、整合 AB 实验等操作。我们将内部的流量调度、染色、动态配置开关和灰度发布能力整合成 AB 实验的流水线，并对应用监控和可观测能力以及发布能力进行自动化整合，能够根据灰度发布结果自动放量。

难点主要在于集成成本，因为工具链分散在字节的各个部门或团队中，标准不一致，因此每个集成和工具都需要额外的开发成本，有些还需要重新开发 UI，以确保在效能平台上实现界面的一致性。

另一个突出的问题是稳定性和可用性。这种问题不仅涉及到效能平台本身的稳定性，还影响到一线用户的实际可用性，因为他们将效能平台作为主入口。由于工具的稳定性不同，将多个工具串起来可能会导致更多的问题。为解决这个问题，我们有三个关键点。首先，我们关注高频工具链，由效能团队或平台工程团队负责研发和 QA。其次，我们提供监控能力，以保证被集成工具的团队能够及时发现工具链的问题，并向字节内部的 on-call 流程报告问题并解决问题，从而提高用户体验。最后，当出现无法及时解决的问题时，我们可以提供平台降级能力，将自动化能力转为人工解决或通过权限控制和风险阻止工具强制跳过有风险的步骤来确保流程的顺畅和安全。

CI/CD 早期是从无到有的阶段，中期是从有到全的阶段，现在更多的是从全到精细的阶段，目前处在收敛期。我们致力于打造高品质的 CI/CD 流程并将最佳实践应用于业务，提高一线易用性和体验水准，这是我们现在的阶段目标。

姚志坤：规模化是我们内部做这个的重要原因。规模化带来了四个主要的问题。第一，规模化会带来差异化，种类会更多，包括不同的微服务技术栈、配置和代码框架、前后端等。第二，规模化会提高安全性，因为在 10 万量级的微服务中，任何小的安全漏洞都会被放大，因此需要更加严格的管控方案。第三，规模化会对业务交付产生影响，因为不同的业务对交付有不同的诉求。第四，多样性会造成工具基础工具链的复杂性，这需要解决。

为了解决规模化带来的问题，有两个主要的解决方案：流程化和插件化。核心思想是通过建立云和工具的价值链价值流来整合和兼顾。在价值流构建的过程中，提供一些自定义节点，也就是插件化的思路，并且提升开放性，让业务可以自定义工作流程。

从价值流的角度来看，我们的设计思路是三层的。自下而上的三层设计思路对应着不同的目标层级。

在底层，有原子能力或插件，这与业界类似，主要是将工具链通过插件进行集成，从而实现单点提效。如果我们有新的想法或工具可以提高效率，可以将其作为原子能力接入到工作流程中。这样，我们就可以将一些原来需要人工确认的环节变成自动流转的环节，从而提高效率。

在中层，我们通过一个灵活的流水线系统进行串联，这实现了全链路提效。我们打通了不同工具链之间的上下文信息，从而避免了人为干预，可以同时调度多个工具链以达到目标。对于不同的技术栈和服务，我们可以设置不同的流水线来解决它们的问题。比如后端微服务的流水线、前端 BFF 的流水线、配置发布的流水线，等等。

最上层，我们通过识别业务价值交付流程，将内部所有不同应用和服务之间的子流水线进行归纳，在很多微服务的流水线之上做工作流的整合。例如，安全合规的大阶段需要审核安全卡点、质量门禁等，这些都可以做到最上层的工作流中，实现协同的提效。比如，某个业务的需求涉及多个研发人员、QA 以及多个微服务，他们需要一起进行联调和发布。这种活动可以聚合到工作流中。

我们最终实践了三套微服务端的研发流程，最小粒度的应用变更为中心的模型，中等规模的业务需求为角度去交付的工作流以及版本火车的工作流。它们分别对应了不同粒度的工作流刻画。这块比较复杂，时间关系我们不详细展开了。

姚志坤：确实，尤其在字节的扩张期，多个业务领域同时发力，规模化的微服务和复杂的研发过程使得我们对工具链的开发需求非常强烈。同时，我们非常注重团队构建，以便更好地支持工具链开发。在字节这样庞大的微服务体系中，任何微小的优化都可能产生巨大的价值。因此，作为基础架构团队，我们一直致力于不断改进工具链，以更好地支持研发团队的工作。

姚志坤：根据我目前的观察，海外的研发工程师更注重底层工具的开发和优化。因此，海外大厂的工具会做得更加可对接。举例来说，一个工具可能是测试系统，并且能够便捷地整合前置构建和后置发布，形成一个完整的工作流程。相比之下，国内的工具链相对复杂，为了提升端到端的体验，通常需要一个整合层或平台层来更好地组合这些工具，为一线研发提供优质的服务。

姚志坤：相较于传统的 CI/CD，云原生更加注重标准化和通用性，特别是在容器技术方面，已经形成了一些业界共识和标准化的做法。因此，在云原生环境下构建的工具链更加通用，更快落地最新的工具，而 Jenkins 系统还是需要研发和工具开发人员编写代码或脚本去连接各种物理机、虚拟机等，而这很难规模化。云原生环境下的容器化技术可以加速工具链的产生和规模化。

杨振涛：可以这样理解，Jenkins 和 Jenkins X 代表两个不同的时代。在传统的 CI/CD 领域，Jenkins 是几乎无人能敌的选择。但是随着云原生时代和 Kubernetes 的兴起，Jenkins X 相对滞后，因此出现了更多的新替代方案。

我们继续讨论。字节的平台工程主要服务哪些规模的用户？除了传统的业务开发工程师外，还包括数据科学家、机器学习工程师和其他不属于传统 DevOps 服务范畴的人员吗？人员变化会对平台产生什么影响或对体验方面有特殊要求吗？

姚志坤：从效能平台角度来看，主要服务于研发团队，包括研发、QA 和 SRE。如果从更广泛的平台工程角度来看，也必然包括数据运维这个方面。在效能平台上，我们集成了一些工具，包括数据模型发布等。当然，字节内部也有专门的团队负责数据运维工具链。

理想情况下，平台工程应该面向全链路，使得整个公司的研发资源能够在一个平台上完成研发流程的工作流沉淀。团队结构的变化可能会影响业务交付流程，但是否对平台造成影响，取决于平台是否能够预先设计考虑到这些流程的变化。像效能平台插件式系统，它的工作流是可自定义的。在一定程度上，如果一个团队新增了一个角色，比如 SRE，他们可以在平台上进行配置，因此这种情况下平台不需要做太多的调整，也不会对平台造成太多影响。

姚志坤：从技术趋势的角度来看，软件工程是一个分工和分步的过程。正如我前面提到的，编译工程师的角色已经消失，这是很正常的事情。随着技术的复杂性和更高效能的要求，将会出现更多的角色产生或消失。但是这并不会改变这些角色的价值，只是被一些更加自动化的能力或平台替代了。因此，平台工程师的角色应该逐步地去封装运维这个过程。从更大胆的角度来看，编码测试这一过程也在如今 AIGC 技术的影响下发生着变化，只是这种变化没有那么快或那么明显。

姚志坤：研发效能团队和平台工程团队的目标基本相同，都是打造一个集成式的平台。具体方案取决于实际决策，我们通过整合工作流的方式去做工具链的集合。但实际上我们和平台工程的定义还是有较大差异。目前来看，我们的效能平台应该还是一个子集。以字节为例，我们是一个上层封装的 SaaS 定位，团队没有直接负责编译、发布、测试能力，但与 ToB 产品类似，我们有更多产品角色，也有专业 QA 团队、技术运营、产品运营、领域专家等角色。我们不仅提供功能，还有可扩展共建能力、服务解决方案支持、指导业务做效能提升等角色。平台工程团队现在应该也是一个没有共识或定义的问题。团队应包含整合研发、产品、运营、解决方案等角色，除此之外还有一些其他领域，如大数据领域或项目管理领域等。相比效能平台，平台工程是个更大的概念。

姚志坤：针对我们所在的企业具体情况，涉及到需要在不同阶段考虑对应方案的问题。当没有可用的自建方案时，通常会寻找市场或业界上的工具链。需求管理平台 JIRA 和代码管理平台 GitHub、GitLab 等，都在尝试整合全链路的工具链，以实现平台工程的落地。对于规模较小的集成方案，如 KubeVela 等开源平台也是可行的。但对于像字节这样的大型研发团队，很可能需要定制自己的解决方案，无论是基于开源系统，还是商业化合作，都需要大量的研发工作。

姚志坤：如果在整合工具链时出现了上下游的问题，我们需要定位问题所在的位置。对于这个问题，我们在字节内部有一套解决方案，即 AIOps。我们的整合方案是通过微服务来实现的。针对业务场景，我们的工具链本身就包含了三个微服务，而我们新增的插件就相当于添加了一个新的微服务。通过这个插件，我们可以将指令调度到三个实际工具的微服务中，从而解决业务问题。通过这个方案，我们还可以使用字节自建 trace 能力来发现问题。此外，我们还可以与平台方合作，建立一些基本的错误码和反馈机制，并将其纳入监控中，作为一种可选的路径。

姚志坤：关于混沌工程，可能需要一些专业知识。我作为使用者，可以从我的角度谈一下。混沌工程利用我们环境的能力来注入故障，类似于插件，帮助排查和测试问题。我们可以通过建立一个流水线来实现。首先，我们会启动一个正常的环境，然后使用混沌工程的插件能力来注入一些随机的故障，最后执行 Smoke Test 来对某个环境或版本进行混沌工程的演练，这个实践在效能平台上的落地。除此之外，混沌工程本身也是一个解决方案，它可以提供一些实践经验。例如，在固定或随机时间点，我们可以在测试环境中注入故障，然后尝试查看需要多长时间来恢复。这是我所了解的关于混沌工程的主要内容。

姚志坤：是的，平台需求是一个不断变化的过程。因为效能平台或者平台工程就是一个多目标优化的事情，尤其是当业务的团队或者公司拥有多个目标时，比如研发效能，它就需要平衡效率、质量、安全、体验以及实施成本等因素。以字节跳动为例，早期我们开始效能优化时，公司的主要业务是研发，我们主要强调自动化效率以保障质量在适当范围内。但随着用户数量的增加，质量和安全风险也随之增加。这时，我们的效能平台需要开始做一些稳定性工作，例如增加安全审计功能或卡点。虽然这样效率会变低，但是对于大团队来说，降低事故发生的概率可以及时进行止损。

现在主要强调降本增效，我们的目标是尽可能解决核心问题，将主要路径打磨好。除了提高产研效率之外，我们还需要综合考虑优先级。在字节跳动内部，我们维护了一个基于公司现状的长期规划的工程平台。该平台是由效能专家、产品专家和技术专家共同决定的。最终，这些决策形成了一个主线产品路径，我们希望能够沿着这条路径前进。

在与业务对接的过程中，业务需求或技术需求可能会被插入进来。我们的平台是一个从 0 到 100 的发展成熟度过程，而我们的业务不是。一些业务会比其他业务发展得更快，它可能需要一些比平台成熟度更高的研发效能。例如，某些 AI 检测、风险控制等能力，需要在平台建设到一定程度之后才能实现。

作为支撑所有业务线的横向基础架构团队，我们一定要从全局最优的优先级评估这个问题的优先级。如果业务需要更高的成熟度，我们尽量提前做。但是如果业务有一些特殊性，它可能会提出一些非常局部优先级高的事情。例如，在字节跳动的大多数业务是在线服务的情况下，也有一些业务需要进行 ToB 的私有化交付，这在短期内很难实现。在这种情况下，我们通常会采取共建策略，让业务投入足够的人力资源。我们的平台也会开放一些接口和资源，来满足业务的特殊需求。在专业性方面，我们需要关注的不仅仅是业务需求，还要关注主线产品的迭代。

对于技术类，通常需要一定比例的投入来支持产品迭代过程中的发展。我们主要考虑 ROI，以确保它们不会阻碍主线产品的发展。在研发连续流水线构建量达到 1 万时，需要从技术角度去预测未来增长的长度，并提前进行压力测试，以确保在 3 倍构建量的情况下，系统可以承受，并且保留足够的人力资源来支持这方面的需求。总之，我们需要平衡主线产品、业务需求和技术需求的比例，最后根据 ROI 来评估优先级。

姚志坤：这是一个实现落地的问题，因为即使你的平台设计再好看，也无法与解决业务问题的实际效果相比。我认为有三个关键点：首先，需要明确平台解决了业务的哪些问题，并且对整个业务带来了多大的价值。

其次，需要考虑一线使用量有多少，只有经常被使用的平台才能提供更好的反馈。对于一线来说，平台能够带来的价值在于提高其效率。例如，作为开发人员，如何更快地编写代码、更快地模拟环境并提高体验、降低学习成本等。企业可以通过提升整体效率来降低成本、提高效益，例如新员工或社招员工无需太多培训即可使用云基础设施，仅用半天即可开始编写代码。此外，通过集成和集中式优化高频环节或工具链，也可以降低建设成本。

第三，集中管控整体效率是否提高。例如团队的需求交付量是否增加，流程是否更加顺畅等。对于一些进行转型的企业，平台工程能够帮助屏蔽底层技术，降低学习成本，例如可以将业务模型封装起来，以便开发人员更加专注于应用本身，而不必关心部署在虚拟机或容器云上的底层架构。此外，声明式云资源管理可以在页面上完成，而不需要开发人员去学习 YAML 等技术语言。

姚志坤：这个话题涉及对未来的预测，我想分享一下我的个人理解。从大局上看，我认为基于平台工程思路和价值观的开发模式毋庸置疑，但我们还需要逐步明确边界和目标。业界对于这个问题尚未形成共识。例如，像字节这样的公司，我们以价值交付流程为主线进行设计，并使用工具流程来表达产品形态。然而，我也听说有一些公司以应用为核心进行设计，即采用不同的设计模型。这需要时间来观察，看最终会变成什么样的方案。

另外，从趋势来看，我认为流程化、智能化和规模化是需要关注和发展的。流程化指的是平台工程未来可能会成为软件研发的超级流水线，就像工业界的流水线一样。随着技术的发展，许多节点将自动化，效率也将不断提高。当达到某个阈值时，一线人员甚至不需要了解底层流水线的运作方式和每个节点的工作内容，只需要一个输入输出即可。从云原生的历史经验来看，我们已逐步忘记了机房、计算机硬件、网络等问题。这是否也是平台工程的趋势呢？只需要少数人关注云的底层和流水线工厂的设计，大多数人只需要关注业务即可。第二个趋势是智能化。最近，我们密切关注 AIGC 场景对基于 DevOps 基础设施的影响。可以看到，AI 对软件研发中的各个节点都有可能产生影响，相当于每个节点的效率都将得到提升。所有工具都有可能被 AI 重新编写，例如内部的一些工程师正在尝试用 AI 去完成代码的补全、评审和测试用例的编写。这将使平台工程更加智能化、自动化并且高效。

规模化是实施新技术的前提，而云原生的标准化能够降低建立统一平台的难度。云原生技术的发展对于平台工程带来了重要的变化。然而，云原生也存在一些信息安全和专利问题，这需要一定的时间来解决。随着 AI 技术、开源系统、节点和原子能力的不断加强，平台工程也将逐渐形成最佳范式，并大规模落地。在未来，企业或开发者可能会逐渐区分业务开发、平台工程和基础设施工程师，从而更好地满足业务需求和产品逻辑，提高开发效率和协作。同时，使用平台工程设计可以更快地实现效率飞跃，而老旧基础设施则可能需要面对更高的维护成本和重构。

姚志坤：如果是针对一个通用平台工程，类似代码库、测试以及各种监控等等的工具，这些工具在字节内部已经有了。我们正在建设一个效能平台，它基于 CI/CD 的的逻辑，但它实际上已经超越了 CI/CD 的范畴。我们正在努力将许多工具链整合进来，并优化工作流程，尽可能整合内部领域的工具。就业务而言，我们确实需要了解监控、日志监控和链路等方面的能力，才能更好地使用这些能力，但我们还没有达到通过一个平台自助地提供这些服务的程度。我们有这样的愿景，希望更好地封装这些能力。

姚志坤：让我们先谈谈“反哺”。在字节，我们有许多测试系统，包括业务测试和自动化测试工具，这些工具在业务研发过程中得到了同事的支持，形成了集成到平台工程上的插件功能。更多的业务也可以复用这些能力。测试同事以及 SRE 同事为这些能力做出了贡献，因此这些能力可以在更多的团队中使用。我们还举行了两次开发者大会，介绍了一些优秀的工具，以便让更多的业务方受益。

第二个问题是效能平台如何落地交付价值。在字节，我们有一些效能领域的专家或研发领导作为效能的接口人。在进行效能度量时，我们会产出业务核心指标，这些指标在一定程度上刻画了价值交付过程。我们会度量需求开发、测试和发布阶段的时间周期损耗，并识别关键点，然后进行优化。例如，如果我们希望降低代码回滚率，那么在效能工作流中，我们会增加或减少一些节点、提高准入质量等来实现优化。这样，我们的业务与平台方，或者说效能平台与业务方，可以基于价值流构建，找到落地或优化的路径。

姚志坤：在字节内部，版本兼容有很多解法。微服务的一个标准定义中提到，微服务应该做到版本兼容，也就是说，在升级或降级时，微服务应该考虑与其他微服务的兼容性。然而，在实践过程中，很多企业难以达到每个微服务都是互相兼容的。通常来说，在字节我们需要考虑好领域层面架构设计，使得一个团队管理的多个微服务，对其他团队来说，是做到升级版本兼容的，而团队内部，我们通常会有一些部署依赖方案，例如将业务的微服务上下游的依赖串联在同一个流水线中，以规避兼容性问题。两个前后端微服务相互依赖，一个前端微服务在发布变更时，会优先保证后端微服务的变更，以避免兼容性问题。

姚志坤：这似乎是平台工程希望解决的一些问题。通过平台工程的协助，即使你不懂运维，也能够轻松地完成运维的任务，而且不会感到运维这个工作非常复杂。例如，你可以通过平台自动帮你编写测试用例并测试系统来获得更好的体验。

杨振涛：事实上，这也是平台工程的本质，即知识转移，使得不了解某个领域的人可以通过使用平台获得该领域的能力。

非常感谢今天的嘉宾老师志坤，我们的访谈到此结束，感谢老师分享，也感谢大家的收听。