平台工程成熟度模型

介绍

CNCF最初的平台定义白皮书描述了什么是云计算的内部平台，以及它们承诺为企业提供的价值。但是，为了实现这些价值观，组织必须反思并有意识地追求对他们有影响的结果和实践，请记住，每个组织都依赖于为自己的组织设计的内部平台——即使该平台只是有关如何使用第三方服务的文档。这种成熟度模型为这种反思和识别任何组织中的改进机会提供了一个框架。

什么是平台工程？

在DevOps承诺的跨职能合作的启发下，平台和平台工程已经作为这种合作的明确形式出现在企业中。平台策划并呈现通用功能、框架和体验。在本工作组和相关出版物的背景下，重点是促进和加速内部用户（如产品和应用团队）工作的平台。

平台工程是规划和向开发人员和用户提供此类计算平台的实践，涵盖平台的所有部分及其功能——人员、流程、策略和技术;以及推动他们实现的预期业务成果。

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

如何使用此模型

随着平台工程在过去几年中的地位越来越高，一些模式已经变得明显。通过将这些模式和观察结果组织成一个渐进式成熟度模型，我们的目标是让平台团队适应他们可能面临的挑战和瞄准的机会。每个方面都由该方面每个级别的不同团队和组织的连续特征来描述。我们希望读者在模型中找到自己，并在相邻的层面上发现机会。

值得注意的是，每增加一个成熟度水平，对资金和人员时间的要求就越高。因此，达到最高水平本身不应该是一个目标。每个级别都描述了在该阶段应该出现的品质。读者必须考虑，鉴于所需的投资，他们的组织和当前环境是否会从这些品质中受益。

请记住，每个方面都应该独立评估和发展。然而，与任何社会技术系统一样，这些方面是复杂且相互关联的。因此，你可能会发现，要在一个方面有所改进，你就必须在另一个方面达到最低水平。

同样重要的是要认识到，平台的实现因组织而异。请务必评估团队整体云原生转型的当前状态。可用于此评估的非凡资源是云原生成熟度模型。

最后，该模型鼓励组织通过有意识的规划来完善其平台工程学科及其生成的平台。这种规划和纪律本身就是成熟平台开发和持续演进的必要条件。

目标受众

每个读者都会带来独特的背景，并将从这个模型中学到独特的知识。以下是我们想到的一些角色，以及他们参与此模型的可能动机：

• 首席技术官、副总裁和技术总监：希望规划数字化转型和提高开发人员生产力的道路的领导者
• 工程经理：寻求使工程师能够以更少的开销和更高的效率提供价值的团体和个人
• 企业架构师：在现代技术领域中寻求以价值和解决方案为导向的技术问题视角的个人
• 平台工程师和平台产品经理：寻求为平台构建者和平台用户构建最佳体验的团队和人员
• 产品供应商和项目维护人员：希望设计工具和传递消息的组织和工程师，使用户能够利用平台和功能取得成功
• 应用程序和产品开发人员：希望更详细地了解他们对内部平台的期望的平台用户

模型表

投资

如何为平台功能分配人员和资金？

对平台和平台工程的投资是分配预算和人员以构建和维护共同能力的过程。通常，计划被描述为自下而上有机构建，或通过自上而下的计划来推动。无论哪种情况，都是持续投入努力的能力推动了高影响力的工作。这方面反映了投资的规模和广度如何影响平台的成功。

1级 自愿或临时

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

这些功能由临时或自愿分配的人员构建和维护;没有故意向他们分配中央资金或人员。它们取决于用户当前的战术要求。

• 特性

  • 团队的寿命很短，没有分配也没有时间提供长期规划和支持
  • 员工抱怨倦怠和对他们在核心角色之外所做的大量工作感到沮丧
  • 在处理新需求（例如紧急安全补丁）时，可能会引入流程改进或自动化，但不支持以可重用或可持续的方式构建解决方案

