定义问题空间

在开始定义内部开发人员平台时，首先定义 最薄的可行平台 (TVP) 至关重要。 这是经典产品管理中 最低可行产品 (MVP) 理念的变体。

在 “计划和优先级”中，可以详细了解如何定义 (或增强 TVP) 。 但在我们到达之前，此图可以帮助你确定如何随着时间推移而演变的思维。 请记住，由于现有的投资或组织需求，组织的首要问题可能会导致你偏离此处所述的问题。 关键是，除非组织需要它，否则你不需要进入下一阶段。

如果从头开始，则表示常见的进度。 在早期阶段，专注于发现所需的功能、收缩包装产品的拟合差距分析，以及创建最少数量的工具或平台功能。 接下来，随着缩放，你可能会开始专注于可重用性，并引导人们使用可重用资产走预定义的铺路。 最后，你将转向类似于使用者的“数字存储”模型，以便更轻松地生成和维护应用程序。 你应该始终遵循产品思维模式，因此我们不建议跳到最后，而你的特定旅程会有所不同。 这些最后阶段最类似于传统意义上的收缩包装“产品”，但这是一个目的地，而不是起点。

鉴于本主题的庞大规模，建议将平台工程的谈论方式分解为四个主题领域。 以这种方式对思维进行分类可以简化在一段时间内制定和传达投资计划的方式。 这些方面包括：

• 工程系统：GitHub 和 Azure DevOps 等 DevOps 套件以及其他开发人员工具和服务的特选组合。 除了 CI/CD 或包管理等关键 DevOps 工具和服务外，此领域还包括在编码过程中直接使用的功能，例如基于云的编码环境、代码扫描程序和升，以及 ai 助手（如GitHub Copilot）。
• 应用程序平台：针对每个“应用堆栈”的 iaaS、PaaS 和可观测性) 等 (精心挑选的服务， (一类应用程序、应用模型、语言) ，组织想要使用这些类别来提供业务价值。 这包括应用堆栈特定服务以及整个过程中使用的常见服务的组合。 应用程序平台的示例可能包括 Azure 容器应用、用于存储的 Cosmos DB、用于机密的 Azure 密钥保管库、标识和基于角色的访问控制、用于合规性和审核的Azure Policy、通过 Grafana 的可观测性以及相关的网络拓扑。
• 应用程序模板：一组定义完善的组织创建的快速入门模板，这些模板封装了正确启动，并针对给定的应用程序平台、语言和工程系统集提供正确的指导。 它们可以引用其他集中式模板，并提供入门代码、API 和 SDK 引用、CI/CD 管道、工具配置等。
• 开发人员自助服务功能：这是平台工程工作的粘附。 它是 API、业务流程协调程序、目录、模板和用户体验的组合，旨在减少开发人员的辛劳，使开发团队能够自我服务，更加自主，同时仍坚持前三个领域的选择和指导/治理。

规划和确定优先级