Day30-08｜9.2.3 软件的可靠性模型分类：根据问题选择合适的可靠性模型

一、教材定位

可靠性模型并不是一个单一公式，而是一组针对不同问题、不同阶段和不同数据条件建立的抽象模型。软件可靠性模型可以从建模目的、输入数据、系统结构、运行状态和时间关系等角度分类。掌握模型分类，能够帮助架构师判断“当前问题需要哪一类模型”，避免使用不适合的模型得出貌似精确但没有决策价值的结论。

二、按建模目的分类

1. 预测模型

预测模型根据历史故障、测试数据、运行时间、代码规模或缺陷趋势，预测未来某段时间的失效概率、可靠度或故障数量。它适合制定测试计划、评估版本风险和预测服务等级，但依赖历史数据与未来条件具有一定相似性。

2. 评估模型

评估模型用于判断当前系统或候选架构是否达到可靠性目标。它通常输入组件可靠性、故障率、恢复时间、冗余关系和场景约束，输出可用性、任务成功率或故障影响。架构评估中的可靠性框图、故障树和状态模型都可以发挥评估作用。

3. 增长模型

可靠性增长模型描述测试和修复过程中失效率下降、故障发现和版本改进的趋势。它可以回答继续测试是否有价值、版本是否接近目标、修复活动是否真正改善可靠性。但如果修复质量不稳定或测试环境变化，增长曲线可能不具有可比性。

4. 分配模型

分配模型把系统级可靠性目标分解给子系统、组件、服务和运行环节。分配不能只按组件数量平均切分，而要考虑关键路径、冗余、串并联关系、业务影响和组件责任边界。分配结果应转化为设计、测试和监控目标。

三、按建模对象分类

1. 结构可靠性模型

结构模型关注组件之间的组合关系，典型方法是可靠性框图。它适合分析串联、并联、主备和冗余结构，回答“哪些组件必须同时正常”“增加一个副本能改善多少”。它对动态切换、状态顺序和修复过程表达有限。

2. 行为可靠性模型

行为模型关注系统状态、事件、并发和时间顺序，典型方法包括状态转移模型、Markov 模型和 Petri 网。它适合分析正常、降级、故障、切换、恢复、等待和补偿状态，回答“系统如何从一种状态转到另一种状态”。

3. 故障因果模型

故障因果模型从顶层失效出发，逐层分解原因，典型方法是故障树分析。它适合识别单点、共同原因、故障组合和最小割集，帮助架构师发现容易被忽略的故障路径。

4. 数据统计模型

统计模型根据实际失效时间、故障间隔、恢复时间和任务结果，建立分布和参数，估计可靠度、失效率和趋势。它适合运行数据分析和版本比较，但需要稳定、准确和可比的数据。

四、按运行阶段分类

软件可靠性还可以按运行阶段使用不同模型：需求和架构阶段使用场景、故障树、可靠性框图和状态模型；开发测试阶段使用可靠性增长和缺陷趋势模型；上线运行阶段使用失效率、故障间隔、恢复时间和业务成功率统计；长期治理阶段使用趋势、预测和风险模型。

不同阶段的模型结论不能直接互换。架构阶段的理论可用性是设计预期，测试阶段的可靠度是实验结果，生产阶段的可靠性是实际运行表现。它们之间需要通过验证和校准建立关系。

五、结构模型的特点

结构模型把系统成功条件表达为组件组合。串联系统中任何关键组件故障都可能导致整体失败，并联系统通过冗余降低单点影响。结构模型直观、易沟通，适合早期架构比较和冗余分析。

但结构模型常假设组件独立、故障静态和切换无损。现实系统中副本可能共享机房、网络、配置和供应商，形成共同原因故障；切换也可能丢失会话、产生重复请求和数据冲突。因此结构模型需要补充故障树、状态模型和演练数据。

六、状态模型的特点

状态模型把系统的正常、降级、故障、修复、维护和恢复表示为状态，把请求、故障和修复表示为转移。它能够分析动态可用性、修复策略、主备切换和多阶段恢复。

