使用平台的团队吞吐量低8%，变更稳定性低14% — 为什么不能把 DORA 的数据读成因果

引言 — 先拆开「采用率90%」这个数字
DORA 2024 实际发现了什么 — 好消息与令人不安的消息
DORA 自己提出的三个假设 — 第三个是关键
2025年，DORA 放弃了「效果」这个词
「平台质量」究竟是怎么测出来的
如何阅读厂商研究 — 以 Puppet 2026 为例
这份数据能说什么，不能说什么
那么周一该做什么
结语
参考资料

引言 — 先拆开「采用率90%」这个数字

到2026年年中，几乎没有人再问要不要做平台工程。争论看起来已经结束了。DORA 的2025年报告把平台章节的核心发现总结为 — 「平台采用几乎无处不在:90%。」拥有专职平台团队的组织占76%，报告称这已经是主导的组织模式。

但首先要看清这个数字到底数的是什么。DORA 在调查中使用的平台定义写在附录里 — 平台是「跨多个应用或服务共享的一组能力」，一家公司内可能存在多个相互重叠的平台，但会被统称为「那个平台」。

按这个定义，全公司共用的一个 Jenkins 就是平台。共享的 Kubernetes 集群是平台，公司内部通用的 CI 模板也是平台。2024年的报告把这一点说得更直白 — 当年的调查把内部开发者平台的定义设得「相当宽泛(quite broad)」，结果89%的受访者被算作在使用内部开发者平台。

所以「采用率90%」并不意味着「90%的组织拥有像 Backstage 那样的门户和黄金路径」，它更接近于「90%的组织有某种共享的东西」。抓住这个区别，后面的数字才能读对。

而真正有意思的是接下来的部分。同一个研究项目报告说，使用平台的一方在吞吐量和稳定性上反而更差。

DORA 2024 实际发现了什么 — 好消息与令人不安的消息

2024年 DORA 报告专门用一整章讲平台工程。当年的调查在全球收到约3,000名从业者的回答。以下直接照搬报告的原话。

好消息这一边:

内部开发者平台的用户个人生产力高8%。
团队绩效高10%。
使用平台时，组织的软件交付与运营绩效高6%。

到这里为止，都是我们预期中的画面。但紧接着的下一句话是这样的 — 「然而，这些收益并非没有代价。吞吐量和变更稳定性分别下降了8%和14%，这是一个令人意外的结果。」

报告甚至专门给这段内容加了一个小标题——「意料之外的缺点(The unexpected downside)」。把数字再拆开看:

吞吐量。 与不使用平台的一方相比，下降约8%。
变更稳定性。 下降14%。报告细致地解释了这意味着什么 — 「使用平台时，变更失败率和返工率显著上升。」

还有一层。在被要求「在整个应用生命周期中必须只使用平台」的受访者中，吞吐量还要再低6%。也就是说，被强制使用平台的一方反而更慢。

而最令人不安的组合是 — 报告说它发现了一条关联：不稳定性与平台结合时，燃尽(burnout)水平会更高。但它随即敲定了一句 — 「这并不意味着平台导致了燃尽。」

这句话是本文全部内容的核心。

DORA 自己提出的三个假设 — 第三个是关键

这正是 DORA 值得称道的地方。当自己的数据得出与自己主张相悖的结果时，报告没有藏起来或含糊带过，而是写下「我们自己也不完全清楚原因」，然后一一列出假设。

第一，机制变多了。 解释是，部署前变更需要通过的环节变多了。用报告的话说，通过内部开发者平台构建和部署，通常会增加系统之间——隐含地也包括团队之间——的「交接(handoff)」次数。代码一旦提交，负责测试、安全检查、部署、监控的不同系统会依次接手。每一次交接都是时间可能插入的机会，因此吞吐量下降，但「完成工作的净能力是增加的」。

第二，被强制的排他性。 就是上面看到的那6%下降。如果平台并不适合某项工作，却仍然必须使用它，那么增加的延迟就直接变成了成本。

第三——而这一点是决定性的——反向因果假设。 照搬报告原话就是:变更不稳定性和燃尽水平较高的团队，往往会为了改善稳定性、减少燃尽而建立平台。还有一句 — 「按这个假设，平台工程是那些存在燃尽和变更不稳定问题的组织的症状(symptomatic)。」

值得细细琢磨。如果这是真的，箭头方向就反了。不是平台造成了不稳定，而是不稳定的组织造就了平台。就像医院里病人多，并不意味着是医院制造了疾病。

而仅凭这份问卷数据，没有办法区分这两个方向。仅凭某一时间点的一张快照，「平台 → 不稳定」和「不稳定 → 平台」看起来是完全相同的相关关系。

