过去一年，平台工程的概念悄然兴起，正在变得流行，围绕平台工程和DevOps的争议不断，本文作者曾撰文《DevOps已死?平台工程才是未来?》以澄清，平台工程与PaaS、SRE等等的关系也让人困惑，本文将再做分析，对平台工程中的“平台”、平台工程的价值、平台工程落地逐一详细解读，希望能为读者提供参考。

　　【作者】汪照辉，中国银河证券架构师，专注于容器云、微服务、DevOps、数据治理、数字化转型等领域，对相关技术有独特的理解和见解。擅长于软件规划和设计，提出的“平台融合”的观点越来越得到认同和事实证明。发表了众多技术文章探讨容器平台建设、微服务技术、DevOps、数字化转型、数据治理、中台建设等内容，受到了广泛关注和肯定。

　　平台工程是为了让软件工程团队能够更有效的交付软件应用，以使客户获得有竞争力的业务优势，构建的一些列研发、运维运营工具平台，以更高效的方式持续交付软件应用系统和确保软件稳定运行。平台工程的目的是帮助软件团队提升和持续交付软件业务价值。平台工程为软件研发人员、测试、运维人员等提供一站式的应用生命周期过程所需的所有资源、工具、平台、接口服务以及库文件等(如图)，也相当于给软件人员提供一个包含资源、技术工具、数据和业务应用接口等的环境，不说无所不包的自服务环境，至少说是相对全面的软件工程工具平台等支持，足不出户就可以完成业务应用的研发和部署运行运维等整个生命周期的工作。

　　平台工程本质是自服务敏捷基础设施，为使用者抽象并封装了基础设施能力，提供标准化的 API 等。例如通过基础设施即服务( IAAS)API创建虚拟服务器实例、网络和存储卷等，应用自动化的配置管理和流程，使应用程序和支持服务快速执行和运行。对软件研发人员来说，“平台”提供研发的环境和工具，自动化构建应用程序组件、构建应用程序部署环境，部署应用程序，并启动必要的流程等。研发人员不必考虑他们的代码在哪里运行，也不必考虑是如何到达那里的，都由平台透明地处理这些问题。

　　但这些“平台”或说自服务敏捷基础设施从哪里来?通常来说，是买不来的。首先每家公司都有自己的技术栈、技术积累、业务方向和重点，需求是不一样的;其次，“平台”不是一个平台，而是一些列相互关联和相互支撑的平台工具体系，一家厂商通常是没有能力构建和满足特定客户需求的这样的能力体系的。多家厂商面临着单体系统建设集成、重复建设等问题，因此，“平台”往往需要自己逐步构建，这就需要有相应的平台工程研发和运维团队，专注于基础设施自服务工具的规划、设计、研发和运维等。也因此，平台工程并不适合大部分企业。平台工程的构建需要有足够的技术人员团队和实力，以及足够的业务需求，否则就没有必要性。

　　平台工程的“平台”不是云平台，虽然可以通过云平台为底座来构建。Mauricio将平台定义为对知识进行的编码，从而为开发团队提供高效所需的所有工作流程。平台工程可以通过云原生 Kubernetes 来构建，Kubernetes 相当于操作系统的内核，基于Kubernetes 构建云原生PaaS 平台(云原生操作系统)，提供应用研发、应用托管、应用运维等整个软件应用生命周期过程所需的平台、工具、API 接口等的体系，包括软件的研发、测试、部署、运行、运维、监控、日志等工具、平台和自动化流程等等。

　　平台工程的平台至少包括基础设施资源平台、PaaS平台、中间件工具、平台可复用服务等(如上图)。平台可复用服务从中台架构(“中台”的概念太过混乱，这里是优化的中台架构，中台实现的是经过抽象和封装的以微服务为粒度的企业级可复用服务，不包括支撑这些服务的平台和工具)来说，就是中台架构中的在企业内共享和复用的服务，服务粒度可以是微服务，和平台工程所推崇的 API 化是一致的。因为 API 化，才能便利构建自动化的流程。构建平台工程，就是实现这些自服务能力，赋能软件研发运维人员敏捷交付业务应用，再赋能业务人员敏捷响应客户需求，也就是交付客户价值。

