CNCF 应用交付 TAG – 平台工作组

Wgs: CNCF 平台白皮书

Mon, 01 Jan 0001 00:00:00 +0000

概述

受 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 项目
用于提供和观察功能的网络门户	发布文档、服务目录和项目模板。发布关于系统和功能的遥测数据。	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、WasmEdge、KEDA CNI、Istio、Cilium、Envoy、Linkerd、CoreDNS Rook、Longhorn、Etcd
数据服务	为应用程序持久化结构化数据	TiKV、Vitess、SchemaHero
消息和事件服务	使应用程序异步通信	Strimzi、NATS、gRPC、Knative、Dapr
身份和秘密服务	确保工作负载具有定位信息和用于访问资源和功能的秘密。使服务能够向其他服务标识自己	Keycloak, Dex、External Secrets、SPIFFE/SPIRE、Teller、cert-manager
安全服务	观察运行时行为并报告/修复异常。验证构建和工件不包含漏洞。根据企业要求限制平台上的活动；通知和/或修复异常	Falco、In-toto、KubeArmor、OPA、Kyverno、Cloud Custodian
工件存储	存储、发布和保护用于生产的构建工件。缓存和分析第三方工件。存储源代码。	ArtifactHub、Harbor、Distribution、Porter

Wgs: 平台工程成熟度模型

Mon, 01 Jan 0001 00:00:00 +0000

Note: The content on this page may be outdated.

This page has been updated behind the English version, so the content may be outdated. For the latest information, please refer to the English version of the page.

概述

CNCF 的首份平台定义白皮书描述了什么是云计算下的内部平台，以及该平台应为企业带来哪些价值。但要实现这些价值，一个组织必须反思并刻意追求对它们有影响的成果和实践，同时记住每个组织都依赖于为其自身组织量身定制的内部平台 - 即使这个平台只是关于如何使用第三方服务的文档。这个成熟度模型提供了一个框架，用于反思和识别任何组织中改进的机会。

什么是平台工程？

受到 DevOps 承诺的跨职能合作的启发，平台和平台工程在企业中作为这种合作的明确形式出现。平台汇集并展示了共同的能力、框架和经验。在本工作组和相关出版物中，重点关注那些促进和加速内部用户（如产品和应用团队）工作的平台。

平台工程 是一种为开发者和用户规划和提供此类计算平台的实践，并涵盖平台及其能力的所有部分 —— 其人员、流程、政策和技术；以及驱动它们的期望商业成果。

请先阅读 CNCF 平台定义白皮书，以获得完整的背景信息。

如何应用此模型

随着平台工程在过去几年中的重要性日益突显，一些模式已经变得明显。通过将这些模式和观察结果组织成一个渐进的成熟度模型，我们旨在引导平台团队关注他们可能面临的挑战和应对的机会。每个方面都以各级不同小组和组织在各方面的连续特征加以描述。我们期望读者能在模型中找到自己的位置，并识别相邻层次中的机会。

值得注意的是，每个更高的成熟度层次都伴随着对资金和人员时间的更大需求。因此，达到最高层次本身不应该是一个目标。每个层次描述了在那个阶段应该出现的品质。读者必须考虑，鉴于所需的投资，他们的组织及其当前环境是否会从这些品质中受益。

请记住，每个方面都旨在独立评估和发展。然而，如同在任何社会技术系统中一样，这些方面是复杂且相互关联的。因此，您可能会发现，要在一个方面取得进步，您也必须在另一个方面达到最低水平。

同样重要的是要认识到，平台的实施方式因组织而异。确保评估 your 团队在整体云原生转型方面的当前状态。在进行这种评估时，一个极好的资源是云原生成熟度模型。

最后，这个模型鼓励组织通过有意的规划，提升他们的平台工程学科和由此产生的平台的成熟度。这样的规划和纪律本身是成熟平台开发和持续演进的要求。

通常，请记住，将您的组织映射到一个模型中是为了抓住当前状态，to enable 促进迭代和改进。 Martin Fowler 说得好：“成熟度模型评估的真正成果不是你所处的水平，而是你需要努力改进的事项清单。” 你当前的水平仅仅是为了确定下一步需要获取的技能清单而进行的一项中间工作。遵循这一思路，寻找自己在模型中的位置，然后在相邻层次中识别机会。

该项工作的背景

理解文档编写的背景是非常有价值的。以下部分阐述了该模型背后的一些背景，以及对您这位读者的一些期望。

目标受众

每位读者都有独特的背景，并将从这个模型中获得独特的学习成果。下面是我们考虑到的一些人物角色，以及他们可能的动机，以便与这个模型互动：

首席技术官、副总裁和技术总监：希望规划数字转型和提高开发者生产力的领导者
工程管理者：寻求赋能工程师以较少的开销和更高效率提供价值的团队和个人
企业架构师：在现代技术环境中导航的个人，他们寻求对技术问题具有价值和解决方案导向的观点
平台工程师和平台产品经理：努力为平台构建者和平台用户构建最佳体验的团队和个人
产品供应商和项目维护者：希望设计工具并传达信息以使用户能够成功使用平台和功能的组织和工程师
应用程序和产品开发者：作为平台用户，希望更详细地了解他们可能对内部平台有何期望

了解各个级别

该模型并不意味着要将一个组织或平台团队完全归类为“Level 1”或“Level 4”。每个方面都应独立考虑，每个级别的特征代表该方面内的一个连续体，但不一定与其他方面在同一级别相耦合。甚至更重要的是，许多组织会发现多个级别的特征在其团队和工作中都是适用的。这是因为没有哪个级别本质上是好或坏的，只取决于团队的目标和背景情境。

每个级别的标签旨在反映您的组织中平台工程的影响。当您将您的组织识别在特定级别时，您将获得洞察力，了解接下来的机会。较低级别包括更具战术性质的解决方案，而较高级别的则更具战略性质。

这导致了一种类似于其他数字产品开发的平台开发和成熟性的潜在过程：首先识别问题和对新解决方案的需求，然后开发假设的最小可行产品作为解决方案，第三步是迭代，以更好地解决问题并确保适合您的客户，最后是扩展和优化产品，以解决多个团队和用户的问题。

