定义问题空间
在开始定义内部开发人员平台时，首先需要定义最薄的可行平台（TVP）。 TVP 是经典产品管理中最低可行产品（MVP）的想法的变体。
此关系图可帮助你引导你思考开发人员平台随时间推移的发展。 请记住，由于现有投资或组织需求，组织的首要问题可能会导致你偏离此处所述的内容。 除非组织需要，否则无需继续下一阶段。
如果从头开始，则表示常见的进展。 在早期阶段，专注于发现所需的功能、收缩包装产品的拟合差距分析，以及创建最少数量的工具或平台功能。 接下来，缩放时，可能会开始专注于可重用性，并引导人们使用可重用资产减少预定义的铺路路径。 最后，你将转向类似于消费者的“数字存储”模型，以便更轻松地构建和维护应用程序。 你应该遵循整个产品思维模式，因此不建议跳到最后，你的特定旅程会有所不同。 这些最后阶段最类似于传统意义上的收缩包装“产品”，但这是一个目标，而不是起点。
平台工程主题领域
鉴于本主题的绝对大小，建议将平台工程在内部讨论的方式分解为四个主题领域：
工程系统：GitHub、Azure DevOps 和其他开发人员工具和服务等 DevOps 套件的特选组合。 除了关键的 DevOps 工具和服务（如 CI/CD 或包管理）之外，此区域还包括直接在编码过程中使用的功能，如基于云的编码环境、代码扫描仪和升数，以及 GitHub Copilot 等 AI 助手。
应用程序平台：组织希望用于提供业务价值的每种“应用堆栈”（应用程序类、应用模型、语言）的服务（如 IaaS、PaaS 和可观测性）的特选选择。 这包括应用堆栈特定服务以及在整个过程中使用的通用服务的组合。 应用程序平台的示例可能包括 Azure 容器应用、用于存储的 Cosmos DB、用于机密的 Azure 密钥库、标识和基于角色的访问控制、用于符合性和审核的 Azure Policy、通过 Grafana 的可观测性以及相关的网络拓扑。
应用程序模板：一组定义完善的组织创建、快速启动模板，这些模板封装了开始正确，并且为给定的应用程序平台、语言和一组工程系统提供正确的指导。 他们可以引用其他集中式模板，并提供初学者代码、API 和 SDK 参考、CI/CD 管道、工具配置等。
开发人员自助服务功能：这是平台工程工作的粘附。 它是 API、业务流程协调程序、目录、模板和用户体验的组合，旨在减少开发人员的辛苦工作，并允许开发团队自我服务并更加自主，同时仍坚持前三个领域的选择和指导/治理。
集成工程系统、应用程序平台、应用程序模板和开发人员自助服务功能构成了平台工程策略的基石。 通过结合 DevOps 工具、云服务和自助服务功能，组织可以显著减少开发人员的辛苦工作，提高工作效率，并确保符合治理标准。