以下文章是CNCF平台白皮书的Gemini翻译版本。
原文: https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/
云原生计算基金会 (CNCF) 平台工作组发布
版本 1.0.0 | 2023年10月31日发布
1. 引言 (Introduction)
CNCF 最初的《平台定义白皮书》阐述了云计算的内部平台是什么，以及它为企业带来的价值。然而，为了实现这些价值，组织必须反思并有意识地追求具有影响力的成果和实践。务必记住，每个组织都依赖于为其自身需求精心打造的内部平台，即使它仅仅是关于如何使用第三方服务的文档。本成熟度模型为这种反思提供了一个框架，并帮助所有组织识别改进的机会。
2. 什么是平台工程？ (What is platform engineering?)
受 DevOps 所承诺的跨职能协作的启发，平台和平台工程作为这种协作的明确形式在企业内部兴起。平台筛选并提供通用的能力、框架和经验。本工作组及相关出版物的重点在于那些能够促进和加速产品和应用团队等内部用户工作的平台。
平台工程是将这些计算平台规划并交付给开发者和用户的实践，它涵盖了平台的所有组成部分和能力（人员、流程、政策、技术以及推动这些的业务成果）。为了全面理解其背景，请务必首先阅读 CNCF 平台定义白皮书。
3. 如何使用此模型 (How to use this model)
在过去几年中，随着平台工程的兴起，一些模式变得清晰。通过将这些模式和观察结果整理成一个渐进的成熟度模型，我们旨在指导平台团队应对他们可能面临的挑战以及应该追求的机会。
每个方面（Aspect）都被描述为一个连续体，展示了不同团队和组织在每个级别内的特征。读者将能够在此模型中找到自己的位置，并识别相邻级别中的机会。
注意事项：
- 更高的成熟度级别需要更多的资金和人力时间。因此，达到最高级别本身不应成为目标。
- 读者应考虑其组织和当前背景是否能从该级别特征中受益，并权衡所需的投入。
- 每个方面都应独立评估和发展。然而，它们之间错综复杂地相互关联，改进一个方面可能需要其他方面也达到最低限度。
- 评估您组织当前的云原生转型状态。为此，建议利用“云原生成熟度模型”。
Martin Fowler 曾说：“成熟度模型评估的真正结果不是你处于哪个级别，而是你需要为改进而努力的清单。你当前的级别只是确定接下来要掌握的技能清单的中间工作。”
4. 本工作的背景 (Context behind this work)
目标受众 (Intended audiences)
- CTO、副总裁、技术总监：规划数字化转型和提高开发者生产力路径的领导者。
- 工程经理：旨在赋能工程师以低开销和高效率交付价值的团队。
- 企业架构师：寻求对技术问题采取价值和解决方案驱动视角的个人。
- 平台工程师和平台产品经理：致力于为平台构建者和用户创造最佳体验的团队。
- 产品供应商和项目维护者：旨在设计工具和信息以帮助用户通过平台取得成功的组织。
- 应用程序和产品开发者：希望详细了解内部平台能提供什么的最终用户。
理解级别 (Understanding the levels)
本模型并非旨在将组织完全归类为“级别 1”或“级别 4”。每个方面都应独立考虑。编号较低的级别包含更多战术性（Tactical）解决方案，而编号较高的级别则更具战略性（Strategic）。这类似于典型的数字产品开发流程：问题识别 → MVP 开发 → 迭代和适应性确认 → 扩展和优化。
5. 模型摘要表 (Model table)
| 方面 (Aspect) | 级别 1: 临时 (Provisional) | 级别 2: 运营 (Operational) | 级别 3: 可扩展 (Scalable) | 级别 4: 优化 (Optimizing) |
| — | — | — | — | — |
| 投资 (Investment) | 自愿或临时 | 专属团队 | 作为产品管理 | 活跃生态系统 |
| 采用 (Adoption) | 不规律 | 外部推动 (Push) | 内部吸引 (Pull) | 参与式 |
| 接口 (Interfaces) | 定制流程 | 标准化工具 | 自助服务解决方案 | 集成服务 |
| 运营与测量 (Operations & Measurement) | 按需处理 / 临时措施 | 集中跟踪 / 一致收集 | 集中赋能 / 洞察生成 | 托管服务 / 定量和定性测量 |
## 6. 模型详情 (Model Detail)
6.1 投资 (Investment)
如何将员工和资金分配给平台能力？
- 级别 1, 临时 – 自愿或临时：能力是根据需要构建的，没有计划或有意的资金支持。由临时分配人员或志愿者维护，依赖于用户即时的战术需求。
- 特点：为紧急需求运作“老虎团队”，改进工作被视为“锦上添花”。员工因本职工作之外的工作量而抱怨倦怠。
- 级别 2, 运营 – 专属团队：为持续支持分配预算和人员。任务是提供通用能力以加速软件交付。主要关注响应式技术需求，被视为成本中心，对价值流的影响未被衡量。
- 特点：由技术通才组成，团队预算包含基础设施成本，成为预算讨论的焦点。缺乏时间或经验进行用户研究。
- 级别 3, 可扩展 – 作为产品：像投资外部销售产品一样投资平台。明确投资于产品管理（PM）和用户体验（UX），使用数据驱动的指标和反馈循环来分配资源。
- 特点：引入PM、UX等传统技术团队中没有的角色，内部路线图公开。功能移除（Feature removal）也成为重要的讨论主题。
- 级别 4, 优化 – 活跃生态系统：平台团队超越基本能力，寻求最大化整个组织的效率。核心维护者专注于帮助安全、性能专家直接贡献于平台框架，扩展其功能。
6.2 采用 (Adoption)
用户为何以及如何发现和使用内部平台？
- 级别 1, 临时 – 不规律：共享平台的采用是零星且不一致的。没有组织层面的战略，团队认为外部工具比内部工具更有效。
- 特点：一次性工具泛滥，云服务在没有标准政策的情况下随意使用，工具发现依赖于口耳相传。
- 级别 2, 运营 – 外部推动 (Push)：组织认识到共享平台的价值并鼓励采用。绩效考核或资金条件等外部指令强制或激励使用。
- 特点：能力利用碎片化，用户学习平台意愿低，严重依赖帮助台。
- 级别 3, 可扩展 – 内部吸引 (Pull)：用户因认知负荷降低和高质量的明确价值而自愿选择平台。
- 特点：采用自发发生，用户对一项能力满意后会寻找其他能力。黄金路径模板和自助服务门户使快速使用成为可能。
- 级别 4, 优化 – 参与式：用户加入平台生态系统并直接贡献（Contribution）。他们修改现有功能或为新用例直接添加功能。
- 特点：通过问题板或PR异步增强功能，开发者布道师支持内部社区。
6.3 接口 (Interface)
用户如何与平台能力进行交互和消费？
- 级别 1, 临时 – 定制流程：存在各种不一致的流程，依赖于手动干预。知识在个人之间口头共享，缺乏标准化。
- 级别 2, 运营 – 标准化工具：存在一致的标准接口以满足广泛需求。以文档和模板形式提供“铺设好的道路（Paved roads）”或“黄金路径”。
- 级别 3, 可扩展 – 自助服务解决方案：用户无需维护者支持即可自主使用。通过引导式内部语言等方式抽象复杂性，提供“一键式”实现。
- 级别 4, 优化 – 托管服务：平台能力透明地集成到团队已使用的工具和流程中。可观测性或身份管理在部署时自动配置。以可深度定制的构建块形式提供。
6.4 运营 (Operation)
平台能力如何进行规划、优先级排序、开发和维护？
- 级别 1, 临时 – 按需处理：根据产品团队的零星请求被动开发。仅关注初始交付，缺乏持续维护或安全补丁计划。
- 级别 2, 运营 – 集中跟踪：能力集中文档化并可被发现。明确服务所有权，中央团队管理待办事项以跟踪维护状态。
- 级别 3, 可扩展 – 集中赋能：平台团队理解并优先处理组织的广泛需求。存在标准流程，任何人都可以贡献解决方案，并通过持续交付（CD）部署更新。
- 级别 4, 优化 – 托管服务：所有能力的生命周期都以标准化和自动化的方式进行管理。更新持续交付且不影响用户，并存在明确的“共享责任模型”。
6.5 测量 (Measurement)
收集和整合反馈与学习的流程是什么？
- 级别 1, 临时 – 临时措施 (Ad hoc)：很少收集使用量或满意度指标，决策基于零星需求和不完整数据。
- 级别 2, 运营 – 一致收集：重视结构化收集用户反馈。问卷调查和论坛标准化，用户体验通过数据进行衡量。
- 级别 3, 可扩展 – 洞察生成：以复杂的方式收集数据，以获取特定的战略洞察。利用行业框架（如 DORA）衡量绩效并反映到路线图中。
- 级别 4, 优化 – 定量和定性测量：反馈和测量深度融入组织文化。数据民主化，所有利益相关者参与假设制定和验证，并理解定性变化如何与定量指标改进相关联。
7. 结论 (Conclusion)
平台及其维护者为敏捷数字产品开发提供了基础。它们提供了一套一致的能力，从而实现高效的软件开发和改进。本成熟度模型将成为您平台工程之旅的指南。
发表回复