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 官方博客

你可能感兴趣的:(云告警,it,运维,三部曲)