Day30-02｜9.1.2 软件可靠性的定量描述：用指标和模型度量故障与恢复

一、教材定位

软件可靠性不能只用“稳定”或“不稳定”描述，还需要通过指标、概率和统计数据进行定量表达。定量描述为可靠性目标制定、架构比较、测试评价、运行监控和风险决策提供依据。高级系统架构设计师不仅要理解定义，还要能解释可靠度、失效率、平均无故障时间、平均修复时间、可用性和任务成功概率之间的关系。

二、可靠度

可靠度通常记为 R(t)，表示软件系统在规定条件下，从时刻0开始运行到时间 t 仍然不发生失效的概率。若系统在给定时间内有较高概率持续正确运行，则 R(t) 较高。

可靠度是时间的函数。一般情况下，随着运行时间增加，累计失效概率增加，可靠度不会自然提高。对于具体系统，可靠度还取决于输入分布、运行环境、版本、配置和缺陷暴露情况。不能脱离这些条件比较两个系统的可靠度。

若失效时间为随机变量 T，则可靠度可以表示为：

R(t) = P(T > t)

也就是说，可靠度是系统在时间 t 之后仍未失效的概率。失效分布函数 F(t) 表示在 t 之前已经失效的概率，二者满足：

R(t) = 1 - F(t)

三、失效率

失效率描述系统在某一时刻附近发生失效的倾向。常记为 λ(t)，可理解为在已经运行到 t 且尚未失效的条件下，下一小段时间发生失效的概率强度。

在简化模型中，如果失效率为常数 λ，则可靠度可以写成：

R(t) = e^(-λt)

这个公式用于理解失效率和可靠度的关系，不应脱离模型条件机械套用。软件失效率往往受到缺陷发现、修复、变更和运行环境影响，不一定真正保持常数。

失效率可以按运行时间、交易次数、请求次数或任务次数描述。例如每运行一千小时发生一次失效，或者每百万次交易出现一次业务错误。指标的分母必须明确，否则不同团队提供的数字无法比较。

四、平均无故障时间和平均修复时间

MTBF 是 Mean Time Between Failures 的缩写，通常译为平均故障间隔时间；MTTF 是 Mean Time To Failure，表示平均失效前时间；MTTR 是 Mean Time To Repair，表示平均修复时间。

对于可修复系统，MTBF 描述一次故障到下一次故障之间的平均正常运行时间，MTTR 描述发生故障后恢复到可服务状态的平均时间。MTTF 常用于不可修复对象或从投入运行到首次失效的时间描述。

需要注意，MTBF 高不等于可用性一定高。如果每次故障恢复时间很长，系统仍可能有较大不可用时间；如果 MTTR 很短，即使故障较频繁，也可能保持较高可用性。因此可靠性工程必须同时管理故障发生和恢复能力。

五、可用性与可靠性的关系

在简化稳态模型下，可用性 A 可以表示为：

A = MTBF / (MTBF + MTTR)

该关系说明提高可用性有两条路径：延长故障间隔，或缩短恢复时间。架构上可以通过减少缺陷、隔离故障、冗余切换、快速检测、自动恢复、回滚和备份恢复分别影响这两个方向。

可用率指标必须说明统计口径。计划维护是否计入，部分功能不可用是否算全站故障，数据错误但服务在线是否算失效，跨地域用户的访问差异如何处理，都需要明确。否则“99.99%可用率”可能在不同组织中代表完全不同的实际水平。

六、故障密度和缺陷指标

故障密度可以用单位代码量、单位功能点、单位运行时间或单位请求数中的故障数量表示。缺陷密度常用于开发和测试阶段，业务失败率、错误率和告警率常用于运行阶段。

指标应与阶段和对象匹配。代码缺陷密度不能直接等同于用户感知的业务失效率；一次严重数据错误可能比大量界面小问题带来的风险更大。架构评估中要关注缺陷的严重等级、影响范围、可检测性和恢复能力，而不是只追求缺陷数量下降。

七、任务可靠性和业务可靠性

某些系统不是长期连续运行，而是执行离散任务，如批处理、设备控制、交易处理和数据同步。这类系统可以使用任务可靠性描述：在规定条件下，一次任务成功完成的概率。

业务可靠性比技术组件可靠性更重要。消息队列投递成功不代表订单事件处理成功，数据库写入成功不代表支付已经完成，服务返回200也不代表业务结果正确。应定义端到端业务指标，如订单状态最终正确率、支付对账一致率、批处理成功率、数据同步完整率和设备指令执行成功率。

