8.4 平台工程与开发者体验

Overview and motivation

平台工程是构建并运营一个内部产品（）内部开发者平台（IDP）（）的学科，其他工程师使用这个平台来构建、发布和运维自己的软件。与其让每个团队各自从零搭建自己的流水线、基础设施和工具，不如由一个专职的平台团队沿着经过良好支持的”黄金路径”提供经过精心设计的自助式能力，“黄金路径”指的是内置了合理默认值的、有明确主张且受支持的路线。开发者体验（DevEx）是与之紧密相关的另一个关注点，即身为组织中的一名工程师是何种感受：开发者从产生想法到运行软件能有多轻松、多快捷，以及沿途有多少摩擦阻碍着他们。

对大型团队而言，这一点之所以重要，是因为认知负荷和摩擦并不会随规模优雅地扩展。当你拥有众多团队时，每位工程师必须周旋的工具、系统和决策数量会不断增长。用不了多久，他们大量的时间就会耗费在基础设施管道搭建和协调工作上，而不是交付价值。没有平台的话，每个团队都会以不一致且重复的方式解决同样的问题，比如资源分配、部署、可观测性和合规。一个好的平台能够吸收这种共有的复杂性。这样团队就可以专注于自己的领域，同时仍然继承组织在安全、可靠性和成本方面的标准。

企业和政府场景与之高度相关，因为这些组织把规模与严格的治理结合在一起。平台正是把合规、安全和审计要求一次性编码为默认铺就的道路、供团队默认遵循的天然场所。这比指望每个团队都自行正确地解读和实施政策要好得多。它把治理从摩擦的来源，变成标准工作流程中一项无形的属性（）这正是大型受监管组织在不失去控制力的前提下快速前进所需要的。

Key principles

把平台当作产品来对待，拥有用户、路线图，以及靠赢得采用而非强制推行的使命。
提供黄金路径：有明确主张、受到良好支持的路线，让正确的做法也是最容易的做法。
让能力实现自助化，使团队不必等待工单和人工交接。
铺路而非设卡；构建能够引导而不阻挡正当工作的护栏。
不懈地降低应用开发者的认知负荷。
用均衡、多维度的信号来衡量开发者体验和生产力。
让黄金路径保持可选，但要足够出色，使团队愿意主动选择它们。

Recommendations

把平台构建为一个产品

最重要的一个转变，是把平台当作服务于内部客户的产品来对待，而不是自上而下强制推行的标准。在实践中，这意味着通过研究和反馈来理解开发者的需求、维护一份路线图、衡量采用率和满意度，并对使用体验负责。一个被强制使用却拖慢团队速度的平台，会招致怨恨并被绕开。一个真正能让团队更快的平台，则会凭口碑自然传播开来。凭质量赢得的采用，才是衡量平台成功最真实的标准。

提供黄金路径和铺好的道路

为常见的旅程定义黄金路径：创建一个新服务、部署它、添加一个数据库、接入可观测性、满足合规要求。黄金路径是一条受支持的、有明确主张的端到端路线，内置了合理的默认值。沿着这些路径，嵌入护栏，也就是安全扫描、策略检查和最佳实践，这样一个遵循该路径的团队就自动是合规且安全的。目标很简单：做某件事最容易的方式，也应当是正确、安全、合规的方式。保持路径可选，这样确实有特殊需求的团队可以偏离它。但要让这些路径足够有吸引力，使大多数团队根本不想偏离。

交付真正的自助式基础设施

通过自助式接口（）一个门户、一个命令行工具、一个 API，或模板化的代码仓库（）来暴露基础设施和能力，从而消除工单加等待的交接方式。开发者应当能够在几分钟内配置出一个合规的环境、从模板启动一个新服务，或申请一个数据库，而不必提交请求、等另一个团队处理几天。自助化正是把平台从瓶颈变成加速器的关键。而这一切之所以行得通，正是因为底层的护栏使自助化变得安全。

提供开发者门户、服务目录和记分卡

