在《装备软件质量和可靠性管理》一书中，对John Musa定义的软件可靠性工程过程进行了改进，给出了软件可靠性工程框架——Ruan模型，描述了覆盖软件全生命周期的各项可靠性工程活动。

软件可靠性工程模型-Ruan模型

由于篇幅原因，本文仅简单介绍一下可靠性设计、可靠性参数的内容。

一、软件可靠性

在《GB/T 11457-2006 信息技术 软件工程术语》中，对软件可靠性的定义如下：

a)在规定条件下、在规定时间内，软件不引起系统失效的概率。该概率是系统输入和系统使用的函数，也是软件中存在的缺陷的函数。系统输入将确定是否会遇到已存在的缺陷（如果有缺陷存在的话）；

b)在规定的时间周期内所述条件下程序执行所要求的功能的能力。

在《GB/T 16260.1-2006 软件工程 产品质量 第1部分：质量模型》中，作为软件六大质量特性之一，软件可靠性的定义是：在指定条件下使用时，软件产品维持规定的性能级别的能力。

软件可靠性与硬件可靠性的比较

上图中对软件可靠性与硬件可靠性进行了比较，其中有两点要特别说明一下。首先是时间相关性，实际上软件的失效率虽然不是常数，但往往也不会随时间单调下降的（那只是个美好的愿望）。我们在后面介绍软件维护性时，会再说起这个话题；另一个是为什么说软件无标准件？在介绍了可靠性预计后，应该就好理解了。

二、软件失效机理

软件失效机理

在软件开发过程中的疏忽、失误或者错误，导致软件中存在了缺陷；在软件运行过程中，当缺陷被激活（软件运行于某一特定条件，俗称“踩雷”），使软件产生错误状态即出现了故障；而若无适当的处理措施（容错）对故障加以处理，最终使软件无法向用户提供其所期望的服务，即产生了失效。

换一个角度解释：错误是一种从外部输入的行为；缺陷和故障都属于软件内部不希望或不可接受的偏差，区别在于前者是静态的而后者是动态的；失效是一种向外部输出的状态。

因此，软件可靠性设计的实质就是减少缺陷和避免暴露，形象点说就是把门关起来，不让错误进来造成缺陷，也不让故障出去导致失效。

软件可靠性设计的实质就是减少缺陷和避免暴露

在软件失效机理的图里，还有一点要说明，从系统架构分层的角度看，本层的软件故障通常来源于低层次的软件失效，同理，本层的软件失效也会导致高层次的软件故障。这意味着，在可靠性设计中，除了要与本层的软件缺陷做斗争之外，还应考虑到由低层次软件失效而导致的本层故障，要避免出现单点故障/失效现象（橙色和红色的那两条路径）。

三、软件可靠性设计

在《软件可靠性安全性与质量保证》一书中，将软件可靠性设计归结为四种类型，即避错设计、容错设计、查错设计以及改错设计。

3.1 避错设计

避错设计体现了以预防为主的思想，是软件可靠性设计的首要方法。避错设计涉及到软件研发的各个环节，理论上把软件工程理论全部搬过来也是合理的，这里重点就讲讲“七项避错设计原理”。富士通公司的日野克重从可靠性观点出发，总结了使程序设计不会产生差错的“ 七种设计原理”。

七项避错设计原理

简单原理：越简单越好，包括结构简单、关系简单、算法简单、语句简单等，“抽象与逐步求精”和“封装与信息隐藏”是两种简化系统的手段，当然也要注意模块规模适中，对接口复杂度和圈复杂度也要有限制（避免过犹不及，这是一个平衡的问题）；

同型原理：保持形式一样，包括需求建模方法统一、设计描述方法统一、编程风格统一等，形成统一的规范和标准；

对称原理：保持形式对称，包括软件的体系结构、逻辑控制、条件判断、状态处理等形式都力求对称，例如有“是”就应该有“非”、有“范围内”就应该有“范围外”、有“正常处理”就应该有“异常处理”，如果不对称，就应该重点检查是否存在遗漏；

层次原理：保持形式上和结构上的层次分明，包括需求功能的分层、程序设计的分层等；

线型原理：程序结构最好是线型的（顺序结构），最多是矩形的（判断或者循环），避免交叉型的复杂结构，例如函数的逆向调用（你中有我、我中有你），Goto语句，多重嵌套的判断或者循环等；

易证原理：保证程序逻辑清晰并且易于证明，软件的形式化验证是易证原理的一种典型应用，在航空航天、核工业、铁路等行业的高安全领域有很多应用（如果希望通过数学方法证明程序的正确性，那么前提是通过规范的形式化语言去精确的描述软件的需求规格、逻辑设计、推理验证等等，这需要扎实的数学功底以及分析建模能力，对于我这个仅用过一点儿正则表达式的小白，真是心力皆有不足啊）；

安全原理：保证程序必然稳妥，例如不遗漏可能出现的状态、不遗漏应该执行的操作、充分考虑人为失误和通信错误等。

3.2 容错设计

容错的关键思想是冗余，通过增加多余的资源获得高可靠性。那么可以对哪些资源进行冗余呢？

时间冗余

时间冗余的基本思想是“失败后重做”，包括两种基本形式：

指令复执：正在执行的指令出错后，重复执行该条指令；

程序卷回：运行过程中出现故障后，返回至起始点或离故障点最近的预设恢复点重试。

举例如下：

对于受偶发干扰或瞬态故障影响较大的功能，应采用指令复执的方式，保证系统的可靠性。（如硬件通信、图像识别等场合）

对于逻辑紧密相关的数据库操作，应采用事务方式访问，以便在异常状态下也能保持数据的一致性。

