CNCF 平台白皮书

译者注：本文译自 CNCF 平台白皮书，介绍了如何构建云原生计算平台以及平台可能提供的能力。这些能力包括 Web 门户、API、黄金路径模板、自动化、开发环境、可观测性、基础设施服务、数据服务、消息和事件服务、身份和密码管理服务、安全服务和工件存储。此外，该文档还介绍了与平台相关的术语，如平台、平台能力提供者、平台工程师、平台产品经理、平台团队和平台用户。

介绍

受 DevOps 所承诺的跨职能合作的启发，平台工程正在企业中作为一种明确的合作形式出现。平台策划和呈现基础功能、框架和体验，以促进和加速应用程序开发人员、数据科学家和信息工作者等内部客户的工作。特别是在云计算领域，平台已经帮助企业实现了云计算长期承诺的价值，例如快速的产品发布、跨基础架构的可移植性、更安全和更弹性的产品以及更高的开发者生产力。

本文旨在支持企业领导、企业架构师和平台团队领导者提倡、调查和计划云计算内部平台。我们相信平台对企业的实际价值流有重大影响，但只是间接的，因此领导共识和支持对平台团队的长期可持续性和成功至关重要。在本文中，我们将通过讨论平台的价值、如何衡量该价值以及如何实施最大化该价值的平台团队来实现这种支持。

目录

为什么需要平台？

云平台和平台工程是当前热门话题。在深入探讨平台构建的定义、技术和测量之前，先探讨一下驱动平台提供的价值。

在过去 20-30 年的流程改进中，软件应用程序和产品团队的敏捷性显著提高，为它们提供了基础设施（如计算、网络和存储）和开发人员服务（如构建、测试、交付和可观测性）的灵活服务。这种自主权和流程改进也逐渐使越来越多的支持服务责任转移到产品团队，迫使他们花费越来越多的时间和认知精力处理基础设施问题，从而减少了他们为组织创造价值的时间。

希望重新聚焦交付团队的核心任务并减少组织内重复的工作，促使企业实施云原生计算平台。通过投资平台，企业可以：

这些好处部分得益于少量的平台团队服务于众多的产品团队，从而扩大了其影响力；部分得益于平台团队集中管理共同的功能，促进了治理；部分得益于平台团队将用户界面和体验置于首位。

平台专家团队不仅减轻了对产品团队的共同工作负担，还优化了这些产品中使用的平台能力。平台团队还维护了一组传统的模式、知识和工具，这些都在企业中广泛使用，使开发人员能够快速为基于同一基础构建的其他团队和产品做出贡献。共享的平台模式也允许在模板、模式和能力中嵌入治理和控件。最后，因为平台团队管理提供者并为其提供一致的体验，它们可以为基础但无差异化的能力（例如数据库、身份访问、基础架构运营和应用程序生命周期）的有效使用提供支持。

平台是什么

云原生计算的平台是根据平台的用户需求定义和呈现的一组集成功能。它是一个跨应用程序和用例集合的横向层，确保为广泛的应用程序和用例组织提供典型的功能和服务的一致体验。一个好的平台提供了一致的用户体验，用于使用和管理其功能和服务，例如 Web 门户、项目模板和自助式 API。

根据 Atlassian [ 1] 的说法，“平台团队创建可以由众多流程对齐的 [产品] 团队使用的功能，减少了流程对齐 [产品] 团队的资源和认知负荷…… 平台团队可以创建跨不同用户体验或产品的连贯体验。”

根据 Martin Fowler 和 Evan Bottcher [ 2] 的说法，“数字平台是一个自助式 API、工具、服务、知识和支持基础，按照一个引人注目的内部产品的方式组织。自治交付团队可以利用该平台以更高的速度交付产品功能，并减少协调。”

平台应支持的具体功能和场景应由利益相关者和用户确定。虽然平台为这些所需的功能提供支持，但关键是要注意，平台团队并不总是必须自己 实现 它们。托管服务提供商或专用的内部团队可以维护支持实现，而平台是提供一致性的最薄合理层，能够跨提供的实现提供一致性并满足组织的要求。例如，一个非常简单的“平台”可以是一个 wiki 页面，其中包含链接到标准操作程序，以从提供者那里规定能力，如 [ 3] 所述。

因为这些平台只针对企业的内部用户，所以我们通常将它们称为 内部 平台。

平台对于云原生架构尤为重要，因为它们比以前的范式更好地将支持功能与特定于应用程序的逻辑分离。在类似云的环境中，资源和功能通常独立管理，并与自定义业务组件集成；这些资源可能包括数据库和对象存储、消息队列和代理、可观测性收集器和仪表板、用户目录和认证系统、任务运行程序和协调器等。内部平台以使它们易于集成到其应用程序和系统中的方式向企业团队提供这些资源。

