平均解决时间（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的一组指标（大多基于事件分析）：
● SLO/客户反馈：SLO是服务提供商做出的承诺，承诺自己为用户提供充分的服务（并在需要时投入增强可靠性以达到这些承诺）。SLO有助于弥合技术系统指标和业务目标，使之成为更有用的可靠性框架。然而，SLO与MTTR存在同样的弱点，比如缺乏前瞻性、未包含已知风险的相关信息，以及忽略不影响SLO的未遂事件。
● 社会技术事件数据：现代复杂系统是社会技术性的，由代码、机器和构建并维护这些东西的人组成。但是，团队往往历来仅收集技术数据来评估这些系统的表现。报告指出：“社会技术数据的一大丰富来源是Laura Maguire博士研究的协调成本概念。这些数据类型包括事件所涉人员数量、使用的工具、各支团队，以及并发事件。在你开始收集此类信息之前，你不会知道企业如何实际应对事件（不同于你认知中的做法）。”
● 事后审查数据：评估企业内部/整个企业事件分析有效性的另一方式是跟踪事后审查信息的参与、共享和传播程度，包括阅读简评和资源参加事后审查会议的人数。
● 未遂事件：重视从未遂事件和实际影响客户/用户的事件中汲取经验教训是软件行业又一新做法。“我们从航空业了解到，关注未遂事件可以加深对知识空白、思维模式失调和其他形式的组织与技术盲点的理解。”不过，确定未遂事件的构成因素绝非易事。Verica给出的示例场景包括：“X系统宕机了，但由于Y系统在事件持续或宕机期间提供了缓存或通用内容，用户并没有注意到出现了什么差错。这还算是一起事件吗？此外，备份故障了，但团队一个月都没发现，客户也没注意到。这又是不是事件呢？”
“转变绝非一朝一夕之功，但最终，我们要诚实面对促成因素和人员在提出解决方案上发挥的作用。”Nash表示，“这听起来很简单，但需要时间，而这些都是可以建立更好指标的具体活动。”
声明：本文来自数世咨询，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
