如果你的关注点仅仅在于开发者体验，那么你可能错过了一半的重点，也可能错过了一半的价值。
翻译自 The Real Business Value of Platform Engineering 。
最近几个月以来，有很多关于平台工程在取代（或某种方式解决） DevOps 角色的噪音。
尽管平台工程不太可能作为一种方法取代 DevOps，但它确实可以增强 DevOps 流程。由于平台工程具有许多潜在的好处，我预计其受欢迎程度将继续增长。
不幸的是，工程和技术团队通常在平台工程方面犯一些错误。那么，什么是平台工程？它能为企业提供哪些实际价值呢？
平台工程是构建和维护支持软件交付工作流程的内部工具链的实践。一个专门的团队实施工具和流程，为开发人员提供自助访问基础设施。平台团队将共享的基础设施平台作为产品提供给软件开发和相关团队使用。这种方法旨在减少开发人员和基础设施与运营（I&O）团队的复杂性，以加速软件开发生命周期。
许多平台供应商和其他组织强调开发者体验是平台工程的价值驱动因素。这些好处来自于开发人员通过内部开发人员平台（IDP）如 Backstage 或类似工具通常实现的对应用基础设施的自助访问。
这可以减轻与服务请求、长时间等待或管理自己的基础设施的认知负担相关的麻烦。简化开发人员访问基础设施可以提高生产率，改善员工保留率，并加速应用程序交付。
但如果你的关注点仅仅在于开发者体验，那么你可能错过了一半的重点，也可能错过了一半的价值 - 这就是平台工程的情况。
平台工程的真正价值来自于通过改进对基础设施的控制而实现的一致性和可见性。
当执行正确时，平台工程策略可以使我们更容易理解云基础设施的配置和部署，强制执行云配置和操作的标准，优化生产力，强制执行治理并管理成本。
掌控基础设施利用情况使平台和 I&O 团队在强制执行安全和合规政策方面处于独特的位置。
因为平台配置和部署所有环境，平台团队可以确保安全协议和合规政策被嵌入到每个部署的环境中。他们可以设置关于最终用户有权访问什么，这些资源可以使用多长时间，可以更改什么以及被锁定什么的参数。他们还能够利用机密信息、权限和密钥来设计基础设施，以便安全机制被自动嵌入到基础设施部署中。
使用可定制的基于角色的访问控制（RBAC），平台团队可以确保基础设施与组织的团队结构和人员技能/角色相一致，以控制对云帐户和源代码存储库的访问。
管理云成本的最大障碍之一是理解资源消耗背后的业务背景。
由于平台是所有部署的源头，它可以提供端到端的可见性，跨足软件开发生命周期（SDLC）的所有阶段启动的环境都可以看到。
单独的云计费数据缺乏透明性。然而，一些平台可以暴露云成本的产生方式。将应用基础设施整合到平台中可以将标记自动化为部署过程的一部分。这将使用与特定应用程序、流水线、阶段和团队相关的用法联系起来。
在具有这种业务背景的实时配置跟踪下，工程和技术团队可以就成本优化和资源消耗做出明智的决策。例如，他们可能能够找到经常在周末或假期期间保持环境运行并产生成本的人员或团队。这些见解可以用于实施成本管理的防护措施和消费政策。
由于企业越来越希望理解和管理其基础设施，平台工程方法非常合理。在其核心，它可以让 IT 和运营团队更好地掌控和看到基础设施的配置和利用情况。虽然使用平台工程方法可以明显改善开发者体验，但这种方法论具有广泛的好处，可以在整个业务中实现。
了解基础设施实例的使用方式、时间和目的为智能地优先考虑云支出提供了基础，并可以导致即时降低成本。通过应用集中策略和标准化环境蓝图来加强基础设施可以减轻业务风险。所有这些因素共同大大改善了 DevOps 流程和整体业务结果。随着 DevOps 的不断发展，这些好处将不再是“有会很好”，而是变得至关重要。