一个开发者门户为你提供一个统一的视图：一份包含所有服务及其负责人、文档、依赖关系和健康状况的目录。服务目录让所有权和架构变得可被发现。这在规模化场景下极为宝贵，因为没有人能把整个系统装在脑子里。记分卡依据测试覆盖率、安全态势、待命准备度和文档完整性等标准来衡量每个服务，给团队一幅清晰、客观的画面，说明自己所处的位置以及需要改进什么。这些工具合在一起，减少了工程师花在寻找信息上的时间，也厘清了责任归属。

用均衡的框架衡量开发者体验

抵制单一数字的生产力指标。它们既容易被刻意迎合，也容易造成误导。使用像 SPACE（满意度与幸福感、绩效、活动、沟通与协作、效率与心流）这样的多维度框架，来捕捉开发者体验的真实质地。把来自调查的感知数据与来自工具的系统数据结合起来。把交付指标（比如前置时间和部署频率）与开发者情绪一并追踪。目的是理解并消除摩擦，而不是给个人排名。让人感觉像是在被监视的度量方式，会侵蚀平台所依赖的信任。

把降低认知负荷当作一项一等目标

认知负荷（）开发者完成工作所必须付出的全部脑力（）是平台存在的意义所在，正是要降低这项隐性税负。尽量减少应用开发者必须掌握的工具、概念和上下文切换的数量。提供合理的默认值，使团队需要做的低价值决策更少。构建这样的所有权结构，使每个团队拥有系统中一个有边界、可理解的片段。在评估任何一项平台功能时，问自己一个问题：它是降低了还是增加了将要使用它的团队所承受的负荷？

Trade-offs: pros and cons

选择	优点	缺点	最适用场景
平台即产品（自愿采用）	赢得采用；持续保持有用	达到全面覆盖的速度较慢	大多数组织
强制推行的平台	标准化速度快	招致怨恨；催生规避行为	仅适用于治理需求强烈的场景
购买门户 / 平台	更快见到价值	定制化程度较低；有许可成本	希望获得先发优势的团队
内部自建	完全贴合具体需求	构建和维护成本高	规模大、需求独特的组织
只有严格的黄金路径	一致性最高	阻碍正当的边缘情况	高度统一的工作负载
带逃生舱口的灵活路径	兼顾一致性与自主性	需要管理一定程度的分歧	团队需求多样化的场景

核心张力在于标准化与自主性之间的权衡。标准化太少，每个团队都会以不一致的方式重新发明轮子。标准化太多，则会扼杀那些确实存在不同需求的团队。平台即产品这一理念通过让标准化变得有吸引力、而非强制推行来化解这一矛盾。另一项真实存在的权衡是自建与购买之间的选择。自建内部平台能完全贴合你的具体需求，但会带来可观的持续成本。采用现有工具能更快获得价值，代价是一定程度的定制化能力。

Questions to discuss with your team

