规划和确定优先级

了解如何确定平台工程工作的目标、演练常见方案，并寻找衡量成功的方法。 可以通过将目标范围限定为业务目标来衡量成功。

确定目标和关键方案

正如平台工程主管曾经说过的，“在我有一些东西可以从中获得之前，我不会为平台工程做一些事情。” – Peter，跨国科技公司的平台工程主管

与其查看功能或功能的死记清单，不如先确定平台工程工作的目标。 你可以不断计划和更新一段时间的目标。 但是，明确希望从投资平台工程旅程中获得什么，这在帮助构建组织支持方面大有帮助。

在考虑目标时，请将其范围限定为与平台工程工作相关的业务目标，而不是特定开发团队的具体情况。 例如，下面是一些常见的高级平台工程目标：

• 提高应用程序质量，减少发布期间的 bug 和问题。
• 提高安全性、减少安全事件数，或一旦在生产环境中检测到的 CVE 。
• 通过在许可、辅助功能、隐私或政府监管等领域提高合规性来降低风险。
• 通过降低复杂性和开销，并通过 内部源 实践促进代码共享，加速实现业务时间价值。
• 降低开发或运营成本，最大程度地减少重复，并改进自动化。

虽然所有这些目标都可能是长期目标，但选择首要目标至关重要，因为这会推动你如何看待优先级。

更好的是，与领导层和内部合作伙伴就 OKR () 的目标和关键结果 达成一致，可以帮助你为当前阶段的投资制定可衡量的目标。 (如果组织使用其他方法，则其他计划方法具有类似的概念。) 最佳 OKR 是可以基于具体度量值设置的方法，因为它消除了主观性。

要执行的方案和作业

确定目标后，确定将用于推动积压工作和路线图的关键方案。 例如，请参阅这些方案和要完成的作业。

场景：开始生成新应用程序

• 了解并应用组织最佳做法和策略
• 创建新存储库
• 预配工具
• 预配通用基础结构
• 为团队成员授予访问权限
• 建立 CI/CD 管道
• 预配开发基础结构
• 用于测试“管道”的初始部署

场景：向现有团队添加/删除新成员

• 更新对工具、服务的访问
• 设置开发人员计算机
• 提高应用程序团队成员的力度
• 创建应用程序沙盒环境
• 创建并查看第一个 PR

方案：为现有应用程序添加/更新基础结构

• 了解组织最佳做法和可用选项
• 更新/添加基础结构即代码项目
• 创建应用程序沙盒环境
• 验证更新
• 向其他环境推出更改

场景：为现有团队添加/更新工具

• 了解组织最佳做法和可用选项
• 请求使用新工具
• 更新团队成员对工具的访问权限
• (如果适用，) 将工具集成到客户端或 CI/CD 管道中

方案：查找/重用现有 API、SDK 或服务

• 发现可用的 API、SDK、服务
• 评估它是否满足需求
• 如有任何问题，请与拥有团队联系
• 为应用程序采用

场景：响应操作事件

• 问题通知
• 评估应用代码或基础结构相关的 (或两者)
• 创建沙盒环境，以镜像生产 (（如果) 不同）
• 进行更改、测试、带外发布

场景：快速修正安全事件/常见漏洞和披露 (CVE) 通知