类似于 CNCF 云原生成熟度模型，这个模型强调成功的业务结果只能通过在技术之外平衡人员、流程和政策来实现。值得注意的是，这个模型引入了通常不完全属于单个内部团队职责范围的方面，而是需要在工程部门内和往往是整个组织内进行合作。

但似乎并不适用

那可太好了！每个组织和团队都有其特定的动力和因素。

请记住，本文的目标并不是要提供一种刻板的公式，而是一个您可以应用于您的情境的框架。也许不是每个词都与您相关，但我们希望内容能激发您反思自己的平台之旅，取其所需，舍其所弃。

这个模型的目标是为平台工程从业者、利益相关者和其他感兴趣的各方提供一个工具，以帮助他们在自己的平台工程之旅中指导方向。平台的设计和实施并不是一门精确的科学，而是取决于个别项目、组织和特定的时间与地点的需求。

模型表

方面		暂时性的	可操作	可扩展	可优化
投入	如何分配工作人员和资金给平台能力?	自愿或临时的	专职团队	作为产品	已启用的生态
采用	用户为什么和如何发现和使用内部平台和平台能力？	不稳定的	外部推动	内部拉力	参与性
接口	用户如何与平台进行交互并使用平台能力？	自定义程序	标准工具化	自定义解决方案	综合服务
Operations	平台及其能力是如何规划、确定优先次序、开发和维护的？	按需求	集中跟踪	集中启用	管理服务
衡量	-收集、整合反馈和学习的流程是什么？_	临时的	一致的收集	见解	定量与定性

模型详情

How are staff and funds allocated to platform capabilities?

对平台和平台工程的投资是分配预算和人员以建立和维护通用能力的过程。通常情况下，各种举措被描述为自下而上的有机建设，或通过自上而下的举措来推动。无论哪种情况，都是持续投入的能力推动了高影响力的工作。这一方面体现了投资规模和广度如何影响平台的成功。

第一阶段，临时性——基于自愿或临时安排

单个能力的存在可能是为通用或关键功能提供共同的基础。这些能力的建立和维护是出于需要，而不是有计划的和有意资助的。

这些能力由被临时或自愿指派的人员构建和维护；没有专门为它们分配集中的资金或人员。它们依赖于用户当前的战术需求。

特点

为应对紧急需求，会组建“打击”或“突击”团队。这些团队的存在时间很短，既没有被指派也没有被给予进行长期规划和支持的时间。
迁移、改进或增强通常被视为“锦上添花”的工作项，依赖于“研究”或“黑客松”等方式的努力。
在处理新需求时，例如紧急安全补丁，可能会引入流程改进或自动化，但没有支持以可复用或可持续的方式构建解决方案。
员工抱怨因在其核心角色之外的工作量而感到疲惫和沮丧。

示例场景：

有一名特定的雇员被视为测试环境专家。虽然这位员工意图良好，但他们在有限投资下努力改善测试环境的尝试导致了风险增加，因为他们的解决方案没有得到维护，且没有共享关于如何处理坏掉的测试环境的理解。
当管理层对产生收入的功能没有施加压力时，工程师们被鼓励投资于提升能力的改进。这意味着在一些sprint的最后几天，他们会优先考虑自动化和改进他们CI/CD流水线的某些部分。这些改进往往是突发性的，因为可能有几个月的冲刺任务过于繁重，不能再在这些方面花费时间

第二阶段，可操作 — 专职团队

为持续的人力和资源支持分配预算和人员。被指派的人员负责提供一系列常用的能力，以加快软件交付。这些小组往往把重点放在满足被动技术要求上。他们可能被称为DevOps、工程支持、开发者体验（DevEx 或 DevX）、共享工具、卓越中心，甚至是平台。他们的资金来源是集中分配的，被当作一个成本中心来对待；而他们对直接产生价值的流程和应用开发团队的影响并没有进行评估。在这个级别上，平台团队对组织及其价值流的影响可能难以衡量，这可能使维持和继续为这种小组提供资金变得很困难。

特点

团队几乎全部由技术通才组成。
团队预算可能包括与他们的工作相关的基础设施成本，这通常是预算讨论中的一个关键点。
待办事项涵盖多种技术，导致频繁且大规模的上下文切换。
这个团队通常是首个填补尚未解决的空白的团队，即使这不在团队声明的范围内。这个团队接管了无主的资源。
被指派的人员很少有时间或经验进行客户研究，以验证他们的设计或实现。

示例场景：

应用开发者提出他们的应用开发时间过长的问题。一个核心的团队被指派任务，要将构建时间缩短50%。他们通过将CI runner的大小和数量增加一倍来解决这个问题，因为他们离软件太远，无法单独改进应用构建。这给他们的核心团队带来了预算上的担忧，因为生产力的提升无法直接与增加的基础设施成本进行量化对比。

第三阶段，可扩展 — 作为产品

对内部平台及其功能的投资类似于对企业外部产品和价值流的投资：这基于它们预期为客户提供的价值。产品管理和用户经验得到明确考虑并投入使用。收费制度可用于反映平台对客户本身直接价值流和产品的影响。企业使用数据驱动的绩效指标和反馈循环，为适当的举措分配资金和员工。平台团队最终可以优化业务本身，并有助于提高盈利能力。

特点

平台团队配置的角色不仅限于传统的内部服务或技术团队，例如产品管理和用户体验。
团队向组织内部公布路线图，指明提供的价值和高层次的功能目标。
在设计、交付和部署后，功能都要经过实施质量和用户体验的测试。
功能移除是讨论的关键部分，目标是拥有一套受到良好支持、良好使用的能力，而不是一片可能无法维护的庞大领域。

示例场景：

从平台使用度量表中得出的数据为决定将资金和工作人员分配给影响最大的举措提供了依据。

第四阶段，优化-已启用的生态系统

平台小组设法提高全组织超出基本能力的效率和效益。核心平台维护者有意致力于优化新产品的上市时间，降低企业整体成本，实现新服务的高效治理和合规，快速且轻松地扩展工作负载，以及其他横向需求。这些核心维护者专注于使专业能力方面的专家能够无缝地将他们的需求和产品整合到平台的现有和新部分中。此外，本组织集中精力利用安全、业绩等专门领域的人员和资源。通过参与提供的平台框架以引入高级功能，使产品团队能够在不依赖集中团队积压的情况下加速实现公司目标。

