超越DevOps的平台工程：云计算背景下的平台战略和实施

近年来“平台工程”概念的兴起，标志着企业云战略进一步深化。当前企业已不仅满足于简单地上云、用云。如何在云环境中高效开展IT工作，并进一步解放研发团队的生产力？如何改善企业的云上研发环境与协作？高效的DevOps团队是中心化的还是去中心化？这些更深层次的问题成为许多企业新的关注点。而越来越多的企业发现通过建设平台工程可以更有效融合技术团队，进而赋能企业价值交付与业务发展。

从上云说起

自云计算兴起以来，许多企业经历了从上云，到开始大量使用无服务、托管服务，再到大规模微服务的技术演进之路。在这个过程中，许多企业建立了自己的DevOps体系，并且依托一系列DevOps文化和实践基本解决了项目上云需求的紧迫性与团队缺乏DevOps能力这一矛盾。

随着近年来相关技术的进步，云端基础设施服务的复杂度和体量也在不断上升。由此带来的系统治理压力对团队提出了新的挑战，这其中一个著名的论述是宠物与牛。然而这只是我们面临的诸多挑战之一，不论是在技术层面还是组织层面，新增的云端组件和流量载荷无时无刻不在消耗着团队的工作时间。

尽管如此，研发人员并不想关注基础设施。DevOps文化将大量的基础设施责任与工作赋予给了业务导向的交付团队，而这种去中心化的工作模式使得各个交付团队中负责DevOps工作的人员各自为战，孤立无援。在许多大中型组织中，也随之出现了基础设施和服务治理缺失、系统稳定性降低、研发和DevOps效能浪费等诸多问题。

研发人员不想关注基础设施

相反的，我们也观察到一些企业建立了“独立的DevOps团队”（Separate DevOps team），即不在业务导向的交付团队中配置DevOps能力，而把DevOps人员集中起来组建团队。虽然原本的意图是好的，但这种完全中心化的模式本质上和DevOps文化相矛盾。并且，由于康威法则，它会造成的负面效果包含但不限于延长交付周期，制造效能瓶颈等等。“独立的DevOps团队”在2014年被Thoughtworks“技术雷达”列为Hold (停止采用)。

Thoughtworks“技术雷达”建议停止采用“独立的DevOps团队”

基于以上讨论，随着云服务复杂度日益增长，有限的DevOps能力和有缺陷的组织方式已成为技术团队发展过程中的重要阻碍。我们需要提供一种新的方法来解决这一问题，而问题的关键在于如何平衡好DevOps能力的中心化和去中心化。

什么是平台工程？

平台工程这一概念由来已久，Thoughtworks于2017在“技术雷达”中首次讨论平台工程的产品化和相关团队，并于2021年开始将其标注为Adopt（采纳）。Gartner在其发布的2023年十大战略技术趋势中将其定义为：一套用来构建和运营支持软件交付和生命周期管理的自助式内部开发者平台的机制和架构。

我们认为平台工程的本质是建立一种新的协作模式，从而改善传统DevOps组织架构中相关人员各自为战的现状，并最终达到中心化和去中心化之间的平衡。

平台工程的定义与构成

依托团队拓扑理念，我们认为DevOps能力应该被同时分布在中心团队（平台团队，赋能团队）和非中心团队（业务导向团队，复杂子系统团队）。而团队间可以依托平台进行有效协作。需要额外指出的是这里的中心和非中心更多是指团队运作模式，而不是指团队在组织中的地位。

基于平台工程的团队协作

平台在技术团队的演进中提供足够的透明度、敏捷性，从而引导企业在平台的建设过程中形成适合其业务架构的高效协作模式。并且在这一过程中逐步将知识体系固化到平台中，从而使得工程方式标准化、流程化和规模化并持续改善。

平台工程战略

平台工程的最终实现形式是搭建一个具有通用能力、可复用的平台，以供技术团队使用。通过使用平台提供的基础设施和能力，技术团队可以把更多的时间精力投放在研发对组织业务和顾客有直接价值的功能之上。由于平台功能繁多，各个业务和技术团队的需求不同，平台搭建通常是一个循序渐进、与组织同步演进的过程。我们认为平台工程的演进一般需要经过的三个阶段：

利用平台减少开发运营分歧

随着平台功能的迭代与日趋成熟，它能提供更多的能力并吸引更多的用户频繁使用。一个成功的平台往往可以通过以下几种能力提升开发人员的研发效率和产品发版上线速度：

• 提供自助服务、可扩展的能力用以消除与运营职能的分歧
• 消除无关的认知负担，使产品工程团队能够专注于构建业务能力
• 通过缩短交付周期来实现快速实验和更短的反馈循环
• 启用具有内置合规和治理的适用性功能

