# 跟线上事故相关的几个指标


最近业界比较流行面向指标的开发，据我所知在一些大厂，所有的开发过程指标和结果指标都要被明确定义出来并进行统计。

这里无意去罗列各种过程指标和结果指标，只想稍微分享一下跟线上事故相关的几个指标。

## 事故量度指标

事故量度指标帮助我们评估整个系统的表现。它们通过事故数量和时间频率,反映了系统的可靠性。然而,事故量度指标并不能让我们知晓我们对事故预案的准备程度。

### ✅ 告警转化率(Alert-to-Incident Ratio)

这个指标也被称为告警转换率，它对团队的健康状况至关重要。虽然我们强调快速响应每一个告警的重要性，但过多的告警可能会适得其反。当告警数量过多时，团队成员可能会产生"告警疲劳"，这不仅会影响团队的整体效率，还可能削弱我们的可靠性策略。

长期处于高压状态下的团队成员容易感到精疲力竭，当真正严重的事故发生时，他们可能无法以最佳状态应对。这就是为什么我们需要密切关注告警转换率的原因。

如果我们发现大量告警最终并未演变成实际事故，那就意味着我们需要重新审视告警机制了。找到合适的平衡点并非易事，这需要我们不断调整和优化可观测性工具链。正因如此，持续监控和分析告警转换率变得尤为重要，它能帮助我们及时发现问题，并做出必要的调整。

### 👻 单位时间事故数(Incidents Over Time)

这个指标简单地统计了特定时期内的事故发生次数。虽然看似直观，但单独使用时往往缺乏深度洞察。有趣的是，这个数据常常引起 SRE 团队之外人员的关注，但我们要警惕它可能变成一个华而不实的指标。

需要注意的是，某个月份或季度的事故数量并不能直接反映系统的可靠性。这些数字的波动可能与业务的季节性特点有关，或者受到一些我们无法掌控的外部因素影响。

不过，跟踪事故数量的变化趋势确实有其价值。它能帮助我们评估当前的值班安排是否合理，以及是否需要增加人手支持。为了保护团队不被过度劳累，很多公司都会设定每个值班轮次最多处理 2 起事故的上限。这种做法既能确保及时响应，又能避免团队成员疲惫不堪。

### ✅ 平均故障间隔时间(MTBF)

Mean Time Between Failures

MTBF（平均故障间隔时间）是一个重要的可靠性指标，它计算的是系统或某个组件在两次故障之间的平均时间。想象一下工厂里的安全记分牌，上面记录着"已安全运行天数"，MTBF 的概念与之类似。这个指标之所以能够很好地反映系统可靠性，是因为它直观地展示了系统出现故障的频率。

MTBF 的应用非常广泛。通过分析这个指标，我们可以：

1. 对系统未来的可靠性进行预测
2. 制定更加合理的预防性维护计划
3. 比较不同组件的可靠性表现

特别值得注意的是，当我们发现某些组件的 MTBF 明显低于其他部分时，这就为我们提供了强有力的数据支持。利用这些数据，我们可以说服相关方投入资源，对这些问题频发的组件进行深入分析和改进。这种数据驱动的决策方法，能够帮助我们更加精准地提升系统的整体可靠性。

## 事故响应指标

事故响应指标是衡量我们处理事故能力的重要标尺。通过这些指标，我们可以清晰地看到团队在应对事故时的表现，同时也能发现我们的工具链中可能存在的不足之处。这些洞察为我们持续改进事故响应流程提供了方向。

### 👻 平均确认时间（MTTA）

Mean Time To Acknowledge

想知道你的团队对告警的反应有多快吗？平均确认时间（MTTA）就是答案。这个指标精确地测量了从系统发出告警到团队成员确认接收之间的时间。

虽然 MTTA 是个重要指标，但它更多地反映了你的值班系统的设置是否合理。如果你发现 MTTA 高于预期，那可能就需要重新审视你的值班轮换安排和升级策略了。

不过，使用 MTTA 时要小心，因为它容易被值班工程师"钻空子"。如果你为 MTTA 设定了具体目标，工程师们可能会为了达标而快速确认告警，但这并不能保证他们会有效地处理整个事故直到解决。换句话说，快速确认不等于高效解决。

因此，在使用 MTTA 时，我们需要全面考虑，将其与其他指标结合使用，以获得更全面的事故响应效率评估。

### ✅ 平均解决时间（MTTR）

Mean Time To Resolve

在所有事故响应指标中，MTTR 无疑是当之无愧的明星。它代表平均解决、恢复或修复时间。几乎所有推销 SRE 相关工具的人都会强调 MTTR 的重要性，因为从一线事故指挥到高层管理，每个人都关心一个核心问题：我们能多快解决问题？