你们如何知道平台正在降低认知负荷，而不是又多添了一个需要学习的工具？ 认知负荷是工程师完成工作所必须付出的全部脑力，一个增加了概念和上下文切换的平台，即便看起来令人印象深刻，也可能让情况变得更糟。为每一项功能采用同一个测试：它是降低了还是增加了使用它的团队所承受的负荷？在规模化场景下，这一点具有决定性意义，因为平台面对着数百名工程师，一个令人困惑的抽象每天都在向他们所有人征税。带上证据：一名开发者为交付一次变更需要接触多少个工具和门户、新员工的首次部署耗时，以及关于人们在何处卡壳的定性反馈。如果平台让工具链变得更庞大而不是更精简，你构建的就是一项税负，而不是一条铺好的道路。
你们的记分卡在执行什么标准？一个得分很差的服务实际上会发生什么？ 记分卡依据测试覆盖率、安全态势、待命准备度和文档完整性等预期标准来衡量每个服务，如果红色的分数不带来任何后果，它的价值就会崩塌。决定记分卡纯粹是咨询性的、会纳入评审，还是会限制某些能力，并决定谁来拥有这些标准。在受监管的组织中，记分卡可以让监督机构持续、直观地看到合规态势，取代人工汇报，因此你设定的标准高低至关重要。带上你们的草拟标准，以及一批依据这些标准打分的真实服务，讨论团队在哪些地方会合理地提出异议。一份没有人依据其采取行动的记分卡不过是一个仪表盘；一份与明确预期绑定的记分卡则会改变行为。
你们是把平台当作一个真正的产品来运行（）有路线图、用户研究和采用率指标（）还是当作一项强制命令？ 本章的核心押注是标准化应当是有吸引力的，而不是被强加的，而这一点只有在你把内部工程师当作必须赢得的客户时才能成立。决定谁来为平台扮演产品经理的角色、你们如何收集开发者的需求，以及哪些采用率和满意度数字定义了成功。对大型组织而言，强制推行很有诱惑力，因为它能快速实现标准化，但当工具拖慢人们速度时，它会滋生规避行为和怨恨。带上当前的自愿采用率、满意度信号，以及团队当下反映的主要摩擦点。如果强制命令一旦解除，团队就会立刻抛弃这个平台，那你们建立的就不是一个产品，而是一项政策。
当一个团队走到某条黄金路径的边缘时，逃生舱口是什么？由谁来决定是拓宽这条路径，还是坚守现状？ 黄金路径是一条受支持的、有明确主张的路线，内置了合理的默认值，它的价值来自大多数团队都留在这条路径上，但一条没有出口的路径会变成一道把确实特殊的工作彻底推离平台的闸门。提前商定一个团队如何申请偏离、由谁来评审，以及你们如何区分一次性的例外和一个说明路径本身应当改变的信号。对大型组织而言，这正是一个能够吸纳多样性的平台，与一个在团队感到受阻的那一刻就分裂成影子工具链的平台之间的区别。带上目前偏离路径的团队数量、他们给出的理由，以及一次例外获批需要多长时间。在企业和政府场景中，把每一个逃生舱口与它所绕开的合规控制措施绑定起来，这样一次对铺好道路的偏离，就永远不会悄悄变成对安全或认证基线的偏离。
你们是自建平台还是购买平台？你们是否诚实地核算过任一路径的持续成本？ 平台本身就是一个有生命周期的产品，自建与购买的选择会决定你们未来数年的成本结构：内部门户能完全贴合你们的具体需求，但需要一支有预算保障的团队来维护它，而购买的平台能更快见到价值，代价是许可费用以及一份永远不会完全贴合的适配度。决定哪些能力具有足够的差异化价值值得自建，哪些属于商品化能力应当购买，并随着供应商的成熟而重新审视这条界线。对大型团队而言，赌注在于杠杆效应：一个错误的自建决定会把稀缺的资深工程师淹没在本可由一个现成产品处理的管道工作中，而一个错误的购买决定则会把成百上千名开发者锁死在别人的路线图里。带上每个选项的现实总成本估算，包括维护、升级和退出成本。在企业和政府采购中，加上认证和数据可移植性条款，优先选择那些能让你在不放弃已构建的服务目录和记分卡的情况下离开的合同。
平台团队相对于其所服务的开发者，其资金和规模是如何配置的？预算收紧时它会怎样？ 平台通过杠杆效应赢得自身的价值，因为一个小团队能够放大一个规模大得多的应用开发者群体的生产力，但正是这种定位，使它在财务部门寻求削减开支、且收益又分散而难以归因到某一条产品线时，很容易成为被砍的目标。决定资金模式、平台工程师与其所支持的开发者之间的比例，以及你们将如何用证据而非信念来捍卫这项投资。对大型组织而言，一个资金不足的平台比没有平台更糟：团队依赖它，它却在退化，摩擦随之带着一份依赖关系一并回归。带上平台的人员编制、其采用率和满意度趋势，以及在整个组织范围内被回收的开发者工时估算。在政府和受监管的企业中，应把平台定位为合规被一次性编码的地方，因此削减它并不能省钱，只会把审计和安全工作重新分散到每一个如今必须手工完成这些工作的团队身上。

Sector lens

创业公司。 在工程师人数有限、没有余地可挥霍的情况下，不要组建平台团队；构建一个黄金路径模板仓库，让新服务可以克隆并在一小时内运行起来。预先接好 CI、容器构建、代码检查和健康检查，让它凭借明显节省时间的特性自然传播开来，而不是靠任何人强制推行。尽可能购买每一项商品化能力，让工具链保持精简，把认知负荷而非覆盖率当作需要保护的东西。

