DevOps 与平台工程

DevOps 是一种文化和理念。平台工程，是我们实现**“谁构建、谁运行”**的唯一方式。这是 DevOps 的核心初衷，也是后来企业级规模和云原生时代的实现基础。平台工程关注的不一定是教你怎么用工具，而是构建起一套能够实现这种自我服务能力的平台。有了平台工程，核心软件工程部门才有机会获得自我服务能力。这种观念上的转变，决定我们要把平台视为一种产品进行建设。

DevOps 最初的想法非常简单，基本目标就是消除开发人员和运营人员间的障碍，促进双方协作。达成目标的方法基本就是做左移，实现“谁构建、谁运行”。当所有这些云原生趋势融合在一起之后，就有了云原生、Kubernets、容器化、基础设施即代码和 GitOps 等等，情况已经完全不同了。

为什么需要平台工程

面对复杂的工具链，开发者没必要成为全面的专家，相反，应该把底层基础设施的复杂性从开发者那里抽象出来，为他们提供一条最佳路径，由开发者自己决定最适合的上下文层级。

在企业中，平台工程的推动会遇到困难，特别是认知负荷相关的问题。首先，开发者不知所措从而不断向运营团队求助，最终运营团队成为业务瓶颈；亦或高级工程师会悄悄用自己的办法接管了运营任务，成为“影子运营”，并没有把全部的精力投入到编码当中。这两种方式会陷入恶性循环最终成为技术债务。因此，我们建议树立平台工程团队的角色、考虑建设和使用工程平台。

什么样的团队需要工程平台

如果团队中只有大约20 名工程师，而且不是每个人都熟悉 helm、IaC、Terraform 或者 Kubernetes，PaaS 是不错的选择。 DevOps 的基本诉求“谁构建、谁运行”可以实现。但 PaaS 只能提供一条路径，只能通过简单设置支持相对不那么复杂的用例。

当企业从几十名开发者转变为成百上千开发者时，平台有助于解决的痛点才开始真正出现。痛点出现了，摩擦出现了，如果还没有任何平台，那需要行动起来了。如果已经拥有 PaaS 解决方案，不妨考虑逐渐过渡到自建的内部开发者平台，或者使用价值观相同的、较为成熟的外部产品。

如何建设平台工程

设立平台工程团队，平台工程团队的使命和愿景是构建、成就或引入一款产品，这款产品的客户就是开发者。

其次，平台工程团队要重视沟通能力。在跟开发人员交谈时，要强调的是如何缩短等待时间、改善开发体验。而在跟运营团队交流时，要告诉他们如何减轻压力并快速处理工单。而在跟管理层沟通时，最重要的一点就是告知如何缩短产品上市时间，并且能够降低运营成本。这个指标类似于给平台设定投资回报率。

开发者平台的目标是为工程师们提供类似于 PaaS 的使用体验和开发体验。但它基于更复杂的标签和工具堆栈，搞清楚工具箱里到底有着怎样的技术组合。把整个栈接管过来，完成最后一英里的优化，通过微调为开发者构建起适宜的最佳上下文路径。

平台工程不能成为开发团队的束缚。一方面，需要通过标准化普及降低认知和使用门槛，实现自服务。同时，还得确保开发者使用基础设施资源的方式跟平台标准要求相一致。这里要么采用始终如一输出相同的配置文件，进行动态配置管理，实质在于每次部署时都能动态生成配置文件，包括谁部署了什么、在哪里部署、输出了什么。动态配置管理还能在每次 Git 推送时执行策略和标准，在部署等环节之间建立约束。如果没有明确思路且基础较薄、或不想投入非主营业务成本，可以评估选择一款外部产品，其具备完整的交互控制台、践行一套认同的方法论、最重要的是愿意与客户保持沟通、持续迭代，客户可以和产品一同走向平台工程终态。

平台工程产品化趋势

在海外，开源社区非常火爆，存在不少开源工具如 Argo CD、Backstage，特别是围绕 Backstage 的插件体系非常丰富，已经出现了上百种插件；也有平台编辑类产品 Humanitec，服务于企业平台层中内部开发者平台的核心引擎，是平台工程、团队和组织中的解决方案之一。相比之下，国内的工具链相对复杂，为了**提升端到端的体验，通常需要一个整合层或平台层来更好地组合这些工具。**而且在国内平台工程主要以代码和自我品牌为中心，比如腾讯云的 CODING Orbit 等产品。

以开发者视角为出发点，围绕着代码管理、项目管理、需求设计、缺陷管理、测试管理和制品管理、持续集成、持续交付、应用管理/观测等核心特性构建。在这些平台中，代码和制品形式的流转更多地发生在不同的产品模块之间。每个产品内部都有非常丰富的功能机制，这种商业软件的玩法是开源平台无法做到的。国内外工具与平台最终是否按照平台工程的需求场景演进趋同？让我们拭目以待。