那个MTTR啊，其实靠不住，这一回真的被揭开了。先给大家讲个事儿：上周末香港那个阿里云服务器出了问题，停机好几个小时呢，惹得大家议论纷纷。OKGroup的创始人徐明星，直接把它形容成“阿里云发展史上的重大丑闻”。你们知道阿里云平时都给自己吹99.995%的SLA，这个指标是特别看重的吧。结果这次事件让人们发现了一个问题，就是即使SLA再高，MTTR也不能完全靠得住，反而给我们留下了一个“至暗时刻”的印象。然后Verica就出来发表报告了，它是和OKGroup合作的。Verica说呢，MTTR这套指标最初是给工厂用的，工厂的机械故障周期比较好预测，所以就挺直观的。但是把它套用到软件系统里就不太合适了。软件系统里有代码、网络还有运维人员这些复杂因素影响着呢。每个故障原因、影响范围还有修复方式都不一样呢，而且高可靠的投资反而可能掩盖一些风险。 Verica还举了例子来证明MTTR不靠谱。他们引用了Štěpán Davidovič的研究做了两个实验：控制样本总量把时间缩短10%，重新算MTTR，结果发现数值基本没变；再引入一些极端异常值事件，比如只有一两个时间特别长的事件，结果MTTR数值就波动很大了。这说明只要故障样本多样了，MTTR就会失去稳定性，看着精准其实很误导人呢。 所以Verica建议我们换个思维方式吧。他们给的替代方案不是简单换指标哦。首先是用SLO（服务等级目标）代替MTTR。SLO是服务提供给用户公开承诺的，用业务语言表达出来的指标。这样用户就能明白自己能不能感知到影响啦。不过要注意的是SLO只能事后回顾啦。然后还有“社会技术事件数据”这个概念，劳拉·马奎尔博士提出了这个概念呢。现代系统故障不只是代码网络的问题还涉及到人和社会因素呢。传统指标只收集告警耗时这些东西忽略了很多社会属性信息。比如事件涉及多少人多少工具多少并发问题还有沟通成本决策节奏什么的都很重要呢。 再来说说未遂事故吧。航空业就发现关注未遂事故比追查已遂事故更能提前堵住漏洞呢。软件领域也应该这样做。比如说系统X宕机被缓存替代用户没有感知算不算事件？备份系统默默故障一个月算不算事件？未遂事故的判定标准看似宽松但能把知识缺口思维定式技术盲区暴露无遗。Verica建议我们把未遂事故纳入组织学习流程（PAI）而不是简单归档。 最后是事后审查让数据流动起来吧。无论收集多少技术指标最终都要回到组织学习循环里面去：阅读报告的人数自愿参加复盘会议的比例知识沉淀为文档脚本检查表数量这些都很重要哦。 总之Verica报告说的很明确啊：单一MTTR无法描述复杂软件系统的可靠性啦！从这次阿里云宕机事件也可以看出高SLA和低MTTR并不等于高用户体验啊！我们要把指标从修复时间转向用户影响组织学习社会技术协调这些方向才是云计算时代真正的可靠性进化方向呢！