CNCF平台白皮书

以下文章是使用Gemini翻译的CNCF平台白皮书。

原文: https://tag-app-delivery.cncf.io/whitepapers/platforms/

引言

受DevOps所承诺的跨职能协作的启发，“平台工程”开始在企业内部作为这种协作的明确形式出现。平台精心策划并提供基础能力、框架和经验，以促进和加速应用程序开发人员、数据科学家和信息工作者等内部客户的工作。特别是在云计算领域，平台正在帮助企业实现云计算长期以来承诺的价值，例如更快的发布产品、基础设施之间的可移植性、更安全和更具弹性的产品以及更高的开发人员生产力。

本白皮书旨在支持企业领导者、企业架构师和平台团队负责人倡导、研究和规划用于云计算的内部平台。我们相信平台对企业的实际价值流（Value Streams）有重大影响，但这是一种间接的方式。因此，高层管理人员的共识和支持对于平台团队的长期可持续性和成功至关重要。本文将通过讨论平台的价值是什么、如何衡量其价值以及如何实施能够最大化价值的平台团队来促成这种支持。

为什么选择平台？

如今，在云计算世界中，平台和平台工程是热门话题。在深入探讨构建平台的定义、技术和测量方法之前，首先探索平台带来何种价值以引起这种兴趣至关重要。

过去二三十年的流程改进显著提升了软件应用程序和产品团队的敏捷性。他们获得了计算、网络、存储等基础设施服务，以及构建、测试、部署和可观测性等开发人员服务。然而，这种自主性和流程改进却矛盾地导致了支持服务的责任逐渐转移到产品团队。结果，产品团队在基础设施问题上花费了越来越多的时间和认知精力，从而减少了为组织创造实际价值的时间。

让交付团队专注于其核心工作并减少整个组织的重复工作，这种愿望促使企业实施云原生计算平台。通过投资平台，企业可以获得以下优势：

降低产品团队的认知负荷（Cognitive load），加速产品开发和部署。
通过让专家配置和管理平台能力，提高依赖这些能力的产品可靠性和弹性。
通过使企业内多个团队能够重用和共享平台工具和知识，加速产品开发和部署。
通过将平台能力及其周围的用户、工具和流程置于治理之下，降低产品和服务的安全、法规和功能问题的风险。
通过保持对用户体验的控制，同时将实现委托给公共云和托管服务提供商，从而实现成本效益高且富有成效的服务使用。

这些优势部分源于少数平台团队为大量产品团队提供服务，从而倍增其影响力；部分源于平台团队整合通用功能管理，从而简化治理；最后，源于平台团队将用户界面和体验置于首位。

平台专家团队不仅减少了产品团队所需的常见任务，还优化了这些产品中使用的平台能力。此外，平台团队在整个企业中维护广泛使用的惯例模式、知识和工具集，使开发人员能够快速为基于相同基础构建的其他团队或产品做出贡献。共享的平台模式允许在模板、模式和能力中嵌入治理和控制功能。最后，平台团队管理提供商并提供一致的体验，从而可以高效利用公共云和服务提供商来处理数据库、身份访问、基础设施操作和应用程序生命周期等基础但非差异化的功能。

平台是什么？

云原生计算平台是根据平台用户需求定义和呈现的能力集成集合。它是一个横切层（cross-cutting layer），确保在获取和集成各种应用程序和用例的通用能力和服务时提供一致的体验。一个好的平台提供一致的用户体验来使用和管理能力和服务，例如Web门户、项目模板和自助服务API。

根据Atlassian[1]的说法，“平台团队以最小的开销创建可供众多流对齐[产品]团队使用的能力。平台团队最大限度地减少产品团队的资源和认知负荷，并能在不同的用户体验或产品之间创建连贯的体验。”

根据Martin Fowler和Evan Bottcher[2]的说法，“数字平台是自助服务API、工具、服务、知识和支持的基础，它们被部署为引人注目的内部产品。自主交付团队可以利用这个平台以更快的速度交付产品功能，同时减少协调工作。”

平台支持的具体能力和场景集应由利益相关者和用户的需求决定。重要的是，虽然平台提供这些基本能力，但平台团队并不总是需要直接实现它们。托管服务提供商或专门的内部团队可以维护后端实现，而平台则充当“最薄且合理的层（thinnest reasonable layer）”，在所提供的实现中提供一致性并满足组织要求。例如，一个非常简单的“平台”可能只是一个包含从提供商处配置能力的标准操作程序链接的维基页面[3]。

由于这些平台仅面向企业内部用户，我们通常将其称为内部平台（Internal Platforms）。

平台在云原生架构中尤为重要。原因在于，它比以前的范式更清晰地将支持能力与应用程序特定逻辑分离。在云等环境中，资源和能力通常独立管理，并与定制的业务组件集成。这些资源可能包括数据库、对象存储、消息队列、可观测性收集器和仪表板、用户目录和身份验证系统等。内部平台以一种企业团队可以轻松将其集成到其应用程序和系统中的方式提供这些资源。

平台成熟度（Platform maturity）

在最基本的阶段，内部平台为获取和使用管道运行器、数据库系统或秘密存储等单个服务提供一致的体验。随着成熟度的提高，内部平台将这些服务的组合（compositions）作为Web应用程序开发或数据分析（MLOps）等主要场景的自助服务模板提供。

企业通过平台可以实现的用例可以按以下方式发展：

