CNCF 平台白皮书 | 云原生资料库

点击查看目录

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

介绍

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

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

为什么需要平台？

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

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

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

减轻产品团队的认知负荷，从而加速产品开发和交付
通过专家的配置和管理改进依赖于平台能力的产品的可靠性和弹性
通过在企业内的多个团队之间重用和共享平台工具和知识，加速产品开发和交付
通过管理平台能力及其周围的用户、工具和流程，减少产品和服务的安全、法规和功能问题的风险
通过使公共云服务和其他托管提供商的服务具有成本效益和生产力，使其能够代表他们实施实现而保持对用户体验的控制

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

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

平台是什么

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

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

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

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

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

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

平台成熟度

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

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

产品开发人员可以按需提供能力并立即使用它们来运行系统，例如计算、存储、数据库或身份验证。
产品开发人员可以按需提供服务空间并使用它们来运行管道和任务，存储工件和配置，并 / 或收集遥测。
第三方软件的管理员可以按需提供所需的依赖项，例如数据库，并轻松安装和运行该软件。
产品开发人员可以从模板中提供完整的环境，组合运行时和开发时所需的服务，以满足特定场景的需求，例如 Web 开发或 MLOps。
产品开发人员和经理可以通过自动仪表化和标准仪表板观察已部署服务的功能、性能和成本。

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

平台的属性

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

平台作为产品。平台存在是为了服务于其用户的要求，它应该基于这些要求进行设计和演进，类似于任何其他软件产品。平台应该提供必要的能力，以支持产品团队中最常见的用例，并优先考虑那些只被单个团队使用的更具体的能力，以最大化提供的价值。
用户体验。平台应该通过一致的接口提供其功能，并专注于用户体验。平台应该尽力满足其用户的需求，这可能意味着使用 GUI、API、命令行工具、IDE 和门户的组合。例如，平台通常提供部署应用程序的功能。开发人员可能会通过 IDE 消费这样的功能，测试人员可能会使用命令行工具，而产品所有者可能会使用基于 GUI 的 Web 门户。
文档和入门。文档是成功软件产品的关键方面之一。为了能够使用平台的功能，用户需要文档和示例。平台应该随着适当的文档交付，以满足其用户的需求。它还应该提供工具来加速新项目的入门，以帮助用户以快速简单的方式消费必要的平台服务。例如，平台可以提供用于在 Kubernetes 上构建、扫描、测试、部署和观察 Web 应用程序的可重用的供应链工作流。这样的工作流可以与一个初始的项目模板和文档捆绑在一起，通常被描述为黄金路径。
自服务。平台应该是自服务的。用户必须能够自主和自动地请求和接收功能。这个属性对于平台团队能够启用多个产品团队并根据需要进行扩展是关键的。平台的能力应该随时可用，并且通过上述接口进行最小的手动干预。例如，用户应该能够通过运行命令行工具或在 Web 门户上填写表单来请求数据库并接收其定位器和凭据。
减少用户的认知负荷。平台的一个重要目标是减少产品团队的认知负荷。平台应该封装实现细节，并隐藏由其架构引起的任何复杂性。例如，平台可能将某些服务委托给云提供商，但用户不应该接触到这些细节。同时，平台还应该允许用户根据需要配置和观察某些服务。用户不应该负责操作平台提供的服务。例如，用户经常需要数据库，但他们不应该管理数据库服务器。
可选和可组合。平台旨在使产品开发更加高效，因此它们不能成为障碍。平台应该是可组合的，并使产品团队仅使用其提供的部分功能。当必要时，它还应该使产品团队在平台的提供范围之外提供和管理自己的能力。例如，如果平台不提供图形数据库，而产品需要它，那么产品团队应该能够自行提供和操作图形数据库。
默认安全。平台应该默认安全，并提供基于组织规则和标准的合规性和验证能力。

平台团队的属性

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

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

