CNCF 即将推出平台成熟度模型丨亮点导览

今年年初，云原生计算基金会（CNCF）发布了平台白皮书（点击这里查看中文版本）。白皮书描述了云计算内部平台是什么，以及它们可以为企业提供的价值。 

为了进一步挖掘平台对企业的价值，为企业提供一个可以评估其内部平台的框架，CNCF 正在编写平台工程成熟度模型，通过这个模型可以让企业看到内部平台的有待改进之处。 

正式版计划于 11 月 2 日发布，本文仅针对当前的信息整理相关内容，如果您对这一模型有任何建议及想法，欢迎到 GitHub 上反馈（https://github.com/cncf/tag-app-delivery/pull/472），截止日期为 10 月 27 日。

在进一步了解成熟度模型之前，我们需要达成一个共识：企业不需要把 Level 4 当作唯一的追求目标。因为成熟度每提高一个级别，对资金和人员投入时间的要求也会随之提高。企业需要因地制宜地制定平台建设规划，这种有效的规划和规范本身就是平台持续演进的先决条件。 

了解平台成熟度模型

在平台白皮书中列出了诸多平台的属性，包括平台作为产品、用户体验、自服务等。本成熟度模型则受到这些属性的启发，并与这些属性相关联。但是这个模型不是要将一个组织或平台团队完全分类为“Level 1”或“Level 4”。模型中的每个方面之间都是独立的，每个标签只是为了反映出企业内部平台工程的影响力。 

成熟度模型并不是为了提供一个严格的公式，而仅仅只是一个评估框架，您根据实际情况来使用即可。 

这个模型的目标是为平台工程从业人员、利益相关者以及其他有兴趣的人提供一个工具，帮助他们在平台建设过程中前进。平台的设计和实施不是一门有标准答案的科学，而是根据具体项目、企业内部情况以及特定节点制定的具体需求。 

如 Martin Fowler 所说：“一个成熟度模型评估的真正成果不只是为了告诉你所在的级别，而是会告诉你需要努力提高的技能清单。你当前所处的级别仅仅是为了确定下一步需要掌握的技能清单。” 

平台成熟度模型受众

• CTO（首席技术官）、VP（副总裁）和技术总监：寻求制定数字化转型和提高开发效率的路径

• 工程经理：希望赋予工程师更多价值，并减少开销，提高效率

• 企业架构师：在现代技术领域中寻求以价值和解决方案为导向来解决技术问题

• 平台工程师和平台产品经理：寻求为平台构建者和使用者提供最佳体验

• 产品供应商和项目维护者：通过设计产品来帮助用户成功使用平台和功能

• 应用和产品开发人员：希望更详细地了解他们对内部平台的期望的平台用户

成熟度模型表格

图源：https://github.com/cncf/tag-app-delivery/blob/maturity-model-v1/platforms-maturity-model/v1/index.md#model-table 

成熟度模型解读

投资：如何为平台能力分配人员和资金？

在平台和平台工程方面的投资（Investment）是指分配预算和人员来构建和维护通用能力的过程。这种做法通常是自下而上构建的，也可以通过自上而下的方法来推动。无论哪种情况，持续的投入都会带来高影响力的工作成果。这个方面涵盖了投资的规模和广度如何影响平台的成功。 

Level 1 初始阶段：自愿或临时 

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

这些能力是由被临时或自愿分配的人构建和维护的，没有专门的预算和人员。它们依赖于用户目前的战术需求。 

Level 2 运营化阶段：专门团队 

预算和人员被分配用于持久的人员和资源支持。分配的人员的任务是提供一组常见的所需能力，以加快软件交付的速度。通常这些团队侧重于满足响应式技术需求。它们可以被称为 DevOps、工程支持、开发者体验（DevEx 或 DevX）、共享工具、卓越中心，甚至是平台。统一为它们提供资金，因此它们被视为成本中心；无法衡量它们的直接价值和对应用团队的影响。 

在这个层面上，很难将平台团队对组织和其价值的影响联系起来，这可能使维持和继续分配预算给这类团队变得困难。 

Level 3 可扩展阶段：作为产品 

对内部平台及其能力的投资类似于对企业对外产品和价值流的投资：基于它们预期为客户提供的价值。产品管理和用户体验得到明确考虑和投资。可能会使用计费系统来反映客户对平台的评价。企业通过使用数据驱动的绩效指标和反馈回路，为相关的举措分配预算和人员。平台团队最终可以优化业务本身，提高盈利能力。 