关于稳定性下降，报告同样留了几条不同的解释路径。一种是乐观的解读 — 有了平台后，团队会更有信心：即使推出坏的变更也能快速恢复，于是更愿意做实验、更频繁地推送变更。在这种情况下，变更失败率的上升不是坏信号，而是实验增多的结果。另一种是悲观的解读 — 平台提供了自动化的测试执行，但如果应用团队没有真正改进自己的测试、只是一味追求吞吐量，那坏的变更就会直接通过，然后以返工的形式返回来。

同样的数字支撑着两个截然相反的故事。与其说这是数据的缺陷，不如说这本来就是这类数据能说的话的上限。

还有一点，2024年报告里有一个不常被引用、但很有用的发现。把平台的「年龄」一起看，曲线呈 J 形 — 平台项目初期绩效上升，随后经历下滑与恢复，平台逐渐成熟。报告把这称为典型的转型项目模式——「先实现早期收益，随后遇到困难」。报告也写道，从长期看生产力收益会保持下去。如果有组织因为第二年数字变差就想解散平台团队，展示这条 J 曲线也许会有帮助。

关于什么真正带来收益，报告的发现也很具体。开发者独立性——定义为「开发者无需依赖赋能团队(enabling team)，就能在整个应用生命周期中完成自己工作的能力」——一旦具备，个人和团队两个层面的生产力都会提高5%。相比之下，专职平台团队的存在对个人生产力的影响微乎其微，只在团队层面带来6%的收益。而不收集对平台的反馈，被明确指出会产生负面影响。

2025年，DORA 放弃了「效果」这个词

2025年报告于2025年9月发布。样本量为4,867人(报告的说法是「近5,000人」)，同时还配有超过100小时的定性数据。

这份报告里最值得关注的地方，不是平台章节，而是一条脚注。第20条脚注原文照搬如下:

去年，我们使用了「效果(effects)」这样的措辞。但今年，我们想用「比较(comparisons)」的语言来表达。虽然我们努力创造能够进行因果表述的条件，但我们不想给人一种错误的印象，好像我们已经理解了背后的因果结构。我们偶尔仍会使用因果语言，但归根结底，我们做的是比较。

它援引 Gelman 和 Hill 的《Regression and Other Stories》作为依据 — 观察到的是一种观察性模式，「对回归系数最安全的解读方式是把它当作比较。」

这并不常见。一个每年调查数千人、靠卖报告为生的研究项目，主动把自己措辞的强度降了一档。然而，引用这份报告的文章和会议演示，几乎无一例外地把它翻译回因果语言——「平台提升了组织绩效」——尽管原文明确写的是「比较」。

平台章节的内容同样诚实。2025年报告是这样总结2024年的发现的 — 平台对组织绩效和生产力有正面影响，但「这些收益伴随着权衡:软件交付不稳定性增加，吞吐量下降。」

而在2025年的数据里，这个模式并没有消失。报告写道 — 「与以往的研究一致，更好的平台与软件交付不稳定性的小幅但可靠的上升相关联，这意味着更高的变更失败率和更多的返工。」

这一次 DORA 的解读偏向乐观 — 它提出这种不稳定性的上升「可能是健康、快速系统的一个特征」，是一种风险补偿(risk compensation):平台让从失败中恢复变得又快又便宜，于是团队愿意做更多实验，容忍更多小的失败。这是一个说得通的解读。但它同样是解读，不是测量结果。

「平台质量」究竟是怎么测出来的

2025年报告的头条发现是这样的 — 高质量的内部平台会放大 AI 采用带来的效果。更准确地说，当平台质量低时，AI 采用对组织绩效的影响可以忽略不计;当平台质量高时，这种影响强烈且为正。这正是 Google Cloud 博客宣传的那个发现 — 「高质量内部平台与实现 AI 价值的能力之间存在直接相关性。」

那么「平台质量」是怎么测量的呢?报告正文这样解释 — 平台质量被测量为一个单一分数，代表受访者认为自己的平台具备的12项特征的数量。

附录里列出了这些题目，都挂在「你的平台在多大程度上表现出以下特征?」这个问题下面。

- 平台帮助构建和运营可靠的应用与服务
- 平台帮助构建和运营安全的应用与服务
- 平台的 UI 清晰、简洁
- 平台提供了独立工作所需的工具和信息
- 平台的行为方式符合我的预期
- 平台帮助遵循所需的流程(代码评审、安全审批等)
- 平台就我的工作成果给出清晰的反馈
- 在平台上完成的工作自动化程度很高
- 平台团队会依据我给出的反馈采取行动
- 平台易于使用
- 平台有效地抽象了底层基础设施的复杂性

读一遍就能看出，这些全都是主观感知。「平台易于使用」「行为方式符合我的预期」——这些不是被测量出来的指标，而是开发者的主观感受。这本身没有恶意，开发者体验本来就是主观的，去问这些问题也是正当的。