　　有人说平台工程是典型的的赋能方案，这点我非常赞同。平台工程主要目的就是为了提供给研发人员等完成研发等工作所需的各种工具平台和服务等。不过平台工程的价值不仅仅限于赋能，它是技术发展的结果。云计算提供了一个资源融合的基础设施底座，分离了应用和基础设施的耦合性，可以让研发人员专注于应用的研发。因此云计算在基础设施平台上实现了统一的方案。云原生为企业的敏捷研发、变更、部署、运行等提供了解决方案，驱动企业以云平台为底座构建统一的基础设施平台，避免重复建设、提升协作效率、降低成本并敏捷响应业务需求。

　　一些大企业业务繁多，团队众多，传统单体系统建设模式下，面临着各团队各自为政、重复投入、重复建设、集成繁琐、共享困难等问题。数字化使业务之间的交互越来越多，IT 应用数据和功能需要频繁协作，从而也导致 IT 团队、IT与业务之间等的协作增多。数字化趋势要求企业不得不考虑内部团队和业务之间的协作和融合，以更快的响应跟上生产力变革。这就要求内部系统、工具平台等的整合、融合，疏通内部协作，构建统一的基础设施，自服务工具、平台、流程等，通过复用和自动化，环境一致性提升交付效率，部署效率，变更效率，可观测性能力等。

　　有人把平台工程看作是内部开发平台，这个定义有点窄了。平台工程是为软件人员构建和维护企业内部的自助服务工具平台，却不仅仅是内部开发平台，而可以看作是软件工程平台，是个系统性的工程。就像很多人对 DevOps 的片面理解一样，把DevOps 看作是一个研发度量平台，误解了这些概念的本来目的。

　　平台工程本质上是自服务敏捷基础设施，从这点上理解，就相对容易实施和落地。自服务敏捷基础设施包含研发平台，也包含部署运行运维监控平台、工具等，还有就是企业内部沉淀的可复用服务，以及 GPU 、CPU、存储等基础设施资源等，这些都是基础设施的部分。平台工程的落地需要专业的平台工程团队来规划实施。平台工程团队和 SRE 的工作有些类似，但侧重不一样。平台工程团队不做业务应用系统的研发，只负责自服务基础设施平台工具的建设、维护和运营(平台工程团队内部实现研发运维一体化)，赋能业务应用研发团队完成业务应用的生命周期过程(业务应用研发团队内部也实现研发运维一体化，使用基础设施工具平台，研发运维的是业务应用);平台工程团队和业务应用团队职责清晰，业务应用团队是平台工程团队的内部客户，提需求并由平台工程团队完成这些需求;SRE 侧重于服务和系统的可靠性，虽然也开发自动化的工具，但目的不是赋能业务应用研发团队，而是为了消除重复性的手工工作。

　　平台工程落地很重要的一点是API的抽象和封装。我们把中台架构优化为中间层是可复用服务，而把支撑这些服务的工具平台看作后端层，这就明确了中台架构的可复用粒度，中台的落地也就很清晰了。平台工程同样需要构建这些可复用服务，松耦合后端工具。举例来说，消息的发布订阅服务，用 Kafka 可以实现，用 Rabbit MQ也可以实现，如果通过消息服务的封装，松耦合 Kafka 、RabbitMQ 等消息中间件，则不会受制于具体的某个工具。哪天 Kafka 不让用了，则可以快速切换到其他消息中间件工具。这就是 API 的价值，隐藏底层的复杂性，隔离应用和基础设施工具，提供一层稳定的可复用接口层。

　　实现基础设施 API 的目的，也在于能够简化开发人员从平台使用服务的工作。可以自服务实现相关的业务流程。比如如果需要一个开发环境，调用 Environment 接口，输入配置需求，就可以通过快速自动地构建一个所需的环境。

　　每家的实际不一样，所以平台工程在落地是也会不一样。不过基本思想是一致的。总的来说，无论概念怎么变，本质是不变的。认识到概念的本质，就不会被众多的概念牵着鼻子走。