国际权威知名调研机构 Gartner 在《2023年最重要的10个技术趋势》报告中将平台工程（Platform Engineering）列为高速发展的技术趋势之一，并预测到2026年80%的软件企业都将搭建平台团队以为内部的工程师提供可复用的服务、组件以及工具来帮助应用交付。
图源：Gartner
平台工程是一门新兴技术，专注于通过减少现代软件交付的复杂性和不确定性来提高开发人员的生产力。它解决了规模化DevOps的一些最大挑战，包括减少在整个应用生命周期内管理复杂工具和基础设施网络的负担。无论是基础设施配置、流水线、监控还是容器管理等，自助服务平台将所有这些复杂的问题放入黑盒中，进而为开发人员提供开箱即用的所有必要工具。
平台团队将基础设施管理自动化，并使开发人员能够从一个集中管理的技术平台上自助获取可靠的工具和工作流程。由于减轻了开发团队的认知负担，平台工程是云原生软件交付的一个重要转向。
正如我们之前诸多文章中阐述的那样，DevSecOps 将安全左移到开发流程中，借助各类工具简化部署、管理、监控以及安全治理等工作，在获得 DevOps 敏捷交付优势的同时还能保障软件开发的安全。而平台工程会借鉴 DevSecOps 的做法，采用这些工具、流程和最佳实践，并将其产品化为可重复使用的服务和工具，以便在企业内部的不同开发团队和实际场景中使用。
举个例子，企业里的每个产品团队都有证书轮换的需求，此时如果有一个统一的服务能解决这一需求将会省下许多麻烦，也就是需要解决方案可重复。那么如果有多个需求都与此类似，那么表明企业内部需要一个平台来统一解决此类问题，而不是让每个团队都重复造轮子。
平台工程是随着DevOps的成熟和规模的扩大而出现的。在DevOps（或 DevSecOps）的前期阶段企业内部的每个开发团队都会创造符合其自身需求的实践。例如，交付物可以是 Terraform 模板或 Terraform 模块，工程师随后可以 clone 并添加他们的配置，但在 clone 之后，就不再维护最初的那套模板或模块了。于是如果产生问题，那么问题的解决方案通常存在于各个团队内部。
随着企业的成熟和发展壮大，DevSecOps 会走向后期成熟阶段。在此阶段，企业开始收集数据点并了解 DevSecOps 工具和实践的影响，此时会发现不同团队正在分别解决同样的问题，这十分低效，因此企业内部各团队需要借助统一的共享平台来避免重复造轮子。
如上文所述，平台工程可以为研发团队提供更好的开发体验，这一小节我们将详细聊聊平台工程的主要优势。
在没有平台工程的情况下，许多开发流程是手动的。无论是手动创建和配置代码仓库，管理云基础设施，还是创建CI/CD流水线，手动过程都需要时间，而且容易出错，许多安全问题恰恰由于配置错误产生。
平台工程非常注重流程的自动化。因此，在自动化平台的帮助下，开发人员可以更快地传输他们的代码。现在，开发人员可以通过自助服务来启动环境和交付他们的软件版本，进而大大加快开发周期。一个与自动化测试集成的代码流水线将可以在不影响质量或进度的情况下为你的客户提供商业价值。因此，产品进入市场的时间将被缩短。
基础设施和应用程序的自助服务部署将会消除流程中的复杂度。平台工程会自动化整个 DevOps 周期，进而提升生产力以及减轻开发人员的负担。在传统方法里，开发人员依赖于 DevOps 团队创建和维护软件部署。现如今，借助自助服务门户，开发人员可以自主、快速交付新版本。这将会简化企业内部的开发流程。
有这样一个场景：开发者需要对微服务应用程序进行一个微小的更改，首先进入 staging 阶段，其次再进入生产环境。这是一个多集群 Kubernetes 环境。只有掌握了 Kubernetes、Helm chart 以及 Terraform 模块的开发者才能够自己完成所有的部署流程。但是规模较小的企业可能没有预算来招聘这么多的资深开发者。那么，此时借助平台工程师的帮助，开发人员无需将此类工作推卸给运维团队，而仅需点击几下即可将代码推送到任意环境，而无需了解复杂的底层架构。这改善了不同团队成员之间的反馈迭代，使产品更加完善，进而为客户带来巨大的商业价值。
当前大多数 CI/CD 设置主要聚焦于容器镜像的更新。CI server 在配置中构建镜像并更新镜像路径。然而，当你需要完成以下事项时，则变得有些复杂：
平台工程师为开发环境提供全面的环境自动化，开发人员可以创建、复制、移除和更新部署环境而无需了解底层架构知识。这意味着，甚至初级的UX开发也可以自助使用环境，这个环境已经完全配置了开发者需要部署和测试的一切。自动化环境的能力可以让业务快速、高效增长。
上文所提到的平台工程团队的优势十分诱人，那么是否每个企业都需要采用呢？
如果企业内部已经有团队跨职能来管理应用基础设施、部署以及运维等工作，那么企业应该开始考虑平台工程，因为这在不知不觉之间已经完成了平台工程的部分内容。
另外，如果企业已经有一个成熟的产品，一个清晰的发展愿景并计划开始扩展市场，那么此时也是搭建平台团队的好时机。
如果企业管理者希望开发团队专注于产品的开发，而不是被基础设施配置、代码流水线设置、密钥管理等工作牵扯精力，那么企业需要一个平台工程团队。借助该团队的帮助，应用开发人员可以轻松将代码推送到生产环境中。
如果企业内部的工程团队人数正在增长，同时云原生应用也需要扩展，那么仅仅有技术专家是不够的，还需要团队之间的合作。在一个开发团队中，并不是所有的团队成员在技术上都善于处理扩展操作。团队中的一个薄弱环节会降低团队的速度，减慢整个开发周期的速度。在这种情况下，平台工程团队将是理想的选择。
另一方面，如果企业规模不大，仅有屈指可数的几位开发人员来构建一个单体应用，那么平台团队对于该企业来说收益并不大。此时，企业需要首先专注于实现产品与市场的契合，并将任何重复的任务自动化，使开发人员能够专注于创新。此后，开始将应用程序分割成单独的服务，需要由多个工程团队交付不同的价值时，可以开始引入平台团队，他们可以帮助你实现效率和稳定性的最佳平衡。
平台工程的原则和理论总结起来可以用一句话概括，即真正重要的是将平台工程付诸实践。平台团队一开始可以先从小处着手，聚焦于所有团队都会用到的技术栈。换言之，平台团队不应该构建一个类似于“万金油”的平台，而是关注某个具体的技术，比如容器和K8S。
平台搭建初期需要先确立目标，比如在不增加认知负荷的情况下实现开发者自助服务，或者在不强迫开发者学习以基础设施为中心的技术的情况下实现运维工单数量的减少。
构建平台最好的方式是采用产品的方法，即Platform as a Product，通过用户研究、征求用户反馈、获得内部相关方的认可，进而平台团队可以全面了解开发者的痛点和整个组企业所面临的共同挑战。这些决定了开发人员需要什么特性，进而构建包含这些解决方案的黄金通道。
但平台不止于此，成功的平台团队会持续保持与开发人员的沟通并跟踪一些指标（如部署频率、交付时间、稳定性等）以确保开发人员采用了平台并且对其开发体验有所改善。
平台团队及其所提供的黄金路径是将所有复杂设置黏合在一起的胶水，但由于平台团队只面向内部工作，许多企业错误地将其视为成本控制中心。平台团队应该努力争取利益相关者群体的内部认同，以确保其内部平台项目的长效性。
最后，也许也是最重要的一点，成功的平台团队应尽量避免重复造轮子。平台工程的 landscape 正在不断发展壮大，以解决广泛的问题。平台团队可以通过尽可能地定制现成的解决方案来节省时间和创造更多价值。
本文我们详细介绍了平台工程（Platform Engineering）这一新兴技术，包括其与 DevSecOps 的关系、主要优势以及实践原则，作为 DevSecOps 成熟化、规模化的产物，平台工程可以帮助企业减轻开发人员的认知负担和基础运维的负担，避免重复造轮子，帮助企业提升开发效率，进而产生更大的商业价值。