针对企业在财务层面与ROI估算上的需求，DORA 在2020年发布的《DevOps转型的投资回报率》白皮书也提供了详细的公式以量化类似转型项目的投资回报：

潜在回报计算公式

我们认为通过类似量化方式得出的ROI估算将对企业在平台工程的投注决策提供高价值的指导意见。

如上所述，一个可用的、高效的平台并非一个技术团队埋头苦干就可以产出的。恰恰相反，一个成功的平台工程需要企业各个组织部门合作、协调、推广并根据实际使用反馈不断迭代。由于工程涉及众多部门，作为牵头者的平台团队更应当紧密关注组织内部潜在的动力和阻碍，并制定策略以系统化管理利益相关因素，从而达到平台效果的最大化。根据我们过往成功的平台工程经验，以下是一些常见的动力和阻碍：

平台工程的动力与阻碍分析

建设平台工程的动力主要来源于组织在战略和业务上的需要，因此我们往往可以把这些动力与企业的具体目标相连。如果平台团队根据具体战略目标提供一个相对最优的解决方案，平台团队便可以说服该战略目标的干系人和工程负责人等关键人员采取平台提供的解决方案。再通过关键人员本身具备的影响力来驱动执行团队作出改变并拥抱平台。由此积累的内部成功案例可以有效扩大平台团队在组织内部的影响力并最终帮助建立内部的忠实用户群体（promoter）。

与此同时平台团队更需要留意并消除工程上会遇到的阻碍。常见的阻碍分三大类：

• 固有组织文化：在平台上进行开发需要对现有工作和协同方式做出改变
• 不明确的投入产出：平台的搭建和维护需要持续开发
• 用户采纳：新平台会带来学习曲线，迁移现有应用亦需要开发投入

平台团队可以协同管理层，通过组织调整、量化投入产出、平台产品化等方式来消除这些障碍，从而控制工程遇到的风险。

不同的组织对平台提供的能力有不一样的需求，然而我们也在过去工程实践中观察到一些共性。我们认为平台工程涵盖并集成了从本地研发环境到生产环境开发、部署、维护和管理操作代码所需的所有技术、安全和治理流程。例如：开发人员环境和工具配置 、源代码与配置管理、项目和工作流管理系统、CI/CD 流水线，认证和授权、运行时、可观察性和监控、生产发版流程、治理自动化护栏等等。

虽然平台的战略目标、服务范围和参与团队一旦确立，平台工程便能以项目形式启动，但我们认为这并不足够。随着外部环境改变，组织业务会改变，而对平台服务的需求也会随之改变。要让平台跟得上技术团队的使用需要，我们认为必须要把平台作为一个产品来开发和演进。以产品管理的方法，收集实际用户的需求，重视产品功能的可用性，制定有优先级的产品路线图，并通过实际使用反馈来不断迭代和推广平台产品。

平台产品运营模型

平台工程组织

组织基于文化驱动。而使用平台将会带来工作方式上的改变，若要让一个平台成功和最大化利用其优势，我们不可避免地要发展新的组织能力和责任。这种发展需要基于组织文化来进行传播和建立。除了传统的DevOps文化之外，平台工程会提出一些额外的倡议：

• 以长期结果来组织工作：我们首先关注目标成果，并建立支持组织结构进行交付。
• 平衡团队自治与问责制：管理层需要将自主权分配给交付体验和构建技术资产的开发团队并提供适当的上下文、护栏和激励措施。
• 以对齐而非设计来领导团队：我们无法设计未来，必须通过迭代来实现。领导层应为全局系统提供对齐整合和优化支持。

基于平台工程与DevOps文化，我们建议参考团队拓扑（Team Topologies）来组织团队，团队拓扑概念是目前业界主流的团队组织方案，其中将团队分为以下四类并基于分类以规范、治理团队间互动，达到有效的团队平衡：

• 平台团队（Platform Team）：建设可信赖的平台以提升业务导向团队的交付速度
• 赋能团队（Enabling Team）：帮助业务导向团队克服障碍
• 业务导向团队（Stream-aligned Team）：在严重依赖技术和数学方面专业知识时组建
• 复杂子系统团队（Complicated Subsystem Team）：与业务领域的部分工作流匹配，处理核心业务逻辑

组织架构示例

在此之中，我们尤其关注赋能团队的成效。他们担负着引导整个技术组织的责任，拥有最广泛的影响面和视野，在很多情况下需要作为驱动者影响整个组织发生转变。

