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