常见的软件可靠性度量和分析方法

常见的度量方法或者说可靠性的表示方法主要有以下几种。

1、可靠性数据来源

可靠性数据来源包括两类：可以通过软件主动上报（事件、指标、Trace、日志等）等技术方法自动完成数据采集和分析；也可以通过接收或汇总来自用户的报告（包括软件提供的反馈渠道、客服渠道报告、弹幕报告、App市场评论、微博微信等社交媒体反馈），在后台通过一定机制形成故障报告单，供后续分析。

2、通过故障进行度量

故障复盘后形成故障结论报告，在周期（如季度、月度）结束后进行统计分析。可用如下几种分析方法实现。

• 按故障分级度量

最常见的度量方法是对故障进行分级，根据故障的影响程度、影响面给故障定级。级别越高代表故障越严重，常见的用P1～P4分级，部分公司也会增加P0、P5、P6级别。特别严重的故障会被定为P0级别，影响较小的故障被定为P5以下故障，如P5～P6故障级别。对故障进行周期性的统计分析，从几个常见维度分析故障的分布情况。

故障定级本身就是一个度量的过程。故障的严重程度与受影响业务的重要性、影响时长、影响程度三者相关，业务服务越重要、影响时间越长、影响面越大、程度越高，表示整个故障的严重等级越高。这是可以通过一些量化指标进行度量的。除了量化指标之外，也有用户报障、投诉、资金损失等业务关联性明显的指标作为兜底，以避免有些故障没有指标度量或指标无法明确代表故障影响程度的情况。

本质是确定故障标准。常见的故障标准在业界有一些比较笼统的定义，如某线上业务故障/事故的级别定义如下。

P0：核心业务重要功能不可用且大面积影响用户，造成重大负面舆情影响。

P1：核心业务重要功能不可用，但影响用户有限，如仅影响小部分用户。

P2：核心业务周边功能不可用，持续故障将大面积影响用户体验。

P3：周边业务功能不可用，轻微影响用户体验。

P4：周边业务功能不可用，但基本不影响用户正常使用。

• 按故障时长度量

平均故障间隔时长(Mean Time Between Failure, MTBF)

MTBF：周期内总时长/故障次数，代表平均故障间隔时长，用于考核周期内的故障的频繁程度。故障出现了总要修复，修复后可能再次出现，这个指标对经常重复出现的故障也很有参考意义。

MTBF=（周期总时长-故障总时长）/故障次数×100%

可理解为这个产品平均每隔一个MTBF就会发生一次故障。

平均故障修复时长(Mean Time To Repair, MTTR)

每个故障会有一定的不可用时长，MTTR是统计各级故障的平均不可用时长。假设汇总过去一年的故障报告，得到各个等级故障的MTTR记录，其中P4故障时长（单位：分钟）为180、710、439、277、405、522，于是P4故障的MTTR分别是：MTTR(P4)=(180+710+439+277+405+522)/6=422.17（分钟）

P级故障不可用时长预算消耗

每次故障都会有一定的不可用时长，这个时长累计起来就是本周期的不可用时长，与本周期不可用时长预算进行对比就可以得到不可用时长的预算消耗。如本月的可靠性目标是99.9%，则本月不可用时长预算为43.2分钟。某次故障导致的不可用时长是20分钟，则消耗了20/43.2×100%=46.3%的预算。不可用时长也可按故障等级进行分别度量，如P1～P4严重故障累计不可用时长，忽略P5以下小故障的不可用时长。

• 按故障处理过程度量

故障处理的速度会影响可用时长，它不能代表业务视角的可靠性，而是代表故障处理的能力。如前面故障生命周期所讲，故障修复时长可以拆分为几个阶段的时长分别度量。

互联网运维非常看重从故障发现到恢复正常水平的时长指标，这个指标能反映出运维人员发现问题、定位问题、修复问题的效率和能力。这些可靠性过程的度量，也是对SRE团队的能力的度量。

1. 发现时长：从故障发生到发现（监控指标开始异常、发出告警时间）的时长。
2. 定界时长：从开始响应到确定问题边界、业务影响范围的时长。
3. 定位时长：从发现故障到定位出根因的时长。
4. 恢复时长：从定位出原因、修复，到业务恢复正常水平的时长。