• 问题通知
• 评估系统) (问题的广度
• 了解客户是否直接受到影响
• 创建沙盒环境，以镜像生产 (（如果) 不同）
• 进行更改、测试、带外发布
• 与受影响的任何人沟通

场景：弃用工具

• 了解工具使用情况
• 通知用户弃用
• (可选的) 协调将用户迁移到新工具

场景：定义/推出新的应用模型/体系结构

• 试点建议的体系结构
• 根据试点结果进行调整
• 更新最佳做法文档
• 创建模板、更新自动化、策略、治理

审核应用程序符合性 (GDPR、辅助功能、基础结构标准)

• 了解当前合规性规则
• 验证应用程序是否满足规则
• 为偏差的修复设定截止时间
• 进行更改、测试、发布

许多方案适用于多个角色，因此你还需要考虑指标来了解方案改进程度。

从问题到概念

接下来，建议寻求了解开发人员和其他角色在确定的方案和作业方面面临的最大问题。 开始调查新产品以填补感知的空白可能很诱人，但如果这些产品不能解决一个主要的痛点，它们不太可能被采用或欣赏。

有几种方法可以帮助你执行此类调查。 一个是 假设进展框架。 即使你不使用像假设进展框架这样的正式化流程，也可以从采访开发人员中获取很多好处，了解要完成的工作，以限定讨论的范围，然后确定他们在完成工作时遇到的最大问题。 一旦你对这些问题有了很好的了解，就可以继续提出解决这些问题的概念。 这有助于确保生成开发人员要使用的功能。

为了能够快速重复此过程，你需要确定可以直接在内部开发人员平台团队中代表客户声音的人员。 此角色通常称为产品经理 (即使他们具有不同的职务) ，并且随着知识的增长，他们将能够准确预测较小决策的结果，并确定何时需要进行更多面试。 这可以保持敏捷性，同时确保专注于为内部客户提供价值。

为初始投资提供案例

一旦你有了一组经过验证的问题和概念，你将能够提出投资的论点。 但是，请记住所需的前期投资和长期维护水平。 可以解决问题的工作量最低的解决方案往往是一个合适的开始，但通常维护工作最终决定你的投资是否成功。

换句话说，除非确实需要，否则不要创建面向旅程后续阶段的解决方案。

确定最 薄的可行平台 (TVP) (平台) 的 MVP 后，你可以通过一组愿意提供反馈的开发团队对其进行试点。 如果你的试点解决方案解决了这些团队面临的问题，则你不应该很难找到有兴趣参与的人。

在试用新功能或更改时，应捕获一些关键指标，以便在推出之前衡量概念是否成功。

衡量成功和证明价值

无论你是否进行首次投资，衡量你的成功程度都是产品思维模式的重要组成部分。 它不仅可以帮助你了解自己是否实现了目标，而且即使是以适度投资取得的小成功也可以为更大的投资奠定基础。

例如，很难为合规性工作获得资金或支持，因为它们可能被视为对提供业务价值的开发团队的运营税。 产品思维模式可以改变这种观念。 使用产品思维模式，你正试图确保内部开发人员平台的客户满意，并满足利益干系人的业务目标。 指标使你能够使用事实来证明你正在提供商业价值。 设置 OKR 会有所帮助，特别是如果你有可用于消除主观偏见的指标。 即使你目前没有测量任何适用的内容，也可以设置学习 OKR 来设置一个基线，然后在了解此基线后进行优化。

下面是可以衡量的已知指标示例，用于确定你正在合作的团队是否从你正在构建的内容中获取价值。 对帮助你衡量你和开发团队客户是否正在实现目标的人员进行归零。 例如，下面是一组指标，可帮助你评估平台是否为有效的工程组织做出了贡献：

• 速度/业务时间价值：完成第一个拉取请求 (载入) 的中值、生成和测试过程的中值分钟数 (示例：CI) 、合并拉取请求的中值时间。
• 软件质量：每月) 创建的事件 (问题，每个开发人员 (计数规范化为开发人员) 数，平均修正 (MTTR) 的时间，调查和修正安全问题的平均时间。
• 平台易用性： net user satisfaction (NSAT)
• 蓬勃发展的生态系统：以下每个被调查问题的平均分数：“我有权尽我最大的努力”，“大多数日子我被我所做的工作所激励”，“我所做的工作对我来说很有意义。

然后，可以按组织、团队或项目细分这些指标。 首先，需要测量一些基线，但随后可以在改进平台时watch这些指标的变化。

你或你的发起人可能感兴趣的其他指标包括：

区域	示例指标
软件交付性能	DEVOps 研究和评估 (DORA) ：更改提前期、部署频率、更改失败率、还原服务的时间 (MTTR)
操作	DORA (MTTR) 、平均故障 (MTBF) 间隔时间、平均确认时间、最终客户可用性、延迟、吞吐量指标、每个团队的成本、每个部署的成本
平台功能采用指标	随时间推移使用工具或功能的团队或开发人员的数量、使用平台的存储库百分比、最常用的模板、管道等。

收集指标需要时间和精力，因此请务必专注于确定的核心目标的关键指标，尤其是那些支持 OKR 的目标。 基于 OpenTelemetry 的产品（如 Application Insights）可以提供帮助。 无论如何，请务必定期衡量平台的易用性，并调查你拥有蓬勃发展的生态系统。 内部系统通常会遗漏这些指标，并且是衡量你能否实现更广泛的业务目标的一个领先指标，因为参与对成功至关重要。 它还有助于你了解是否该进行进一步的客户开发，以了解下一步要去哪里。

其他提示

无论如何开始，请记住以下准则。

规划更改

目标应用程序平台将随着时间的推移而发展，你可能无法一次性迁移所有现有投资。 你可能需要考虑如何随时间推移支持多个变体并规划更改。

使用较新的应用程序验证想法

在试点新平台或平台功能时，通常最好从大小合理的新应用程序开始。 这也将为你提供将平台作为产品进行管理的经验。 远离重新平台化项目开始，因为你将一路学习，而大型现有应用程序通常具有独特的需求，这些需求只有在重新平台工作本身时才发现。 因此，将你的成功与这类工作相耦合可能会导致期望不匹配或后期中断性问题。 从较新的东西开始，可以让你对它提供的价值的方向充满信心。 这降低了应对这些更大努力的风险。 换句话说，如果你相信人们可以从正确的开始和保持正确的开始，那么使用你从经验中学到的知识来推动一个正确的市场活动变得更加容易。 如果此方法不可行，则需要仔细分析、设置预期并逐步介入，而不是尝试一次性更改所有内容。

在创建新体验之前，请关注用户体验的现有重心

当开发人员出现在他们已经喜欢和使用的东西中时，他们更有可能采用和坚持新功能。 在评估概念以提供新功能时，请务必调查采用扩展现有“重心”的选项。例如， (Visual Studio、VS Code) 、DevOps 套件 (GitHub、Azure DevOps) 、现有 CLI 或现有内部门户的编辑器/IDE 可以比全新的门户或其他 UX 更有效。 有关详细信息 ，请参阅用户体验 。

假定最小特权原则

假设开发人员对下游系统的访问权限有限，例如预配基础结构。 你需要一种受控的方式为自助服务体验启用此访问。

计划受控试验

在推出重大或有风险的更改之前进行试验。 并非所有内容都必须完全自动化才能启动。 自动触发的手动工作流可能是试点创意的好方法。

最小化应用平台自定义

尝试避免软件供应商随时间推移发布的功能可能掩盖的自定义生成应用程序平台功能。 例如，运行时托管、服务网格、标识系统等。 如果你发现某个领域存在紧急需求，你怀疑可能是这样的，那么，考虑到长期维护，规划多个实现选项可能会导致你随时间推移而切换。

应用软件工程系统