• 示例场景：

  • 有一位特定的员工被视为测试环境专家。虽然这位员工的本意是好的，但他们在投资有限的情况下试图实现更好的测试环境，这导致了风险的增加，因为他们的解决方案没有得到维护，也没有对如何对损坏的测试环境进行分类的共识。
  • 当管理层没有对创收功能施加压力时，我们鼓励工程师投资于能力改进。 这转化为一些冲刺的最后几天，他们优先考虑自动化和改进 CI/CD 管道的部分内容。 这些改进突然出现的情况并不少见，因为可能有几个月的过度冲刺，没有时间进行这些副业。

2级 运营 — 专业团队

预算和人员分配用于持久的人员和资源支持。 指定人员的任务是提供一组常用的功能来加快软件交付速度。 这些团队通常专注于满足反应性技术要求。 它们可能被称为 DevOps、工程支持、开发人员体验（DevEx 或 DevX）、共享工具、卓越中心，甚至平台。 它们得到集中资助并被视为成本中心； 它们对直接价值流和应用程序团队的影响没有被衡量。 很难描绘出这个级别的平台团队对组织及其价值流的影响，这使得维持和继续资助此类团队变得困难。

• 特性

  • 团队预算可能包括与其工作相关的基础设施成本，这通常是预算对话中的一个关键点。
  • 积压工作 （backlog） 项包含多种技术，导致频繁且大型的上下文切换。
  • 这个团队通常是第一个填补尚未解决的空白的团队，即使不在团队声明的范围内。此团队拥有没有所有者的资源的所有权。
  • 被指派的人员很少有时间或经验进行客户研究来验证他们的设计或实施

• 示例场景：

  应用程序开发人员提出了一个问题，即其应用程序的构建时间过长。集中式团队的任务是将构建时间缩短 50%。他们通过将 CI 运行器的大小和数量增加一倍来解决这个问题，因为它们与软件的距离不够近，无法单独改进应用程序构建。这给他们的集中式团队带来了预算问题，因为生产力的提高无法直接衡量这种增加的基础设施成本。

3级 可扩展 — 即产品

对内部平台及其功能的投资类似于对企业对外产品和价值流的投资：基于它们预期为客户提供的价值。产品管理和用户体验被明确考虑和投资。退款系统可用于反映平台对其客户自身直接价值流和产品的影响。企业通过使用数据驱动的绩效指标和反馈循环，将资金和人员分配给适当的计划。平台团队最终可以优化业务本身，并有助于提高盈利能力。

• 特性

  • 平台团队员工角色传统上在内部服务或技术团队中找不到，例如产品管理和用户体验。
  • 团队在组织内部发布路线图，该路线图指示交付的价值和高级功能目标。
  • 在设计、交付和部署后阶段，对功能的实施质量和用户体验进行了测试。
  • 功能删除是对话的关键部分，目标是拥有一个得到良好支持、使用良好的功能套件，而不是可能无法维护的庞大资产

• 示例场景： 从平台使用指标中获得的数据为决策提供信息，将资金和人员分配给最具影响力的计划。

第 4 级，优化 — 启用的生态系统

平台团队想方设法提高组织范围的效率和有效性，而不仅仅是基本功能。核心平台维护人员有意努力优化新产品的上市时间、降低整个企业的成本、实现新服务的高效治理和合规性、快速轻松地扩展工作负载以及其他跨领域要求。这些核心维护人员专注于使能力专家能够将他们的需求和产品无缝集成到平台的现有和新部分。此外，该组织将来自安全、性能、质量等专业领域的人员和资源集中在与提供的平台框架互动上，以引入高级功能，使产品团队能够加速实现公司目标，而无需依赖集中的团队积压工作。

• 特性：

  • 使专家能够扩展平台功能并引入新功能成为当务之急。
  • 该组织可以集中专家，允许他们的知识和支持通过平台功能传播。

• 示示例场景：

  • 营销部门与平台建设者合作，引入一致的用户跟踪，以便将营销工作归因于产品结果。
  • 自动化计划将每个实例配置数据库的人工时间缩短了 30 分钟，每年可节省 1000 万美元。

采用

