Day30-20｜9.6.4 软件可靠性的评价和预测：从历史证据推断未来风险

一、教材定位

软件可靠性评价回答“在已有运行条件下系统表现怎样”，可靠性预测进一步回答“在未来相近条件下可能怎样”。二者都需要可靠的运行数据、明确的故障定义和合理的模型假设。预测不是保证，也不是凭经验猜测，而是在已知证据基础上对未来故障概率、无故障运行时间、恢复能力或达到目标所需工作量作出有边界的推断。

本节综合前面软件可靠性定义、测试、数据收集和模型选择的知识。考试中常见要求包括：根据故障数据评价系统是否达到目标；分析可靠性增长趋势；说明预测结果为什么不可信；提出如何改进数据和模型。答题时应写清评价对象、运行条件、样本和统计口径，并把预测不确定性、模型验证和变化风险说明白。

二、评价与预测的区别

评价主要基于已发生或已观测的数据，描述过去和当前的可靠性。预测使用这些数据及模型假设，推断未来某个时间、运行量或环境下的表现。评价更关注证据，预测更关注趋势和不确定性。

例如，测试期间处理了一百万个事务，其中发生十次可确认故障，可以据此计算该观察窗口下的故障率。但要预测上线后一个月的故障数量，还要考虑生产事务量、运行剖面、版本配置、用户行为和外部依赖是否变化。直接把十次故障乘以未来事务量，只有在相关条件稳定并且统计假设合理时才有参考价值。

三、可靠性评价的指标与口径

1. 故障率和成功率

故障率可以按单位时间、事务数、请求数或设备工作量计算。成功率要明确是技术成功、业务成功、首次成功还是最终成功。对具有重试的系统，第一次失败但最终成功不能简单归入成功而不记录重试，否则会掩盖故障和延迟。

2. 无故障时间和失效间隔

无故障运行时间可以用于观察系统是否稳定，失效间隔可以用于比较版本和测试阶段。必须明确如何处理计划维护、预期拒绝、用户取消、外部业务拒绝和未确认状态。统计规则变化会直接改变指标，必须保持版本化。

3. 检测、恢复与修复指标

平均检测时间、平均恢复时间和平均修复时间分别反映监控、运行处置和研发修复能力。对高可用系统还应区分自动切换时间、人工接管时间、业务恢复时间和数据补偿时间。恢复速度快但数据错误，不能视为可靠性良好。

4. 数据正确性指标

记录丢失、重复、错账、状态不一致、消息积压和补偿失败等指标。对于关键业务，应建立“可用但错误”和“不可用”两个维度，避免业务错误被技术成功率掩盖。

四、评价和预测的基本过程

第一步：确定对象、条件和目标

明确版本、配置、部署拓扑、运行剖面、负载、依赖和观察时间，确定是评价当前版本、比较两个版本，还是预测上线后的风险。没有这些条件，结果无法复现，也不能判断是否可外推。

第二步：检查数据质量

核对运行量、故障时间、故障分类、修复记录、业务影响和正常观察区间。检查监控中断、时间不一致、重复事件和口径变化。数据不足时，要在结论中降低精度或补充采集，而不是强行计算。

第三步：计算直接指标

先用直观指标建立基线，按时间窗口、版本、业务路径和故障类型分组。观察平均值、分位数、趋势、峰值和长尾，分析核心路径与非核心路径差异。

第四步：建立候选模型

根据评价目标和数据特征选择故障计数、时间间隔、可靠性增长、状态转移或失效分布等方法。记录模型假设、参数和输入数据，不要只报告最终预测数值。

第五步：验证预测能力

可采用时间切分，将早期数据用于建模、后期数据用于验证；也可采用交叉验证或不同窗口比较。关注预测误差、趋势偏差和参数稳定性。模型只能在验证结果支持的范围内使用。

第六步：表达结论和不确定性

预测结果最好以区间、风险等级或条件结论表达，并说明数据量、观察窗口、模型假设和可能改变结果的因素。避免使用“必然”“绝对不会故障”等不符合工程实际的表述。

五、可靠性增长与趋势判断

软件在测试和维护过程中，缺陷被发现并修复，可靠性可能逐步提高。评价增长趋势时，要观察单位运行量故障率、严重故障数量、故障间隔和修复后回归结果是否改善。故障总数减少不一定意味着增长，因为测试负载可能下降；故障总数增加也不一定意味着退化，因为测试覆盖扩大了。

要区分“发现更多问题”和“系统本身变差”。可以按相同运行剖面、相同故障口径和相同观察窗口比较，也可以把新引入的测试场景单独分析。修复是否有效应通过复测和后续运行数据确认，不能仅凭关闭缺陷单判断。

若故障间隔持续增长、严重故障比例下降、恢复时间缩短且数据差异减少，通常说明可靠性在改善；如果某些故障减少但资源泄漏、长尾延迟和数据补偿量上升，说明总体可靠性可能没有真正提高。

六、预测中的关键假设

1. 运行剖面稳定

历史数据和未来使用方式应具有可比性。上线后用户增长、业务比例、批量规模或第三方渠道变化，都会使预测失效。对重大活动和新业务，应建立单独的场景预测。

