基于发布数据、可按服务细分的 DORA 指标

大多数工程团队都能告诉你他们发布了什么。但很少有团队能告诉你发布得有多快、多久出一次故障，以及出故障后花了多长时间恢复。部署次数是有的，质量信号却没有。

之所以存在这个盲区，是因为交付效能和架构文档一直分属两个世界。你的 CI/CD 工具了解流水线，你的架构工具了解系统。但两者都不足以回答真正重要的那个问题：你的团队在交付软件这件事上是否越来越好？

DORA 指标弥合了这道鸿沟——而 Archyl 现在可以从你的发布数据中自动计算它们。本文介绍它是如何运作的。至于为什么交付指标本就应该放在架构旁边，请参阅面向架构团队的 DORA 指标。

真正重要的四项指标

2018 年，DORA 团队（DevOps Research and Assessment，现为 Google Cloud 的一部分）发表研究，表明有四项特定指标比其他任何指标都更能预测软件交付效能。此后，它们成为衡量工程效能的行业标准：

部署频率（Deployment Frequency） —— 团队向生产环境部署的频率。精英团队按需部署，每天多次。低效能团队则介于每月一次到每六个月一次之间。

变更前置时间（Lead Time for Changes） —— 从代码提交到生产部署需要多长时间。精英团队以小时计。低效能团队以月计。

变更失败率（Change Failure Rate） —— 在生产环境中导致故障（需要热修复、回滚或补丁）的部署所占的百分比。精英团队保持在 5% 以下。低效能团队超过 46%。

平均恢复时间（MTTR） —— 生产故障发生后，需要多长时间恢复。精英团队在一小时内恢复服务。低效能团队需要一周到一个月。

DORA 的强大之处不在于任何单一指标，而在于四项指标放在一起。一个每天部署十次、却有一半时间把生产环境搞坏的团队，表现并不好。一个零故障、却一个季度只部署一次的团队，又过于保守。这四项指标构成了一张兼顾速度与稳定性的平衡计分卡。

Archyl 中的 DORA：构建在你的发布数据之上

关于 DORA 指标，有一点值得说明：如果你在跟踪发布，原始数据其实已经存在。每一次发布都有时间戳、状态和环境。这就足以自动计算全部四项指标。

如果你一直在使用 Archyl 的发布管理——无论是通过 GitHub Actions、Webhook 还是 REST API——你就已经有了这些数据。我们只需要把账算出来。

部署频率根据给定时间窗口内成功部署到生产环境的次数计算。如果你在过去 30 天里向生产环境发布了 45 次，你的部署频率就是每天 1.5 次。

变更前置时间是从发布被创建（如有提交时间戳则用提交时间戳）到它成功部署到生产环境之间的时间。Archyl 计算该时间段内所有发布的中位数。

变更失败率看的是状态为 Failed 或 Rolled Back 的发布占全部部署的百分比。如果你部署了 40 次，其中 3 次被回滚，你的 CFR 就是 7.5%。

平均恢复时间衡量从一次失败的部署到同一环境下一次成功部署之间的时间。它反映了团队从事故中恢复的速度。

四项指标全部自动计算。无需配置，无需手动输入。只要你的发布在流入 Archyl，DORA 指标就已经在那里了。

DORA 计分卡

每项指标都会依据 DORA 研究确立的基准，被划入四个效能等级之一：

  • Elite —— 顶级效能。你处于全球工程团队的最高梯队。
  • High —— 强劲效能。你领先于大多数团队，但仍有提升空间。
  • Medium —— 平均效能。存在明确的改进方向。
  • Low —— 低于平均。这些指标标出了交付流水线中需要关注的地方。

计分卡让你一目了然：四张卡片、四项指标、四个等级。每张卡片显示当前数值、带颜色标识的效能等级，以及对该等级含义的简短说明。你不需要记住 DORA 的基准——计分卡会替你解读这些数字。

整体效能等级由四项指标的组合计算得出。如果你有三项指标是 Elite、一项是 High，那么整体上你就处于 Elite 等级。

趋势图：方向比位置更重要

DORA 指标的单次快照告诉你现在身处何处。趋势则告诉你正走向何方。DORA 仪表盘包含趋势图，会把每项指标随时间的变化画出来，让你看到情况是在改善、保持稳定还是在恶化。