采用不仅描述了组织使用平台功能的方式和程度，还描述了他们这样做的动机。在早期阶段，许多目标用户可能根本没有意识到他们正在使用一个平台，而是将他们的工具视为来自各种内部来源的功能的临时集合。这可能会发展成为一组一致管理并呈现给用户的功能，即一个或多个平台。随着功能变得更加精细和可发现，平台使用的驱动力通常会远离更多的外部动机，如授权或激励。这导致用户自行选择平台功能，理想情况下甚至将自己的努力投入到更广泛的平台生态系统中。

指示平台采用的常见增长模式的图表。这展示了主要由平台建设者推动的缓慢起步。一旦平台为用户提供了足够的价值，增长就会更多地受到用户的拉动，从而导致更陡峭的采用曲线。

1 级，临时 — 不稳定

共享平台和功能的采用是零星且不一致的。在选择和整合所需的支持服务和技术方面，没有组织范围的战略或指导。各个团队可能会利用平台实践来改进自己的流程，但整个组织没有协调的努力或标准化。这种采用程度的特点是缺乏连贯的方法，并且认为外部工具比内部提供的工具更有效。

• 特性：

  • 一次性工具、服务和功能由组织中的各个团队和部门管理和使用。
  • 提供商管理（又称“云”）服务的采用和使用不一致，并且没有标准的做法和策略，因为内部配置很难找到或使用。
  • 应用和服务团队通过谣言和偶然的对话随意发现工具和功能，而不是通过更集中的流程。
  • 组件和功能的协调和重用仅由最终用户（应用程序团队）驱动（如果有的话）。
  • 每个产品团队都维护自己的一组脚本或工具来部署其应用程序。

• 示例方案：

  • 银行服务需要数据库。开发人员从另一个团队的朋友那里得知，他们可以请求 AWS 账户并设置 RDS 数据库。他们从另一个团队中找到了一个 Terraform 脚本来预配该数据库。为了进行监控，他们临时使用 CloudWatch;在运行 Terraform 脚本之前，他们手动将密钥从 AWS 控制台复制到 Hashicorp Vault 实例。

第 2 级，可操作 — 外在推动

该组织认识到共享平台和功能的价值，并努力鼓励和培养它们。内部指令激励甚至要求在某些用例中使用共享平台服务。一些产品团队比其他产品团队更多地使用平台功能;功能涵盖组织中的典型用例，但不包括不寻常的用例;并且很难将这些异常值添加到通用平台。

用户对功能的发现及其使用方式不一致;除非平台团队指示，否则产品团队中的用户可能不会发现受支持的功能。

• 特性：

  • 一定程度的外部推动力导致使用平台功能，例如：个人评论等激励措施/要求用于生产发布或获得资金等任务
  • 平台功能的利用是分散的——用户可能利用一种功能，但可能不知道或有兴趣采用其他可用的功能。
  • 用户学习如何使用平台功能的积极性较低，并且严重依赖通过办公时间或服务台等论坛与提供商的协作。
  • 鼓励平台用户加入非正式的实践社区，分享问题和解决方案，但出席人数可能会受到限制。

• 示例场景：

  • 工程组织决定使用标准部署工具，并指示所有团队使用它。新流程（发行说明的沟通等）是围绕该标准构建的。指示团队停止使用其他类型的部署脚本，而是使用通用工具。对于一些团队来说，这很困难，他们的需求没有被新流程满足，但又不理解或不允许扩展它。

第 3 级，可扩展 — 内在拉力

产品和服务团队的用户之所以选择使用平台及其功能，是因为它们在减少产品团队的认知负担方面提供了明确的价值，同时提供了更高质量的支持服务。文档和符合人体工程学的界面使产品团队用户能够快速配置和使用平台功能。用户选择内部平台实施，而不是自己开发功能或雇用提供商等替代方案。

• 特性：

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

