作者:Emily Arnott,失败是不可避免的。

数据帮助一流的团队做出正确的决定。分析系统的指标会告诉您在哪里投入时间和资源。一种常见的度量标准是到达 X 的平均时间,或 MTTx。这些指标详细说明了某事发生所需的平均时间。 “x”可以代表系统事件响应过程中的事件或阶段。

然而,MTTx 指标很少能说明系统可靠性的全部情况。要了解 MTTx 指标真正告诉您什么,您需要将它们与其他数据结合起来。在这篇博文中,我们将介绍:

• 什么是常见的 MTTx 指标,为什么要使用它们?

• 依赖 MTTx 指标有哪些问题?

• 如何让 MTTx 指标更有帮助?

• 如何摆脱浅层指标?

• 更好的指标如何帮助建立无可指责的文化

常见类型的 MTTx 指标

[](https://res.cloudinary.com/practicaldev/image/fetch/s--tJL76LaX--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws .com/uploads/articles/hrk34h4f1zhwmim73xaq.png)

依赖 MTTx 指标有哪些问题?

对于每个指标,趋势可以帮助建议在哪里进行改进。例如,如果 MTTD 正在增加,您可能会努力改进您的监控。但是,仅 MTTx 指标不足以识别可靠性趋势。

在电子书 Incident Metrics in SRE 中详细介绍的一项实验中,作者 Štěpán Davidovič 对具有不同事件频率和持续时间的多个系统进行了模拟。他生成了一组假设数据,并比较了每组的 MTTx 指标。目标是确定为改进 MTTx 指标(例如购买工具)所做的更改是否会反映在系统中。

调查结果是决定性的:“MTTx 指标可能会误导你。”正如实验所述,“即使在模拟中,改进总是奏效,38% 的模拟中 A 公司的 MTTR 差异低于零,B 公司为 40%,C 公司为 20%。看看绝对变化在 MTTR 中,看到至少 15 分钟改善的概率分别仅为 49%、50% 和 64%。尽管该场景中的产品有效并缩短了事故发生时间,检测到任何改进的几率都远远超出了 10% 随机侥幸的容忍度。”

这意味着即使您的工具或流程改进_正在工作_,您甚至可能无法检测到它。这使得很难理解什么实际上改善了事件响应。而且,它并没有真正告诉我们有关整体系统可靠性的任何信息。

如何让 MTTx 指标更有帮助?

MTTx 指标在与有关事件的其他信息关联时更有帮助。正如 Blameless SRE 架构师 Kurt Andersen 所建议的那样,“将这些指标与某种形式的事件分类相结合是很有启发性的。”使用您的事件分类过程,您可以分析 MTTx 指标以找出较小的事件子集。

您可以通过以下一些方法对事件进行进一步分类以使用更有意义的数据:

• 事件的严重性

• 如何发现事件(内部或通过客户报告)

• 服务区中断

• 用于响应事件的资源(例如运行手册、备份)

• 事件发生时系统的其他监控数据(如服务器负载)

以下是这些组合如何导致可操作更改的一些示例:

• 如果客户报告的事件的 MTTA 远高于内部检测到的事件,您能否创建更快的管道来处理客户报告?或者,您的监控是否有办法检测到问题,从而降低客户报告的频率?

• 如果使用某个 Runbook 会导致 MTTR 指标降低,那么该 Runbook 是否可以用于其他 Runbook?

• 如果某个服务领域的 MTTD 非常高,您可以实施哪些监控工具来更快地捕获事件?

远离浅层指标

当您对指标进行更深入的分析时,您会发现没有单一的 MTTx 指标可以讲述整个故事。但是,您可以通过更好的方法分析数据,以深入了解您的整体可靠性和事件响应流程。

通过 SLO 关注客户影响

事件发生后您要评估的最重要的事情之一是客户影响。这可能很难确定。可靠性是主观的,取决于客户如何看待您的服务。

要确定对客户满意度的影响,您可以使用 SLI 和 SLO。SLI或服务水平指标,衡量您的服务的关键领域与客户期望相比的表现。SLO或服务水平目标,标志着客户开始因不可靠性而痛苦。

与 MTTx 指标相比,您在 SLO 上的表现通常是更好的可靠性指标。这是因为可靠性由您的用户决定。 SLO 可帮助您了解事件对客户满意度的影响。由于 SLO 是可移动的目标,会随着客户需求的变化而变化,因此您永远不应该发现自己或您的团队的目标是任意数字。修订是设置良好 SLO 的一部分。

检查异常值而不是关注平均值

Kurt 还建议查看异常值而不是平均值:“总的来说,我发现‘集中趋势’不像调查分布中的异常值那样有趣。”尽管它们可能不代表典型事件,但 MTTx 趋势中的异常值可能很有价值。

了解使该事件成为异常值的不同之处。有可能再次发生吗?您可能需要专注于定性而不是定量的方法。 Lorin Hochstein 在博客文章中打破了这个概念。 Lorin 建议寻找“信号”,而不是依靠指标来预防重大事件。使用您团队的专业知识来捕捉值得注意的数据并采取行动。

看看你的事件背后的真实工作故事

在 Adaptive Capacity Labs 的帖子中,John Allspaw 着眼于如何超越浅层数据。他的结论是“有意义的洞察力来自于研究_真实_人们如何在_真实_条件下进行_真实_工作。”单独的指标不能包含实际工作中的许多复杂因素。

John 展示了如何建立对数据的“更深入”的理解。您可以绘制出事件是如何发展和解决的。这比单一指标“混乱”得多,但通常更有洞察力。当这些复杂的表示偏离均值时,应该检查它们。

更好的指标如何帮助建立无可指责的文化

当您依赖肤浅的指标时,您可能需要对系统进行博弈,甚至放弃尝试满足 KPI。团队成员可能会觉得他们的绩效是通过特定(有时是不相关的)指标来衡量的。他们可能会试图仅仅改进该指标而不是实际改进系统。这种现象存在于许多行业,从制造业到医疗保健。

这会导致许多问题:

• 员工不愿提出可能会改善系统的问题,如果这会对指标产生负面影响

• 当指标达到不理想的水平时,员工可能会指责他人以避免被指责

• 如果员工担心会对指标产生负面影响,他们会犹豫冒险或创新

• 员工甚至可能误报数据以人为夸大指标,尤其是在工作、晋升或奖金取决于它的情况下

为了授权和鼓励员工,您需要培养一种无可指责的文化。摆脱浅层指标是这种转变的一部分。强调每个人都有一个共同的客户满意度目标。使用 SLO 作为指导指标可以帮助团队量化这一点。

强调员工或团队的表现没有单一的“分数”。这鼓励团队将事件视为学习的机会,而不是重大挫折。

如果您希望从指标中获得更多收益,我们可以提供帮助。Blameless SLO将事件置于客户满意度的背景下,Reliability Insights允许团队将 MTTx 指标分类为信息量更大的数据子集。要了解如何操作,请随时注册演示。

如果您喜欢这篇博文,请查看以下资源:

• 博客文章:工程师,停止囤积指标

• 博客文章:以下是您需要了解运营状况的指标

• 网络研讨会:了解运营健康状况的现代指标