产品开发人员可以根据需要配置和立即使用计算、存储、数据库或身份等能力来运行其系统。
产品开发人员可以根据需要配置服务空间，并使用它们来运行管道和作业，存储工件和配置，以及收集遥测数据。
第三方软件管理员可以根据需要配置数据库等基本依赖项，并轻松安装和运行其软件。
产品开发人员可以从结合了Web开发或MLOps等特定场景所需的运行时和开发时服务的模板中配置完整的环境。
产品开发人员和管理员可以通过自动化仪表和标准仪表板观察已部署服务的功能、性能和成本。

请参阅本白皮书首次发布后创建的平台工程成熟度模型。

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

平台的属性

在定义了平台是什么以及为什么要构建它之后，让我们确定一些影响其成功的关键属性。

平台即产品（Platform as a product）：平台的存在是为了满足用户需求，并且像任何其他软件产品一样，应该基于这些需求进行设计和演进。平台应提供支持产品团队中最常见用例所需的能力，并优先考虑通用能力而非仅由单个团队使用的特定能力，以最大化交付价值。
用户体验（User experience）：平台应通过一致的接口提供能力，并专注于用户体验。平台应努力在用户所在之处（GUI、API、CLI、IDE、门户等）与他们会面。例如，产品负责人可以使用Web门户，开发人员可以使用IDE，测试人员可以通过CLI使用相同的部署能力。
文档和入职（Documentation and onboarding）：文档是任何成功软件产品的核心。平台应提供满足用户需求的适当文档和示例。它还应提供新的项目入职工具，以帮助用户快速简单地使用平台服务。这些捆绑包通常被称为黄金路径（Golden Path）。
自助服务（Self-service）：平台必须是自助服务的。用户应该能够自主、自动地请求和接收能力。这是平台团队支持和扩展多个产品团队的关键特性。
降低用户的认知负荷（Reduced cognitive load for users）：平台的主要目标是降低产品团队的认知负荷。平台应封装实现细节，并隐藏可能出现的架构复杂性。用户不应负责操作平台提供的服务（例如：他们不应需要自己管理数据库服务器）。
可选和可组合（Optional and composable）：平台旨在提高效率，而不是阻碍效率。平台应是可组合的，允许产品团队仅使用所提供功能的一部分。此外，如有必要，产品团队应能够在平台外部管理自己的能力。
默认安全（Secure by default）：平台应默认安全，提供确保符合组织定义的规则和标准的合规性和验证能力。

平台团队的属性

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

平台团队的主要职责包括：

调查平台用户需求并规划功能路线图
营销、传播和倡导平台的建议价值
管理和开发能力和服务的使用/观察接口，包括门户、API、文档、模板和CLI工具

最重要的是，平台团队必须持续学习用户需求，以改进他们提供的接口。学习方法包括访谈、黑客马拉松、问题跟踪器、调查以及通过可观测性工具进行直接观察。

如果入站反馈和周到的设计是产品交付的一面，那么另一面就是出站营销和倡导。如果平台是为满足用户需求而构建的，用户将乐于使用它。平台团队应通过内部营销活动（如公告、演示和定期反馈会议）来促进用户采用。

平台团队不一定需要直接运营计算、网络等服务。事实上，内部平台应尽可能依赖外部提供的服务和能力。平台团队主要负责这些服务提供的接口（GUI、CLI、API）和用户体验。

平台实施中的挑战

平台虽然承诺了巨大的价值，但也伴随着以下挑战：

平台团队必须将平台视为产品，并与用户共同开发。
平台团队必须谨慎选择优先级和初始合作伙伴应用程序团队。
平台团队必须寻求企业领导层的支持，并展示其对价值流的影响。

最重要的是，必须将平台视为面向客户的产品，并认识到其成功取决于用户和产品的成功。那些在没有反馈的情况下发布功能或依赖自上而下的命令（top-down mandates）强制采用的平台团队，很可能会面临用户的抵制。

赋能平台团队

平台团队也因其多样化的职责而面临认知负荷。将团队的精力集中在业务独有的经验和能力上至关重要。以下是减轻平台团队负担的方法：

在托管提供商的实现之上构建最薄的可行平台层（thinnest viable platform layer）。
利用开源框架和工具包来创建文档、模板和组合。
确保平台团队根据其领域和客户数量配备适当的人员。

如何衡量平台的成功

平台团队应持续收集用户反馈并衡量其活动。衡量指标包括：

用户满意度和生产力：活跃用户和留存率、净推荐值（NPS）以及SPACE框架[4]等开发人员生产力指标。
组织效率：从服务请求到完成的延迟（latency）、新服务的构建和部署时间、新用户提交首次代码更改的时间。
产品和功能交付：跟踪DORA指标（部署频率、变更前置时间、恢复服务时间、变更失败率）。

最终，组织产品和应用程序的成功是衡量平台成功的真正标准。

平台能力

云原生计算平台结合了各种支持提供商的能力。平台充当能力提供者和应用程序开发人员之间的桥梁，执行安全、性能和成本治理。

需要考虑的能力领域：

Web门户：用于产品和能力观察/配置
API和CLI：用于自动化配置
“黄金路径”模板和文档：支持最佳使用
构建/测试/部署自动化
开发环境：托管IDE等
可观测性：功能、性能、成本仪表板
基础设施服务：运行时、网络、存储
数据服务：数据库、缓存、对象存储
消息和事件服务
身份和秘密管理
安全服务：：静态/运行时分析、策略执行
工件存储库：：镜像和包存储

（随后的表格部分列出了每个能力的CNCF/CDF项目示例，其中包括Backstage、Kubernetes、Argo、Crossplane、Prometheus等熟悉的项目。）

引言

目录