• 示例场景：

  • 应用程序团队以前曾成功请求新数据库。他们的过程很容易理解，几乎不需要等待时间。此外，还包括备份和监控等关键功能，使团队能够毫无问题地将其使用一直推进到生产。这种经验意味着，当团队以后需要队列时，他们的第一反应是检查内部平台选项。虽然他们最初打算使用特定的队列技术，但最终，他们选择使用内部提供的队列技术，因为他们知道该解决方案对他们的组织的集成程度如何。

第 4 级 优化——参与式

来自产品团队的用户通过加入生态系统并回馈生态系统来进一步投资平台功能。一些贡献改进和修复了现有功能;其他人则引入了新功能和特性，以解决新的用例。定义了流程和服务，使用户能够识别需求并协调多个产品和平台团队之间的贡献。新功能通过一致的界面和门户发布，并提供完整的文档和标准版本控制。

• 特性：

  • 应用/服务团队中的用户有权为平台功能提供修复、功能和反馈。
  • 战略性地利用外部项目和标准来降低维护成本、加速新功能交付，并最有效地利用组织员工人数。
  • 新功能和增强功能通过问题板和拉取请求异步协调。文档和清单使贡献者能够自我驱动开发。
  • 开发者倡导者和内部大使建立并支持内部用户社区，将平台所有权扩展到应用和服务团队贡献者。
  • 领导层和个人贡献者都认为使用平台功能是在组织中工作的最佳方式。
  • 平台工程师参与产品团队规划，以了解需求并建议相关的现有功能。

• 示例场景：

  • 团队需要替代备份计划。在将其作为一般产品提出后，由于重用最少，它被视为低优先级。建议团队选择将其解决方案集成到平台框架中，并将其提供给组织。它最初是一个 alpha 产品，但一旦满足所有操作要求，就可以提升为核心平台功能。

接口

用户如何与平台功能交互和使用平台功能？

平台提供的接口会影响用户与这些平台产品进行交互以预配、管理和观察功能的方式。界面可以包括工单系统、项目模板和图形门户，以及可自动化的 API 和命令行 （CLI） 工具。

界面的主要特征包括它在关键用户旅程（如初始请求、维护或事件分类）中的可发现性和用户友好性。此处的成熟度越高，反映出接口的集成度更高、一致性更高、自动化程度更高、更受支持。

级别 1，临时 — 自定义流程

存在一组不同的进程来提供不同的功能和服务，但不考虑接口的一致性。定制的流程可以满足个人或团队的迫切需求，即使提供商使用一些自动化实施脚本，也依赖于人工干预。

有关如何请求这些解决方案的知识在人与人之间共享。请求服务的过程缺乏标准化和一致性。预配和使用平台服务可能需要功能提供商的深入支持。

由于缺乏核心要求和标准，当公司尚未确定和记录期望时，这一水平是合适的。它对于处于早期阶段的公司或平台工作的团队特别有效。在这些环境中，团队可以自由地根据自己的需求发展流程和功能，使他们能够更快地交付，并且只有在以后需要时才为标准化付出代价。

• 特性：

  • 用户交互不是讨论的关键主题，并且很少（如果有的话）在设计和交付新功能期间测试交互。
  • 功能主要通过手动请求提供，但提供商可以选择自动执行预配用户请求所需的部分或全部活动。
  • 表面上“简单”的请求由于找到要遵循的正确流程而变得复杂
  • 有时，一个流程似乎得到了批准，但当不同的部门或团队参与进来时，用户会遇到问题

• 示例场景：

  • 应用程序团队希望对其新更改进行性能测试。为此，他们需要一个包含足够测试数据的隔离环境，以获得准确的性能读数。上一次他们提出这个请求时，一位前队友能够访问一个环境，但他们已经离开了，没有人知道如何重新创建它。最后，他们与基础架构团队的工程师建立了联系，该工程师能够在几天内为他们提供一个环境。
  • 处于产品开发探索阶段的团队使用定制流程来配置新的云服务，而无需验证其解决方案，从而保证进一步投资。

第 2 级，可操作 — 标准工具

存在用于配置和观察平台和功能的一致标准接口，并满足广泛的需求。用户能够确定哪些功能可用，并能够请求他们需要的功能。

