这 4 个系统可靠性评估指标，可能比 MTTR 更靠谱！

如果要评选研发效能管理中最重要的 10 个度量指标，相信 MTTR（Mean Time to Recover，平均恢复时间）一定榜上有名。

MTTR 代表一定周期内可修复系统不可用状态的平均持续时长，可以帮助企业更好地理解技术团队与研发工作，是评估系统可用性和可靠性的重要指标之一。。LigaAI 详细分享过 MTTR 和 MTBF 等 9 个研发质量管理指标，欢迎点击文章回顾：

1. 介绍 9 个研发质量度量指标
2. 研发质量指标大 PK：MTTR vs MTBF，谁是靠谱王？

但是，Verica 公开事件数据库（VOID）通过对近 600 个组织共享的超过 10,000 个事件进行研究与分析，发现对复杂的软件系统而言，MTTR 可能不是一个合适的管理指标。他们在 The 2022 VOID Report 中是这么说的：

我们认为 MTTR 对于复杂的软件系统来说并不是一个合适的指标，部分原因是系统无故障时间数据的分布以及系统故障不会（像物理组件或设备一样）随着时间的推移而规律出现。

01 MTTR 不适用于评估复杂系统的可靠性

MTTR 起源于制造业，用于衡量修复物理组件或故障设备的平均耗时。制造业的硬件或设备的磨损/故障周期相对规律，更易于管理且可预测性高，有利于使用 MTTR 展开适当标准化和统一评估。随着时间推移，MTTR 逐渐被引入并应用在软件系统管理方面，软件公司也将其视为系统可靠性和团队敏捷性/有效性的指标。

但是，Verica 研究团队怀疑，使用 MTTR 衡量软件网络故障和中断是不合适的，因为软件系统的「故障」不同于物理制造设备的故障，其每个故障本质上都是不同的。这也是为什么尽管在系统可靠性建设上大力投入，现代软件系统的运营商也仍会被意外和异常故障打得措手不及。

Verica 团队基于 Štěpán Davidovič 发布的 SRE 事件指标研究（Incident Metrics in SRE: Critically Evaluating MTTR and Friends），开展了两次实验以验证 MTTR 的有效性和可靠性。

实验结果表明，无论样本容量的大小如何，将事件持续时间减少 10% 并不会导致 MTTR 显著减少；持续时间数据的极端差异会对 MTTR 的计算结果产生显著影响。

02 是否存在 MTTR 的替代指标？

「哪些指标可以取代 MTTR？」

报告回答道，「研发团队不应该试图使用单一指标衡量或描述复杂的社会技术系统的可靠性。 无论计算出怎样的（不可靠的）MTTR，都需要深入调查事件，并了解系统真正发生了什么。」

Verica 团队称，定性事件分析是寻找替代指标的理想方式。基于事件分析，他们列出了 4 个可以代替 MTTR 衡量软件系统可靠性的指标。

1. SLOs 和客户反馈

SLO（Service Level Objectives，服务等级目标）是服务提供商为确保能为用户提供充分服务（并在需要时投资于可靠性以满足承诺）而做出的服务质量预期承诺。SLO 有助于结合技术系统指标与业务目标，使其成为更有用的可靠性框架。

需要注意的是，SLO 并不是 MTTR 的理想替代品。它具有和 MTTR 一样的缺点：

• 无法捕捉不影响 SLO 的未遂事件。
• 只考虑已发生的事件，不包括有关已知风险的信息。
• 随时间推移，导致 SLO 异常的事件发生的随机性很高，因此存在潜在的信噪比问题。

2. 社会技术事件数据

现代社会复杂系统的问题往往是社会技术性的，涉及代码、机器以及开发和维护的人。但是，研发团队总是倾向于只收集技术数据来评估系统表现。

Laura Maguire 博士对「协调成本 Costs of Coordination」的研究极大地丰富了社会技术数据的类型和来源。这些数据类型包括事件涉及的团队数、人数、工具、沟通渠道和并发事件等等。

在开始收集以上分析数据之前，技术团队无法真正地了解组织响应事件的实际方式。收集有关参与人员及其认知负荷的数据，以及所需的工具和技术资源，将有助于更全面地了解系统和团队的弹性。

3. 未遂事故

从未遂事件和实际影响客户/用户的事件中学习也是一种新兴方法。专注于「未遂事故」可以更深入地了解知识差距、思维错位和其他形式的组织和技术盲点。未遂事件相关的信息有助于推进组织变革，从而避免未来发生类似的、更严重的事件。

然而，发现未遂事故的原因绝非易事。下面是一些场景示例:

• 系统 X 已关闭，但用户没有注意到，因为系统 Y 在持续时间或中断期间提供缓存或通用内容。这是一个事件吗？
• 备份系统一个月前发生了故障，至今没有被技术团队或客户发现。这算事件吗？

4. 事后审查数据

评估组织内部事件分析有效性的另一种方法是跟踪事后审查信息的参与、共享和传播程度，例如阅读报告人数、自愿参加事件后审查会议的人数、与事后审查报告相关的代码注释和提交消息/架构图/其他相关事件的报告的数量等等。

03 LigaAI 总结

Verica 团队通过研究发现，MTTR 无法描述复杂软件系统的可靠性。他们解释道，这与系统无故障时间和故障出现时间的不确定性有关。

研发团队不应该试图使用单一指标来衡量或描述复杂的社会技术系统的可靠性，而是应该全面、深入地了解组织响应事件的真实处理手段和过程，并通过定性分析寻找合适的 MTTR 替代指标。

基于事件分析数据，VOID 报告提出四个可以替代 MTTR 的系统可靠性指标：SLOs 和客户反馈、社会技术事件数据、未遂事故和事后审查数据。

LigaAI@SegmentFault 还将分享更多研发效能度量、研发管理实践等干货内容，欢迎关注我们。

LigaAI 助力开发者扬帆远航，点击体验新一代智能研发协作，一起变大变强！