了解如何根据 平台工程功能模型确定平台工程工作的目标，演练常见方案，并寻找衡量成功的方法。 通过将目标范围限定为业务目标来衡量成功。
确定目标和关键方案
若要开始，请先使用 平台工程功能模型评估组织目前所处的位置。 使用模型绘制组织跨六项核心平台工程功能的位置：投资、采用、治理、预配和管理、接口以及度量和反馈。 所有组织在某些功能方面都比其他组织更高级。 一旦你知道你的组织今天所处的位置，你可以选择想要增长的功能。 若要了解详细信息，请参阅 评估当前做法并设定未来目标。
可以不断规划和更新平台工程目标。 明确您希望通过投资平台工程旅程获得的成果，这在帮助构建组织支持方面可以大有帮助。
作为一位平台工程主管曾经说过，“除非我能从平台工程中获得收益，否则我不会为平台工程做点什么。” - 彼得，平台工程主管，跨国科技公司。
在考虑目标时，请将其范围限定为与平台工程工作相关的业务目标，而不是特定开发团队的具体内容。 常见的高级平台工程目标包括：
- 提高应用程序质量，并减少发布期间的 bug 和问题。
- 提高安全性，减少进入生产环境后发生的安全事件或检测到的常见漏洞与暴露风险（CVE）的数量。
- 通过在许可、辅助功能、隐私或政府法规等领域更好地合规，降低风险。
- 通过降低复杂性和开销，并通过内部开源实践促进代码共享，从而加速实现商业价值。
- 降低开发或运营成本，最大程度地减少重复，并改进自动化。
选择首要目标至关重要，因为目标会推动你思考优先级的方式。
更好的是，与你的领导和内部合作伙伴就 目标和关键结果（OKR） 达成一致有助于为投资的当前阶段制定可衡量的目标。 如果你的组织使用其他方法，那么其他规划方法也有类似的概念。最好的 OKR 是那些可以基于具体度量标准设置的，因为这样能够消除主观性。
要完成的方案和作业
确定目标后，选择关键场景以推动待办事项和项目路线图。 例如，请参阅以下方案和要完成的关联作业。
方案：开始生成新应用程序
- 了解并应用组织最佳做法和策略
- 创建新存储库
- 配置工具
- 预配通用基础结构
- 授予团队成员访问权限
- 建立 CI/CD 流水线
- 配置开发基础结构
- 用于测试“管道”的初始部署
方案：向现有团队添加或删除新成员
- 更新对工具和服务的访问权限
- 设置开发人员计算机
- 在应用程序上增加团队成员
- 创建应用程序沙盒环境
- 首先创建拉取请求，然后进行审查
方案：为现有应用程序添加或更新基础结构
- 了解组织最佳做法、可用选项
- 更新或添加基础结构作为代码项目
- 创建应用程序沙盒环境
- 验证更新
- 向其他环境推出更改
方案：为现有团队添加或更新工具
- 了解组织最佳做法、可用选项
- 请求使用新工具
- 更新团队成员对工具的访问权限
- （如果适用）将工具集成到客户端或 CI/CD 管道中
方案：查找或重用现有 API、SDK 或服务
- 发现可用的 API、SDK 或服务
- 评估它是否符合需求
- 与拥有团队联系以解答任何问题
- 采纳用于应用
场景：响应运营事件
- 问题通知
- 评估是否与应用代码或基础设施相关，或两者皆相关。
- 创建镜像 prod 的沙盒环境（如果不同）
- 进行更改、测试、带外发布
方案：快速修正安全事件
- 问题通知书
- 评估问题广度（哪些系统）
- 了解客户是否直接受到影响
- 创建镜像 prod 的沙盒环境（如果不同）
- 进行更改、测试、带外发布
- 与受影响的任何人通信
方案：弃用工具
- 了解工具使用情况
- 通知用户弃用
- （可选）协调用户迁移到新工具
方案：发布新应用架构模型
- 试点建议的体系结构
- 根据试点结果进行调整
- 更新最佳做法文档
- 创建模板、更新自动化、策略和治理
审核应用程序符合性（GDPR、辅助功能、基础结构标准）
- 了解当前的符合性规则
- 验证应用程序是否满足规则
- 为偏差的修复建立截止时间
- 进行更改、测试、发布
许多方案适用于多个角色。 考虑如何衡量改进的指标。
从问题到概念
接下来，了解开发人员和其他角色面临的最大问题，以及你确定的方案和作业。 开始研究新产品以填补感知到的空白可能很诱人，然而，如果这些产品不能解决一个主要的难题，它们不太可能被广泛采用或受欢迎。
有多种方法可以帮助你进行此类调查，例如 假设进展框架。 即使你没有使用诸如假设进展框架这样的正式过程，你也应该采访开发人员，以确定讨论的范围并找出他们在完成工作中面临的最大问题。 一旦你对这些问题有很好的了解，继续提出解决这些问题的计划。 这有助于确保生成开发人员想要使用的功能。
若要快速重复此过程，请确定可以直接在内部开发人员平台团队中代表客户的声音的人员。 此角色通常称为产品经理（即使他们拥有不同的职务），随着知识的增长，他们能够准确预测较小决策的结果，并确定何时需要做更多的面试。 这样可以提高敏捷性，同时确保专注于为内部客户提供价值。
为初始投资进行论证
一旦有了一组经过验证的问题和概念，就可以确定投资地点。 但是，请考虑评估解决方案时所需的前期投资和长期维护。 从最轻松的方案开始解决问题往往是正确的做法，但通常决定投资成功与否的在于后续的维护工作。
换句话说，不要创建面向旅程后期阶段的解决方案，除非你真的需要。
确定 最薄可行的平台（TVP）（ 例如平台 的最低可行产品 ）后，请与一组愿意提供反馈的开发团队进行试点。 如果你的试点解决方案解决了这些团队面临的问题，你不应该很难找到有兴趣参与的人。
在试点新功能或更改时，应捕获一些关键指标，以便衡量概念在推出之前是否成功。
衡量成功并证明价值
衡量成功是产品思维模式的重要组成部分。 即使是投资适度的小成功，也为更大的投资奠定了基础。
例如，对于合规工作，很难获得资金或支持，因为它们可以被视为对提供业务价值的开发团队的额外负担。 产品思维模式可以改变这种感知。 通过产品思维模式，你正在努力确保内部开发人员平台的客户满意，并满足利益干系人的业务目标。 指标使你能够使用事实来证明你提供业务价值。 设置 OKR 可以帮助，特别是如果你有指标，你可以使用这些指标来帮助消除主观偏见。 即使你目前未测量任何适用内容，也可以设置学习 OKR 来设置一个基线，然后在此基线已知后进行优化。
下面是可以衡量的已知指标示例，以确定你正在使用的团队是否正在从所构建的内容中获取价值。 集中于能帮助你衡量你和你的开发团队客户是否正在实现目标的关键指标。 例如，下面是一组指标，可帮助你评估平台是否为有效的工程组织做出贡献：
- 业务价值的速度/时间：完成第一个拉取请求的中位数天数（载入）、构建和测试流程的中位数分钟数（例如：CI）、合并拉取请求的中位数时间。
- 软件质量：每个开发每月创建的事件（按开发数规范化为数量）、 平均恢复时间（MTTR）、调查和修正安全问题的时间。
- 平台易用性： 净用户满意度（NSAT）
- 蓬勃发展的生态系统：以下每一个被调查的问题的平均分数：“我有权尽我最大的努力”，“大多数日子我都精力充沛的工作，”我所做的工作对我有意义。
然后，可以按组织、团队或项目细分这些指标。 你需要测量一些基线才能开始，但你可以在改进平台时查看这些指标的变化。
你或发起人可能感兴趣的其他指标包括：
| Area | 示例指标 |
|---|---|
| 软件交付性能 | DevOps 研究和评估（DORA）：变更交付周期、部署频率、变更失败率、平均修复时间（MTTR） |
| Operations | DORA (MTTR)，故障间平均时间 (MTBF)，平均确认时间，终端客户可用率，延迟，吞吐量指标，每个团队成本，每次部署成本 |
| 平台功能采用指标 | 一段时间内使用工具或功能的团队或开发人员数、使用平台的存储库百分比、最常用的模板、管道等。 |
收集指标需要时间和精力，因此请务必专注于确定的核心目标的关键指标，尤其是为 OKR 提供支持的关键指标。 基于 OpenTelemetry 的产品（如 Application Insights）可以帮助。
请务必定期测量平台的易用性，并检查确保您的生态系统蓬勃发展。 对于内部系统，这些指标常被忽视且是衡量你是否达到更广泛业务目标的关键指标，因为积极的参与对于成功至关重要。 它还有助于了解是否是时候进行进一步的客户开发，以了解下一步要去哪里。
其他提示
无论如何开始，请记住，你应该计划更改，从试点的新应用程序开始，专注于增强现有用户体验，采用最低特权原则，规划受控试验，并最小化自定义。
应对变化的计划
目标应用程序平台会随着时间的推移而发展，你可能无法一次性迁移所有现有投资。 思考如何随时间推移支持多个变体并计划更改。
使用较新的应用程序验证想法
在试点新平台或平台功能时，从大小合理的新应用程序开始。 这还可以让你获得将平台作为产品来管理的经验。 避免一开始就进行平台迁移项目，因为在迁移过程中你会不断学习，而大型现有的应用程序往往有独特需求，且这些需求只有在平台迁移工作进行时才会被发现。 因此，将您的成功与这些类型的努力关联起来可能会导致预期不匹配或突发性问题。 从较新的东西开始，你可以对方向和它提供的价值充满信心。 这降低了应对这些更大努力的风险。 换句话说，如果你相信大家可以正确开始并保持正确，那么借鉴你的经验推动一个正确的方案会变得更加容易。 如果此方法不可行，需要仔细分析、设置预期并逐步介入，而不是尝试一次性更改所有内容。
在创建新用户体验之前，请专注于现有的重心
开发人员更可能采用并坚持使用新功能，当这些功能呈现在他们已经喜欢和使用的内容中时。 评估概念以提供新功能时，请务必调查采用扩展现有 重力中心的选项。 例如，编辑器/IDE（Visual Studio、VS Code）、DevOps 套件（GitHub、Azure DevOps）、现有 CLIS 或现有内部门户比全新的门户或其他 UX 更有效。 若要了解详细信息，请参阅 用户体验。
假定最低特权原则
假设开发人员对下游系统的访问权限有限，例如配置基础设施。 你需要一种受控的方式来为自助服务体验启用此访问。
规划受控试验
在推出重大或有风险的更改之前进行试验。 并非所有事物都必须完全自动化才能开始。 自动触发的手动工作流是试点理念的好方法。
最小化应用平台自定义
避免自定义构建应用程序平台功能，这些功能可由软件供应商随时间推移发布的功能所掩盖。 例如，运行时托管、服务网格、标识系统等。 如果在您怀疑可能存在类似情况的某个区域中发现紧急需求，请为多种实施方案做好计划，因为长期维护可能会导致您随着时间的推移而进行切换。