以文档和模板的形式提供“铺砌的道路”或“黄金路径”。这些资源定义了如何使用合规且经过测试的模式来预配和管理典型功能。虽然一些用户能够自己使用这些解决方案，但这些解决方案通常仍然需要深厚的领域专业知识，因此维护人员的支持仍然至关重要。

• 特性：

  • 技术解决方案是特定于其问题领域的内置工具，并不总是用户熟悉的工具。
  • 在共同的道路上进行投资;然而，偏离这条道路很快就会发现很少的自定义选项，因为重点是构建一个选项。
  • 在标准化的情况下，非正式的内部小组能够形成和聚集在一起，分享良好做法并克服共同的问题。
  • 当团队采用模板、自定义模板，然后无法合并来自集中式团队的更改时，功能实现可能会出现偏差。

• 示例场景：

  • 集中式团队策划了一个 Terraform 模块、Kubernetes 控制器和 CRD 库，用于预配不同类型的基础设施。
  • 共享位置包含有关整个组织解决方案的综合文档。

级别 3，可扩展 — 自助服务解决方案

解决方案的提供方式为用户提供了自主权，并且几乎不需要维护人员的支持。该组织鼓励并启用解决方案来提供一致的接口，以实现用户体验从一种功能到另一种功能的可发现性和可移植性。虽然是自助服务，但解决方案确实需要团队意识和实施。为了改善这种体验，可能会有一种引导式和简化的内部语言，使用户能够更快地采用和集成平台功能。这将生成以用户为中心、可自助服务且一致的功能集合。

• 特性：

  • 解决方案以“一键式”实施的形式提供，使团队能够从功能中受益，而无需了解它们是如何配置的。
  • 虽然解决方案易于创建，但在管理解决方案的第 2 天和之后，可能没有那么多的可用性。
  • 可用的解决方案仍然很窄，使具有独特需求的用户不确定如何进行。

• 示例场景：

  • 提供了一个 API，该 API 抽象了数据库的创建和维护，并为用户提供了利用该平台功能所需的任何信息，例如连接字符串、机密数据的位置以及包含可观测性数据的仪表板。

第 4 级，优化 — 托管服务

平台功能透明地集成到团队已经用于完成工作的工具和流程中。某些功能是自动预配的，例如已部署服务的可观测性或身份管理。当用户到达所提供服务的边缘时，就有机会超越自动化解决方案并根据他们的需求进行定制，而无需离开内部产品，因为平台功能被视为构建块。这些构建块用于构建透明和自动的合成，以满足更高级别的用例，同时在必要时实现更深入的自定义。

• 特性：

  • 很明显，哪些功能对组织来说是差异化的，哪些不是，允许内部团队仅在无法利用行业标准的情况下投资定制解决方案。
  • 虽然功能以一致的方式显示，但没有一种方法可以使用功能。有些最适合作为脚本中使用的 CLI 工具，而另一些则受益于集成到用户在其编辑器和 IDE 中编写代码的位置。
  • 通过关注软件开发和发布的流程，扩展了单个功能的价值，从而关注如何将功能组合到更高级别的产品中。
  • 虽然功能通常以包的形式提供，但超级用户能够分解这些更高级别的产品，以便在他们需要的时间和地点进行优化。

• 示例场景：

  • 可观测性代理被注入到每个工作负载中，并将 OIDC 代理放置在所有应用程序的前面。
  • 默认情况下，每个新项目都会在任务运行程序（管道）和运行时环境（K8s 命名空间）中接收一个空间，但是项目可以选择其他选项，例如serverless runtime.
  • 从 Service Now 门户的目录中，用户选择“预配数据库”。Automation 预置 RDS 数据库，并发送 URL 和位置以获取用户的凭据。

运营

平台及其功能是如何规划、优先排序、开发和维护的？

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

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

1 级，临时 — 根据要求

平台和功能是根据临时产品团队的请求和要求被动地开发、发布和更新的。产品团队本身甚至可能需要规划和构建他们所需的功能。

