IT 运营社区的游戏规则正在改变，这意味着过去的规则越来越没有意义。组织需要准确、易懂且可操作的指标，并在正确的上下文中衡量运营绩效并推动关键业务转型。
客户使用的现代工具越多，他们管理的事件类型变化越多，将所有这些不同的事件放入一个桶中来计算一个代表运营绩效的平均解决时间就越没有意义，而这正是 IT 部门长期以来所做的事情。
历史和指标
历史表明，在分析信号以防止错误和误解时，上下文至关重要。例如，在 20 世纪 80 年代，瑞典建立了一个系统来分析水听器信号，以提醒他们注意当地瑞典水域中的俄罗斯潜艇。瑞典人使用了一种他们认为代表一类俄罗斯潜艇的声学特征，但实际上是被潜在捕食者吓到的鲱鱼释放的气泡。这种对指标的误解加剧了两国之间的紧张关系，几乎导致了一场战争。
平均修复时间 (MTTR) 是运营经理用来了解实现其目标的主要运营绩效指标。它是一种基于系统可靠性工程的古老指标。MTTR 已被许多行业采用，包括制造业、设施维护，以及最近的 IT 运营，它代表了从事件创建到解决事件所花费的平均时间。
MTTR 的计算方法是将解决所有事件所花费的时间（从事件创建到解决的时间）除以事件总数。
Ophir Ronen, CC BY
MTTR 正如其字面意思：它是所有事件的平均值。MTTR 将高优先级和低优先级的事件混在一起。它还会重复计算每个单独的、未分组的事件，从而导致有偏差的解决时间。它在同一上下文中包含手动解决和自动解决的事件。它将创建后搁置数天（或数月）甚至完全被忽略的事件混在一起。最后，MTTR 包括每一个短暂的突发事件（在 120 秒内自动关闭的事件），这些事件要么是嘈杂的非问题，要么是机器快速解决的事件。
Ophir Ronen, CC BY
MTTR 采用所有事件，无论类型如何，将它们放入一个桶中，将它们全部混合在一起，并计算整个集合的“平均”解决时间。这种过于简单的方法会导致对运营绩效的指示嘈杂、错误且具有误导性。
衡量绩效的新方法
关键事件响应时间 (CIRT) 是一种新的、显着更准确的评估运营绩效的方法。CIRT 侧重于最有可能影响业务的事件，通过使用以下技术从传入信号中剔除噪声：
- 真正影响业务（或可能影响业务）的事件很少是低优先级的，因此排除所有低优先级的事件。
- 真正影响业务的事件很少（如果有的话）由监控工具自动解决，而无需人工干预，因此排除不是由人工解决的事件。
- 在 120 秒内解决的短时、突发和短暂的事件不太可能是真正影响业务的事件，因此排除它们。
- 长时间未被注意到、搁置或忽略（未确认、未解决）的事件很少会影响业务；排除它们。注意：此阈值可以是一个统计得出的、客户特定的数字（例如，高于平均值的两个标准差），以避免使用任意数字。
- 由单独警报生成的单独的、未分组的事件不能代表更大的、影响业务的事件。因此，使用非常保守的阈值（例如，两分钟）来模拟事件分组，以计算响应时间。
应用这些假设对响应时间有什么影响？简而言之，影响非常非常大！
通过关注关键的、影响业务的事件期间的运营绩效，解决时间分布会缩小并大大向左移动，因为现在它处理的是相似类型的事件，而不是所有事件。
因为 MTTR 计算出的响应时间长得多，并且人为地倾斜，所以它是运营绩效的不良指标。另一方面，CIRT 是一种有意的措施，侧重于对业务最重要的事情。
另一个明智的、与 CIRT 一起使用的关键指标是已确认和已解决的事件的百分比。这很重要，因为它验证了 CIRT（或 MTTA/MTTR）是否值得使用。例如，如果 MTTR 结果较低，比如 10 分钟，听起来很棒，但如果只有 42% 的事件得到解决，那么 MTTR 就值得怀疑。
总之，CIRT 以及已确认和已解决事件的百分比构成了一组有价值的指标，让您更好地了解您的运营表现。衡量绩效是提高绩效的第一步，因此这些新措施是实现组织可衡量的持续改进周期的关键。
1 条评论