问题在于，结果变量那一边同样是主观的。附录中「我们如何评估结果」这一节写道，组织绩效(organizational performance)是通过这样的问题测量的 — 「在过去一年里，相对于目标，你的组织在以下方面表现如何?」而具体项目包括:组织整体绩效、整体盈利能力、组织与使命目标的达成情况、客户满意度、运营效率、产品/服务质量。

也就是说，这不是经过审计的财务报表，而是受访者用李克特量表回答的、他们对自家公司相对于目标盈利能力表现的主观感受。生产力、代码质量、个人有效性，附录里也全部明确标注为「self-assessed(自我评估)」。

于是，「高质量平台提升组织绩效」这句话的实际内容变成了 — 给自己平台打高分的人，也倾向于给自己公司打高分。 这依然是一个有意义的发现。但离因果主张还很远。也许是公司经营得好，才有余力投资平台;也可能只是一个对公司整体持正面看法的人，在所有问题上都给出了偏高的评分(这就是所谓的共同方法偏差)。

样本的招募方式也值得留意。正如报告方法论章节自己披露的那样，DORA 通过两条渠道招募受访者 — 一条是通过博客、邮件、社交媒体的「自然(organic)」渠道，其中包括请社区帮忙扩散的滚雪球抽样;另一条是作为补充的面板(panel)渠道。这不是概率抽样。处于 DORA 社交媒体和社区触达范围内的人——也就是已经参与 DevOps 讨论的人——会被过度抽样。定性访谈那一侧的偏差更明显 — 报告自己披露，78名访谈对象中有76人身处美国，报告将其归因于访谈者的语言能力和日程安排上的限制。

最后，这份报告的发布方也需要点明。2025年 DORA 报告由 Google Cloud 发布(版权标注为「Google LLC」，采用 CC BY-NC-SA 4.0 协议)，研究合作方列出了 IT Revolution、GitHub、GitLab、SkillBench、Workhelix。销售云服务和开发者工具的公司，赞助了一项最终得出「投资平台和 AI」结论的研究。DORA 的方法论在这个行业里属于比较严谨的一类，这一点是事实;这种利益冲突的存在，也是事实。两者都需要记住。

如何阅读厂商研究 — 以 Puppet 2026 为例

有了对照对象，才有基线。来看2026年发布的 Puppet(Perforce)的 State of DevOps Report: Platform Engineering Edition 2026。头条数字如下:

平台工程成熟的组织中，73%表示其成熟度推动了 AI 的成功，而在不成熟的组织中这一比例是44%。
66%的组织正在将 AI 应用到基础设施工作流中，但只有31%报告实现了完全自主运营;在标准化的内部开发者平台环境下，这一比例升至44%。
平台成熟的组织中，79%报告拥有成熟的治理机制，而不成熟的组织中这一比例是14%。
成熟组织中81%表示信任 AI，不成熟组织为48%。在标准化的 IDP 环境下升至92%，在拥有正式治理机制的组织中升至94%，而在临时拼凑式治理下只有51%。

数字本身是准确的——我在页面原文中逐一核对过。问题在于，这些数字能说明什么。

先看样本。打开方法论页面会看到这样一句话 — 「本研究通过一项时长20分钟的在线调查完成，调查对象为820名全球 IT 决策者(ITDM)、采购影响者以及 DevOps 从业者。」

采购影响者被明确纳入了样本。一家销售基础设施自动化产品的公司，向能影响采购决策的人，询问平台成熟度是否是一件好事。这并不意味着数字本身有错。但这份样本，与其说反映「开发者如何体验平台」，不如说更接近「采购相关人员相信什么」。

而同一页面的「Limitations(局限性)」一节，全部内容就是这一句话 — 「结果反映的是自我报告的实践与认知。」

一句话。DORA 为因果语言加脚注、引用 Gelman、主动调低自己措辞的强度，而这里，一项820人调查的局限性只用一行字就处理完了。这正是阅读厂商研究时的一个实用信号——局限性一节的篇幅长短，是判断该研究可信度的一个相当不错的近似指标。

内容层面也有需要留意的地方。「平台成熟组织中79%报告拥有成熟治理，不成熟组织为14%」这句话里，成熟度和治理是由谁判定的?是同一批受访者。而如果成熟度模型本身就把治理作为成熟度的一个组成部分，那这个相关关系与其说是发现，不如说更接近于定义本身。我没能把 Puppet 的成熟度模型定义完整核实到底，所以不会断言就是如此。但每次遇到这种「成熟的组织在 X 方面也做得好」的句式，都应该问一句——X 是不是已经内含在成熟度的定义里了?

「73%表示成熟度推动了 AI 的成功」也是同样的道理。这不是对 AI 成功的测量，而是对人们信念的测量。这是两件不同的事情。

