MTTR是什么？或者说为什么别给婴儿喝白兰地

在团队纷纷谈起工作效率的时候，对运维工作者，他们通常喜欢用「故障的平均解决时间」来衡量团队的工作效率。然而这往往是不正确的。一个迅速解决大量突发事故的团队十分高效，而实际上这更有可能意味着该团队的基础设施十分脆弱易损。那我们应该使用什么标准来衡量团队的工作效率呢？

**本文系国内 ITOM 管理平台 OneAPM 翻译整理自Dan Turchin 2015 撰写的文章
《What is MTTR?Or why not to feed the baby cognac》，**

MTTR（平均恢复前时间）是什么？我们不已字面的角度去回答它，这个提问更倾向于它的哲学意义。基于解决突发事故的时间来测量评估工作效率已经过于绝对，显得老旧。就如同大海中的一帆孤舟，漂泊不定，不知方向。

如同禅宗关于只手之声的谜语一般，解谜的要点是首先提问如下问题：

• 什么是突发事故？

• 解决突发事故意味着什么？

• 解决问题是不是越快越好？

我的答案如下:

什么是突发事故？

（突发事故）是对人、进程或事物有负面影响的，被某些非预期行为触发的问题。它们通常是更严重问题的征兆，经常可能导致系统或者业务发生毁灭性的的灾难。并且通常能经由常规方式修复，比如重启机器、重新连接、重启程序三部曲。

但是对于IT运维的目标，并不是通过修复自己制造的问题而获取赞誉，而是经营一个不会出现大量突发事故的健康的服务器环境。由「平均恢复前时间」所驱动的生产运作系统管理通常会误认为，一个迅速解决大量突发事故的团队十分高效，而实际上这更有可能意味着该团队的基础设施十分脆弱易损。

解决突发事故意味着什么？

通常认为解决突发事故是积极举措。然而事实上解决突发事故时，正确的做法是首先判定被评估对象。以「平均恢复前时间」为评估手段可能会掩饰警示，将红灯变为安全的绿灯。其他度量手段，例如平均故障间隔时间，对于判定基础设施是否保持一贯健康运行状态而言，是更佳的度量指标。

迅速解决突发事故是否总是最佳选择？

在IT领域，仅评估影响业务正常运行的时间无异于给婴儿浸有白兰地的奶嘴。虽然孩子迅速停止哭泣，但他的爸爸却可能因此入狱（然而妈妈绝对不会作出给婴儿喂酒的糟糕决断）。

那么，什么是 MTTR（平均恢复前时间）？

（平均恢复前时间）是讨论运营卓越性的基点。它的价值在每个企业中不尽相同，且是众多评价健康进程和基础设施的指标之一。最好的统计方法是计算全时段所有突发事件在「未解决状态」下的时长，而不是事件「被解决」状l态下的时长除以突发事件总数。在后一种情况下，（系统正常运行）持续时间是基于机器时间戳（区别于运营人员提供的状态改变点）进行计算的，此时机器会使用监测数据（作为基线），重启的相同突发事件（或称为震荡）总会被认定为独立突发事件。

请不要把这篇文章看做是 IT 技术准则的无端攻击，请将它看作是一封邀请信，邀请你花半个小时来评估 MTTR 否是与商业价最契合的度量手段。

OneAlert 是北京蓝海讯通科技有限公司旗下产品，中国首个 SaaS 模式的云告警平台，集成国内外主流监控/支撑系统，实现一个平台上集中处理所有IT事件，提升IT可靠性。想了解更多信息，请访问 OneAlert 官网 。

本文转自 OneAPM 官方博客