平台工程功能模型
平台工程是一场旅程。 一种渐进的迭代方法通常比尝试大规模、立即实施或完全依赖自上而下的任务更有效。 增量进度，从最少可行的产品 (MVP) 开始，团队可以在一段时间内优化其方法，同时在过程中整合反馈。
平台工程生命周期表示一种结构化方法，用于确保平台可靠、可缩放且持续改进。 此生命周期包含不同的阶段，每个阶段都有助于平台的长期成功。
生命周期的一个重要要素是平台工程功能模型，该模型提供一个全面的框架，用于评估、规划和实施平台工程工作。 该模型概述生命周期的每个阶段所需的成熟度级别、最佳做法和关键功能，确保与组织目标和用户需求保持一致。
该模型概述跨五个阶段趋于成熟的平台工程实践的进度：初始、可重复、定义、托管和优化。 在初始阶段，组织的结构有限，采用临时流程，并且在平台功能方面投入极少。 随着它们进入可重复阶段，基本流程出现，但采用和管理方面仍然不一致。 定义阶段标志着明确标准和流程的建立，用户开始有意识地采用平台解决方案。 在托管阶段，平台会受到主动管理，资源得到有效预配和管理，用户交互通过标准化接口保持一致。 最后，在优化阶段，平台通过可靠的反馈机制、度量的结果以及符合用户需求和组织目标的自适应功能不断改进。
根据以下六项功能评估模型：投资，反映资源和资金的分配；采用，侧重于用户发现和利用；治理，确保资源可访问性、成本控制和数据/IP 保护；预配和管理，定义资源的部署和维护方式；接口，解决用户与平台的交互问题；度量和反馈，通过性能指标和用户见解强调持续改进。 这些功能与 Cloud Native Computing Foundation 平台工程成熟度模型 概述的关键领域紧密配合，并反映组织平台工程成熟度的水平。
若要使用平台工程功能模型，请首先评估组织目前在六个功能领域的状态。 可以手动执行此评估或完成 平台工程功能模型调查。 确定当前阶段后，为增长设定未来目标，并绘制组织每个功能的进度图表。 进度不需要同时在所有功能之间发生。 专注于对你的组织最有意义的领域。
投资
随着投资能力发展到不同阶段，其重点是如何向平台功能分配员工和资金，重点关注预算和人员配置、范围管理和衡量投资回报 (ROI)。
- 初始（自愿）：平台能力因需求而生，由个体工程师出于自愿，为解决当下战术需求所推动。 预算和人员配备最少，通常没有资金，并与现有职责一起执行。 解决方案的范围很窄，针对特定问题展开工作，但团队间知识共享有限。 ROI 通过解决直接要求的有效程度及其对核心项目结果的影响来衡量。
- 可重复（临时贡献）：专属团队开始应对反复出现的挑战，例如不一致的预配或安全漏洞，但相关工作在很大程度上仍处于被动应对状态。 预算和人员配备仅限于横切关注点，全组织范围内授权受限。 范围管理侧重于不涉及更广泛的平台范围的特定问题。 通过解决关键挑战（例如积压工作减少）的改进来衡量 ROI。
- 定义（操作化-专属团队）：出现集中提供资金的平台团队，专注于加快软件交付和满足技术要求。 领导层开始促进协作并实施初始 DevOps 做法，但衡量团队价值仍存挑战。 中央团队的预算和人员配置已正式确定，以满足技术需求。 解决方案变得更加广泛，解决跨团队的共同挑战，不过关注点仍放在短期上。 ROI 通过交付速度的提高来衡量。
- 托管（可缩放-作为产品）：发生文化转变，将开发人员视为客户，领导层强调共情和产品主导的方法。 平台团队像产品团队一样运营，由开发人员、产品经理和用户体验专家组成。 范围管理与产品路线图保持一致，由工程团队协作审查，以满足组织范围内的需求。 ROI 通过增强的开发人员满意度进行评估，反映持续改进，并与用户需求保持一致。
- 优化（已启用生态系统）：投资侧重于创新，保持平台相关性，并在整个组织中鼓励贡献。 平台团队引入了高级功能，例如安全性和性能增强功能，使产品团队能够在不依赖于集中积压工作的情况下进行构建。 预算范围超出了中央团队，整个组织都有可用资金。 范围管理强调实现快速、组织范围内的知识共享。 ROI 通过开发人员满意度的持续改进来衡量。
采用
采用功能侧重于用户如何发现和使用平台工程解决方案及其产品/服务，通过服务、工具和技术的发现、选择和使用来体现。 随着组织成熟，采用的方法从非正式和零星的使用转向更结构化和更有参与性的模型，用户积极参与平台，助力其演变。 此进展反映用户发现、决策和使用实践随时间的变化，从初始非正式发现到完全参与平台开发。
- 初始（非正式）：采用不一致，团队无需组织范围的协调即可独立改进流程。 外部工具通常优先于内部工具。 平台是以非正式的方式被发现的，主要是通过口碑或偶然发现，工程团队根据他们的特定需求选择服务。 每个团队维护自己的脚本和工具，以满足其独特的要求。
- 可重复（强制）：组织强制要求使用共享平台，但功能仅限于常见用例，因此难以满足异常要求。 用户发现依赖于平台团队指引，通常通过内部文档或指令来指引。 团队可以通过与平台团队进行非正式讨论来选择强制服务。 尽管围绕平台标准构建了流程，但团队可能无法完全采用它们，或者对结果不满意。
- 定义（播发）：平台功能得到积极推广，符合团队需求。 平台团队与工程团队协作，提供可降低运营开销的高质量服务。 但是，由于依赖过时的做法和技术债务，一些团队仍可能会获得较低的 ROI。 团队通过涵盖典型用例的指令发现功能，平台团队通过协作鼓励使用。 对平台使用的推广也会通过团队大使以非正式的方式进行。
- 托管（价值驱动）：产品团队识别并选择平台功能，因为它们在减少认知负载和提供高质量服务方面具有显著价值。 平台受广泛的文档、人体工学接口和自助服务 UX 支持，以便快速预配。 团队现在更喜欢内部平台，而不是自行构建或依赖外部提供商构建解决方案。 发现和决策得到简化，团队使用模板、论坛和文档来完全支持平台采用。
- 优化（参与）：产品团队通过建议新功能和修补程序，积极帮助改进平台功能。 已制定相关流程，以便用户可确定要求并协作提供帮助。 开发人员倡导者和大使培育内部社区，将平台归属感扩展到参与者。 平台工程师与产品团队密切合作，了解需求并建议新功能，使用户能够提交拉取请求并参与评审。
治理
随着治理功能的发展，其重点是确保用户有权访问他们需要的资源和功能，同时管理成本、数据和知识产权。 此进展基于多个类别进行评估，包括定义策略和框架、实施策略、监视和减少合规性风险以及管理访问权限。 治理从手动和被动应对过程演变为集成的预测系统，该系统将集中控制与自适应管理进行平衡，以满足不断变化的需求。
- 初始（独立）：治理是手动进行，依赖于集中式控制和把关，这会阻碍可伸缩性。 开发人员和安全团队独立工作，被动应对策略违规行为。 合规性以最低标准进行维护，安全措施通常事后添加。 无需标准化过程即可根据即时需求授予访问权限。
- 可重复（记录）：组织开始记录和共享策略，但这些策略很基础，且执行起来缺乏一致性。 引入了票证系统等治理工具来管理策略评审，但该过程仍为手动，进程缓慢。 审核过程已建立，但仍是被动反应。 某些角色和权限已标准化，但执行仍然不均衡。
- 定义（标准化）：治理变得集中和标准化，以提高所有团队的一致性和效率。 策略得到记录并集中管理，实现过程具有某种程度的自动化。 关键治理标准通过定期审核得到维持，访问控制通过正式的 RBAC 系统自动执行，不过开发团队对策略更改的控制依然有限。
- 托管（集成）：安全性和合规性无缝集成到工作流中，自动化可确保策略在系统和团队中得到一致的应用。 实时监视和高级分析有助于检测和预防治理漏洞。 策略嵌入到 CI/CD 管道中，访问管理受最低特权原则的约束，并采用自动评审，确保采取更主动和集成的治理方法。
- 优化（预测）：治理变得动态且具有情境感知能力，能够响应不断变化的条件，并优化访问控制。 预测分析有助于在发生潜在风险之前识别风险，从而实现主动减少风险。 使用高级分析持续优化策略，并根据实时因素（如用户位置和访问时间）动态调整访问控制，确保合规性，同时启用定制的工作流。
预配和管理
借助预配和管理功能，重点介绍用户如何创建、部署和管理资源。 该过程从手动的孤立操作演变为自适应自动化系统，在灵活性与治理之间取得平衡，确保在满足合规性要求的同时高效预配资源。 这一发展进程涵盖多个阶段，这些阶段按确定预配过程、响应和管理请求以及监视资源分配来分类。
- 初始（手动）：开发人员根据 IT 或体系结构团队的指导手动设置基础结构，导致不一致和延迟。 如果没有标准化流程，请求将手动审查，从而增加错误的风险。 随着需求的增长，这种方法变得不可持续，孤立的操作造成效率低下。
- 可重复（协调）：组织开始使用票证系统管理基础结构请求，以集中预配过程。 虽然仍需要手动审批，部分错误有所减少，但瓶颈仍然存在。 各团队开始使用标准工具来监视资源，尽管视图仍然孤立且特定于项目。
- 定义（已铺设）：整个组织采用基础设施即代码 (IaC) 将资源调配流程正式化，将模板和工具标准化。 通过结构化工作流处理请求，但平台团队可能难以满足不断增长的需求。 集中式仪表板允许监视资源分配，从而提供更好的性能见解。
- 托管（自动化）：预配将自动化并集成到 CI/CD 管道中，最大限度地减少手动工作，并确保一致的部署。 治理和合规性检查嵌入到工作流中。 自动化自助服务功能允许用户在受控参数内预配资源。 缩放基于使用模式自动进行，以优化性能。
- 优化（自适应）：预配变得自适应，使用智能系统实时预测基础结构需求。 此方法可确保高效资源分配，同时保持治理和合规性。 系统主动处理请求，平衡灵活性与治理，同时通过预测分析优化性能和成本效益。
接口
在接口功能中，主要考虑因素是用户如何与平台服务和产品进行交互和使用。 其改进侧重于建立标准、提高用户自主性，并将平台功能无缝集成到现有工作流中。 该方法从不一致的手动流程演变为自助服务集成系统，从而提高用户体验和运营效率。
- 初始（自定义进程）：用户通过各种不一致的自定义流程与平台交互，这些流程可满足即时需求，但缺乏标准化。 工程师通过咨询同事或依赖个人实践来独立设置环境，他们选择工具和流程来诊断应用程序行为，而无需任何既定准则。 知识共享是非正式的，因为缺乏正式化的过程，预配服务通常需要提供商的深入支持，这限制了可伸缩性和效率。
- 可重复（本地标准）：工程师和团队开始以非正式的方式定义标准以增进高知识共享，尽管由于依赖个人承诺，一致性仍然面临挑战。 某些团队可能会使用文档或容器来定义其设置过程，但这些做法会随着时间推移而出现分歧，需要努力协调统一。 在团队内部，诊断应用程序行为变得更加标准化，不过在获取已部署资源方面，部分依赖于 DevOps 团队或 IT 团队。 虽然本地标准出现，但它们的定义仍然较为宽松，并且在各个团队之间缺乏一致性。
- 定义（标准工具）：随着引入标准化工具和书面规范做法，接口变得更加一致。 中央团队管理模板和文档，使用所谓的铺设好的道路或黄金路径来指导如何预配和观察能力。 这些工具和流程满足广泛的组织需求，不过往往仍需专家支持。 各团队可能会修改模板，但更改并不总是能集中整合回去，这可能会在保持一致性方面导致一些效率低下的问题。 诊断应用程序行为遵循标准化的做法来访问和分析已部署的资源，从而在团队之间提供更高的一致性。
- 托管（自助服务解决方案）：该平台通过提供只需最少的维护人员支持的自助服务解决方案，实现更大的用户自主性。 用户可以访问一致的易于使用的界面，这些界面允许他们发现和修改模板，从而创建一个以用户为中心的环境，提高可用性。 通过平台按需提供用于诊断应用程序行为和观察资源的工具，确保用户拥有所需的资源，无需严重依赖外部团队。 通过发现和修改模板促进知识共享，从而提高平台功能的价值。
- 优化（集成服务）：平台功能无缝集成到团队已使用的工具和流程中，例如 CLI 或 IDE，使其成为用户工作流的自然组成部分。 某些功能会根据用户需求自动预配，平台为更高级别的用例提供灵活的构建模块，这些模块可能需要更深入的自定义。 平台团队持续评估哪些功能最有效，以此指导进一步投资以优化平台产品/服务。 平台会自动为已部署的应用程序设置可观测性，提供对诊断数据的实时访问，并简化监视和管理应用程序行为的过程。
度量和反馈
度量和反馈功能涉及收集、分析和整合指标与反馈，以评估平台工程做法是否成功。 其成熟度体现在从临时和非正式的方法转变为积极主动、数据驱动的文化。在这种文化中，反馈和见解集成到持续改进流程，指导战略决策和平台开发。
- 初始（临时）：在初始阶段，度量和反馈过程不一致且碎片化。 指标的收集与组织目标缺乏明确的一致性，导致数据不完整且不可靠。 反馈以非正式方式收集，且往往基于传闻，利益相关者参与度极低。 因此，基于有限的信息做出决策，很难衡量平台工程实践的真正 ROI。 反馈和结果的文档很少，从中获得的经验教训也极少被留存或分享。
- 可重复（结构化进程）：建立基本的反馈机制（如调查或论坛），可以更系统地捕获用户体验，但这些流程在不同团队之间仍然有所不同。 成功的度量通常侧重于基于活动的指标，如部署或时间线，提供对性能的一些见解，但缺乏更广泛的基于结果的视角。 反馈仍然是非正式和自下而上的，不过它开始影响规划。 做出了一些努力让利益干系人参与，但这种努力仍然有限，创建了流程和反馈的初始文档，但并不全面或未一致利用。
- 定义（一致）：反馈收集变得更加正式化和标准化，从而得以更深入地了解用户需求和关键指标。 衡量指标转向基于结果的度量，如开发人员的工作效率，不过将它们与财务业绩挂钩依然颇具挑战。 反馈分析是系统性的，同时使用定性和定量方法，以及 DORA（DevOps 研究与评估是一套指标，用于衡量软件交付性能，包括潜在时间、部署频率、平均还原时间和更改失败率）或 SPACE（满意度和福祉、性能、活动、通信和协作、效率，是用于衡量这五个维度中的开发人员工作效率的框架）等标准指标。 与跨职能团队定期举行的评审会议可确保利益干系人积极参与。 在各个团队之间维护和共享反馈流程、结果和经验教训的综合文档。
- 托管（见解）：在此阶段，反馈机制和度量框架是稳健的，侧重于战略业务成果。 数据驱动的见解指导平台操作，反馈集成到平台路线图中，从而推动持续改进。 使用高级分析来评估平台对业务成果（例如收入增长）的影响，同时将反馈与性能指标关联，以确定战略改进的关键领域。 整个组织的利益干系人都深入参与反馈过程，通过结构化协作来避免信息孤岛。 实时动态文档反映持续收到的反馈以及汲取的经验教训，所有利益相关者均可查阅。
- 优化（主动）：反馈和度量流程紧密集成到组织的文化中，为预测和适应未来的挑战和机遇创造了积极主动的方法。 预测分析和高级指标用于预测未来的需求和机会，使平台能够持续发展，以响应不断变化的条件。 反馈完全集成到持续改进周期中，并在组织的各个层级建立反馈文化。 动态实时文档反映正在进行的反馈，并不断更新，确保所有利益干系人共享和访问获取的经验教训。