我住在阿姆斯特丹，这是一个紧凑的城市，运河纵横交错，到处都是小桥，偶尔小桥会升起让驳船来回穿梭。它美得令人难以置信，所以散步是一种真正的乐趣。我的办公室在两公里之外，步行大约需要 25 分钟，有时多一点，有时少一点。
像大多数当地人一样，我最终改骑自行车，通勤时间缩短到了 6.5 分钟左右。后来，我找到了一条较短的路线，没有桥，也没有红绿灯；我的通勤时间缩短到了大约 4.8 分钟。
如果你将这些行程随时间绘制出来，你会得到这样一张图：
图 1 每个平坦的部分，或高峰，代表一个稳定的过程（步行、骑车、新路线）。真正的改进表现为清晰的、突然的下降到一个新的、更快的水平。
每个平坦的部分代表一个稳定的过程，步行、骑车、新路线，每个都有其自己的平均值和一些自然的变化。
即使没有什么变化，也没有两次行程完全相同的时间。这种变化只是噪音：风、红灯或等待过桥。
只有当我在正确的时间做出真正的改变，买了一辆自行车，找到了一条新路线，这个过程才转移到一个新的性能水平。
但如果我没有买自行车，而是买双新鞋呢？当然，那不会有太大改变。
软件交付也是如此。
每个团队都有一个由自己的规则、工具和习惯塑造的稳定过程。如果我们应用随机的或不协调的改进，而不是针对真正的瓶颈，它们很少会带来明显的进步。久而久之，这会产生挫败感并失去动力。
可持续的文化改进依赖于三件事：基于结果的指标来衡量真正的进步，专注于瓶颈而不是随机调整，以及评估结果并从中学习的能力。
什么是好
这就是 DevOps 研究和评估（DORA）指标的用武之地。它们基于扎实的研究，并且与期望的结果（团队福利和组织绩效）有一致的、可预测的相关性，如在《加速》（Accelerate）一书和DORA研究计划中所示。我们可以使用 DORA 指标来描述我们的软件开发过程，并得出导致有意义的结果的结论。
DORA 框架由几个关键指标组成。其中，变更前置时间（CLT）显示了团队交付变更的速度。部署频率（DF）显示了团队实际交付的内容。虽然很重要，但 DF 通常更不稳定，受团队规模、假期和正在进行的工作类型的影响。最后，不稳定性指标和可靠性 SLO 作为一种平衡。是的，我们希望走得更快，但绝不能以牺牲稳定性为代价。
图 2 期望的 DORA 指标趋势的高级图示。随着团队改进他们的交付过程，变更前置时间通常会减少，而部署频率会增加。
在我们的软件开发过程中，使用 DORA 指标，我们希望 CLT 下降。我们期望 DF 随时间稳步上升。
过程行为图如何增强 DORA 指标的使用
好消息是，我们可以从统计过程控制中获得很多有用的工具来帮助我们利用数据。其中之一是过程行为图（PBC），由Donald Wheeler提出并推广。
让我们放大一下我通勤过程中骑自行车的部分。
图 3 骑车过程的过程行为图。第 24 次行程的峰值是一个特殊原因，一个异常事件（被罚款）超出了正常变化。
PBC 显示了平均值以及上下限。所有在这些限制内的点代表共因变化，这是正常的波动，如交通或风。任何超出它们的点都表明一个特殊原因，一个异常事件，不是通常过程的一部分。
我喜欢在冬天的清晨早早去上班，所以天还是黑的。有一天，我因为骑车没有开灯而被警察罚款，这是一个明显的特殊原因，一个意外的事件，超出了我的常规。由于我只在荷兰生活了很短的时间，我还没有把骑自行车当作一件严肃的事情，所以警察的检查让我感到惊讶。尽管如此，就我的常规通勤而言，这并没有太大变化，因为再次发生的可能性很低，而且警官处理得非常快（尽管在经济上很痛苦）。我最终修好了车灯，但不是因为我的通勤过程，而是为了安全，一旦我意识到阿姆斯特丹的自行车交通有多拥挤，在黑暗中穿着迷彩模式骑车有多危险。
请注意，解决特殊原因并不能改善过程本身，它只是防止退化或不稳定。为了可持续的改进，我们必须关注当前过程中被认为是正常的部分：共同原因。
除了发现特殊原因外，PBC 还有助于检测变化，即整个系统移动到新的性能水平的时刻。在上面的通勤示例中，这些变化出现在每次引入真正的改进时，如购买自行车或找到更短的路线，这些变化就会表现为平均通勤时间的明显下降。从技术上讲，当几个连续的点落在之前的均值之上或之下时，就会发生变化，表明过程已经发生了根本改变。与一次性的特殊原因不同，变化表明了一个新的“常态”，通常是由自动化或工作流程变化等刻意改进引起的。
爱因斯坦曾经说过，我们不能期望通过做同样的事情得到不同的结果。这正是关键所在：真正的进步，比如将通勤时间从 25 分钟缩短到 6 分钟，只有在挑战系统本身时才会出现。
解释性注释：过程行为图并不能证明因果关系，它只能显示系统在统计上有意义的变化。图表告诉我们变化何时发生，但没有告诉为什么。解释性的联系来自上下文：如果我们知道在那个时间没有其他重大因素发生变化，观察到的变化就成为支持假设的有力证据。一个完全严谨的证明将需要 A/B 风格的实验，这在现实世界的软件开发中往往是不切实际的。在实践中，PBC 提供了一种务实的平衡：不是科学证明，而是坚实的、数据支持的信心，即变革正在按计划发挥作用。
现在，让我们将这个框架付诸行动。下面的实际示例展示了如何在战术和战略上下文中应用 DORA 指标。
案例研究 1：在变更前置时间内发现实际问题与正常噪音
想象一下，一个团队注意到在 2025 年 2 月中旬，CLT（变更前置时间）上升（见下图）。
图 4 变更前置时间的过程行为图，每周汇总。图表显示了一个由几个因素引起的不稳定期：工具损坏、新成员加入和个人问题。
这是麻烦的征兆吗？PBC 说不是；一切都还在正常变化范围内。在快速查看 PR 数据后，团队找到了解释：那个月的大部分工作都涉及到了手动部署和大量摩擦来触及遗留的单体应用。既然已经有了摆脱它的长期计划，就不需要立即采取行动了。
然后，在 3 月下旬，图表再次亮起，这次是真的。PBC 显示了一个清晰的信号，表明有些不寻常的事情正在发生。经过一些挖掘，团队发现了罪魁祸首：部署工具问题，它减缓了整体的发布速度。一旦平台团队修复了这些问题，交付速度就恢复了。
但故事并没有就此结束。在 4 月底和 5 月初，又出现了几次峰值，这次是出于人为原因。一个原因是新队友还没有适应团队在小的、增量变化中的工作方式。同时，另一个队友正在经历影响他们性能和沟通的个人问题。这些因素共同打乱了团队的正常流程，并在 PBC 中显现出来。经过一些有针对性的支持和调整后，流程再次稳定下来。到了 8 月，数据显示系统回到了正常节奏。
不稳定的工具、不稳定的环境或个人情况可能会慢慢积累，可能几周都未被注意到。在这种情况下，PBC 使这些模式变得可见，并给了团队一个在事情变得更糟之前采取行动的机会。
有些人可能会认为，CLT 的 PBC 是一个滞后指标；它基于已经部署到生产的变更。这是真的。但是，团队部署得越频繁，这个工具就越有用，帮助他们更快地发现问题，并根据证据而不是假设采取行动。
案例研究 2：验证大胆的过程变化：结对编程
除了检测问题外，PBC 还有助于用数据而不是观点来确认重大的过程变化。
持续改进的一个核心理念是减少 PR 大小，这带来了许多好处：更快的反馈周期、更容易在中断期间进行诊断，以及更平滑的开发流程。但在小批量工作中这并不是微不足道的，它需要一些技能，比如进行安全的、增量的重构、并行运行更改，以及有效地使用特性标志。为了提高性能，团队已经在这些实践上投入了一段时间。
然而，在某种程度上，团队意识到异步代码审查的开销使得进一步减少 PR 大小变得困难。虽然我们常说较小的 PR 更容易审查，但这只是部分正确。有意义的审查仍然需要理解变更的上下文，而太多的 PR 迫使审查者反复切换上下文。结果，整个过程变得更慢、效率更低。
Stepanovic描述了这种效果，他还强调了一个关键的权衡：“通过异步工作方式，我们被迫在牺牲质量（大 PR）和牺牲吞吐量（小 PR）之间做出权衡”。团队不想牺牲质量或吞吐量，决定尝试结对编程，尽管普遍担心这会降低吞吐量。结果证明并非如此。CLT 下降了 3 倍，而 DF 增加了大约 20%。12 月下旬的一次下降是由于临时的发布冻结。
图 5 一个团队的部署频率和变更前置时间的过程行为图。上面的图表显示了自引入结对编程以来，检测到的向更高性能水平的转变。下面的图表显示，吞吐量不仅没有降低，甚至有所提高。
实验证实了这一假设，并表明最初的担忧是没有根据的。如果没有这些数据，讨论将仍然是主观的：“感觉更快”与“感觉更慢”。PBCs 将直觉转化为证据。
结对编程是一种强大的实践，得到了 Kent Beck 等知名专家和 XP 社区中的许多人支持。然而，根据我的经验，它在现实世界的团队中仍然没有得到充分的利用。其中一个原因是它的 ROI 很难传达：结对编程容易被看作是“两个开发人员做一个人的工作”。没有数据，这种直觉很难被挑战。在我们的案例下，PBC 帮助使影响变得可见，并提供了团队所需的理由。
案例研究 3：测量团队扩展对吞吐量的影响
让我们看看另一个团队。
图 6 一个团队的部署频率和变更前置时间的过程行为图。上面的图表显示，在增加额外资源后检测到吞吐量变化了 60%。
我们在 4 月份增加了新的团队成员，DF 立即上升了大约 60%，而 CLT 保持不变。这是一个好兆头。我们的系统足够成熟，可以在不减慢速度的情况下接纳新成员。这是一个值得庆祝的结果。
三年纵向分析：性能停滞期与策略转变
可持续的改进很少是线性的。它取决于一系列战略决策，这些决策的效果会随时间逐渐显现。有些决策会成功，有些则会失败，而从工具变更到团队人员流动等外部因素，往往会带来暂时的挫折。
通过缩小视角，我们可以看到更宏观的情况：哪些方法奏效，哪些没有，以及团队构成或战略选择如何影响性能。在如此长的时间跨度内，图表不再代表一个单一的稳定过程，而是代表了一系列不同的系统状态。在此背景下，PBC 式分析的价值不在于严格的统计控制，而在于揭示长期变化和性能停滞期。
图 7 过程行为图风格的时间序列，说明了一个团队在近三年的部署频率和变更前置时间中的长期变化和性能停滞期。
尽管团队的主要约束是遗留组件，但只有当迁移与过程和文化变更相结合时，我们才看到有意义的改进。当团队机械地从单体迁移到微服务或微前端时，他们经常复制相同的重量级流程，结果几乎没有改进，甚至退化。
典型的例子包括部署过程，它需要多阶段的手工验证，即使更改是微不足道的，并且完全由一个团队拥有；仍然依赖于缓慢的、强制性的跨团队审查过程的迁移；或者对每个部署实施端到端测试的平台策略，有效地破坏了松耦合。这些决策中的许多都是出于好意，但也有一些反映了围绕信任和控制的文化问题——而它们的影响在你查看这些指标之前往往是看不见的。
当我们查看图 7 中近三年的 DORA 数据时，我们可以区分出三个稳定的性能级别，每个级别对应于一个不同的系统状态，并由主要的过程更改分开：
CLT ≈ 25 小时，DF ≈ 每周 5 次（完成遗留迁移，没有流程变化）。
CLT ≈ 10 小时，DF ≈ 每周 10 次（引入部署自动化）。
CLT ≈ 3 小时，DF ≈ 每周 15 次（引入结对编程）。
每一个平台都代表着一个新的、更高效的系统。第一个主要的转变来自部署自动化，转移到一个模型，在这个模型中，每个合并的更改都直接进入生产，没有手动步骤或批准，建立在早期对遗留迁移、测试和重构的投资之上。第二阶段采用了结对编程，这加速了协作并减少了审查延迟。
团队组成的变化（入职、离职、长期休假）也引入了明显的变化，有时还会出现暂时的退化，突出了交付性能对团队稳定性的敏感程度。
在三年内，CLT 改善了大约十倍，DF 提高了三倍。这种改进是由内部优化驱动的。还能更好吗？可能。更早地采用结对编程可能会更快地获得这些收益。
值得注意的是，团队成员知道这些指标，但没有受到它们的激励。DORA 指标从来没有成为个人目标的一部分，所以没有什么动机去“操纵”这些数字。相反，我们讨论每项倡议时，都会讨论它如何能够解锁更好的工作方式或改善结果。指标是一种温度计，是观察变化的一种方式，而不是优化的目标。这有助于将重点放在产品改进上，而不是追求特定的价值。
与结果建立连接
DORA 指标的优势在于它们易于收集，并且在团队之间保持一致。这使得客观比较性能和跟踪改进成为可能。根据 DORA 研究，这些指标与更广泛的结果（如组织绩效和团队福祉）具有预测性关系。换句话说，在 DORA 指标上得分更高的团队在统计上更有可能实现更好的业务结果并报告更高的满意度。但这种相关性只有在观察大量团队时才能可靠地显现。对于小样本，我们不能自信地宣称因果关系；指标的改进并不自动证明结果的改进。
尽管如此，早期迹象还是令人鼓舞的。在少数已经采用这种方法的团队中，我们已经看到了交付的重大举措数量的明显增加，以及内部调查中报告的更高幸福感。随着更多团队的加入，我们将能够验证这些局部改进是否一致地转化为更广泛的组织成果。
回顾文章开头提到的通勤例子，我最终还是选择了步行。我意识到自己一直在为一个狭窄的指标——旅行时间进行优化，尽管它已经足够好，而对我来说，总体满意度才是更重要的结果。事后看来，一些改进并不是绝对必要的；更早地投资一双好的步行鞋可能比优化速度带来更多价值。
同样的原则适用于软件交付。交付性能只是更广泛价值创造系统的一部分。虽然交付通常是值得解决的初始瓶颈，但一旦改进，约束通常会转移到其他地方。团队可能会发现，真正的限制不再是他们交付的速度有多快，而是他们是否在构建正确的产品，他们从用户那里学习的速度有多快，如何在生产中采用更改，或者对于从事这项工作的人来说，速度有多么的可持续。
如何开始
测量基线。跟踪你的 DORA 指标，并收集三到六个月的数据，以了解正常变化。
探索变化。分析个别 PR 以发现瓶颈而不是症状。
选择实验。选择预期影响和努力平衡的举措，并定义明确的成功指标。
实施和观察。推出变更并寻找统计上有意义的变化，而不是孤立的数据点。
反思和重复。与团队一起审查结果，保留有效的部分，并设计下一个实验。改进是一个循环，而不是一个项目。
结论
我们都有过这样的经历，“感觉更慢”被“感觉更快”反驳，讨论毫无进展。许多有能力的团队一直在努力工作，但数据显示性能平平。有些人因为随机的成功而受到奖励；其他人则因无法控制的结果而受到指责。
正如 W. Edwards Deming 所说：“没有数据，你只是一个有观点的人”。DORA 指标提供了超越意见的数据，而过程行为图显示了如何解释它。它们一起将直觉转化为证据，将进步转化为可见的东西。
这就是团队停止争论噪音并开始有意识地改进的方式。不要只是有自己的观点，而要做一个有答案的人。
本文中的所有图片和图表都是作者根据匿名的真实团队数据创建的原始可视化图。
原文链接：