八、可靠性数据的收集

定量描述依赖高质量数据。需要收集启动和停止时间、失效时间、故障类型、影响范围、检测时间、恢复时间、修复版本、输入负载、环境和配置。日志、指标、链路追踪、审计、工单和故障复盘应能够关联同一个事件。

数据收集要避免重复统计和漏报。一次底层节点故障可能触发大量接口告警，不能简单将每条告警都算作一次独立故障；一个业务失败可能由多个技术原因共同造成，需要建立故障归因规则。指标还要区分计划维护、外部依赖故障、用户误操作和软件内部缺陷。

九、可靠性模型的使用边界

可靠性模型可以帮助预测趋势、比较方案和安排测试，但模型建立在假设之上。常见模型可能假设失效率稳定、失效相互独立、修复不改变系统结构或运行环境稳定。现实中的软件系统常有版本变更、流量变化、依赖波动和配置调整，因此模型结果只能作为决策依据之一。

使用模型时应说明数据来源、假设、适用范围和不确定性。不能用历史低负载数据预测峰值，也不能把某个版本的指标直接外推到重大架构变更后的系统。

十、架构策略与定量指标

冗余和自动切换通常影响可用性和 MTTR；模块隔离和输入校验影响失效概率；灰度发布和回滚影响变更风险与恢复时间；缓存、异步和扩展影响性能和容量；监控和告警影响故障检测时间；备份和恢复影响数据丢失窗口与业务恢复时间。

架构评估应把指标映射到策略。例如目标是恢复时间不超过5分钟，就要验证故障检测时间、切换时间、数据恢复时间和业务验证时间的总和，而不是只看进程重启时间。

十一、案例分析：电商订单平台指标分析

某订单平台一个月运行720小时，发生3次软件故障，累计不可用时间为45分钟。粗略计算平均故障间隔和恢复指标时，先明确口径：故障间隔按从一次恢复到下一次故障计算，MTTR为45分钟除以3，即15分钟。若用简化稳态公式估算，可用性约为正常运行时间除以总观察时间，即（720小时-0.75小时）/720小时，约为99.90%。

但这个数字并不能说明全部可靠性。进一步分析发现，三次故障中一次是数据库连接池耗尽，一次是外部支付超时放大，一次是错误配置发布；订单服务虽然可访问，但部分支付状态需要人工对账。因此团队增加连接池隔离、外部调用超时和熔断、幂等补偿、配置校验和灰度回滚，并增加订单最终状态正确率和对账一致率指标。

这个案例说明，定量描述不仅是计算一个可用率，还要追溯指标背后的故障原因和业务影响。

十二、计算练习

题1

某系统一年内发生4次故障，累计修复时间为8小时，观察期为8760小时。如何计算平均修复时间和近似可用率？

参考答案

MTTR = 8 / 4 = 2小时。若不考虑计划维护和外部故障，近似可用率为（8760-8）/8760，约为99.91%。实际报告还应说明统计口径、故障影响范围和是否存在部分功能不可用。

题2

为什么平均指标可能掩盖可靠性问题？

参考答案

平均值会掩盖长尾和严重个例。少量超长恢复、部分用户失败、关键交易错误和高峰期故障可能对业务影响很大，因此还要观察百分位、最大值、严重等级、业务成功率和数据正确率。

题3

为什么业务可靠性指标不能只使用服务器可用率？

参考答案

服务器在线不代表业务结果正确。支付、订单、消息和数据同步都可能出现服务在线但结果错误的情况。应增加端到端任务成功率、状态最终正确率、数据完整率和对账一致率等指标。

十三、论文写作素材

论文中可以写“项目建立了可靠性指标体系，分别记录失效率、故障间隔、恢复时间、接口错误率、业务任务成功率和数据一致率。通过日志、监控、链路追踪和故障工单收集数据，区分软件缺陷、外部依赖和配置问题；针对 MTTR 偏高的问题增加自动切换、回滚和恢复演练，针对业务错误增加幂等、补偿和对账机制，并在运行中持续复核指标的统计口径和适用范围。”

十四、今日复盘

定量描述的核心是可靠度、失效率、MTBF、MTTF、MTTR和可用性。记住：可靠性关注规定时间内正确运行，可用性同时受故障间隔和恢复时间影响；指标必须明确条件、时间、分母和业务口径；技术指标最终要落到端到端业务结果。