构建新功能的团队，无论是专门的集中式团队还是满足自身需求的应用程序团队，都只承担非正式的责任来支持其他人使用它。他们不需要积极维护它，也很少有流程来审查产品的质量。在这个级别中，实现通常会被忽略，直到发现安全漏洞、错误阻止使用或新需求到来，此时可以快速实施另一个反应性计划。

• 特性：

  • 这些功能旨在满足各个应用程序团队的迫切需求。
  • 重点是核心能力的初始交付;没有制定持续维护和可持续性的计划。
  • 功能实现通常已过时，正在等待更新。
  • 对于功能的最新高影响更改（例如发现漏洞），会引入突然的工作高峰。
  • 更改可能导致计划内和计划外停机。
  • 每次升级都是以定制的方式完成的，需要时间和研究来设计每次升级的流程。

• 示例场景：

  • Log4Shell 安全漏洞被宣布，该组织成立了一个专业团队来调查组织可能易受攻击的地方并启动补丁。一旦团队确定了影响，他们就必须与许多不同的团队携手合作，因为每个团队都以不同的方式管理他们的服务器和升级过程。即使这项工作被认为是完成的，置信度也相当低，不会发现更多的实例。

可操作 — 集中跟踪

平台和功能是集中记录和可发现的，规划和管理功能生命周期的流程至少是轻定义的。记录了每个服务和功能的责任和所有权。生命周期管理流程因功能而异，具体取决于其所有者及其优先级。集中式团队维护或能够按需生成积压工作功能清单，以提供当前功能的维护状态。这使组织能够跟踪功能提供和符合升级要求的进度。

• 特性：

  • 应用程序团队根据需要创建新功能，以满足迫切的需求。
  • 中心团队提供整个组织中可用共享服务的登记册。
  • 松散的标准（例如需要可自动化的 API 和使用文档）适用于功能。
  • 基础架构即代码用于更轻松地跟踪已部署的服务。
  • 通过服务清单启用对 PCI DSS 或 HIPPA 等合规性法规的审核。
  • 根据燃尽图跟踪迁移和升级工作，使组织能够跟踪合规性和完成时间。
  • 跟踪并不表示支持级别;通常，此阶段的升级仍然是手动和定制的。

• 示例场景：

  • PostgreSQL 11 将于今年年底停产。组织知道哪些数据库需要升级，并计划完成每个团队积压工作的工作。

级别 3，可扩展 — 集中启用

平台和功能不仅集中注册，而且集中编排。平台团队负责了解组织的广泛需求，并相应地确定平台和基础架构团队的工作优先级。负责某项功能的人员不仅要在技术上维护它，还要提供标准的用户体验，以便将该功能与组织内的其他相关服务集成，确保安全可靠的使用，甚至提供可观察性。

存在用于创建和发展新功能的标准流程，使组织中的任何人都可以贡献满足预期的解决方案。平台功能和特性的持续交付流程支持定期推出和回滚。计划和协调大型更改，就像它们用于面向客户的产品更改一样。

• 特性：

  • 应用程序团队在创建服务之前，首先向平台团队请求服务。
  • 新服务必须遵循标准做法，例如标准接口、文档和治理。
  • 升级过程已记录在案，并且跨版本和服务是一致的。
  • 果功能提供商不管理升级，他们会为用户提供工具和支持，以将影响降至最低。

• 示例场景：

  • 组织将升级到 RHEL 9。在此过程中，每个应用程序团队都需要验证其软件是否继续工作。为了启用此测试阶段，集中式计算团队正在为每个团队设置具有正确软件和操作系统版本的测试环境。

第 4 级，优化 — 托管服务

每个功能的生命周期都以标准化、自动化的方式进行管理。功能、特性和更新持续提供，对用户没有影响。平台提供商发起的任何重大更改都包括针对现有用户的迁移计划，这些计划具有明确的职责和时间表。

平台能力提供商首当其冲地承担着维护责任，但有一个明确的合同——“责任共担模型”——描述了用户的责任，使双方能够大部分自主运行。