平台成熟度

在最基本的层面上，内部平台为获取和使用诸如管道运行器、数据库系统或密钥存储等单个服务提供了一致的体验。随着内部平台的成熟，它们也提供了此类服务的组合，例如针对关键场景（如 Web 应用程序开发或数据分析，即 MLOps）的自助模板。

企业可通过平台实现的用例可能按以下顺序发展：

通过为单个能力或它们的集合提供一致、合规的体验，内部平台最终使用户更轻松、更有效地交付有价值的产品。

平台的属性

在定义平台是什么以及组织为什么要建立一个平台之后，让我们识别一些影响平台成功的关键属性。

平台团队的属性

平台团队负责平台能力的接口和体验，如 Web 门户、自定义 API 和黄金路径模板。一方面，平台团队与实施基础设施和支持服务的团队合作，以定义一致的体验；另一方面，他们与产品和用户团队合作，收集反馈并确保这些体验满足要求。

以下是平台团队应负责的工作：

最重要的是，平台团队必须了解平台用户的需求，以便为他们的平台提供能力和接口，并持续改进。了解用户需求的方式包括用户访谈、交互式黑客马拉松、问题跟踪器和调查以及通过可观测性工具直接观察使用情况。例如，平台团队可以发布一个表单，供用户提交功能请求，主持路线图会议以共享即将推出的功能并审查用户的使用模式以设置优先级。

入站反馈和周到的设计是产品交付的一面；另一面是出站市场营销和倡导。如果平台确实是基于用户需求构建的，那么这些用户将会很高兴使用提供的能力。平台团队可以通过内部营销活动来促进用户采用，包括广泛的公告、引人入胜的演示和定期的反馈和沟通会议。关键在于满足用户的需求并带领他们踏上旅程，与平台互动并从中受益。

平台团队不一定运行计算、网络、存储或其他服务。事实上，内部平台应尽可能依赖于外部提供的服务和功能；平台团队应仅在从受管理供应商或内部基础架构团队处无法获得这些服务和功能时才构建和维护自己的服务。因此，平台团队最负责的是服务和功能的接口（即 GUI、CLI 和 API）以及平台提供的服务和功能的用户体验。

例如，平台中的一个 Web 页面可能描述并甚至提供一个按钮来为应用程序进行身份验证；而该功能的实现可能通过云托管的身份验证服务。内部平台团队可能管理网页和 API，但不管理实际的服务实现。平台团队通常应在所需的功能不可在其他地方获得时考虑创建和维护自己的功能。

平台的挑战

虽然平台承诺了很多价值，但也带来了以下挑战，实施者应该注意这些挑战。

也许最重要的是将平台作为面向客户的产品，并认识到其成功直接取决于其用户和产品的成功；因此，平台团队与应用程序团队和其他用户合作以优先考虑、规划、实施和迭代平台的功能和用户体验是至关重要的。发布功能和体验而不考虑反馈或依赖自上而下的命令来实现采用的平台团队几乎肯定会遇到用户的阻力和不满，并错过了很多承诺的价值。为了解决这个问题，平台团队应该从一开始就包括产品经理，分享路线图，收集反馈，并全面了解和代表平台用户的需求。

在采用平台时，选择要启用的正确能力和体验可能至关重要。通常需要且无差异的能力，如管道、数据库和可观测性等，可能是一个很好的起点。平台团队还可以选择首先关注有限数量的参与度高且技能娴熟的应用程序团队。这些团队的详细反馈将改善第一个平台体验；而这些团队的成员将帮助宣传和推广平台，以吸引后续的采用者。

最后，在大型企业中，快速获得领导支持对于平台团队至关重要。许多企业领导人认为 IT 基础设施是与其主要价值流不相关的开支，并可能试图限制分配给 IT 平台的成本和资源，导致实现效果不佳、承诺未实现和沮丧。为了减轻这种情况，平台团队需要展示其对产品和价值流团队的直接影响和联系（参见前两段），将平台团队呈现为产品团队在向客户提供价值方面的战略合作伙伴。

赋能平台团队

从这些挑战中可以清楚地看出，平台团队面临着许多不同的责任，这些责任导致认知负荷。与应用程序团队的同事一样，重点是将平台团队的精力集中在与其特定业务相关的体验和功能上。减轻平台团队负担的方法包括：

如何衡量平台的成功

企业将希望衡量其平台计划是否提供了上述价值和属性。此外，在本文中我们强调将内部平台视为产品的重要性，而良好的产品管理取决于定量和定性测量产品的性能。为了满足这些要求，内部平台团队应不断收集用户反馈和测量用户活动。

与内部平台的其他方面一样，平台团队应使用最小可行的工作量来收集他们需要的反馈。我们将在这里建议度量标准，但最初简单的调查和用户行为分析可能最有价值。

