CNCF—平台工程成熟度模型

概述

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

什么是平台工程？

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

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

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

如何应用此模型

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

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

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

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

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

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

该项工作的背景

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

目标受众

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

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

了解各个级别

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

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

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

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

但似乎并不适用

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

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

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

模型表

模型详情

InvestmentAdoptionInterfacesOperationsMeasurement

How are staff and funds allocated to platform capabilities?

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

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

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

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

特点

• 为应对紧急需求，会组建“打击”或“突击”团队。这些团队的存在时间很短，既没有被指派也没有被给予进行长期规划和支持的时间。

• 迁移、改进或增强通常被视为“锦上添花”的工作项，依赖于“研究”或“黑客松”等方式的努力。

• 在处理新需求时，例如紧急安全补丁，可能会引入流程改进或自动化，但没有支持以可复用或可持续的方式构建解决方案。

• 员工抱怨因在其核心角色之外的工作量而感到疲惫和沮丧。

示例场景：

• 有一名特定的雇员被视为测试环境专家。虽然这位员工意图良好，但他们在有限投资下努力改善测试环境的尝试导致了风险增加，因为他们的解决方案没有得到维护，且没有共享关于如何处理坏掉的测试环境的理解。

• 当管理层对产生收入的功能没有施加压力时，工程师们被鼓励投资于提升能力的改进。这意味着在一些sprint的最后几天，他们会优先考虑自动化和改进他们CI/CD流水线的某些部分。这些改进往往是突发性的，因为可能有几个月的冲刺任务过于繁重，不能再在这些方面花费时间

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

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

特点

• 团队几乎全部由技术通才组成。

• 团队预算可能包括与他们的工作相关的基础设施成本，这通常是预算讨论中的一个关键点。

• 待办事项涵盖多种技术，导致频繁且大规模的上下文切换。

• 这个团队通常是首个填补尚未解决的空白的团队，即使这不在团队声明的范围内。这个团队接管了无主的资源。

• 被指派的人员很少有时间或经验进行客户研究，以验证他们的设计或实现。

示例场景：

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

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

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

特点

• 平台团队配置的角色不仅限于传统的内部服务或技术团队，例如产品管理和用户体验。

• 团队向组织内部公布路线图，指明提供的价值和高层次的功能目标。

• 在设计、交付和部署后，功能都要经过实施质量和用户体验的测试。

• 功能移除是讨论的关键部分，目标是拥有一套受到良好支持、良好使用的能力，而不是一片可能无法维护的庞大领域。

示例场景：

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

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

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

特点

• 使专家能够扩大平台能力并引进新平台能力已成为一个优先任务。

• 该组织可以集中专家，以便通过平台能力传播他们的知识和支持。

示例场景：

• 市场营销团队与平台构建者合作，引入一致的用户追踪机制，以便将市场营销工作的成效归因于产品成果。

• 自动化举措将数据库配置所需的人工时间每实例减少30分钟，从而每年节省1000万美元。

结语

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

 Download PDF <—点击下载PDF完整版