• 特性：

  • 共享所有权模型清楚地定义了谁负责平台及其功能以及对用户的期望。
  • Teams 编写升级执行和任何回滚策略的脚本，以保持较低的风险和影响。

• 示例场景：

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

度量

收集和整合反馈和学习的过程是什么？

通过对用户的显性和隐性反馈做出反应，组织可以提高用户满意度并确保平台的长期可持续性。组织必须在创新和满足用户需求之间取得平衡，以保持平台相关性。随着技术和用户偏好的变化，敏捷且对这些变化做出响应的平台将脱颖而出。定期检讨和完善反馈机制，可以进一步优化平台开发，提高用户参与度。

1 级，临时 — 临时

使用情况和满意度指标以自定义方式收集，如果有，则适用于每个平台和功能。不同能力的结果和成功衡量标准不一致，因此无法收集相应的见解。用户对平台使用情况的反馈和工具可能不会被收集，或者如果收集，将是非正式的。决策是根据轶事要求和不完整的数据做出的。

• 特性：

  • 没有关于如何衡量平台成功的经验或意见
  • 使用熟悉的工具收集具有有限意图和深思熟虑的常见指标
  • 依赖少量数据
  • 难以确保用户参与 — 用户认为他们的反馈没有被考虑
  • 如果使用调查，则问题在运行之间会发生变化，从而否定跟踪进度的能力

• 示例场景：

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

级别 2，可操作 — 一致的收集

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

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

• 特性：

  • 数据收集是大多数主要规划会议或功能实施的一部分。
  • 在验证成功的确切衡量标准上可能没有达成一致。
  • 可以衡量平台功能是否成功，例如通过衡量用户采用率或节省的用户时间。

• 示例场景：

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

第 3 级，可扩展 — 见解

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

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

• 特性：

  • 在提供任何新的平台功能之前，团队会讨论如何评估其工作的结果。
  • 该组织在表明平台计划成功的措施上有着广泛的一致性。
  • 产品经理或专门的团队成员推动持续且一致的反馈收集和分析过程。
  • 组织已经建立了要观察的指标和目标，并有目标表明成功。

• 示例场景：

  • 该组织一直在跟踪构建时间和交付周期。然而，现在他们意识到，虽然很容易收集，但仅凭这些并不能全面了解软件交付。考虑到这一点，该团队实施了服务可靠性和稳定性的测量。

第 4 级，优化 — 定量和定性

反馈和衡量已深深融入组织文化。整个组织，从高层管理人员到整个组织的工程师，都认识到数据收集和反馈对产品演变的价值。数据正在民主化，包括平台用户和业务领导者在内的各种利益相关者积极参与确定平台改进的假设，在设计过程中提供反馈，然后在交付后衡量影响。在规划平台计划时，会考虑所有这些衡量标准。

不仅利用了标准框架，而且人们认识到，从多个角度进行测量可以创建更全面的图景。在了解定性措施如何随着定量措施的改进而变化方面进行了投资。重点是确定领先的措施，这些措施可以预测支持用户需求的功能，减轻他们的挑战，并保持领先于行业趋势和业务需求。

• 特性：

  • 平台团队不断寻求方法来改进他们关注的指标和收集数据的方式。
  • 该组织熟悉并敏感于古德哈特定律：“当一项措施成为目标时，它就不再是一个好的措施。
  • 对收集的指标和遥测数据进行持续评估，以获得真正的见解和价值。
  • 指标数据管理得到了很好的支持，例如用于管理数据湖和获取见解的标准平台功能。
  • 鼓励跨部门协作，以避免数据孤岛并实现有效的反馈周期。

• 示例场景：

  • 随着时间的推移，该组织收集的数据表明构建时间增加了 15% 以上。这会触发负面的开发人员体验，一旦触发，即使构建时间减少到原始时间以下，开发人员也会在更长时间内感到沮丧。这种洞察力促使构建团队设定并遵守服务级别目标 （SLO），从而在煽动用户的负面循环之前及早识别和改进。