2. 软件和配置稳定

新版本、依赖升级、配置变更和架构调整会改变故障规律。预测结果必须绑定版本和配置，发布后重新评估，不能把旧版本的可靠性指标直接套到新版本。

3. 修复过程稳定且有效

模型往往假设故障修复能够降低后续故障概率。如果修复质量不稳定、回归不足或修复引入新缺陷，预测将过于乐观。应跟踪修复后的同类故障、回归缺陷和变更风险。

4. 观测机制稳定

监控规则、日志级别和故障定义发生改变，会造成观测数据变化。增加监控后故障数量上升，可能是发现能力提高而不是系统变差；关闭监控后故障减少，也不代表可靠性提高。

5. 故障之间满足模型关系

独立性、同分布、可修复和无共因故障等假设必须经过检查。分布式系统中的配置错误、证书过期、网络分区和共享存储故障会同时影响多个组件，必须显式处理相关性。

七、预测结果的验证和更新

预测不是一次性报告。上线后应将预测区间与实际运行数据比较，记录偏差来源，并更新模型或运行剖面。若实际故障超出预测范围，要分析是数据质量问题、条件变化、模型不适用还是新故障模式。

可以采用滚动窗口：每隔一段时间加入最新数据，重新估计参数，并保留历史版本以便比较。对核心系统，应在版本发布、重大配置变化、流量增长、依赖变化和重大故障后触发重新评价。

更新不能只追求让模型拟合当前数据，还要检查是否丧失可解释性。若新旧数据来自完全不同的运行阶段，应分段建模并说明差异，而不是简单混合。

八、评价结果与上线决策

可靠性评价和预测最终要服务于决策。可以设置硬门槛和风险分层：核心数据一致性、严重安全缺陷和不可恢复故障属于不可接受风险；一般查询的长尾延迟可能通过限范围灰度和监控缓解；低风险问题可以纳入明确期限的整改计划。

上线建议可以是全量放行、分批灰度、限制业务范围、延长观察、补充测试或暂缓上线。每种建议都要写清触发条件、监控指标、回滚方案、责任人和复评时间。预测结果不能取代架构师判断，但可以让判断有证据、有边界、有追踪。

九、案例分析：预测促销高峰故障风险

某电商平台根据平时一个月的故障率预测大促期间不会出现严重问题。实际上，大促时查询流量增加十倍，订单和支付比例上升，库存扣减变为热点，第三方支付也出现更高延迟。旧模型预测的故障量远低于实际结果。

原因在于模型使用了不匹配的运行剖面，没有区分普通查询和高价值交易，没有考虑流量突增、数据热点和第三方依赖变化，也没有把重试放大和消息积压纳入预测。改进时应分别建立平时、预热、峰值、峰后恢复四个场景，按事务权重和资源约束模拟流量，加入支付超时、库存竞争、节点扩容延迟和消息积压等条件。

评价指标不只包括接口成功率，还要包括订单最终成功率、库存差异、支付状态一致率、重复订单、积压峰值和恢复时间。测试和灰度数据用于校准模型，预测结果以区间和风险等级表达。若关键业务指标超过停止阈值，则暂停扩大流量并执行回滚或降级。

十、综合知识练习

题1

为什么可靠性预测不能简单根据历史故障次数外推？

参考答案：未来的运行剖面、流量、版本、配置、依赖和故障相关性可能发生变化，历史数据还可能存在删失、监控缺失和口径变化。只有在条件可比、数据质量可靠并经过模型验证时，历史数据才具有有限的预测价值。

题2

如何判断可靠性增长是真实的？

参考答案：在相同或可调整的运行剖面和统计口径下比较故障率、严重故障、故障间隔、恢复时间和数据差异，检查修复后的同类故障是否下降，并确认监控和测试覆盖没有变化造成假象。

题3

预测结果超出实际运行范围时，应如何处理？

参考答案：先检查数据质量、运行条件、版本配置和故障定义是否变化，再分析模型假设和参数是否适用；扩大数据采集、重新建模或分场景建模，并在重新验证前降低原预测结论的使用范围。

十一、论文写作素材

论文中可以这样描述评价与预测：

“我将可靠性评价与预测分开处理，先在明确版本、配置、运行剖面和观察窗口的前提下，计算故障率、业务成功率、恢复时间、数据差异和资源趋势等直接指标，再根据数据条件选择可靠性增长或状态转移分析方法。模型使用前检查样本量、删失数据、运行剖面稳定性、修复有效性和共因故障，使用后通过时间切分和滚动观察验证预测误差。预测结论以区间和条件风险表达，并在重大版本、配置和流量变化后重新评价，最终结合硬门槛、灰度策略和回滚方案支持上线决策。”

十二、今日复盘

评价描述已观测表现，预测推断未来风险，二者都依赖可靠数据。
预测必须绑定运行剖面、版本、配置和模型假设。
故障率、可用性、恢复时间和业务正确性要同时评价。
可靠性增长要排除负载、测试覆盖和监控口径变化造成的假象。
预测结果必须验证、更新并表达不确定性。
上线决策应把预测结论与灰度、监控、回滚和剩余风险结合起来。