对所有故障进行统计分析，用平均值有时会掩盖某些重要信息，此时可以用分位值来分析，如分析90分位的故障发现时长表示对所有故障的发现时长进行正序排序，取故障样本中第90个故障的发现时长，此种方法可排除尾部的边角情况，更有代表性。其他定位时长、恢复时长也可用类似方法进行度量。

• 按故障模式或特点分类度量

做故障分类是为了对故障发生的规律进行分析，从而在修复阶段采取不同的方法，建设不同的能力进行应对。如单点故障是最容易处理的情况，对单点故障进行快速隔离即可。仔细分析故障可以发现，故障按其发生特点可以分为以下几类。

1）按故障发生的范围分类

• 单点故障：分布式系统中、单个节点的故障，也就是在前面可靠性设计的冗余设计中，某个冗余节点出现软硬件故障。单点范围也有单实例、单应用集群、单机房、单地域等。
• 局部故障：某些服务、部分集群、部分地区发生故障，只影响了部分用户。
• 全局故障：整个业务发生了故障，影响了全部用户。

2）按故障发生时间分类

• 间歇性故障：在时间上不是持续的故障。有可能是有规律的间歇发生故障，如在每天某个时间点或时间段出现；也可能是系统出现故障紧急处理后又再次出现的；还可能是到了某个业务高峰期触发的。
• 渐变故障：随着系统压力、用户规模、数据规模、时间推移的变化，系统逐渐产生变化进而出现的故障。
• 突发故障：很突然的由意外因素造成的故障。

3）独立故障与从属故障

• 独立故障：服务自身故障，且对其他服务没有影响，原因和影响都在服务内部。
• 从属故障：被其他故障引发的相关故障，根因可能是内部其他服务，也可能是外部第三方服务，还可能是公共基础设施等引发的。

4）系统性故障与偶然性的故障

• 系统性故障：系统性发生的故障，是因为系统架构设计、流程管理、运维体系等造成的，在一定条件下必然发生的故障。
• 偶发故障：没有特定规律，可能是多种小概率事件偶然组合到一起造成的故障。

5）新型故障与复发故障

• 新型故障：第一次发现的新的故障类型，可能是新软件Bug引入或是第一次触发某些因素。
• 复发故障：相同的原因或相同的软件环节出现的故障；复发故障值得警惕，因为这表示上一次故障发生后没有彻底解决，可能存在管理不到位、故障原因分析不深入或者解决不彻底等问题。

6）责任故障与非责任故障

• 责任故障：由人为因素、主动操作、设计不足、处理不到位造成的故障。
• 非责任故障：由自然的、外部的或不可抗力造成的故障，如由自然环境、政治政策导致。

3、通过质量指标来度量

通过质量指标度量可靠性的优势在于不会由于故障报告、故障定级等人为因素导致遗漏、失真的情况，可以比较客观地从质量角度来度量可靠性，也能度量一些未达到严重程度的可靠性问题。

• 按周期内失败率统计

按重要业务服务的失败率统计平台服务的可靠性。在移动互联网的应用中，由于手机端软件、用户使用错误、用户侧网络环境、传输环节的网络环境等原因，一般会存在小部分的常态失败率。这种方法统计度量周期（每天、周、月）的失败率，正常情况下相关指标应该保持持平，如每天的开播成功率、登录成功率、支付成功率等。如果失败率波动明显则表示可能出现了问题，需要重点关注。如一天内有100万次请求，其中有100次失败了，那么当日的失败率就是0.01%。端上（用户端侧）统计一般要根据用户/IP去重后再进行判断，以便得到更准确的数据，避免单个用户上报大量的错误信息造成指标强烈的波动。

周期失败率=（周期内失败请求次数/周期内总请求次数）×100%

• 按达标时长或不可用时长统计

对成功率类的指标设定一个统计周期和基准值，在基准值以下则认为是不可用的。比如统计周期可为1分钟，每个周期统计一个成功率，则每天总共会有1440个点，度量周期（每天）内的1440个点中有多少个点的成功率在基准值以下，在基准值以下的时长累计为不可用时长。

达标率=（达标时长/周期总时长）×100%

达标时长还可以结合不可用时长预算来度量，如可靠性目标SLO是99.9%，则每月（按30天计算）的不可用时长预算有43.2分钟，用预算扣除消耗则为本月的不可用时长预算余额。

不可用时长预算余额=不可用时长预算-统计到的不达标时长

这种统计方式比用故障时长更加精确，因为故障时长需要被定级才扣减，定级过程涉及太多因素，而不可用时长则是可以准确统计出来的。