MTTR无用，CIRT万岁[DevOps]

通过关注对业务有影响的事件，CIRT是衡量运营绩效的更准确方法。

Green graph of measurements

IT操作社区的游戏正在发生变化，这意味着过去的规则变得越来越不合理。组织需要在正确的上下文中提供准确，可理解且可操作的指标，以衡量运营绩效并推动关键业务转型。

使用现代工具的客户越多，管理的事件类型越多，将所有这些不同的事件粉碎到一个存储桶中以计算代表操作性能的平均解决时间的意义就越小。做了很长时间。

历史和指标

历史表明，在分析信号以防止错误和误解时，上下文是关键。例如，在1980年代，瑞典建立了一个系统来分析水听器信号，以提醒他们注意瑞典当地水域中的俄罗斯潜艇。瑞典人使用了他们认为代表了一类俄罗斯潜艇的声学签名，但实际上是鲱鱼在面对潜在掠食者时释放出的气泡。对度量标准的这种误解加剧了国家之间的紧张关系，几乎导致了战争。

Funny fish cartoon

平均解决时间（MTTR）是运营经理用来获得实现目标的洞察力的主要运营绩效指标。 这是一项基于系统可靠性工程的古老措施。 MTTR已在许多行业中采用，包括制造，设施维护以及最近的IT运营，它代表从解决给定时间段内创建事件起的平均时间。

通过将解决所有事件所需的时间（从事件创建到解决的时间）除以事件总数，可以计算出MTTR。

MTTR formula

MTTR就是它所说的：这是所有事件的平均值。 MTTR将高紧急事件和低紧急事件混在一起。 它还会重复计算每个单独的，未分组的事件，并导致解决时间有偏差。 包括在相同上下文中的手动解决的事件和自动解决的事件。 它将创建后几天（或几个月）内提交的事件混在一起，甚至完全忽略掉。 最后，MTTR包含每个微小的瞬态突发事件（在120秒内自动关闭的事件），这些突发事件要么是嘈杂的非问题，要么是由机器快速解决的。

Variability in incident types

MTTR接收所有事件，无论其类型如何，将其放入单个存储桶中，将它们混在一起，然后计算整个事件集中的“平均”解决时间。这种过于简单的方法会导致嘈杂，错误和误导性的操作执行指示。

一种衡量绩效的新方法

关键事件响应时间（CIRT）是一种新的，更加准确的评估运营绩效的方法。 CIRT通过使用以下技术来消除来自传入信号的噪声来关注最有可能影响业务的事件：

真正的影响业务（或潜在影响）的事件很少具有低紧急性，因此请排除所有低紧急性事件。

真正的影响业务的事件很少（如果有的话）通过监视工具自动解决，而无需人工干预，因此请排除未由人类解决的事件。

在120秒内解决的短暂，突发和瞬态事件极不可能是真正影响业务的事件，因此请排除它们。

长时间不被注意，被记录或忽略（未确认，未解决）的事件很少对业务有影响；排除他们。注意：此阈值可以是特定于客户的统计数字（例如，均值上方两个标准差），以避免使用任意数字。

由单独的警报生成的单个，未分组的事件不代表较大的业务影响事件。因此，请以非常保守的阈值（例如两分钟）模拟事件分组，以计算响应时间。

应用这些假设对响应时间有什么影响？简而言之，效果非常非常大！

通过关注关键的，对业务有影响的事件期间的操作性能，解决时间分布会缩小并向左大大偏移，因为现在它正在处理类似类型的事件，而不是所有事件。

由于MTTR会计算更长的人为偏差响应时间，因此它不能很好地指示运营绩效。另一方面，CIRT是针对对业务最重要的事件的有意措施。

与CIRT一起明智使用的另一项关键措施是已确认和解决的事件百分比。这很重要，因为可以验证CIRT（或该问题的MTTA / MTTR）是否值得使用。例如，如果MTTR结果很低，例如10分钟，听起来不错，但如果仅解决了42％的事件，则该MTTR值得怀疑。

总之，CIRT和已确认和已解决的事件百分比构成了一组有价值的指标，这些指标可以更好地了解自己的运营方式。衡量绩效是提高绩效的第一步，因此，这些新措施对于实现组织可衡量的持续改进周期至关重要。