小型企业。 你们没有专职的平台专家，预算也紧张，因此要依靠托管平台或有明确主张的云服务产品，而不是自己构建一个内部开发者平台。把这个决定框定为”买”还是”造”，并默认选择”买”：一个购买来的门户及其模板，能在不需要专门团队维护的情况下，为你们的通才工程师提供黄金路径。选择自助式且易于离开的工具，这样更换供应商就不会让你们运行的少数几个服务陷入困境。

企业。 规模和众多团队使投资组合的一致性成为关键目标：一支有资金保障的平台团队、带护栏的黄金路径、自助式资源配置、一份服务目录，以及能让所有权和质量在数百个服务中可见的记分卡。把平台当作一个靠自愿采用赢得青睐的产品来运行，而不是一项滋生规避行为的强制命令，并把安全和合规一次性编码为铺好的道路，使治理默认随行。用均衡的框架衡量开发者体验，并用被回收的开发者工时来捍卫平台的资金投入。

政府。 采购规则、透明度和公共问责制塑造着这个平台。把强制性的安全控制措施和认证要求编码为黄金路径沿途的护栏，这样一个通过自助式门户配置资源的团队，就继承了一个已经满足控制基线的环境，把长达数月的人工认证工作变成了一个基本自动化的步骤。用记分卡为监督机构提供对合规态势的持续、可审计的可见性，并在采购中要求数据可移植性和开放接口，使你们构建的目录和铺好的道路不会被锁定在单一供应商身上。

Examples

创业公司。 一家十二人的创业公司没有平台团队，因此一名资深工程师利用几个周五，构建了一个单一的”新服务”模板仓库，其中预先接好了 CI、Dockerfile、代码检查和健康检查。任何工程师都可以克隆它，并在一小时内让服务在预发布环境中运行起来，而不必从某个旧项目复制配置、再去猜测缺失了什么。这个模板就是黄金路径，由于它明显为每个人节省了时间，整个团队都在没有人下令的情况下自发采用了它。

企业。 一家大型保险公司组建了一支平台团队，上线了一个内部开发者门户。它为每个服务编目，记录其负责人、文档和健康记分卡。新服务从预先接好 CI/CD、安全扫描、可观测性和合规检查的黄金路径模板创建。数据库和环境通过门户自助式配置。新工程师的入职时间从数周缩短到数天，审计证据也自动生成，因为每个服务都遵循同一条铺好的道路。平台的采用是自愿的，它之所以传播开来，是因为使用它的团队明显交付得更快。

政府。 某联邦机构运营着数十项数字服务，搭建了一个共享平台。它把强制性的安全控制措施和认证要求编码为其黄金路径沿途的护栏。一个通过自助式门户配置基础设施的团队，继承的环境已经满足控制基线要求。这把一场原本长达数月的人工认证工作，变成了一个基本自动化的过程。记分卡追踪每个服务的合规态势，让监督机构无需人工汇报就能获得持续的可见性，也把稀缺的专家人手从重复性的评审工作中解放出来。

Business case: motivations, ROI, and TCO

平台工程的投资回报，来自被回收的开发者时间和获得的一致性。当工程师花在对抗基础设施和搜寻信息上的时间减少时，他们那些昂贵的时间中，就有更多被投入到交付产品价值上。更快的入职、更少的重复方案，以及自动化的合规，都转化为可衡量的产能和降低的风险。由于该平台服务于众多团队，对它做的每一项改进都会在整个组织范围内被放大。

在总拥有成本方面，采用平台的成本是一项真实、持续的投入：一支有资金保障的平台团队、工具（自建或购买），以及把平台当作产品持续改进所需的纪律。不采用平台的成本是分散的，却也是巨大的：每个团队反复缴纳同样的基础设施税负、不一致的安全和合规、缓慢的入职过程，以及在琐事上逐渐耗尽的资深工程师。对领导层而言，这个论证最好用杠杆效应来表达。一支规模适中、运营良好的平台团队，能放大一个规模大得多的应用开发者群体的生产力，并把治理一次性编码，而不是依赖每个团队各自把它做对。