特点

使专家能够扩大平台能力并引进新平台能力已成为一个优先任务。
该组织可以集中专家，以便通过平台能力传播他们的知识和支持。

示例场景：

市场营销团队与平台构建者合作，引入一致的用户追踪机制，以便将市场营销工作的成效归因于产品成果。
自动化举措将数据库配置所需的人工时间每实例减少30分钟，从而每年节省1000万美元。

Why and how do users discover and use internal platforms and platform capabilities?

采用不仅描述了一个组织使用平台功能的方式和程度，还描述了他们这样做的动机。在早期阶段，许多目标用户可能根本没有意识到他们在使用一个平台。相反，他们将他们的工具视为来自各种内部资源的功能的临时集合。随着时间的推移，这可能会发展成为一组能力，并由一个或多个平台进行统一管理并呈现给用户。随着功能的日益完善和可发现性的提高，平台的驱动力通常会从更多的外部动机（如授权或激励）中转移出来。这导致用户自主选择平台功能，甚至在理想情况下将自己的精力投入到更广泛的平台生态系统中。

第一阶段，临时-不稳定

对共享平台和功能的采用是不一致的。在选择和整合所需的技术能力和支撑服务方面缺乏组织范围内的战略或指导思想。个别团队可能会利用平台实践来改进自己的流程，但整个组织内没有协调或实现标准化。这个阶段采用的特点是缺乏一致的方法论，认为外部工具比内部工具更有效。

特征：

由组织内不同团队或部门分别管理和使用一次性的工具、服务或能力。
由于内部配置很难被找到或使用，供应商管理（又称“云”）服务的采用和使用前后不一致，没有标准做法和策略。
应用程序和服务团队探索工具和功能的方式五花八门，都是通过传言和偶然的对话，而不是通过更集中的流程。
即便组件和能力的协调和复用方式存在，也只能由最终用户（应用团队）来驱动。
每个产品团队各自维护一套脚本或工具来部署自己的应用程序。

示例场景：

假设一个银行服务需要一个数据库。一个开发者从另一个团队的朋友那里打听到他们可以通过请求创建一个AWS帐户并初始化一个RDS数据库实例。从另一个团队那里他们打听到可以使用Terraform脚本来实现该需求。为了使用CloudWatch来监控这个实例，在运行Terrafrom脚本之前，他们需要手动将AWS控制台中的密码复制到Hashicorp密码库中保存。

第二阶段，可操作化——外在驱动力

组织认识到共享平台和能力的价值，并加以鼓励以实现不断演进和发展。内部指令鼓励甚至要求在某些场景中使用共享平台服务一些产品团队比其他团队更多使用平台功能；功能涵盖组织中的典型案例，但不包括特殊案例；很难将这些特殊情况添加到共享平台中。

用户对能力的发现以及如何使用这些能力并不一致；除非由平台团队指导，否则产品团队的用户可能不会发现平台所支持的功能

特征：

在一定程度上的外部驱动力导致平台能力的使用，例如：
- 激励措施，如个人审查等
- 任务规定，如要求用于生产发布或接受赞助等
对平台功能的利用是分散的–用户可能会利用一种功能，但可能不知道或没有兴趣采用其他可用的功能。
用户学习如何使用平台功能的积极性不高，在很大程度上依赖于在工作时间内通过服务台等渠道与供应商进行合作。
鼓励平台用户加入非正式实践社区，以分享问题和解决方案，但参加人数可能有限。

示例场景：

一个工程组织决定采用一种符合标准的部署工具，并推广所有团队使用这一工具。新的流程（发布说明的沟通等）都是围绕该标准建立的。各团队被要求停止使用其他类型的部署脚本，转而使用通用工具。这对一些团队来说很困难，因为新流程无法满足他们的需求，但他们又不理解或不允许扩展新流程。

第三阶段，可扩展——内在拉力

产品和服务团队的用户之所以选择使用平台及其功能，是因为它们在减轻产品团队的认知负担、提供更高质量的支持服务方面具有明显的价值。文档和符合人体工程学的界面使产品团队用户能够快速配置和使用平台功能。用户会选择内部平台实现，而不是自行开发功能或雇佣供应商。

特征：

平台的采用是自我维持的 - 核心驱动力不是强制用户使用平台产品的外部动力或激励措施，而是这些平台本身的价值吸引用户使用它们。
在使用并理解了一个或一些平台能力后，用户会寻找其他功能，并发现不同功能的体验是相似的。人们期望某一项功能不是孤立的，而是一个较大的平台功能集中的一项功能。
平台团队通过收集用户反馈、分享规划蓝图和维护与用户对话的开放论坛，鼓励平台的自然演进。
应用和产品团队对平台功能的重视程度足以为其付费，例如通过付费系统。
用户可以通过公开论坛和共享路线图分享反馈和了解即将到来的功能。
自助服务门户、黄金路径模板和其他文档可以快速使用。

示例场景：

一个应用程序团队之前曾成功申请过一个新数据库。他们的流程简单易懂，几乎不需要等待时间。此外，还包括备份和监控等关键功能，使该团队能够顺利地将其使用交付到生产阶段。这种成功经历意味着，当团队后面需要一个消息队列时，他们的第一反应就是查看内部平台选项是否支持。尽管他们最初打算使用特定的队列技术，但最终还是选择了使用内部提供的技术方案，因为他们知道该解决方案将如何很好地集成到他们的组织中。

第四阶段优化——参与

产品团队的用户通过加入生态系统并为其做出贡献，进一步投身于平台功能发展。有些贡献是对现有功能的改进和修复，有些则是为解决新的使用案例而引入新的功能和特性。已定义的流程和服务使用户能够确定需求，并在多个产品和平台团队之间进行协调。新的功能通过统一的界面和门户发布，并配有完整的文档和标准版本。

特征：

应用/服务团队的用户有权为平台能力提供修复、功能和反馈。
战略性地利用外部项目和标准，以降低维护成本，加快新功能的交付，并最有效地使用组织人员。
新功能和增强功能通过 Issue 和 PR 进行协调。文档和核对表使贡献者能够进行自我驱动的开发。
开发人员倡导者和项目内部领头人建立和维护一个内部用户社区，将平台所有权扩展到应用程序和服务团队贡献者。
领导层和个人贡献者都将使用平台功能视为在组织工作的最佳方式。
平台工程师参与产品团队规划，了解需求并提出相关的现有功能建议。

