从某种程度上来说，平台工程（为公司自己的员工提供预构建的工具链和工作流程）正是 DevOps 团队蓬勃发展所需要的。DevOps团队越容易获取交付软件所需的工具和环境，构建和更新应用程序的效率就越高。
尽管平台工程具备增强DevOps的潜力，但这并不意味着它总能达到预期效果。平台工程也可能会带来挑战，阻碍DevOps工程师完成工作。如果想确保平台工程真正提升DevOps，理解平台工程策略的潜在缺点和优点同样至关重要。我们可以通过探讨平台工程的含义及其对DevOps的利弊来进一步了解这一点。
什么是平台工程？
平台工程是一种为公司内部用户提供自助服务的预配置IT工具和服务的实践。平台工程的目标是帮助员工获取所需的资源，以提高生产力，而无需他们自己构建这些资源或请求IT部门代为完成。相反，员工可以从预构建的工具链和工作流程目录中选择并部署所需的资源。
例如，设想一个软件开发人员希望创建一个Kubernetes集群来测试新应用。如果开发人员所在的公司通过平台工程提供了一个预配置的Kubernetes集群，那么开发人员可以快速、轻松地创建集群，而不必从头构建集群。这不仅大大加快了速度，也更为简便。
同样重要的是，这一过程还确保了开发人员使用的环境与公司的安全和治理策略保持一致，而这可能无法通过开发人员自行选择工具和配置来实现。
平台工程对DevOps的好处
在许多方面，平台工程与DevOps密切相关。并不是说实施DevOps必须依赖平台工程，因为DevOps只是意味着IT运维工程师和软件开发人员之间的协作，不需要依靠平台工程就可以实现这一点。然而，平台工程在多个方面有助于实现DevOps的目标：
它提供符合公司标准的预配置资源，帮助避免软件开发人员和IT之间的摩擦。
它允许开发人员自动请求资源，而无需通过手动方式联系IT团队，从而促进IT和开发团队之间的流畅协作。
它加快了软件交付，使DevOps团队能够实现CI/CD的目标。
平台工程帮助DevOps团队更高效、更可靠地“实施”DevOps。
平台工程对DevOps的潜在缺点
话虽如此，但如果实施不当，平台工程可能给DevOps团队带来更多问题，而非解决问题。
一个常见的问题是提供的解决方案没有实际用途。例如，如果你使用平台工程创建了一个运行在AWS上的预配置Kubernetes集群，但开发人员是在Azure上构建和测试应用程序，他们可能会觉得这个解决方案并没有什么用。这种情况往往发生在负责平台工程的工程师对其“客户”——即开发人员和其他DevOps相关方——的需求缺乏清晰的了解时。
平台工程也可能在提供的解决方案难以部署时出错。理论上，部署一个解决方案应该像点击按钮或执行脚本一样简单。然而，若部署工具存在问题，或者软件环境不一致，DevOps工程师可能需要花时间调试和修复有缺陷的平台工程解决方案，或者请求IT团队的帮助。在这种情况下，本应节省时间、简化协作的解决方案反而适得其反。
类似地，如果平台工程提供的解决方案没有始终符合组织的治理和安全策略，其价值也会大打折扣。这种情况通常出现在不同团队实施了不同的解决方案，而每个团队都遵循自己的政策，而不是遵循公司范围内的规则。（这种情况也可能因为组织缺乏清晰、一致的安全政策而发生。）如果DevOps团队通过平台工程启动的环境和工具链不安全或配置不一致，它们将阻碍协作，无法优化软件交付流程。
DevOps团队如何改进平台工程
在上述平台工程挑战中，你可能注意到一个共同点：这些问题都源于平台工程解决方案设计或实施不当。因此，从DevOps的角度来看，问题并不在于平台工程本身，而在于糟糕的平台工程。
这意味着，通过平台工程为DevOps提供实际价值并进行改进的关键在于：企业必须确保其构建的解决方案具有高质量、对用户具有相关性，并以一致的方式配置，以符合公司范围内的目标。这并不复杂，但需要采取系统化的平台工程方法，并制定清晰的规则，规定公司实施的解决方案类型及其工作方式。
不妨利用平台工程来提高DevOps效率，减少相关方之间的摩擦。但确保实施的平台工程能够真正提供价值，而不是成为IT团队和开发人员的另一个头疼来源。
