共计 3415 个字符，预计需要花费 9 分钟才能阅读完成。
国内权威出名调研机构 Gartner 在《2023 年最重要的 10 个技术趋势》报告中将平台工程（Platform Engineering）列为高速倒退的技术趋势之一，并预测到 2026 年 80% 的软件企业都将搭建平台团队认为外部的工程师提供可复用的服务、组件以及工具来帮忙利用交付。
图源：Gartner
何谓平台工程（Platform Engineering）？
平台工程是一门新兴技术，专一于通过缩小古代软件交付的复杂性和不确定性来进步开发人员的生产力。它解决了规模化 DevOps 的一些最大挑战，包含缩小在整个利用生命周期内治理简单工具和基础设施网络的累赘。无论是基础设施配置、流水线、监控还是容器治理等，自助服务平台将所有这些简单的问题放入黑盒中，进而为开发人员提供开箱即用的所有必要工具。
平台团队将基础设施治理自动化，并使开发人员可能从一个集中管理的技术平台上自助获取牢靠的工具和工作流程。因为加重了开发团队的认知累赘，平台工程是云原生软件交付的一个重要转向。
平台工程 vs DevSecOps
正如咱们之前诸多文章中论述的那样，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 成熟化、规模化的产物，平台工程能够帮忙企业加重开发人员的认知累赘和根底运维的累赘，防止反复造轮子，帮忙企业晋升开发效率，进而产生更大的商业价值。