Level 4 优化阶段：启用生态系统 

平台团队找到了提高整个组织效率和效益的方式，不仅仅只提供基本能力。核心平台维护者有意致力于优化新产品上市时间、降低整个企业的成本、为新服务提供高效的治理和合规性、快速和容易扩展工作负载以及满足其他跨部门需求。这些核心维护人员的工作重点是使能力专家能够将其需求和产品无缝集成到平台的现有部分和新部分中。此外，该组织还集中安全、性能、质量等专业领域的人员和资源，与所提供的平台框架集成，引入高级功能，使产品团队能够加速实现公司目标，而无需依赖于集中的团队积压工作。 

采用：用户为什么以及如何发现和使用内部平台和平台功能？

采用（Adoption）不仅描述了组织如何以及在多大程度上使用平台能力，还描述了驱使他们这样做的原因。在早期阶段，许多目标用户可能根本没有意识到他们正在使用一个平台，而是将他们的工具视为来自各种内部来源的各种能力的临时集合。这可能会逐渐演变成一组能力，这些能力得到一致的管理和呈现给用户，也就是说，一个或多个平台。随着这些能力变得更加精细和易于发现，通常推动平台使用的动力会从更多外部的动机，如法规或激励，转向用户自主选择平台能力，甚至最理想的情况是，他们投入自己的精力到更广泛的平台生态系统建设中。 

上图说明了平台采用的常见增长模式。这表明平台的起步通常比较缓慢，主要由平台建设者推动。一旦平台为用户提供了足够的价值，增长就会更多地由用户拉动，从而形成更陡峭的采用曲线。 

Level 1 初始阶段：不稳定 

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

Level 2 运营化阶段：外部推动 

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

用户对功能的发现以及如何使用这些功能并不熟悉；产品团队的用户可能不会发现某些功能已经得到支持，除非由平台团队指导。 

Level 3 可扩展阶段：自发使用 

在这一级，产品和服务团队的用户自主选择使用平台和其能力，因为它们在减轻产品团队的认知负担，同时提供更高质量的支持服务。文档和符合用户习惯的界面使产品团队用户能够快速配置和使用平台功能。基于此，用户会选择内部平台实施，而不是自行开发或雇佣供应商。 

Level 4 优化阶段：参与建设 

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

接口：用户如何与平台功能互动并使用平台功能？

平台提供的界面影响用户如何与这些平台产品交互，以进行配置、管理和监控。界面可以包括工单系统、项目模板和图形门户，以及可自动化的 API 和命令行（CLI）工具。 

界面的关键特征包括在关键用户流程中（如初始请求、维护或事故排除）其可发现性和用户友好性。成熟度越高，反映出界面的集成性、一致性、自动化和支持程度越高。 

Level 1 初始阶段：定制流程 

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

如何请求这些解决方案的知识是从人与人之间共享的。请求服务的过程缺乏标准化和一致性。配置和使用平台服务可能需要来自能力提供者的深度支持。 

在公司对此尚未存在期望的情况下，由于缺乏核心要求和标准，该级别是合适的。在早期阶段的公司或平台努力中，这可以特别有效。这对处于早期阶段的公司团队或平台工作尤为有效。在这些环境中，团队可以根据自身需要自由发展流程和能力，从而更快地交付成果，并在日后必要时才付出标准化的代价。 

Level 2 运营化阶段：标准工具 

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

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

Level 3 可扩展阶段：自服务解决方案 

提供解决方案的方式是让用户自主，只需维护者提供少量支持。组织鼓励并支持解决方案提供一致的界面，从而实现用户体验从一种功能到另一种功能的可发现性和可移植性。虽然是自助服务，但解决方案确实需要团队意识和实施。为了改善这种体验，可能会有一种指导性的、简化的内部语言，使用户能够更快地采用和集成平台功能。这会生成以用户为中心、可自助服务且一致的功能集合。 

Level 4 优化阶段：集成的服务 

平台功能以透明的方式集成到团队已经用于开展工作的工具和流程中。有些功能是自动提供的，例如已部署服务的可观测性或身份管理。当用户触及所提供服务的边缘时，有机会在不离开内部的情况下超越自动化解决方案并根据自己的需要进行定制，因为平台功能被视为构建模块，内置于透明的自动组合中，以满足更高级别的用例，同时在必要时进行更深入的定制。 