示例场景：

一个团队想要一个备份计划。在将其作为一般提案提出后，由于复用程度极低，该方案被认为优先级较低。提议团队选择将其解决方案集成到平台框架中，并提供给本组织使用。该方案最初只是一个辅助方案，但一旦满足了所有业务要求，就可以提升为平台核心功能。

How do users interact with and consume platform capabilities?

平台提供的接口会影响用户与这些平台进行配置、管理和观察的方式。接口可以包括工单系统、项目模板、图形门户以及可自动API和命令行(CLI) 工具。

一个接口的关键特征包括在关键用户流程（如初始请求、维护或故障排除）中的可发现性和用户友好性。较高的成熟程度反映了更加一体化、一致、自动化和支持的接口。

第一阶段：临时–自定义程序

有一组不同的程序来提供不同的能力和服务，但没有考虑接口的一致性。即使定制化程序提供者使用了一些自动化的执行脚本，定制程序能满足个人或团队的眼前需要，但是程序也需要人工干预。

对于如何获得这些程序问题的解决方案都是靠人们口口相传。这些创建这些的自定义程序的过程缺少标准化和一致性。配置和使用平台服务可能需要能力平台开发者的大力支持。

在公司尚未能明确记录程序未来需要做到什么程度的时候，这种缺少一致性要求和标准是可行的。这种自定义程序对处于早期阶段的公司或平台工作中的团队是极其有效的。在这些情况下，小组可以自由地根据自己的需要发展各种过程和能力。只有在必要时在做标准化，以便能够更快地交付。

属性：

用户互动不是讨论的一个关键主题，很少（如果有的话）在设计和交付新能力时对互动进行测试。
能力主要是通过手工请求提供的，但平台开发者可能会选择将提供用户请求所需的部分或全部活动自动化。
表面上的“简单”请求变得复杂，是因为找出了遵循的正确过程。
有时候一个流程似乎是经过认可的，但是当不同的部门或团队介入时，用户会就遇到问题。

示例

一个应用程序团队想要测试他们的新更改。要做到这一点，他们需要一个包含足够测试数据的孤立环境，以便获得准确的性能读取。上次他们使用这个请求时，是一名前队员能够进入这个环境。但是自从环境变化了之后，就没有人知道怎么创建这个请求了。最后，他们与基础设施小组的一名工程师联系起来，后者能够在几天内为他们提供一个环境。
在产品开发的探索阶段，一个团队使用定制流程来提供新的云服务，而无需验证他们的解决方案是否需要进一步投资

第二阶段：可操作性–标准工具化

由于存在一致且标准的接口来提供和监控平台的功能，并这些接口满足了广泛的需求。用户能够确定现有哪些能力，并能够要求具备所需能力。

现在就有了通过文档和模板形式提供的所谓的”铺装路面“和“黄金路径”。这些模板资源定义了如何使用合规且经过测试的模式来配置和管理型的功能。虽然有些用户能够独自使用这些解决方案。解决方案往往仍然需要深入的领域专业知识，因此平台开发者的支持仍然至关重要。

属性：

技术解决方案是专门针对其问题领域内的工具，并非总是用户熟悉的工具。
在公共路径上进行了投资，但是一旦偏离这条路径，很快就会发现定制选项很少，因为重点是构建单一选项。
由于标准化，非正式内部小组能够组织聚集在一起，团队内可以交流良好做法，克服共同的问题。
在团队采用模板、进行定制化后，可能会出现实施的偏离，并且无法将来自核心团队的更改合并进来。

示例

一个核心小组管理一个Terraform单元库、Kubernetes控制器和CD，以便提供不同类型的基础设施。
一个包括关于整个组织解决办法的共享目录。

第三阶段：可扩展–自定义解决方案

提供解决办法的方式为用户提供自主权，几乎不需要维护者的支持。组织鼓励并支持解决方案提供一致的接口，以实现用户体验在不同能力之间的可发现性和可移植性。虽然是自定义解决方案，但是这仍需要团队的能有对应的认知和实现为了快速提升这些经验，在组织内部可能有指导性和简化的内部语言，使用户能够更快地适应和整合平台能力。这样的平台将产生以用户为中心、可自定义和一致的能力。

属性：

提供的解决办法是“一键式”的实施方案，使团队能够从平台的能力中受益，而不必了解如何这些能力是如何实现的。
尽管解决方案的创建过程可能相对容易，但在解决方案的日常管理和后续阶段可能没有充分考虑可用性的建设。
用户在面临独特需求时可能会感到困惑，因为可用的解决方案仍然相对有限。

示例

提供一个 API 来提取数据库的创建和维护，并为用户提供它们所需要的任何信息，以利用平台能力，例如连接字符串，保密数据的位置和带有观察能力数据的仪表盘。

第四阶段：优化–可管理的服务

团队已经毫无阻力的降平台能力集成到了日常的流程与工具中。有些能力是自动提供的，例如部署服务的观察能力或身份管理能力。由于平台的模块化构建方式，当团队在遇到超出平台能力的情况的时候，可以根据自己的需求进行定制，而不需要脱离内部提供的服务这些构建模块被用来构建透明自动组件，以满足更高级别的用例，同时在必要时实现更深层次的定制化

属性：

清楚地了解哪些能力是组织的差异化能力，哪些能力不是，使得内部团队能够在无法利用行业标准的地方专注于定制解决方案的投资。
虽然能力以一致的方式呈现出来，但并没有一种固定的使用方式。有些工具最适合作为CLI工具用于脚本，而另一些工具则更适合用户在编辑器和IDE中。
通过关注软件开发和发布的流程，将个别能力的价值扩展，从而将重点放在如何将能力组合成更高级别的产品或服务上。
虽然能力往往以一揽子方式提供，但是超级用户能够按需提供能力，以便能在需要的时候优化。

示例

