健康经济学指标

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

DORA指标

DORA（DevOps研究与评估）指标是衡量软件交付表现的四项指标——部署频率、变更前置时间、变更失败率，以及部署失败后的恢复时间——再加上作为第五项的可靠性。它们是该领域中经过最充分验证的交付基准，且每一项都能直接对应到健康经济学的解读方式。

为何重要

DORA长达十年的研究，将这些指标与组织绩效直接关联起来。2024年度报告中的分组：**卓越（elite）**团队按需部署（每天多次），从提交到生产环境不足一天，变更失败率约5%，恢复时间不到一小时；**低效（low）**团队每月部署一次或更少，耗时数月，变更失败率约40%，恢复需要数周。对医疗系统而言，这些绝非IT部门自娱自乐的虚荣数字：它们决定了临床价值触达患者的速度，以及每一次变更所携带的风险大小。

计算方法

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

健康经济学层面的转译：

前置时间   → cost-of-delay.md：在流水线中滞留的周数 × 延迟成本（£或QALY/周）
失败率     → 软件变更的"不良事件率"：变更失败率 × 每次事件的成本
恢复时间   → 停机造成的危害：MTTR × (损失的临床活动 + 安全风险敞口)/小时
可靠性     → 效益折扣：一项可用性为99%的服务，实际交付的效益约为其
             建模效益的0.99倍——这正是软件版本的"依从性"

实例演算

某信托机构患者流转软件团队，在进行交付工程投资前后的对比：

                    投资前      投资后
部署频率            每月一次    每周一次
前置时间            6周         4天
变更失败率           25%        8%
MTTR                2天         2小时

该团队每年交付约30项改进，每项改进的平均价值为每周£4,000（参见延迟成本）。前置时间缩短约5.4周，使每一项改进的效益流都提前到来：30 × 5.4 × 4,000 ≈ 每年£648,000的价值被更早交付。变更失败率的改善：30 × (0.25 − 0.08) = 每年约减少5次失败变更 × 每次事件平均成本£15,000（临床系统停机、补救处置） = 每年£76,500。这笔交付工程投资，正是以与任何临床干预完全相同的货币单位来估值的。

与软件工程的联系

这份文档本身就属于软件的那一侧——真正值得指出的，是反向的映射关系：DORA指标其实是披着不同外衣的医院运营指标。前置时间 ↔ 转诊至治疗；变更失败率 ↔ 再入院率（"弹回"的工作）；MTTR ↔ 急诊响应；部署频率 ↔ 门诊吞吐量。改进方法在两个方向上都可以相互迁移，因为二者本质上都是在安全约束下运行的排队系统。同样值得注意的是DORA 2025年度报告关于AI的发现：如今AI的采用与更高的吞吐量相关，却也与更差的稳定性相关——这是一种既有疗效、又有副作用的干预措施，恰恰需要本书所教授的那种净收益分析（参见AI开发者生产力）。

陷阱

  • 指标操纵：通过无实际意义的空发布虚增部署次数；通过不将热修复计入失败来压低变更失败率。应像卫生技术评估界定终点指标那样，精确界定每一类事件。
  • 跨团队排行榜：DORA的分组比较的是实践方式，而非风险状况各异的团队本身；一个处于"高效"分组的临床系统团队，可能已是最优解，而追求"卓越"反而可能是鲁莽之举。
  • 只优化单一指标：只追求速度而不顾变更失败率/可靠性，正是"吞吐量-稳定性"权衡取舍的陷阱——应始终将这四项指标一并报告（它们构成的是一份成本后果表，而非一个单一分数）。

来源