我们继续将 平台工程产物团队 视为默认团队配置，关键在于是他们只是一个专注于内部平台客户的。因此，在使用与任何其他（以外部为重点的）产物团队相同的工程学科和工作方式的同时，明确定义客户和产物至关重要；平台团队在这方面并不特殊。我们强烈警告不要只将现有的内部团队重命名为“平台团队”，而同时保持工作方式和组织结构不变。在考虑如何最好地组织平台团队时，我们仍然非常喜欢使用中的概念。我们认为平台工程产物团队是一种标准方法，也是高性能 IT 的重要推动者。
正如本期雷达主题之一所指出的那样，业界在创建和支持内部平台的“平台工程产物团队”中积累了越来越多的经验。组织中的团队使用这些平台，可以加速应用程序开发，降低运营复杂性并缩短产物上市时间。随着采用率的提高，我们对于这种方法的好和坏的模式也越来越清楚。创建平台时，至关重要的是要明确定义可以从中受益的客户和产物，而不是凭空建立。我们不仅要谨防分层平台团队，它保留了现有技术孤岛，只是贴上了“平台团队”的标签而已，还要小心工单驱动的平台运营模型。当考虑如何最好地组织平台团队时，我们仍然是概念的忠实拥护者。我们认为平台工程产物团队是一种标准方法，并且是高性能滨罢的重要推动者。
采用云计算和顿别惫翱辫蝉，虽然提高了团队生产力，减少了对集中式运维团队和基础设施的依赖，但也制约了那些缺乏自管理完整应用和运维技巧的团队。一些组织通过创建 平台工程产物团队 来应对这些挑战。这些团队维护着一个内部的应用平台，该平台使交付团队能够自助部署和运维系统，从而减少交付时间和降低技术栈的复杂度。这里的重点是 API 驱动的自服务和支持工具，而交付团队仍然需要对部署在该平台上的应用负责。当组织考虑组建这样一个团队的时候应当非常小心，避免无意中创建一个独立的 DevOps 团队，也不要把现有托管及运维设施重新打上平台的标签。对于如何最佳地组建平台团队，我们一直在使用中的概念，将项目中的平台团队划分为赋能团队、核心“平台中的平台”团队和齐头并进的团队。
The adoption of cloud and DevOps, while increasing the productivity of teams who can now move more quickly with reduced dependency on centralized operations teams and infrastructure, also has constrained teams who lack the skills to self-manage a full application and operations stack. Some organizations have tackled this challenge by creating platform engineering product teams. These teams operate an internal platform which enables delivery teams to self-service deploy and operate systems with reduced lead time and stack complexity. The emphasis here is on API-driven self-service and supporting tools, with delivery teams still responsible for supporting what they deploy onto the platform. Organizations that consider establishing such a platform team should be very cautious not to accidentally create a separate DevOps team, nor should they simply relabel their existing hosting and operations structure as a platform.
The adoption of cloud and DevOps, while increasing the productivity of teams who can now move more quickly with reduced dependency on centralized operations teams and infrastructure, also has constrained teams who lack the skills to self-manage a full application and operations stack. Some organizations have tackled this challenge by creating platform engineering product teams. These teams operate an internal platform which enables delivery teams to self-service deploy and operate systems with reduced lead time and stack complexity. The emphasis here is on API-driven self-service and supporting tools, with delivery teams still responsible for supporting what they deploy onto the platform. Organizations that consider establishing such a platform team should be very cautious not to accidentally create a separate DevOps team, nor should they simply relabel their existing hosting and operations structure as a platform.