每个工作负荷都注入了可观察的agent，并将一个可观察的代理置于所有应用程序的前面。
默认情况下，每个新项目都会在任务运行器（pipelines）中获得一个空间和一个运行时环境（K8s命名空间）。然而，项目可以选择其他选项，如无服务器运行时。
从现在的服务门户中的目录，用户选择"提供数据库"。自动化提供了一个RDS数据库，并且发送一个 URL 和地址给用户获取账号密码。

How are platforms and their capabilities planned, prioritized, developed and maintained?

平台的运营意味着在其整个生命周期内运行和支持其功能及其特性，包括接受新请求、初始发布、升级和扩展、持续维护和运营、用户支持，甚至废弃和终止。组织及其平台团队选择要创建和维护的平台和能力，并可以优先考虑最有价值和最有影响力的项目。

值得注意的是，提供功能的大部分工作都是在其最初发布后进行的——包括提供无缝升级、新功能和改进功能、运营支持以及用户的启用和培训。因此，一个有影响力、有价值的平台将提前计划并管理他们的平台，以实现长期可持续运营和可靠性。

第一阶段，临时-不稳定

平台和能力是根据临时的产品团队请求和需求进行反应性开发、发布和更新的。产品团队甚至可能需要规划和构建他们所需的能力。

那些构建新能力的团队，无论是专门的集中团队还是满足自身需求的应用团队，只对支持其他人使用该能力承担非正式的责任。他们不需要积极维护它，并且很少有流程用于评估该能力的质量。在这个级别上，实施通常被忽视，直到发现安全漏洞、错误阻止使用或出现新需求时，才会迅速实施另一个反应性计划。

特征：

示例场景：

发布了Log4Shell安全漏洞，该组织成立了一个专门的团队来调查组织可能存在脆弱性并进行修补。一旦团队确定影响范围，他们必须与多个不同的团队紧密合作，因为每个团队都以不同的方式管理其服务器和升级流程。即使完成了此项工作，对于不会出现更多的漏洞实例，信心水平仍然相当低。

第二阶段，运营化 — 专职团队

平台和能力的信息都有集中的文档记录和可查找性，并且规划和管理能力生命周期的流程至少有轻微的定义。每个服务和功能的责任和所有权都有文档记录。针对不同的能力，生命周期管理流程会因其所有者和优先级而有所不同。一个集中的团队负责维护现有能力的待办事项清单，或者可以根据需求生成待办事项清单，以提供当前能力的维护状态。这使得组织可以追踪能力提供和升级要求的合规性的进展情况。

特征：

应用小组根据需要建立新的能力，以满足迫切的需要。
一个中央小组负责登记整个组织现有的共享服务。
对于功能，采用宽松的标准，例如要求具备可自动化的API和使用文档。
基础设施即代码（Infrastructure as Code）的目的是为了实现更轻松地追踪部署的服务。
符合PCI DSS或HIPPA等合规性法规的审计是通过服务清单来实现的。
迁移和升级工作是根据火焰图进行跟踪，使组织能够跟踪合规率和完成时间。
跟踪不表示支持水平；通常在此阶段升级仍然是手动的，定制化的。

示例场景：

PostgreSQL 11将于年底结束生命周期。组织已经意识到哪些数据库需要升级，并正在安排每个团队的工作，以完成升级。

第三阶段可扩展-集中启用

平台和能力不仅是集中注册的，而且也是集中协调的。平台小组负责了解本组织的广泛需要，并相应地确定平台和基础设施小组的工作优先次序。负责某项能力的人不仅需要在技术上对其进行维护，还需为能力与组织中的其他相关服务进行标准用户体验的整合，确保安全稳定的使用，并提供可观测性。

建立和发展新能力的标准进程已经存在，使本组织的任何人都能够提出符合预期的解决办法。平台能力和功能的持续交付流程使得能够正常推出和回滚。计划和协调大规模的变革，因为它们将用于客户面对的产品变化。

特性：

应用团队在创建服务之前会先向平台团队请求服务。
新的服务必须遵循标准接口、文件和治理等标准做法。
升级流程已在各个版本和服务中记录并保持一致。
如果提供者没有管理升级，他们将为用户提供工具和支持，使其达到最小影响。

示例场景:

该组织将升级到RHEL 9。在这样做的过程中，每个应用程序团队都需要验证他们的软件是否继续正常运行。为了实现这一测试阶段，中心计算团队为每个团队建立了正确的软件和操作系统版本的测试环境。

第四阶段：优化–可管理的服务

每个能力的生命周期都以标准化、自动化的方式进行管理。功能、特点和更新将持续不断地提供，不会对用户造成任何影响。由平台提供商发起的任何大规模变化都包括对现有用户的迁移计划，其中包括明确的责任和时间表。

平台能力提供商肩负起大部分维护责任，但存在着一个明确的合同——“共同责任模型”，该模型描述了用户的责任，并使双方能够基本上独立运作。

特性

共同所有权模型清楚地定义了平台及其功能的责任人是谁，以及对用户有什么期望。
团队脚本同时执行升级和任何回滚策略，以降低风险和影响。

示例场景：

虚拟机的用户不需要管理与版本升级有关的任何事情。他们唯一的要求是在交付流程中包含一个具有代表性的冒烟测试阶段。然后，他们被要求将他们的应用程序声明为具有较低的风险承受能力，以等待一个完全稳定的升级或更高的承受能力来成为早期采用者。虚拟机功能随后负责自动发布升级版本的管理，包括在烟雾测试或金丝雀发布失败后执行回滚操作。

What is the process for gathering and incorporating feedback and learning?

通过对用户的明确和隐式反馈做出反应，组织可以提高用户满意度并确保长期的平台可持续发展。组织必须在创新和满足用户需求之间取得平衡，以保持平台的相关性。随着科技和用户偏好的改变，能够灵活而及时响应这些变化的平台将脱颖而出。定期重新审视和完善反馈机制，可进一步优化平台开发，改善用户参与。

第一阶段，临时-不稳定

对于每个平台和功能，使用情况和满意度指标都是以自定义方式收集的（如果有的话）。不同能力的结果和成功衡量标准并不一致，因此没有收集相应的见解。可能不会收集用户反馈和平台使用情况，即使收集了，也将是非正式的。决策是根据轶事要求和不完整的数据做出的。

特征：