从技术服务于业务的价值观角度，我们认为团队需要制定适应其业务和技术现状的技术原则。然而基于我们的观察，我们认为优秀的平台工程实践团队们一般会具备这些共同点：

• 以客户（终端客户和研发组织）业务需求为导向：需要提供客户可以在实践中使用的能力，而不是为了纯粹解决技术问题。
• 内建安全：帮助并促使技术团队能够更早、更迅速并且持续性的从源头发现并解决安全隐患。
• 优先关注常见问题：需要优先解决组织内常见的问题，以提供可复用的功能和模版供多个团队使用。
• 以标准化来驱动自动化：与架构和工程干系人共同制定标准化解决方案，并通过自动化加速开发流程。
• 自助服务：推进自助服务以减少团队之间的交接，并通过解藕团队来使他们快速独立地行动。

平台工程实施与体验

由于平台工程的作用域很广泛，而每个企业团队的优先级又各不相同，所以整体看来平台工程涉及到的能力非常广泛，其子系统包罗万象，纷繁复杂。为了梳理其中的脉络，我们尝试把平台的实体抽象成两个组件：工具库和知识库。

我们可以认为研发人员在整个研发生态中需要使用的工具以及其带来的体验是一种工具库。平台工程对于如何形成一个集成化、一体化的研发人员体验有着特定的需求，这直接关系到平台的客户，即研发人员群体的满意度。所以优化工具体验，使其流程化和集成化是其中的重要命题之一。

而支撑工具运用，决定具体执行逻辑的，是知识库。这里的知识并非只有文档和图表一类静态载体，而应该同时包含着规则、流程、视图、查询、模型等等动态载体。载体的形式由其消费形式决定。我们认为，平台的本质是知识，而只有经过实践检验的知识才能保证其可靠性与价值。团队应当尝试将知识沉淀入平台，并通过与工具库的集成来高效、稳定、全面地实践和检验知识。只有这样，知识才能不断迭代积累，从而发挥规模化效应，应对未知挑战，提升价值转化速率。

知识与实践 – 平台工程的正向循环

在日常工作中，团队成员应该明确感受到平台提供的支撑：

• IDE中集成了相关代码扫描工具，会帮助尽早发现code smell或安全、性能相关问题。扫描工具的相关规则由知识库统一管理。其标准由赋能团队牵头制定，基础版由平台团队研发并扩散，在广大范围内共享。而继承自该基础版，业务导向团队在项目级别会与赋能团队协商进行一定的客制化修改。这样最终符合公司统一的安全、质量管控标准，又兼顾了各个项目需求的不同。而针对各个团队汇总的客制化设计和优秀实践，平台团队可以进一步浓缩沉淀为新的基础版规则以发布更新到各个团队。
• 类似的，流水线中的各种门禁也会使用类似的方式加以管控。
• 而部分场景下的优秀实践也会基于按需、自愿的原则加以扩展。比如一个复杂子系统团队在研发过程中设计了一套较为先进的算法模型，则赋能团队发现其价值后由平台团队对其进行普适化研发，选择合适的复用方式（API，镜像或源代码），再通过平台扩散到各个团队。
• 统一的仪表板和性能统计口径等有助于跨团队专家知识的借调。如某个业务导向团队在遇到特殊系统相关性能问题时，需要借调复杂子系统团队的专家。如果各团队使用的是统一的性能报表和日志收集体系，则专家可能不需要关注于数据埋点的细节问题而可以直接开展日志和数据分析。相关结论也可以重新融入平台知识库以在日后应对其他团队碰到的类似问题。

我们还观察到，平台工程不仅有效辅助了日常研发，同时在新项目规划、线上突发问题处理等其它场景下，平台工程也实实在在发挥着作用。事实上，在应对未知（如新产品和需求），突发（如线上问题）的时候，团队中的人员往往会需要更多的支持：前者在于未知问题本身具备的额外复杂性和博弈性，而后者在于时间的紧迫性。此时平台工程的价值也进一步被体现出来。

平台工程 – 将复杂DevOps工作移入研发人员舒适区

总结

作为2023年最重要的技术趋势之一，平台工程的作用已经日益凸显。长期以来研发组织所面临的一些系统性问题在这一理念中被广泛而深刻的讨论，并且对于其中一些紧要的问题，我们已经看到了解决的曙光。在可以预见的将来，作为企业IT整体协作的中枢，平台工程将渗透到技术工作的方方面面。Thoughtworks也将持续投入这个领域，并期待与平台工程践行者们深入交流合作。

文/Thoughtworks 张莅程，黄艺琦

更多精彩洞见，请关注公众号Thoughtworks商业洞见！

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/yjsyd/6761.html