阿里云至暗时刻：为什么说MTTR指标不靠谱？

点击蓝字 关注我们            ///

@GoUpSec

上周末阿里云香港服务器长达十几小时的超长宕机事故对大量云计算企业用户的在线业务产生严重影响，OKGroup创始人徐明星更是把该事件称为“阿里云发展史上重大丑闻”。

对于中国公有云市场的领头羊，如此漫长的宕机恢复时间堪称阿里云的“至暗时刻”，同时也引发了业界对SLA和MTTR等可靠性指标的反思（阿里云的多区多实例SLA高达99.995%，为全球最高标准，MTTR数据也优于很多国内竞争对手）。

本文，我们将结合Verica最新报告谈谈为什么MTTR不是一个靠谱的可靠性指标（部分也适用于SLA/SLO）。

MTTR（平均修复时间）是IT和安全运营人员最常用的可靠性评估指标之一，能够直观地展示和评估系统（例如安全产品）/服务（例如云计算）/团队的可用性和可靠性。

但是，根据Verica的最新报告，MTTR并不适用于评估复杂软件系统的可靠性或安全性，应该被其他更值得信赖的指标所取代。

报告认为，使用MTTR来衡量软件网络故障和中断是不合适的，（部分）原因是：此类系统的无故障时间分布并不均匀。因此，站点可靠性工程（SRE）团队和其他类似团队不该将MTTR作为关键指标使用，而是寻求其他方案，包括服务水平目标（SLO）和事后数据审查。

MTTR指标不能描述复杂系统可靠性

MTTR起源于制造企业，用于测量修复物理组件或设备故障所需的平均时间。这些物理系统有着相对简单，可预测的磨损/故障周期，有助于使用标准化的MTTR来统一评估。但随着时间的推移，MTTR逐渐被应用推广到软件系统，软件公司也将其视为系统可靠性和团队敏捷性/有效性的指标。

Verica研究人员指出，MTTR不是复杂软件系统的合理指标。与物理设备的问题不同，（软件系统）每次故障本质上都是不同的。现代软件系统的运营商经常投资提高其系统的可靠性，却往往被各种“黑天鹅”故障打个措手不及。

“MTTR吸引人的地方在于，它似乎能够清晰，直观地展现混乱和问题，但事实上，由于MTTR基础数据存在太大的差异，无法衡量复杂系统可靠性，”Verica首席研究员Courtney Nash指出：“MTTR很难揭示事件对组织的真实影响，在事件相关人员和团队数量、压力水平、企业需要在技术和组织上做什么来修复它，以及团队能够汲取的经验教训方面可能会有很大差异，”Nash说：“可以想象，同样的技术环境可能会有很多不同的处理方式，这取决于响应者，他们知道或不知道什么，他们的风险偏好和内部压力等。”

根据报告中收集的事件数据，Verica声称能够证明MTTR不能描述复杂软件系统的可靠性，基于Štěpán Davidovič之前发布的SRE事件指标研究（Incident Metrics in SRE:Critically Evaluating MTTR and Friends）中的成果，Verica进行了两次实验来测试MTTR的可靠性。

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

MTTR指标的替代方案

报告称，MTTR这样的单一指标不应该被用来衡量或描述复杂软件系统的可靠性。“无论您计算出了什么样的（不可靠的）MTTR，您仍然需要深入调查事件以了解系统真正发生了什么。企业还需要明白一点，放弃MTTR不仅仅是将一个指标换成另一个指标，而是一种思维方式的转变”，Nash指出：“就像早期的DevOps运动既是一场技术变革也是一场文化变革，数据驱动的敏捷企业需要打破陈规陋习，摒弃MTTR这样的无效指标。”

Vericas在报告列出了一组指标（其中大部分是基于事件分析的），用来取代MTTR描绘系统的可靠性：

• SLO/客户反馈：SLO（服务等级目标）是服务提供商为确保他们为用户提供充分服务（并在需要时投资于可靠性以满足这些承诺）而做出的（服务质量预期）承诺。SLO有助于使技术系统指标与业务目标保持一致，使其成为更有用的可靠性框架。但是，SLO与MTTR存在同样的弱点，包括仅向后看、不包括有关已知风险的信息，以及会忽略不影响SLO的未遂事件。

• 社会技术事件数据：现代社会复杂系统的问题往往是社会技术性（Sociotechnical）的，涉及代码、机器以及开发和维护它们的人。但是，团队倾向于始终如一地仅收集技术数据来评估系统的表现。劳拉·马奎尔博士研究的协调成本概念（链接在文末）极大丰富了社会技术数据的类型和来源。这些数据类型包括事件中涉及的人数、使用的工具、唯一团队和并发事件。在你充分收集分析社会技术类数据之前，你不可能真正客观了解企业应该如何实际应对事件（而不是基于某个人的认知）。

• 事后审查数据：评估组织内部事件分析有效性的另一种方法是跟踪事后审查信息的参与、共享和传播程度，例如阅读报告和自愿参加事后审查会议的人数。

• 未遂事故：软件行业中另一种新兴方法是优先考虑从未遂事故和实际影响客户/用户的事件中学习。“我们从航空业了解到，关注未遂事故可以更深入地了解知识差距、错位的思维模式以及其他形式的组织和技术盲点。然而，发现未遂事故的原因绝非易事。”Verica提供的示例方案包括：“系统X已关闭，但用户不会注意到，因为系统Y在持续时间或中断期间提供缓存或通用内容。这算是事件吗？您的备份系统故障，但团队一个月没有注意到，客户也没有注意到。这算是事件吗？”

参考链接：

• https://www.thevoid.community/report

• https://www.resilience-engineering-association.org/blog/2021/01/12/new-phd-thesis-controlling-the-cognitive-costs-of-coordination-in-large-scale-distributed-software-systems/

• https://sre.google/resources/practices-and-processes/incident-metrics-in-sre/

END

相关阅读