Anti-patterns and pitfalls

强加而非提供的平台。 强制推行一个开发者不喜欢的平台，会滋生规避行为和怨恨。
象牙塔式的平台团队。 在不理解真实开发者需求的情况下构建平台，只会产生没有人想要的工具。
闸门而非铺好的道路。 阻挡正当工作的护栏，会促使团队彻底绕开平台。
单一的生产力指标。 把生产力压缩成一个可以被刻意迎合的数字，会扭曲行为并侵蚀信任。
把度量当作监视。 用于给个人排名的 DevEx 指标，会摧毁平台所需要的心理安全感。
没有逃生舱口的黄金路径。 无法为确实特殊的情况提供灵活性的僵化路径，会变成一种障碍。
资金不足的平台。 把平台当作一个副业项目对待，会使其陷入匮乏，并注定带来糟糕的体验。

Maturity model

第 1 级：启动。 不存在任何平台。每个团队都被动地、各自组装自己的工具和基础设施，伴随着大量工单驱动的交接、重复的方案，以及高认知负荷。每个团队都各自以不一致的方式解决资源配置、部署和合规问题。

第 2 级：发展。 一些共享工具、模板和初始仓库开始出现，往往由某位热心的工程师构建，但它们是碎片化的，且部分依赖人工。少数团队采用了某条黄金路径，其他团队则忽视它，自助化程度有限，开发者体验也没有被度量，因此平台的价值只能靠口口相传。

第 3 级：标准化。 一支平台团队运行着有文档记录的黄金路径、自助式资源配置、带有服务目录的开发者门户，以及在全组织范围内应用的记分卡。安全、策略和合规方面的护栏被嵌入铺好的道路中，因此标准工作流程就是合规的工作流程，同样的惯例在各个团队之间保持一致，而不是因团队而异。

第 4 级：管理。 平台被数据度量并依据基线加以控制。采用率、满意度、首次部署耗时、前置时间和部署频率，用 SPACE 等均衡框架、结合调查与系统信号进行追踪；记分卡结果被纳入评审，认知负荷、入职耗时和被回收的开发者工时都相对目标被监控。是否投资或退役某项能力的决策，建立在证据而非主张之上。

第 5 级：编排。 平台是一个成熟的产品，拥有很高的自愿采用率，通过开发者反馈和指标持续改进，并与整个组织的安全、合规和交付规划集成在一起。黄金路径随需求变化而调整，治理是标准工作流程中一项无形的属性，平台团队随着技术和组织的演变，常态化地退役、替换和重新界定各项能力的范围。

Ideas for discussion

在不强制推行的前提下，你们如何为平台赢得采用？如果确实需要强制推行，在什么情况下才是合理的？
哪些黄金路径能率先为你们的团队带来最大价值？
你们如何在不让开发者体验的度量感觉像是监视的前提下进行衡量？
逃生舱口应当设在哪里，才能不把有特殊需求的团队彻底推离平台？
相对于所服务的开发者，一支平台团队的合理规模和资金模式应该是什么样的？
对于你们的开发者门户和工具链，你们如何决定哪些自建、哪些购买？

Key takeaways

把平台当作一个通过让团队真正变快来赢得采用的产品来运行。
提供黄金路径和铺好的道路，让正确、安全、合规的方式也是最容易的方式。
交付真正的自助化，使团队不再等待工单和交接。
使用门户、目录和记分卡，让所有权、架构和质量变得可见。
用像 SPACE 这样均衡的框架衡量开发者体验，绝不使用单一的、可被刻意迎合的数字。
把降低认知负荷当作平台的核心宗旨。

References and further reading

Matthew Skelton and Manuel Pais, Team Topologies.
Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, et al., “The SPACE of Developer Productivity”（论文）。
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate.
Gregor Hohpe, The Software Architect Elevator.
Camille Fournier, The Manager’s Path.
Cloud Native Computing Foundation，平台工程白皮书。