维护：如何规划、排列优先级、开发和维护平台及其能力？

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

值得注意的是，提供功能的大部分工作都是在首次发布后进行的——提供无缝升级、新功能和改进功能、运维支持以及最终用户支持和教育。因此，一个有影响力、有价值的平台需要提前规划并管理其平台，以实现长期可持续运维和可靠性。 

Level 1 初始阶段：根据要求 

平台和能力是根据临时的产品团队请求和需求而被响应式地开发、发布和更新的。甚至可能需要产品团队自己计划和构建所需的能力。 

构建新能力的团队，无论是专门的中央团队还是满足自身需求的应用团队，只对支持他人使用该能力负有非正式的责任。他们不必积极维护它，也几乎没有流程来审查提供的质量。在这个级别，实现通常会被忽视，直到发现安全漏洞、bug 阻止使用或出现新需求，才可能会迅速实施另一个响应式计划。 

Level 2 运营化阶段：集中跟踪 

对平台和能力进行集中记录和发现，至少对能力生命周期的规划和管理流程进行简单定义。每项服务和功能都有文档记录的责任和所有权。根据所有者和优先级的不同，不同功能的生命周期管理流程也会有所不同。一个中央团队负责维护或能够按需生成待办能力清单以及当前能力的维护状态。这使得组织能够跟踪功能的进展情况以及是否符合升级要求。 

Level 3 可扩展阶段：中心化启用 

平台和能力不仅集中记录，而且集中编排。平台团队负责了解组织的广泛需求，并根据平台和基础设施团队的工作来安排优先级。负责某项能力的人不仅需要在技术上维护它，还需要为将该能力与组织内的其他相关服务集成提供标准的用户体验，确保其使用安全可靠，甚至提供可观测性。 

现有用于创建和发展新功能的标准流程，使组织中的任何人都能够贡献满足期望的解决方案。平台功能和特性的持续交付流程支持定期推出和回滚。大型变更的计划和协调与面向客户的产品变更相同。 

Level 4 优化阶段：托管服务 

每项能力的生命周期以一种标准化的自动化方式进行管理。在不影响用户的情况下，持续提供功能、特性和更新。平台提供商发起的任何大型变更都包括针对现有用户的迁移计划，并规定了责任和时间表。 

平台能力提供者承担了大部分的维护责任，但有一个明确的合同——即“共享责任模型”，描述了用户的责任，使双方能够基本自主地运作。 

衡量：收集和采纳反馈与学习意见的程序是什么？

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

Level 1 初始阶段：临时性 

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

Level 2 运营化阶段：持续收集 

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

将反馈转化为可操作的任务仍面临挑战。虽然用户数据的存储量在不断增长，但组织可能需要帮助才能有效理解这些反馈并将其整合到平台建设 Roadmap 中。可能很难确保用户看到由其反馈驱动的切实变化。 

Level 3 可扩展阶段：洞察 

在这个阶段，虽然已经有了健全的标准反馈机制，但数据收集的方式要精雕细琢，以形成具体的战略见解和行动。先确定期望的结果和结果，然后选择标准指标来表明实现这些结果的进展。可以利用行业框架和标准，借鉴有关某些行为影响的行业研究。 

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

Level 4 优化阶段：定量和定性 

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

不仅利用标准框架，而且还认识到从多个角度进行衡量可以获得更全面的信息。需要投入精力了解定性指标如何随着定量指标的改进而变化。重点是确定具有引领性质的衡量标准，从而能够预测支持用户需求的功能，减轻他们面临的挑战，并领先于行业趋势和业务要求。 

总 结

平台是敏捷产品开发的基础框架，它们在软件开发和运维中提供了一致性和效率。这个成熟度模型可以作为规划您的平台之旅的方式。本文仅根据当前内容介绍了模型的主要部分，和最终版本也许存在一些差距，如果您还想了解更多内容和进展可以访问下方链接：

https://github.com/cncf/tag-app-delivery/blob/maturity-model-v1/platforms-maturity-model/v1/index.md

参考链接：https://mp.weixin.qq.com/s/F_BK4uv6FmYe9KR_aC_1dg