对于如何衡量平台的成功没有经验或意见
使用熟悉的工具收集具有有限意图和远见的公共指标
依赖少量数据
难以确保用户参与——用户认为他们的反馈没有得到考虑
如果使用调查，问题会在运行之间发生变化，从而无法跟踪进度

示例场景：

平台技术负责人希望通过在下一个季度计划中添加关键主题来改善与用户的协作。他们决定对用户希望看到的内容进行调查。反应是压倒性的，这令人兴奋，但也导致难以组织和回应所有想法。虽然某些想法会影响季度计划，但用户并不认为他们的想法被接受，并且不太愿意回复下一次调查。
该团队希望自动捕获更多数据，因此他们寻找轻松收集的机会，例如 CI 中的测试失败。然而，并非每个团队都使用相同的 CI 自动化，因此数据仅适用于 Java 应用程序，尽管有些团队已开始使用 Scala 编写服务。

第二阶段可操作——一致的收集

此级别的组织有一个有意的目标，即验证平台产品是否满足其内部用户市场的需求。可操作的、结构化的用户反馈收集受到重视。可能会指派专门的团队或个人来收集反馈，以确保采取更加一致的方法。反馈渠道（例如调查或用户论坛）是标准化的，并且反馈是分类和优先级的。除了用户反馈之外，还期望用户体验能够随着时间的推移生成使用数据。

将反馈转化为可操作的任务仍然面临挑战。尽管用户数据存储库不断增长，但组织可能需要帮助有效地理解这些反馈并将其集成到平台路线图中。可能很难确保用户看到由他们的反馈驱动的切实变化。

特征：

数据收集作为大多数主要规划会议或功能实施的一部分进行讨论。
对于验证成功的具体衡量标准可能并不一致。
可以衡量平台功能是否成功，例如通过衡量用户采用率或节省的用户时间。

示例场景：

平台团队将 20% 的时间分配给用户定义的功能，这些功能是他们根据调查和其他访谈技术确定的。他们的发现被收集到一个工具中，该工具可以进行额外的投票和评论，以进一步完善优先事项。在实施过程中，我们会联系提出请求的用户，以就早期设计和实施进行协作。一旦实施，就会发布公告，确保请求用户了解新功能并支持采用它们。
专注于软件交付功能的团队希望自动捕获更多数据，包括他们通过构建工具自动化从提交到生产的周期时间。有一种理解是，周期时间可以包括其他活动，如审阅，但目前尚未包括在内。

第三阶段，可扩展——内在拉力

虽然已经存在强大的标准反馈机制，但在此阶段，数据是通过精心设计的方式收集的，以产生具体的战略见解和行动。确定期望的结果和结果，然后选择标准指标来表明实现这些结果的进展行业框架和标准可用于从对某些行为影响的行业研究中受益。

采用专门的团队或工具来收集和审查反馈并总结可行的见解。平台产品与其用户建立了共生关系。反馈被视为指导平台运作和路线图的战略资产。可以定期举办反馈审查会议，让跨职能小组聚集一堂，根据用户的见解进行讨论和制定战略。

特征：

