MTTR不是复杂软件系统可靠性和安全性的可行标准

平均解决时间（MTTR）不是衡量复杂软件系统可靠性或安全性的可行标准，应该被其他更可信的选项取代。以上结论出自Verica近期发布的一份报告，报告辩称，使用MTTR衡量软件网络故障和宕机并不合适，部分原因在于事件持续时间数据的分布，因为此类系统中的故障并不是随时间均匀出现的。因此，站点可靠性工程（SRE）团队及其他类似角色应当不再将MTTR用作关键指标，应转而考虑服务水平目标（SLO）和事后数据审查等其他策略。

MTTR指标无法描述系统可靠性

Verica的报告指出，MTTR源自制造业，用于测量修复故障实体组件或设备所需的平均时间。然而，此类设备的运行损耗比较简单可测，可以采用标准化的MTTR统一评估。“随着时间流逝，MTTR逐渐用到了软件系统上，软件公司将之视为系统可靠性和团队敏捷性/有效性的指标。”

Verica研究人员预计，MTTR不是复杂软件系统的恰当指标。“不同于实体制造设备，软件系统的故障千奇百怪。现代软件系统运营商经常投入提升其系统的可靠性，却往往被非预期的意外故障搞得措手不及。”

“MTTR挺有吸引力，因为它似乎能明确标示无法简单总结的混乱情况，但MTTR的底层数据差异太大，并不能充做系统可靠性的衡量指标。”Verica首席研究员Courtney Nash解释道，“MTTR也无法告诉我们事件对公司的真正影响，在所涉人员和团队数量、压力水平、修复所需技术和组织工作，以及团队可获得的经验教训方面，每起事件之间差异巨大。”可想而知，取决于响应人员所知或不知，及其风险胃纳和内部压力，同样的技术环境可能会有很多不同的走向。

基于报告中收集的事件数据，Verica声称MTTR无法描述复杂软件系统的可靠性，并根据Štěpán Davidovič之前发布的SRE事件指标研究成果进行了两次实验来测试MTTR的可靠性。结果表明，无论样本量（如事件总数）如何，减少10%的事件持续时间未必能相应缩短算出的MTTR。“我们的结果还凸显了事件持续时间数据的极大差异会对MTTR计算结果产生多么显著的影响。”

MTTR指标的替代方案

报告指出，本就不应该用一个平均数来衡量或代表复杂软件系统的可靠性。“无论你那（不可靠的）MTTR看起来指征了什么，你仍旧需要对事件展开调查，了解自己的系统到底真正发生了什么。而且，放弃MTTR不仅仅是从一个指标转向另一个指标，而是一整套思维方式的转换。”Nash表示，“正如早期的DevOps运动既是技术变革也是文化变革，迎接数据驱动决策并授权员工在必要时付诸变革的企业，会考虑到这种没用的指标并加以调整。”

Verica在报告中列出了可供替代MTTR的一组指标（大多基于事件分析）：

“转变绝非一朝一夕之功，但最终，我们要诚实面对促成因素和人员在提出解决方案上发挥的作用。”Nash表示，“这听起来很简单，但需要时间，而这些都是可以建立更好指标的具体活动。”

参考阅读
2022年网络安全并购交易超450起
ChatGPT爆火出圈带来的AI网络安全的思考
2023年ChatGPT改变信息安全领域的三种姿势
MITRE发布网络韧性系统可视化设计工具CREF Navigator