选择一个时间段——7 天、30 天、90 天或自定义范围——趋势图就会显示你的轨迹。部署频率可能在稳步上升。前置时间可能在一次大规模重构后骤增，但现在正在回落。变更失败率可能稳定在一个健康的水平。

正是趋势，把指标从绩效考核工具变成了持续改进工具。你不是每季度看一次 DORA、然后把它归档进报告里。你每周看趋势，注意到前置时间在悄悄变长，在它变成问题之前就去调查。

按架构细分

因为 Archyl 了解你的 C4 模型，DORA 指标就不局限于项目整体的汇总。你可以把指标限定到某个特定的系统或容器。

想知道仅 Payment Gateway 的部署频率？按该系统筛选即可。好奇 Notification Service 的变更失败率是否比 Account API 高？把它们并排比较。

这正是具备架构感知的指标真正有用的地方。项目整体的 MTTR 为两小时，听起来可能很不错——直到你发现 API Gateway 15 分钟就能恢复，而 Billing Service 要 18 小时。细分后的指标能揭示被平均值掩盖的异常点。

组织级 DORA 概览

对于管理多个项目的工程负责人，组织级 DORA 概览提供了工作区内所有项目的全局视图。

概览顶部是显示整体效能等级的汇总栏，下面是项目卡片网格——每张卡片展示四项 DORA 指标及其各自的等级。你能立刻看出哪些项目处于 Elite 等级，哪些项目正在挣扎。

这不是为了给团队排名，而是为了找出应该在哪里投入。如果其他项目都很稳定，而某个项目的前置时间却在攀升，那就是一个值得调查的信号。如果变更失败率普遍偏高，问题可能是系统性的——共享基础设施、测试缺口或部署工具。

组织视图使用与项目视图相同的时间段选择器，所以在跨项目比较时可以对齐时间范围。

反馈闭环

DORA 指标作为反馈闭环的一部分时效果最好。以下是我们看到团队有效使用它们的方式：

  1. 设置发布跟踪 —— 通过 GitHub Actions、Webhook 或 REST API 把你的 CI/CD 流水线连接到 Archyl。发布会开始自动流入。

  2. 建立基线 —— 积累几周数据后，查看你的 DORA 计分卡。这就是你今天所处的位置。不要评判它——只需记下来。

  3. 观察趋势 —— 每周查看一次。指标是否在朝正确的方向变化？稳定没问题。恶化就是一个信号。

  4. 调查异常 —— 当某项指标发生变化时，把它细分到单个系统。项目整体的变化往往是由一两个服务驱动的。

  5. 迭代 —— 调整你的交付流程，观察指标如何响应。更快的代码评审会缩短前置时间。更好的测试覆盖会降低变更失败率。功能开关会缩短 MTTR。

DORA 研究的关键洞见是：这些指标是结果，而不是目标。你不是靠多部署来提高部署频率——而是靠消除那些让部署变慢或变得危险的阻力。指标告诉你流程改进是否真的奏效。

把点连成线

DORA 指标是 Archyl 这套"反映现实而不只是意图"的架构文档方法中的最新一块拼图。

C4 图展示结构。API 契约展示接口。ADR展示决策。发布管理展示发布了什么。现在，DORA 指标展示你的交付机器运转得有多好。

每一层都为前一层增添了上下文。你图上的一个系统，不再只是一个带箭头的方框——它是一个有定义好的 API、有设计背后文档化决策、有部署历史、有可衡量交付效能的服务。这就是一张图和一个鲜活的架构平台之间的区别。

开始使用

如果你已经在 Archyl 中跟踪发布，DORA 指标现在就可以使用。进入项目的 Releases 页面，切换到 Metrics 标签页。你的计分卡和趋势图已经填好了。

如果你还没有设置发布跟踪，就从那里开始。按照发布管理指南连接你的 CI/CD 流水线，等积累了几周的部署数据后再回到 Metrics 标签页。

要查看组织级洞察，在不选择特定项目的情况下打开 Releases 页面，然后切换到 Metrics 标签页。概览会显示工作区中的所有项目及其各自的 DORA 分数。

你的架构知道存在什么。你的发布知道交付了什么。现在，你的指标知道你交付得有多好。

在发布管理中了解更多关于跟踪部署的内容，或者看看 Architecture Change Requests 如何为你的 C4 模型带来结构化的评审工作流。