第 63 个主题,共 91 个· 软件工程与数字化交付

DORA 指标 (DORA Metrics)

DORA(DevOps Research and Assessment)指标是衡量软件交付表现的四项指标——部署频率、变更前置时间、变更失败率、以及部署失败恢复时间——再加上可靠性作为第五项。它们是该领域验证最充分的交付基准,并且每一项都能直接对应到健康经济学的解读。

为什么重要

DORA 十年的研究将这些指标与组织绩效关联起来。2024 年报告的分群结果显示:**卓越(elite)**团队按需部署(每天多次),从提交到生产环境不到一天,变更失败率约 5%,并能在一小时内恢复;**低绩效(low)**团队每月部署一次或更少,耗时数月,变更失败率约 40%,恢复需要数周。对于医疗系统而言,这些不是 IT 部门的虚荣指标:它们决定了临床价值到达患者手中的速度,以及每次变更所携带的风险大小。

计算方法

部署频率           = 生产环境部署次数 / 时间
变更前置时间        = t(部署) − t(提交),取中位数
变更失败率          = 失败变更数 / 变更总数 × 100
恢复时间 (MTTR)     = t(恢复) − t(故障),取中位数
可靠性              = SLO 达成率(可用性、延迟、正确性)

健康经济学换算:

前置时间   → 延迟成本 (cost-of-delay.md):管线中滞留的周数 × CoD(£ 或 QALY/周)
失败率     → 软件变更的不良事件率:CFR × 每次事故的成本
恢复时间   → 停机危害:MTTR × (损失的临床活动 + 安全风险敞口)/小时
可靠性     → 收益折扣:可用性为 99% 的服务大约只能交付其建模收益的
             0.99——这是软件领域的依从性类比

实例演算

某信托机构患者流程软件团队在一次交付工程投资前后的对比:

                    投资前        投资后
部署                月度          周度
前置时间             6 周         4 天
CFR                 25%          8%
MTTR                2 天         2 小时

该团队每年交付约 30 项改进,每项改进的平均价值为每周 4,000 英镑(CoD)。前置时间缩短约 5.4 周,使每项改进的收益流提前实现:30 × 5.4 × 4,000 ≈ 每年 648,000 英镑的提前交付价值。CFR 改善方面:30 × (0.25 − 0.08) = 每年约减少 5 次失败变更 × 平均每次事故成本 15,000 英镑(临床系统停机、补救)= 每年 76,500 英镑。这项交付投资,是用与任何临床干预相同的货币单位来估值的。

与软件工程的关联

这本身就是软件的一面——值得指出的是其反向映射:DORA 指标就是医院运营指标换了一身外衣。前置时间 ↔ 转诊至治疗;变更失败率 ↔ 再入院率(被打回的工作);MTTR ↔ 急诊响应;部署频率 ↔ 诊所吞吐量。改进方法可以双向迁移,因为两者本质上都是受安全约束的排队系统。同样值得注意的是 DORA 2025 关于 AI 的发现:AI 采用现在与更高的吞吐量相关,但也与更差的稳定性相关——这是一种既有疗效又有副作用的干预措施,恰恰需要本仓库所教授的净效益分析(参见 AI 开发者生产力)。

常见误区

  • 指标造假:用空操作发布来虚抬部署次数;通过不将热修复算作失败来压低 CFR。要像 HTA 定义终点事件一样精确地定义事件。
  • 跨团队排行榜:DORA 分群比较的是实践方式,而不是风险状况不同的团队;一个临床系统团队处于"高"档位可能已是最优,而"卓越"档位反而可能是鲁莽的。
  • 只优化单一指标:速度提升而不考虑 CFR/可靠性,就是吞吐量-稳定性的权衡取舍——应始终将四项指标一并汇报(它们是一张成本-后果表,而不是一个单一分数)。

来源