MTTR 计算的是从确认事故到最终解决的平均时间。它之所以如此重要，是因为它直接反映了我们处理事故的效率。更快的 MTTR 意味着更少的收入损失，更高的客户满意度，更好的品牌形象，以及更低的 SLA 违约风险。

然而，MTTR 也有其局限性。它只能告诉我们解决问题的总时间，却无法展示事故处理过程中的具体细节。要真正提高效率，我们需要深入分析，找出流程中的瓶颈，并针对性地进行改进。

### ✅ 平均事故响应时间（AIRT）

Average Incident Response Time

别被这个名字迷惑了。AIRT 并不是指解决问题的时间，而是将事故分配给最合适的团队成员所需的时间。

有趣的是，很多公司发现，他们的 MTTR 中有相当大一部分时间其实花在了组建合适的响应团队上。这个发现让人意识到了 AIRT 的重要性。

但是，提高 AIRT 并非易事。它需要我们能够快速准确地诊断事故性质，这就要求响应人员具备出色的日志分析和问题追踪能力。

一些前沿公司已经开始在这方面应用人工智能技术。比如，有的公司使用 AI 来识别曾经解决过类似问题的团队成员。还有像 Meta 这样的公司，则利用 AI 来快速定位可能导致当前事故的代码变更。

### ✅ 平均遏制时间（MTTC）

Mean Time To Contain

MTTC 这个概念源自安全领域，一个经常需要处理最棘手事故的领域。它衡量的是从事故开始到彻底解决的全过程时间。

具体来说，MTTC 包含了三个阶段的时间：问题检测时间（MTTD）、确认时间（MTTA）和解决时间（MTTR）。

通过分析 MTTC，我们可以全面了解系统中潜在威胁的生命周期，评估其可能造成的影响，从而制定更有针对性的防御策略。

这些指标互相补充，共同构成了一个全面的事故响应评估体系。通过持续监控和优化这些指标，我们可以不断提升团队的事故处理能力，最终达到更高的系统可靠性。

## 业务指标

事故的影响远不止于技术层面，它可能会引发一系列连锁反应，从收入损失到法律风险，再到合规问题。因此，负责系统可靠性的领导者们不仅要关注技术指标，还需要密切关注一些反映成本和业务价值的指标。以下是几个关键指标：

### 👻 值班时间

值班制度正在发生变革。过去，很多公司并不为值班时间支付额外报酬，但现在越来越多的组织开始重视这一点。除了遵守某些地区的劳动法规定外，提供值班补贴也能激励员工更积极地响应警报，更有效地解决问题。

当引入补贴机制后，值班人数的安排就变得更加重要了。通常，我们会设置多级响应策略，每个级别可能安排多名值班人员。

不过，值班时间本身通常只是一个参考数据。实际的值班安排、轮换计划和升级策略，往往需要综合考虑系统特性、业务需求和可用人力等因素。如果公司决定提供额外的值班补贴，这部分费用通常已经包含在员工薪酬预算中。

### ✅ 系统正常运行时间

System Uptime

说到可靠性，系统正常运行时间可以说是最直观、最重要的指标。它表示系统正常工作的时间占总时间的百分比。显然，这个数字越接近 100%，客户和其他利益相关者就越满意。

但现实世界中，100%的正常运行时间几乎是不可能的。因此，我们需要持续监控实际的正常运行时间，及时发现并解决潜在问题。

值得注意的是，系统正常运行时间经常被用作营销亮点，在一些要求高可靠性的合同中，它还可能被写入服务级别协议（SLA）。

### ✅ SLA 和 SLO 合规性

在 SRE（网站可靠性工程）领域，SLA（服务级别协议）和 SLO（服务级别目标）是两个核心概念，它们构成了一个复杂而重要的研究领域。

SLA 是我们对客户的承诺，它具有法律约束力，详细规定了我们承诺提供的服务质量和可用性水平。

相比之下，SLO 更多是用于内部管理。它代表了我们希望达到的理想目标，通常会比 SLA 留有一定的余地，我们称之为"误差预算"。这样的设计既能保证我们履行对客户的承诺，又为团队提供了一定的操作空间。

通过持续监控和优化这些指标，我们能更好地平衡技术实现与业务目标，最终为公司创造更大的价值。

## 超越指标理解事故

指标和 KPI（关键绩效指标）无疑是评估系统可靠性的重要工具。它们让我们能够清晰地看到我们的可靠性实践如何随着时间推移和规模变化而表现。这些数据为我们提供了宝贵的洞察，帮助我们了解系统的整体健康状况。