这份数据能说什么，不能说什么

梳理一下。

能说的:

几乎所有组织都拥有某种可以称为平台的共享能力(按宽泛定义为90%)。专职平台团队也以76%成为主导模式。
表示自己使用平台的人，倾向于给自己的生产力和团队绩效打更高的分(以2024年数据为准，分别为8%和10%)。
与此同时，表示自己使用平台的人报告的吞吐量和变更稳定性更低(分别为8%和14%)。这一模式的方向在2025年依然保持。
把自己平台评为高质量的人，报告的 AI 采用与组织绩效之间的关联更强。
开发者独立性是反复出现的信号。无需依赖赋能团队就能完成工作时，生产力高出5%。

不能说的:

「采用平台会使吞吐量下降8%。」箭头的方向并未确定。DORA 自己明确把反向因果假设留在了桌面上。
「高质量平台提升组织绩效。」DORA 在2025年恰恰选择了避免这种措辞。这是比较，不是效果。
「平台成熟度造就 AI 的成功。」这是自评为成熟的那些人相信如此的一份报告。
「我们公司也会提升8%。」这不是概率抽样，你的公司也不在样本里。

再补充一点，所有这些数字都是李克特量表上标准化差异转换成的百分比，不是用秒表测出来的。「吞吐量下降8%」并不是数了部署次数、发现少了8%，而是指与吞吐量相关的题目的回答分数低了这么多。

那么周一该做什么

本文的意思不是「不要做平台工程」。在采用率高达90%的情况下，那种建议毫无意义。但把这些研究读透之后，确实能提炼出几条可以落地的做法。

测量你自己的数据。 这是第一条，也是最重要的一条。DORA 的样本里没有你的公司。而且，调查里的「吞吐量」和你 CI 日志里的部署次数是两回事。好消息是，后者可以直接数出来。在平台上线前后，实际测量各团队的部署频率和变更失败率，会比别人的李克特量表提供好得多的依据。

不要强制排他性。 这是数据里最可操作的一条。被要求只能使用平台的受访者报告吞吐量下降了6%。黄金路径应该是最容易走的路，而不是唯一的路。让平台可以被绕过，而绕过发生的那些时刻，恰恰是路线图的输入。

数一数交接次数。 DORA 的第一个假设把吞吐量下降归因于交接次数增加。这是可验证的。实际画出从提交到生产环境之间，一次变更要跨越多少系统和团队边界、每个边界的等待时间是多少。如果等待时间远超实际执行时间，那就是你的8%。

把开发者独立性当作一个指标。 这是一个反复出现的信号。「不依赖赋能团队能否完成这项工作」不需要问卷也能问出来，也可以直接从工单系统里数出来——落到平台团队头上的「帮我做一下这个」工单的比例，本质上就是独立性的反面。2024年报告把收集反馈本身列为成功因素、把不收集列为负面因素，也是同一个逻辑。这个话题我在以 Backstage 为基础搭建 IDP(一) — 软件目录就是一切一文里从工具角度另外展开过。

如果不稳定性上升了，先分清是哪个方向。 DORA 把两种解读都留了下来 — 是实验增多带来了更多小的失败(健康的风险补偿)，还是坏的变更直接通过了(测试被放任不管的结果)。这在你自己的组织里是可以核实的。看失败变更的恢复时间和用户影响。如果恢复得快、用户没感觉到，更接近前者;如果回滚耗时长、客户开了工单，则更接近后者。

不要被第二年的下滑吓到。 J 曲线是一个可预期的模式。但把 J 曲线当成一切低迷的万能借口也不合适——提前写下预计恢复出现的时间点，到时候诚实地去核实。

结语

这篇文章想说的其实只有一件事。我们这个行业里最常被引用的平台工程证据，是一份问卷。是从一个非概率抽样的群体中、在某一个时间点上收集来的自我报告认知。而制作这份问卷的人，比我们更清楚这一点，所以到了2025年，他们干脆不再使用「效果」这个词。

然而，每当这份报告被搬进会议演示或内部提案时，它总会变成一句因果陈述 — 「根据 DORA 的数据，平台能把组织绩效提高6%。」原文并没有这么写。

与此同时，也要警惕反方向的过度修正。「反正是问卷，没有意义」同样是错的。5,000名从业者一致朝同一个方向报告，这件事本身就是信息。平台与不稳定性之间的关联在2024年和2025年都被复现，这也是信息。只是这些信息没有告诉我们「是什么导致了什么」。

最诚实的态度，似乎就是照搬 DORA 自己的态度 — 我们在做比较，我们不清楚因果结构，存在多个假设，其中一个的箭头可能是反的。在此基础上，我们真正能做的，是数清楚自己组织里可以数的东西，而不是引用别人问卷里的数字。