状态数量是状态模型的主要复杂度来源。若把每个服务、节点、网络和数据状态全部展开，模型规模会迅速增长。应根据评估目标选择必要粒度，将不影响结论的细节抽象掉，并通过测试验证关键转移。

七、故障树模型的特点

故障树适合从结果追溯原因。通过“与”关系表示多个事件同时发生，通过“或”关系表示任一事件即可导致上层故障。它可以帮助识别安全失效、不可用、数据丢失和恢复失败的原因，并发现共同故障源。

故障树的难点在于确定事件独立性和完整性。若遗漏配置、人工操作或外部依赖，结果会低估风险；若把同一根因重复计算，结果会高估风险。故障树应由业务、架构、开发、测试和运维共同审查。

八、可靠性增长和预测模型的特点

增长模型根据测试中发现和修复的故障预测可靠性改善趋势。它适合制定发布门槛和测试停止标准，但需要记录每次故障的发现时间、严重性、修复时间、回归结果和版本。修复缺陷的数量下降并不一定说明可靠性提升，可能是测试覆盖不足或新故障尚未暴露。

预测模型可以帮助估计未来风险，但必须进行数据分层。例如不同版本、负载、地域和用户群的失效数据不能无条件混合。对重大架构变化，应重新建立基线，不能直接使用旧版本预测结果。

九、模型选择矩阵

模型选择应从问题出发，而不是从手头熟悉的工具出发。

十、模型组合使用

复杂系统通常需要组合模型。例如先用故障树识别导致“交易不可用”的原因，再用状态模型分析主备切换和恢复，用可靠性框图比较部署冗余，用统计模型校准失效率和恢复时间，最后通过故障演练验证关键假设。

组合模型时要保持边界和参数一致。一个模型输出的失效率、切换时间或共同故障假设，必须能作为另一个模型的合理输入。否则模型组合会产生不一致的“精确错误”。

十一、案例分析：云平台可用性模型

某云平台提供 API 网关、应用集群、数据库、消息服务和对象存储。架构团队首先用可靠性框图分析关键路径，发现网关和数据库是必须经过的组件；再用故障树分析 API 不可用原因，发现除了节点故障外，还存在共享配置、证书过期和网络设备故障；使用状态模型分析数据库主备切换、消息积压和降级状态；最后用生产数据校准各组件故障间隔和恢复时间。

模型结果显示，增加应用副本对整体可用性改善有限，因为数据库和配置中心仍是共同故障源。团队优先改造配置分发和证书管理，增加数据库跨故障域部署，设计消息积压降级和恢复校验，并通过演练验证模型预测。

十二、练习题

题1

预测软件可靠性模型和可靠性增长模型有什么区别？

参考答案

预测模型利用历史或当前数据估计未来故障和可靠度；增长模型重点描述测试、修复和版本迭代过程中可靠性随时间或修复活动的变化，用于判断改进趋势和测试投入。二者都依赖数据和假设，但使用目的不同。

题2

什么时候优先使用故障树？

参考答案

当需要从顶层失效结果追溯原因、识别单点、共同原因和故障组合时，优先使用故障树。它适合可用性、安全性、数据丢失和灾备风险分析。

题3

为什么模型需要组合使用？

参考答案

结构模型适合组合关系，状态模型适合切换和恢复，故障树适合因果分析，统计模型适合参数估计。复杂系统单一模型难以覆盖所有方面，组合使用可以形成更完整的分析，但必须保持边界、参数和假设一致。

十三、论文写作素材

论文中可以写“项目根据评估问题选择可靠性模型：使用可靠性框图比较冗余部署，使用故障树识别单点和共同原因，使用状态模型分析主备切换和降级，使用统计和增长模型分析测试与运行趋势。模型参数来自故障工单、压测和演练，并通过敏感性分析确定关键因素；对于模型无法覆盖的动态行为，再用故障注入和长期稳定性测试进行验证。”

十四、今日复盘

可靠性模型可按目的分为预测、评估、增长和分配模型，按对象分为结构、行为、故障因果和统计模型。选择模型要从问题出发，明确边界、数据和假设；复杂系统可以组合模型，但任何模型都不能替代真实测试、演练和生产监控。