由于缩略词的使用速度比它们的解释速度还要快，每个IT operations pro都有他们最喜欢的mtt -fill-in- blank。通常，他们会咧嘴一笑，简单地说一句:“当然，这很有道理。”对于我们大多数人来说，这些MTT-somethings '背后的理念是它们提供了讨论某种优化的媒介，通常是在关键业务功能可用性的背景下。
尽管早期版本的平均故障间隔时间(MTBF)被用来表示机器的可靠性，但许多行业已经产生了他们自己的测量方法来帮助指出优化的领域。相应地，IT操作空间有它自己的变化，下面的图像试图描述最常用的重要业务服务的平均时间，并在下面简要说明。
- MTTI / MTTD- 平均时间来识别（或平均时间来检测）
发出环境中出现问题的信号所需的时间 - MTTD- 平均时间决定
在做出解决检测到的问题的决策之前经过的时间 - MTTK-知道的时间不多
在确定问题的根本原因之前所经过的时间 - MTTI- 平均时间无罪
要求业务中断经过时间的独立IT部门是不是在他们的地区 - MTTF-意味着失败的时间
从解决一个问题到出现下一个问题所经过的时间 - MTTR- 平均解决时间（或平均修复时间）
检测到问题后修复问题所需的时间
注意:一种替代方法是，一旦确定了业务影响，就开始度量，因为这个问题可能被认为是不重要的，以后再解决。 - MTTA-平均时间自动化
使用自动化崩溃各个阶段来修复以前的问题所花费的时间 - 平均故障间隔-失败之间的平均时间
经典的从一个问题到后续问题所耗费的时间
毫无疑问，有一些争论的边界的一些，但我希望，它充当开展围绕可用性和正常运行时间富有成效的对话的起点。虽然不同的IT运营管理（ITOM）产品集中于提高不同的方面，最终的回报是消除故障。作为软件定义的IT运营的尝试注入机器学习和人工智能进入IT生态系统，专注于自动化将导致最终用户感知的零个故障。换句话说，数据中心的自我修复性质将提供永远在线的现实的关键业务系统的用户。
如果您有兴趣了解高级IT部门如何利用最新的ITIM平台来减少mtt -任何东西，请考虑加入我的网站GalaxZ18。