有助于企业和平台团队了解其平台影响的类别包括以下内容：

用户满意度和生产率

许多平台所寻求的第一个品质是提高用户体验，以增加生产力。反映用户满意度和生产率的指标包括以下内容：

• 活跃用户和保留：包括所提供的功能数量和用户增长 / 流失
• “净推荐值”（NPS）或其他调查，衡量用户对产品的满意度
• 开发人员生产力的度量，如 SPACE 框架中讨论的那些度量 [ 4]

组织效率

许多平台所寻求的另一个好处是为大量用户提供常见需求的高效方法。这通常通过启用用户自助服务和减少手动步骤和必要的人类干预来实现，同时实施保障安全和合规性的政策。为了衡量平台在减少常见工作方面的效率，请考虑以下措施：

• 从请求到服务或功能（如数据库或测试环境）的履行的延迟
• 将全新的服务构建并部署到生产环境所需的延迟
• 新用户提交第一次代码更改到其产品的时间

产品和功能交付

内部平台的最终目标是更快地向业务客户提供业务价值，因此衡量对企业自身产品和功能发布的影响，可以证明平台的目标已得到实现。Google 的 DevOps 研究和评估（DORA）研究所建议 [ 5] 跟踪以下度量标准：

• 部署频率
• 变更的领先时间
• 服务故障后恢复服务的时间
• 变更的失败率

通常，平台团队的关键目标是将基础架构和其他 IT 能力与企业的价值流 - 其产品 - 对齐。因此，组织的产品和应用程序的成功才是衡量平台成功的真正标准。

平台的功能

正如我们所描述的，用于云原生计算的平台提供和组合来自许多支持提供者的功能和服务。这些提供者可以是同一企业内的其他团队，也可以是云服务提供商等第三方。简而言之，平台从基础 能力提供者 到平台用户（如应用程序开发人员）的中间桥梁；在此过程中，实现和执行所需的安全性、性能、成本治理和一致的体验。以下图形说明了产品、平台和能力提供者之间的关系。

产品、平台和能力提供者之间的关系

我们在本文中着重讨论了如何构建良好的平台和平台团队；现在在最后一节中，我们将描述平台实际上可能提供的能力。这个列表旨在指导平台构建者，并包括典型的云原生应用程序所需的功能。正如我们一直在强调的，良好的平台反映了其用户的需求，因此最终平台团队应该与其用户一起选择和优先考虑平台所提供的功能。

能力可以包括几个特性，意味着父能力域的方面或属性。例如，可观测性可能包括用于收集和发布度量、跟踪和日志以及观察成本和能源消耗的特性。在您的组织中考虑每个特性或方面的需求和优先级。随后的 CNCF 出版物可能会进一步扩展每个域。

在构建云原生计算平台时要考虑以下能力领域：

以下表格旨在帮助读者通过松散相关现有 CNCF 或 CDF 项目来理解每种能力。

术语表

请参见 https://glossary.cncf.io/。

平台聚合能力，为开发人员和运营商开发和交付产品、服务和应用程序提供服务。关于它旨在支持的场景，平台可能被命名为“开发人员平台”、“交付平台”、“应用程序平台”甚至是“云平台”。较旧的术语“平台即服务”或 PaaS 的内涵也具有影响力。

平台通过提供和管理共同的能力，使开发人员和运营人员能够更快地交付应用程序和服务。平台是平台用户和平台能力提供者之间的桥梁，并由平台团队构建和维护。

平台能力提供者开发和维护平台提供的能力。提供者可以是外部组织或内部团队，能力可以是基础设施、运行时或其他支持服务。

平台工程师负责开发和维护界面和工具，以便根据平台产品经理提供的要求和说明，在应用程序中启用平台能力的配置和集成。平台开发人员通常分组在平台团队中。

平台产品经理负责了解平台用户的体验，建立涵盖平台产品差距、需求和机会的路线图，并管理平台团队的日常工作。

平台团队负责开发和维护与平台能力的接口和体验，如 Web 门户、自定义 API 和黄金路径模板。平台团队由平台产品经理管理，并涉及平台开发人员。随着平台的发展和越来越先进，其他角色也可以成为平台团队的一部分，包括但不限于运营商、QA 分析师、UI/UX 设计师、技术作家、开发人员倡导者。

平台用户包括但不限于应用程序开发人员和运营人员、数据科学家、COTS 软件操作员和信息工作者 - 在平台上运行软件或使用平台提供的能力的任何人。

最薄可行平台（TVP） 是由 Matthew Skelton 和 Manuel Pais 在书籍 Team Topologies 中最初定义的一个概念。定义说：“TVP 是在保持平台小的同时确保平台有助于加速和简化团队构建平台的软件交付的谨慎平衡。”。