结构冗余

结构冗余是基于软件相异性设计的原理，即基于相同的需求，采用不同的人员、设计方法、开发工具、编程语言、实现算法、测试与审核，开发满足需求的模块或软件。包括两种实现方法：

恢复块（RB）法：模块处理结束时检验运算结果，如发生故障，则通过代替模块再次运算，直至可以正常输出；

N版本程序（NVP）法：多个版本模块/软件同时运行，通过表决判定和输出结果。

举例如下：

在双机热备冗余系统中，采用NVP法，主从机根据输入同步计算，主机正常时，系统输出主机计算结果，主机降级或宕机时，系统输出从机计算结果。

信息冗余

信息冗余通过在信息中增加部分信息码以便检测和纠正数据偏差，或将信息分块存放在多个内存单元，或将信息进行备份存储等方式实现冗余。

举例如下：

采用CRC-32算法对接口通信数据进行校验；

在判断系统安全关键状态时，状态标识应适当增加冗余位（例如不能使用一位逻辑0或1、多位逻辑全0或全1表示安全或危险）；

建立系统日志和数据副本 ，设计数据备份和系统重构机制， 在出现修改或删除等严重误操作、 硬盘损坏、 人为或病毒破坏以及灾害时能恢复系统。

3.3 查错设计

查错设计可以使程序在运行中自动查找所存在的错误，是容错设计和改错设计的前提。

被动式错误检测

被动式错误检测是在程序的若干部位设置检测点，等待错误征兆的出现。包括以下两个原则：

相互怀疑原则：设计任何单元/模块时，假设其它单元/模块会出现错误；

立即检测原则：错误征兆出现后尽快查明，限制错误损害并降低排错难度。

举例如下：

在各单元/模块处理业务逻辑前，应首先判断所有输入参数、条件的合法性；

对于等待信号的程序，因设置等待次数或时间的上限，避免潜在的死循环；

对于冗余的输入数据应执行一致性验证。

主动式错误检测

主动式错误检测是主动检查程序状态，例如软件BIT。

举例如下：

提供服务器定期监控功能，查看定位CPU高耗线程，提示系统管理员关注。

提供服务端软件心跳监测功能，实时监控服务器的运行状态。

3.4 改错设计

改错设计可以使程序自我改正错误、减少错误危害程度。

改错和容错的前提都是查错，区别在于容错设计通过冗余的方法使系统具备了自我恢复的能力，而改错设计是要求系统去自动改正错误？（为什么不让能改bug的机器人一开始就把代码也写了，那世界就都清静了）这显然是很困难的。

因此改错设计的主要思路是减少错误的危害程度、限制错误的影响范围。具体的方式涉及到各种隔离，包括用户隔离、业务隔离、数据隔离、硬件隔离等等，目的都是隔离错误、防止蔓延。这些隔离措施与软件的安全保密性措施是很类似的，咱们放到以后的专题再介绍。

四、软件可靠性参数

一般的软件可靠性参数包括可靠度、失效率和失效强度、MTTF和MTBF。

注：软件可靠性参数涉及很多数学知识，如果大家在工作中确实有选择可靠性参数、确定和分配指标要求等相关内容，建议先全面的复习一下概率论，重新理解随机事件、离散/连续随机变量以及常见的离散/连续型分布等内容，磨刀不误砍柴工嘛。

4.1 可靠度

软件可靠度是指软件在规定时间内未发生失效的概率。

设规定时间为 ，发生失效时间为 ， 即表示在 内未发生失效的概率。

软件可靠度

4.2 失效率

软件失效率是指在时刻尚未发生失效的条件下，在 时刻后单位时间内发生失效的概率。

设 表示在 时刻发生失效的概率。

设 为可靠度，表示在t时刻内未发生失效的概率。

软件失效率

注：上面的公式是有详细推导的。大家可以用最朴素的思路想一下，由于 时刻尚未发生失效作为前提条件已经成立了，因此要除以这个概率（即可靠度 )，除后结果就是条件成立的前提下， 时刻后单位时间内发生失效的概率（单位时间趋近于0）。

4.3 失效强度

假设在 时刻发生的失效数为 ， 是一个随机数，随时间 的变化而不同。

设 为随机变量 的均值。

软件失效强度

4.4 MTBF和MTTF

MTBF：Mean Time Between Failure,平均失效间隔

MTTF：Mean Time To Failure，平均无失效时间

MTTR：Mean Time To Repair,平均恢复时间

MTBF、MTTF、MTTR

上图应该能比较清晰的表达这三个参数的含义了（把M去掉可能更准确）。

在硬件可靠性中，MTTF通常用于不可修复产品（表示从开始正常使用到最终报废的时间），MTBF通常用于可修复产品；

在软件可靠性中，具有失效自恢复能力的系统，可以使用MTBF；但如果没有自恢复能力，建议使用MTTF（注意是自恢复啊，人出差现场排故调试一个星期终于能用了的那种不算！）。

没有自恢复能力的系统，MTBF和MTTF是等价的。对于软件，建议使用MTTF作为可靠性指标，不仅仅是因为大多数软件没有自恢复能力，同时也是因为用户往往更关心从投入使用到发生失效的这个时间特性。

如果用户特别坚持MTBF这个指标，请确认他/她是否是想增加一个系统自恢复的功能需求，或者只是希望在系统出故障后，尽快在现场见到你。

软件可靠性工程是软件工程的一个重要分支，从编程角度来说，可靠性设计可能更容易被编程人员理解，但这仅仅是可靠性工程中的一小部分，其他还有诸如可靠性分析、测试、评估等等