然而，我们也要意识到，单纯依赖这些数字可能会让我们陷入一种假象。现实世界是复杂和不可预测的，有时会发生一些罕见但影响深远的事件，我们常称之为"黑天鹅事件"。这类事件可能会突然出现，彻底打乱我们的所有预期。同样，公司内部的重大战略调整也可能导致这些指标发生剧烈变化。

正是因为这种不确定性和变化的存在，我们不能仅仅停留在表面的数字上。要真正理解 SRE（网站可靠性工程）团队的工作状况和流程的有效性，我们需要深入到日常工作的细节中去。

## 来源

[原文](https://rootly.com/blog/incident-metrics-that-matter)其实是个软文来着，我去掉了广告，可以放心食用。

## 思考

### MTTR 和 MTTC 的区别

这些指标里有两个我是分不清楚的，那就是 MTTR 和 MTTC，所以我直接问了一下 AI，这是 AI 给出的参考答案。

MTTR（平均修复时间）和 MTTC（平均遏制时间）是两个重要但有所不同的可靠性指标。让我们深入了解它们的区别：

1. 定义：

   - MTTR（Mean Time To Repair/Resolve）：指从确认问题到完全解决问题的平均时间。
   - MTTC（Mean Time To Contain）：指从问题开始到问题被控制（但不一定完全解决）的平均时间。

2. 范围：

   - MTTR 专注于问题的完全解决。
   - MTTC 包括了更广的时间范围，通常涵盖从问题检测（MTTD）、确认（MTTA）到初步控制的整个过程。

3. 目标：

   - MTTR 的目标是尽快恢复正常服务。
   - MTTC 的目标是尽快控制问题的影响范围，防止进一步扩散。

4. 应用场景：

   - MTTR 常用于评估 IT 运维和支持团队的效率。
   - MTTC 更多地用在安全领域，特别是在处理安全事件时。

5. 组成部分：

   - MTTR 通常只包括从确认到解决的时间。
   - MTTC 通常包括检测时间（MTTD）+ 确认时间（MTTA）+ 初步控制时间。

6. 关注点：

   - MTTR 更关注最终结果——问题的彻底解决。
   - MTTC 更关注快速反应和初步控制，即使问题还没有完全解决。

7. 在事故生命周期中的位置：
   - MTTR 通常代表事故处理的最后阶段。
   - MTTC 涵盖了从事故开始到初步控制的整个早期阶段。

理解这两个指标的区别很重要，因为它们提供了不同的洞察：MTTC 反映了组织快速响应和控制问题的能力，而 MTTR 则反映了彻底解决问题的能力。在实际操作中，一个组织可能会先关注降低 MTTC 以快速控制损失，然后再着手降低 MTTR 以彻底解决问题。

两者结合使用，可以全面评估一个组织的事故响应能力和效率。

### SLA 和 SLO 定义

SLA 我比较熟悉，但是 SLO 我就有点孤陋寡闻了，还是让 AI 来回答好了。

这两个概念在服务管理和可靠性工程中都非常重要。让我们深入了解：

SLA（Service Level Agreement）服务级别协议：

1. 定义：SLA 是服务提供商与客户之间签订的正式合同，明确规定了所提供服务的质量、可用性和责任。

2. 特点：

   - 具有法律约束力
   - 通常包含具体的数值承诺，如"99.9%的系统可用性"
   - 违反 SLA 可能会导致赔偿或其他法律后果

3. 用途：

   - 设定客户期望
   - 明确服务质量标准
   - 为服务评估提供基准

4. 示例：承诺月度系统正常运行时间不低于 99.9%，否则给予客户赔偿。

SLO（Service Level Objective）服务级别目标：

1. 定义：SLO 是服务提供商为特定服务设定的内部性能目标。它是 SLA 的基础，但通常比 SLA 更严格。

2. 特点：

   - 内部使用，通常不对外公开
   - 比 SLA 更具体、更严格
   - 没有直接的法律约束力，但是团队的重要工作目标

3. 用途：

   - 指导内部运营和改进
   - 为团队设定明确的性能目标
   - 帮助预防 SLA 违约

4. 示例：内部目标是保持系统月度正常运行时间达到 99.95%，以确保能满足 99.9%的 SLA 承诺。

SLA 和 SLO 的关系：

1. SLO 通常比 SLA 更严格，为 SLA 提供缓冲空间。
2. SLO 是达成 SLA 的内部工具和指南。
3. 公司可能有多个 SLO 来支持一个 SLA。

在实践中，一个明智的策略是设定比 SLA 更严格的 SLO，这样即使偶尔未能达到 SLO，也能确保不违反对客户的 SLA 承诺。这种方法为团队提供了一个安全边际，同时推动持续改进。

理解并正确使用这两个概念，对于平衡客户满意度、服务质量和运营效率至关重要。它们共同构成了现代服务管理和 SRE（Site Reliability Engineering）实践的基础。