研究平台用户需求并计划功能路线图
推广和倡导平台提议的价值
管理和开发用于使用和观察能力和服务的接口，包括门户、API、文档和模板以及 CLI 工具

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

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

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

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

平台的挑战

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

平台团队必须像产品一样对待他们的平台，并与用户一起开发它们。
平台团队必须仔细选择其优先事项和初始合作伙伴应用程序团队。
平台团队必须寻求企业领导的支持，并展示其对价值流的影响。

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

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

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

赋能平台团队

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

寻求建立最薄的可行平台层，以覆盖来自受管理供应商的实现
利用开源框架和工具包，为应用程序团队使用创建文档、模板和组合
确保平台团队在其领域和客户数量方面得到适当的人员配备

如何衡量平台的成功

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

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

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

用户满意度和生产率

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

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

组织效率

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

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

产品和功能交付

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

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

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

平台的功能

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

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

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

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

用于观察和配置产品和能力的 Web 门户
用于自动配置产品和能力的 APIs（和 CLIs）
“黄金路径”模板和文档，以便在产品中实现最佳使用
用于构建和测试服务和产品的自动化
用于交付和验证服务和产品的自动化
开发环境，如托管的 IDE 和远程连接工具
使用仪器和仪表板的服务和产品的可观测性，包括功能、性能和成本的观察
基础设施服务，包括计算运行时、可编程网络以及块和卷存储
数据服务，包括数据库、缓存和对象存储
包括代理、队列和事件织物的消息和事件服务
身份和密码管理服务，例如服务和用户身份和授权、证书和密钥发行以及静态密码存储
包括代码和工件的静态分析、运行时分析和策略执行的安全服务
包括容器镜像和特定语言包、自定义二进制文件和库以及源代码的工件存储

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

能力	描述	示例 CNCF/CDF 项目
用于配置和观察能力的 Web 门户	发布文档、服务目录和项目模板。发布有关系统和能力的遥测数据。	Backstage、Skooner、Ortelius
自动配置能力的 API	用于自动创建、更新、删除和观察能力的结构化格式。	Kubernetes、Crossplane、Operator Framework、Helm、KubeVela
黄金路径模板和文档	用于快速项目开发的良好集成代码和能力的模板化组合。	ArtifactHub
用于构建和测试产品的自动化	自动构建和测试数字产品和服务。	Tekton、Jenkins、Buildpacks、ko、Carvel
用于交付和验证服务的自动化	自动化和观察服务的交付。	Argo、Flux、Keptn、Flagger、OpenFeature
开发环境	启用应用程序和系统的研究和开发。	Devfile、Nocalhost、Telepresence、DevSpace
应用程序可观测性	仪表应用程序，收集和分析遥测数据，并将信息发布给利益相关者。	OpenTelemetry、Jaeger、Prometheus、Thanos、Fluentd、Grafana、OpenCost
基础设施服务	运行应用程序代码、连接应用程序组件并为应用程序持久化数据	Kubernetes、Kubevirt、Knative、WasmEdgeCNI、Istio、Cilium、Envoy、Linkerd、CoreDNSRook、Longhorn、Etcd
数据服务	持久化应用程序的结构化数据	TiKV、Vitess、SchemaHero
消息和事件服务	使应用程序异步通信	Strimzi、NATS、gRPC、Knative、Dapr
身份和密码服务	确保工作负载具有定位器和密码来使用资源和能力。使服务能够向其他服务识别自己	Dex、External Secrets、SPIFFE/SPIRE、Teller、cert-manager
安全服务	观察运行时行为并报告 / 纠正异常。验证构建和工件不包含漏洞。根据企业要求限制平台上的活动；通知和 / 或纠正异常	Falco、In-toto、KubeArmor、OPA、Kyverno、Cloud Custodian
工件存储	存储、发布和保护用于生产的内置工件。缓存和分析第三方工件。存储源代码。	ArtifactHub、Harbor、Distribution、Porter