平台工程：降低认知负担，改善开发人员体验提升企业的数字生产力

为了逐步提升数字竞争力，中国的企业机构正在向组装式架构转型，推动了云原生平台、DevOps平台的采用。“平台”和“平台工程”之间有着微妙但十分重要的差别。

平台工程-Gartner十大技术趋势之一

平台工程是一种组织和帮助工程师工作的方法，而平台只是其中的一个组件。平台工程战略是一些大型企业IT战略的重要组成部分。然而，如果采用传统的管理方法，不借助平台工程专家或平台工程人才支持，企业很难真正获得成功，同样，平台的业务价值也很难体现。受以下相关发展趋势的影响，平台工程的重要性日益凸显：

• 平台工程重点关注开发者体验、数字生产力、合规和安全，以及平台治理和可复用性。反之，传统的方式更侧重于架构、新技术和功能，不仅增添了平台复杂性，而且不易被最终用户采用。
• 平台工程旨在为产品团队或开发人员创建用户友好的平台产品，并在高度复杂的系统和流程上提供自助式的服务和功能，以便开发人员更轻松地进行软件的开发和系统运维。

软件开发日益复杂，催生了着力于提高开发人员生产力和体验的工具市场。其中有些工具是从知名科技企业的大规模平台工作中衍生而来，其价值也已经得到了验证。此外，源自Spotify平台工程的Backstage开源项目也正在发展壮大，为服务此市场而获得资金支持的初创企业也越来越多。

企业实施平台工程的必要性

基础设施和运营的复杂性

在过去的二三十年里，中国的软件开发技术栈、工具和流程都得到了显著提升。这些改进为开发人员提供了丰富的基础设施（如计算、网络、存储、云计算、无服务器和边缘计算）和多种开发人员服务（如持续集成/持续开发[CI/CD]、监控等），显著提高了开发敏捷性和数字生产力。

然而，这些颠覆性技术、工具和自主程序改进也逐渐增加了基础设施和运营的复杂性和基础设施现代化需求。基础设施服务的部分运营和配置职责将会暂时（从基础团队）转移到产品开发团队。在中国，数字化转型带来的压力迫使团队花费更多的时间和认知精力在了解云、容器、Kubernetes或CI/CD管道等基础设施或平台服务上，而较少地关注数字产品价值和业务价值的创造。复杂的现代软件工具和架构带来的认知负担日益加重，平台工程旨减少这一负担，并将平台工程原理与基础设施解决方案对应起来，提高开发人员和最终用户的工作能力。

没有平台工程，企业难以满足快速迭代交付需求

目前，越来越多的大型企业机构需要构建和运营复杂的服务组合，如Kubernetes集群、微服务和组装式架构。他们还采用DevOps敏捷的方法，通过新的架构或工具（如自动测试、CI/CD）、微服务架构和服务网格开发数字业务产品，这不仅增加了架构环境的复杂性，而且还会造成重复建设，对于拥有多个子公司但没有集中化IT治理的一些国有集团公司来说尤其如此。

为了提升用户体验，减少在有价值的工作中的摩擦，有远见的企业已经建立了平台（如DevOps平台、云原生平台和云管理平台）。平台工程已经引起了中国CIO的兴趣，许多CIO计划制定平台工程战略，并利用这些战略来更好地管理平台生命周期。

实施平台工程前的建议

• 构建平台工程方法和计划，改善开发人员体验并提高数字生产力，以更好地加快数字化转型。
• 建立专门的平台工程团队，采用产品管理方法管理平台的整个生命周期，实现平台产品即服务。
• 与产品团队或软件开发团队密切合作，确定最终用户的痛点和需求。从最小可行平台（MVP）开始，根据用户反馈和后续需求进行迭代，从而最大程度地减少浪费，并针对有价值的领域进行投资。
• 提前实施架构和安全等控制措施，而不是等平台成型后再采用。让团队选择自觉遵守这些要求，或遵循平台工程中令人信服的“既定路径”。

平台工程成功的三个关键因素

平台产品、平台团队和平台全生命周期的产品管理方法是平台工程成功的三个关键因素。平台团队负责构建和管理整个平台产品，应与最终用户（如产品团队、软件开发团队或业务技术专家）密切合作，以评估最终用户的痛点以及必需的平台能力。

平台工程及其主要组成部分的整体概念性架构

基于此类评估，平台团队应将这些所需的功能构建成共享服务，以供多个产品团队或开发人员同时使用，这样用户就不必自行构建操作环境、工具或流程。这将用户从低价值的工作中解放出来，从而专注于创造业务价值和客户价值。

当平台团队采用产品管理方法时，平台治理也非常重要，特别是对于中国一些高监管的行业（如银行业和国有企业）。合规、安全和数据主权也应纳入数字平台建设中。

采用“产品管理原则”指导平台工程的建设

现代软件架构是由许多不同服务组成的分布式系统。每个应用的底层服务本身就是一个复杂的子系统，而且复杂性每年都在增加。底层服务通常由其他团队构建，或从第三方（如云提供商）处获得。用户和开发人员通常不是构建和运营底层服务的专家，也无需成为工作流所依赖的数百种此类服务的领域专家。许多企业机构都在用户和所需底层服务之间部署了平台。平台工程正是这种模式的演变，采用产品管理原则来指导平台的创建和发展。

平台工程是有关构建和运营自助式内部开发平台的技术。每个分层平台都作为极具吸引力的产品进行管理，以优化开发人员体验和生产力。以下原则对平台工程至关重要：