在提供任何新的平台功能之前，该小组讨论如何评价其工作成果。
该组织在表明平台计划成功的衡量标准上有着广泛的一致性。
[产品管理员]({https://deploy-preview-80–cnpe.netlify.app/zh/wgs/platforms/glossary/#platform-product-managers})或专职团队成员推动持续和一致的反馈收集和分析进程。
该组织制定了衡量尺度和目标，以观察和确定目标来表明成功。

示例场景：

本组织一直在追踪构建时间和周转时间。然而，他们现在认识到，虽然很容易收集，但仅仅收集这些数据并不能全面反映软件的交付情况。考虑到这一点，该小组对服务的可靠性和稳定性进行衡量。

第四阶段优化 — 定量和定性

反馈和计量已深入融入本组织的文化。整个组织从高层行政人员到整个工程师组织都认识到收集数据和对产品演变反馈的价值。数据实现了民主化，其中包括平台用户和企业领袖。积极参与确定平台改进的假设，在设计过程中提供反馈，然后衡量影响后的交付情况。在规划平台举措时将考虑到所有这些衡量标准。

不仅标准框架得到了利用，而且人们认识到，从多个角度进行衡量可以产生一种更全面的情况。需要投入精力了解定性指标如何随着定量指标的改进而变化。重点是确定领先的措施，这些措施可以预测支持用户需求、减轻他们的挑战并领先于行业趋势和业务需求的功能。

特征：

平台小组不断设法改进他们观察的衡量标准及其收集数据的方式。
该组织熟悉 Goodhart的定律并对其敏感：“当一项指标成为目标时，它不再是一个良好的衡量标准。”
对收集到的指标和遥测数据进行持续评估，以获得真正的洞察力和价值。
指标数据管理得到良好支持，例如用于管理数据湖和获取见解的标准平台功能。
鼓励跨部门协作，以避免数据孤岛，并能够建立有效的反馈周期。

示例场景：

随着时间的推移，该组织收集的数据表明，构建时间增加了15%以上。这会引发负面的开发者体验，一旦触发，即使构建时间缩短到原始时间以下，开发者仍然感到沮丧。这种洞察力促使构建团队设置和遵守服务级别目标 (SLO)，这使得能够在引发与其成员的负循环之前尽早识别和改进。

结语

平台及其维护者为灵活的数字产品开发提供了基础。他们提供了一套一致的能力，以便于能够有效的开发和交付软件。这个成熟模型为您的平台工程旅程提供了一张地图。

Wgs: 平台工作组章程

Mon, 01 Jan 0001 00:00:00 +0000

Problem Statement

In most app-delivery scenarios, the packaging format and delivery mechanism of the application artifacts are targeted, but not necessarily the app’s infrastructure dependencies such as data stores and message queues. That is, application and infrastructure delivery are not coordinated. Often, applications are heavily dependent on infrastructure resources that are not directly linked to a specific deployment, and therefore problems with non-existing infrastructure resources might cause deployments to fail. In addition to this, the application and infrastructure lifecycles are not synchronized, creating additional complexity and challenges when delivering workloads.

Example:

Developers using a storage class for testing an application locally that is not available in higher environments.
Deployment of an application workload is a separate approval process and journey as to deploying the necessary ingress to route traffic to that service.
Delivering complex micro-service architecture and a sustainable GitOps deployment pattern are treated as separate but related workflows.

Setup of a CI/CD pipeline and its constituent parts to enable the delivery of applications in coordination with infrastructure is part of institutional knowledge and not easily transferable across organization, system nor domain boundaries.

Additionally, it is often assumed that infrastructure is always available when dealing with application delivery. At some point, it might be useful that infrastructure could also be deployed by GitOps mechanisms and/or using the deployment pipeline. Therefore, there is always a cut between the infrastructure deployment and the application delivery/deployment tooling, which might lead to deployment problems and misconfigurations.

Currently, it seems that there are no ubiquitous best practices or recommendations for these use cases and no standard for declaring an entire application in a platform-agnostic way.

There are projects like Crossplane and Terraform primarily used for provisioning infrastructure and other tools like Argo, Flux and Keptn for provisioning applications on that infrastructure . There are also emerging projects like OAM and Dapr to abstract infrastructure and “inject” it automatically on behalf of apps, but these have not (yet) been broadly adopted by implementation providers, i.e. public cloud platforms. This working group should clarify what application and infrastructure coordination could look like and develop best practices for such cases.

What combinations of tooling are available out there that aim to resolve this problem, and what are the gaps encountered?

This section aims to propose a few combinations of currently existing solutions, evaluate their pros and cons, and what bits are missing (taking the example above as a first use case).

Examples of known patterns aimed to deploy infrastructure:

Without any claim to comprehensiveness:

Terraform
Crossplane (Do we need a sentence covering their primary purpose?)
ACK
Pulumi
CDK
Open Service Broker ( https://www.openservicebrokerapi.org/)

Examples of known patterns aimed to deploy applications:

GitOps

This pattern is built on top of existing tools like: helm, kustomize or raw yaml and automate applying changes from source of truth in Git repo to the Cluster. ArgoCD and Flux are some examples of projects that implement this pattern.

Application Operator

This pattern is intended to enhance native Kubernetes resources like Deployment to deploy applications and manage their lifecycle. One of the critical features is canary deployment that requires coordination with Ingress or Service Mesh and domain knowledge about the application. ArgoRollout and Flagger are examples of projects that implement this pattern with these advanced features.

Declarative Pipelines

This pattern allows you to build a declarative pipeline that encapsulates some workflow or process. This could be part of the CI process to build an artifact, test or ensure it meets security controls. They can also be used in the CD lifecycle in deploying an artifact and running custom tests or implementing custom canary logic. Declarative pipeline can be thought of as a directed graph with decision points to move to the next point in the graph. The decision could be automated or require manual approval tied to a notification system. Projects like Keptn and ArgoWorkflow are examples of solutions that enable building declarative pipelines.

Composition Operator

The Kubernetes CRD to representation for some resources is complex and at times has dependency on other CRDs. There is also a need for separation of concern between an application and operation teams, especially when it applies to infrastructure resources. This pattern allows you to compose resources using a number of other CRDs as building blocks and simplify or hide the number of parameters that must be provided by the top level CRD. The CrossPlane XRD/XRC and KubeVela are examples of projects that provide this pattern.

Infrastructure Operator

There is a need to declare cloud provider infrastructure resources as CRDs so that they can be integrated as part of application deployment lifecycle on Kubernetes. The Infrastructure Operator pattern allows CRDs to be applied to the Cluster and the Operator implements the necessary logic to converge requests with desired state. The Operator integration to the cloud provider can take many forms, among them native cloud provider APIs, Cloud Formation Templates or TerraForm among them. CrossPlane Provider, AWS Controller for Kubernetes (ACK) are examples of projects that provide this pattern.

Alignment with TAG App Delivery Charter

As application delivery is often coupled to the underlying infrastructure (when thinking of services like external databases, message queues,…), this can often impact package formats and the application delivery workflow. This topic would handle the “Application definition, including description, parameter and configuration”, “Application bundling and deployment”, and “Application delivery workflow and strategy” topics of the TAG charter. As these should be done using configuration-driven tools (“GitOps”), this also touches the “Configuration source driven workflow” area.

Working mode / expected outcome

The group discusses concepts, plans and develops a demo infrastructure (as code) to handle these use cases (e.g. App-Ready-Platform as code). This might be implemented using different tools (link to landscape) and could be a blueprint for end users. Furthermore, the validated best practices might then be documented in a white paper.

Goals

Focusing on the key stakeholder, who in this scenario is an engineer potentially with a CKA/CKAD looking to enable the delivery of an application workload on cloud infrastructure.

Vendor and End-user interviews.
Focused questions that help identify successes and frustrations of products.
Capturing the current practices and the landscape.
Landscape radar
Provide interoperability examples between IaC and CD tools in the Podtato-head project.
Give end-users ideas and examples of how they could integrate application and infrastructure deployment.
Provide patterns in a white paper based on practical work and how end-users are implementing them. Present practices and trends seen occurring within the industry that would be valuable to highlight to end-users.

Non-Goals

Creating a new type of standard
An opinion on how to build microservice applications or cloud-native architecture.
Defining how deployments should be done.
Creation of a new CNCF open source project.

Wgs: 术语表

Mon, 01 Jan 0001 00:00:00 +0000

另可参考：云原生术语表

如果你希望在平台工作组范围之外引用这些定义，请注意它们是在 CNCF 和应用交付的背景下编写的。

平台

平台指的是支持开发、部署、运行和/或管理产品与服务交付的功能、文档和工具的集合。平台可以包括门户网站、API、CLI、协议定义、文档、标准和/或黄金路径模板。如果平台做得好，就可以更快、更可靠地交付组织的应用程序和服务。

根据平台的不同范围和受众，有时也可称其为“开发者平台”、“内部开发者平台 (IDP)”、“交付平台”、“应用程序平台”，甚至“云平台”。“平台即服务 (PaaS)”一词也常用于描述从组织外部购买或以其他方式采用的平台，它提供了一种可管理性更强但定制化程度较低的平台解决方案。

平台工程

平台工程是关于平台的设计、建设、运营和演进的实践。这种实践可以看成是一种同理心驱动的社会技术组织设计方法¹。从该角度来看，这是一个持续的过程，组织通过该过程学习如何以及在何处进行投资，并在内部而不仅仅是外部进行战略性的业务押注。

平台团队

平台团队指的是负责构建和管理平台的人员。平台团队成员包括平台工程师，他们专注于建设构成平台体验的工具和功能。平台团队可能包括专门的平台产品经理角色，他们专注于满足内部客户需求，同时也支持组织更广泛的战略目标。随着平台的发展，平台团队可能会增加其他专家角色，如运维人员、QA分析人员、UI/UX设计师、技术写作者和开发者布道师。

DevOps

“DevOps 是一种方法论，该方法中团队拥有从应用程序开发到生产运维的整个流程。”² 虽然 DevOps 实践可以由团队在不开发专门平台的情况下实施，但将平台工程视为一种通过交付和管理服务于整个组织的统一平台来扩展 DevOps 原则的方法，可能会很有帮助。这种共享平台旨在简化开发、部署和运维流程，为软件交付提供标准化和高效的环境。尽管 DevOps 和平台工程在优化软件交付和运维效能的目标上趋于一致，但平台工程却与众不同地专注于开发有形产品——即平台本身，以促进这些目标的实现。

平台用户

平台用户是指直接使用平台功能的人员，包括但不限于应用程序开发者、应用程序运维人员、数据科学家、商业采购 (COTS) 软件运维人员和信息员——在平台上运行软件、使用平台提供的功能或需要洞察平台使用情况的人员。平台用户也可能包括在底层功能基础上创建上层平台服务的其他平台工程师。

门户

门户指的是基于Web的界面，可集中式访问各种资源、工具和服务。它可以作为更广泛用户的跳板，以便有效地管理底层平台的功能并与之互动。门户网站的存在是为了通过用户友好的界面，简化复杂的流程并提升自助服务能力，从而增强用户体验。

平台能力

平台能力指的是具体的用户价值或者平台提供的**what。这些不应与描述能力如何**体现的平台质量相混淆。这些能力可以处于不同的抽象层次（例如，单一数据库与包含数据库的测试环境），并由不同的供应方提供。随着平台的成熟，它们一般都希望通过自服务来提供能力，从可用能力的可发现性开始，包括不同能力间体验的一致性。能力本身通常相当持久，而供应方及其实现则可能发展得更快。例如，企业不太可能不再需要测试环境，但他们可能会发展到提供容器化解决方案，而不是基于虚拟机的解决方案。

平台能力供应方

这指的是开发和维护平台所提供能力的一组人员。供应方可以是外部组织或内部团队，在较小的组织中，开发更广泛平台的人员自身往往也是供应方。随着平台的成熟，它们可以通过为供应方维护抽象概念来防止锁定，并继续向最薄可行平台（TVP）迈进。

平台质量

平台质量指平台及其能力**_如何**体现，以及在跨功能需求、非功能需求或简单的“功能”方面的预期。例如，管理服务的可靠性或性能可以用服务等级目标（SLO）来衡量；安全性可以用降低已识别风险的时间来衡量；可观测性可以用来调试和报告平台的使用情况。质量常常与能力相混淆，因为有些概念（如可观测性）既可以作为一种能力（如收集应用遥测数据的 OTel 算子），也可以作为一种已声明的质量（如用于测量和预警所提供 OTel 算子正常运行时间的平台指标）。

认知负荷

认知负荷是指量化用户从平台功能中获益之前的心理成本。在认知负荷这个总称中，实际上有三种类型的负荷：有效负荷、内在负荷和外在负荷。如果平台能让用户专注于有效负荷（解决工作中的具体问题），同时简化内在负荷（获取新信息或流程以完成任务），并最大限度地减少外在负荷（分散注意力，有时也被戏称为“ 牦牛剃须”——瞎忙），这样的组织才是最健康的。

最薄可行平台（TVP）

TVP 是在 Matthew Skelton 和 Manuel Pais 所著的《团队拓扑》一书中最初被定义的概念，以鼓励企业在小型而有效的平台之间取得谨慎的平衡。这样，企业就能在实现更广泛的业务目标的同时，加速和简化在平台上构建团队的软件交付。他们鼓励平台专注于业务的独特需求，并定期集成第三方能力供应商，以降低平台的复杂性和运营成本。

CNCF 应用交付 TAG – 平台工作组

Wgs: CNCF 平台白皮书

概述

目录

为什么需要平台？

平台是什么？

平台成熟度

平台的属性

平台团队的属性

平台的挑战

赋能平台团队

如何衡量平台的成功

用户满意度和生产率

组织效率

产品和功能交付

平台能力

Wgs: 平台工程成熟度模型

概述

什么是平台工程？

如何应用此模型

该项工作的背景

目标受众

了解各个级别

但似乎并不适用

模型表

模型详情

How are staff and funds allocated to platform capabilities?

第一阶段，临时性——基于自愿或临时安排

特点

示例场景：

第二阶段，可操作 — 专职团队

特点

示例场景：

第三阶段，可扩展 — 作为产品

特点

示例场景：

第四阶段，优化-已启用的生态系统

特点

示例场景：

Why and how do users discover and use internal platforms and platform capabilities?

第一阶段，临时-不稳定

特征：

示例场景：

第二阶段， 可操作化——外在驱动力

特征：

示例场景：

第三阶段，可扩展——内在拉力

特征：

示例场景：

第四阶段 优化——参与

特征：

示例场景：

How do users interact with and consume platform capabilities?

第一阶段：临时–自定义程序

属性：

示例

第二阶段：可操作性–标准工具化

属性：

示例

第三阶段：可扩展–自定义解决方案

属性：

示例

第四阶段：优化–可管理的服务

属性：

示例

How are platforms and their capabilities planned, prioritized, developed and maintained?

第一阶段，临时-不稳定

特征：

示例场景：

第二阶段，运营化 — 专职团队

特征：

示例场景：

第三阶段 可扩展-集中启用

特性：

示例场景:

第四阶段：优化–可管理的服务

特性

示例场景：

What is the process for gathering and incorporating feedback and learning?

第一阶段，临时-不稳定

第二阶段，可操作化——外在驱动力

第四阶段优化——参与

第三阶段可扩展-集中启用

第二阶段可操作——一致的收集

第四阶段优化 — 定量和定性