• 平台即产品：平台必须被视为产品。
• 最小可行平台：平台应从小配置开始，并根据验证后的有效性和使用率进行扩展。
• 需求驱动：平台产品负责人必须建立用户反馈机制以确定需求。
• 自助服务：平台在没有专家或工单的情况下必须依然可用。
• 既定路径：平台应提供一条与安全、架构、合规指导原则相一致的令人信服的指导路径，并且需要易于使用以及可以节省用户时间。
• 专门的平台团队：这些团队应了解客户和提供可预测共享服务的要求。这需要结合开发人员和运营经验，并辅之以安全技能等其他优化开发人员经验所需的技能
• API集成：平台应提供明确且一致的API，以便功能在平台外部进程中的集成和自动化。
• 组装式架构：该平台应设计为组装式架构，便于最终用户使用或按需组合功能。
• 可观测性：该平台应具有可观测性。平台团队将利用数据指标和趋势主动解决运营难题，为未来的平台优化路线图作出贡献。

平台提供了一组精挑的可复用组件、工具、服务和知识，并将其打包以便于用户使用。平台与云原生架构和云计算相关，因为相较于以往的方法，平台能更有效地将支持功能从特定应用的逻辑中分离出来。在类云环境中，资源和能力通常是独立管理的，并与业务紧密集成。这些资源可能包括数据库和对象存储、消息队列和代理、可观测性收集器和仪表板、用户目录和验证系统、任务执行器和协调器等。内部平台不仅向产品团队提供这些资源和能力，而且使应用可以轻松集成这些能力。

image.png

平台工程是一种涉及多个团队和利益相关者的迭代方法。平台工程可以提高开发人员的体验和数字生产力，对中国的数字化转型工作大有裨益。采用平台工程会面临一些挑战：

• 平台团队必须采用敏捷方法，确定需求的优先级，构建多个不同产品团队所需的通用功能，而不是只用于单个团队或开发人员的独特功能。
• 平台团队应获得领导团队的支持或赞助，并体现对业务价值流的影响力。

平台工程的影响

减轻开发人员的此类认知负担

复杂的微服务架构、云原生应用、Kubernetes和基础设施即代码已成为行业标准。每个架构模式、新兴技术栈、工具和开发阶段的简单任务都要求开发人员对其工具链或底层基础架构有端到端的了解。这极大地增加了他们的认知负担，并造成了组织效率低下，如影子运营和冗余。

为了减轻开发人员的此类认知负担，提高数字生产力和开发人员留任率，大多数企业将考虑平台工程并在现有IT环境中引入平台。为进一步提高开发效率及改善开发人员体验，采用平台工程的企业亦可建立内部开发人员平台，为开发人员提供一站式开发体验。企业还可以组合使用技术并将现有工具集成到平台中，在不影响底层的技术和基础设施的情况下，降低开发者的认知负担。

产品管理方法支持采用敏捷实践来管理整个平台生命周期，对于平台工程的成功至关重要。当团队具有决策权并相互合作以实现共同目标时，强制使用技术就有悖于这种文化变革。平台工程采用敏捷文化，并使用具有吸引力的平台来帮助团队。

中国的内部开发平台市场仍处于早期阶段

平台工程的日益普及还将推动工具设计和解决方案市场向平台赋能市场发展，还将对云原生平台、DevOps平台和内部开发人员门户（IDP）市场产生重大影响。中国的内部开发平台市场仍处于早期阶段；但是，越来越多的云原生平台和DevOps平台供应商已经在这个领域投资，以满足当地客户的多样化需求。有些产品或解决方案甚至旨在提供企业级平台，但仍需要平台工程团队为平台定制化做出额外的努力。因此，技能和才能是另一个挑战。

在中国，多数资历较老的IT、软件员工，特别是传统员工在构建平台和产品管理方面经验有限，因此，CIO应制定相关人员配置策略和培训计划，帮助内部IT员工在平台发展和演变过程中学习这些技能，这一点尤其重要。

平台工程的行动指南

• 制定平台战略。 根据企业的IT战略、软件开发团队需求和数字化转型的业务使用场景，确定未来的平台产品。不要仅仅因为追随潮流而构建平台产品。采用平台工程的主要驱动因素应是改善由于摩擦过多的开发工具、复杂的基础设施和云计算、技术和流程而导致的开发人员体验问题。
• 组建专门的平台团队。任命产品负责人，制定平台的战略方向并积极管理产品路线图。与专注于平台架构、平台工程和站点可靠性工程（SRE）等领域的团队成员密切合作，构建具有可复用和组装式功能、工具、共享知识、服务和自动化流程的自助式平台。
• 定义人员配置策略。根据预期平台的价值流，确定平台团队所需技能。必须从企业架构（EA）、SRE、安全和/或数据和分析领域招聘专家。
• 将平台视为产品。与最终用户（如产品团队或软件开发团队）密切合作，分析用户和开发人员使用复杂技术的体验，从而确定痛点。采用敏捷方法（如scrum或看板）来管理多个需求，确定产品团队或最终用户所需的通用或可复用功能，并进行优先级排序。实施最小可行平台以解决最具挑战性的痛点。
• 使平台易于使用并提供自助服务。专注于让平台具有吸引力且易于使用，无需用户提交申请或求助专家。利用内部开发人员门户，轻松发现和使用平台。
• 将安全和架构嵌入平台。安全和架构团队必须“左移”，尽早将自动控件和护栏嵌入生产工作流或既定路径中。
• 使用平台用户反馈和平台指标来跟踪价值交付。持续衡量用户的满意度、采用率、平台成功度，以及平台指标，以确定工作和投资的优先次序。