最近系统学习了一个系统可靠性及其相关知识，今天在这总结一下。

首先，什么是系统的可靠性呢？系统的可靠性是指在规定的时间内及规定的环境下完成规定功能的能力，也就是系统的无故障运行概率。

我会从以下几个方面来归纳主要内容：

1. 故障模型

2. 可靠性模型

3. 可靠性指标

4. 可靠性设计

故障模型

系统故障是指硬件或者软件的错误状态，一般引进故障的原因是这些：部件的失效、环境的物理干扰、操作错误或不正确的设计。

按照时间的长短，故障可以分为：永久性、间歇性、瞬时性。

故障的级别有：逻辑级故障、数据结构级故障、软件故障和差错故障、系统级故障。

 

可靠性模型

与故障模型想对应的，就是系统的可靠性模型。常用的有以下三种：时间模型、故障植入模型和数据模型。

这三种模型暂时还没有看懂（晕）。

 

可靠性指标

可靠性指标，主要有以下几个：

平均无故障时间（MTTF-Mean Time To Failure）

它表示一个系统平均情况下，正常运行的时间。

与它相关的指标是“失效率”U，关系： U = 1 / MTTF。

平均故障修复时间（MTTR-Mean Time To Fix/Repire）

平均每次修复所需要的时间

平均故障间隔时间（MTBF-Mean Time Between Failure）

一看就知道，MTBF = MTTF + MTTR。

在实际情况下，一般MTTR都会比较小，所以我们近似地认为MTBF = MTTF。

MTTF是用来说明一个软件系统能够正常运行的时间的指标。它越大，说明该系统越可靠。计算方法很简单，

 

可靠性计算

一个系统的可靠性计算往往不能直接得出。这是因为计算机系统是一个复杂的系统，影响其可靠性的因素也非常复杂。所以我们需要为其建立适当的数据模型，把大系统划分为若干子系统，然后再根据一定原则进行组合计算。

这种计算方法，可以简化分析的过程。

对于系统的划分，我们可以把它分为：串联系统、并联系统、模冗余系统、混联系统。（其中模冗余系统是M个并联的子系统中，需要有N个以上的子系统能正常工作，整个系统才能正常工作。这种系统，常在并联后加上一个表决器。）

计算这些系统可靠性时，我们需要计算出每个子系统的失效率，然后根据概率的加法原则（串联系统）和乘法原则（并联系统）进行综合运算，最后得出整个系统的可靠性。

 

可靠性设计

本小节是整单的重点。

提高系统可靠性的方法，主要是两种：避错和容错。避错主要是指提前做一些措施，避免系统在运行中出现错误。而容错则是指系统在运行中部分组件出现错误，仍然不失效，可以继续运行；或者当数据、文件损坏或丢失后，系统可以自动将这些数据恢复到以前的状态，使系统能够继续正常运行。

测试就是最常用的一种避错技术。而容错则一般使用冗余来实现。

 

冗余技术

冗余技术是容错的主要手段。主是通过对资源的冗余，包括硬件、软件、信息、时间等，可以使系统的容错性得到较大的提高。

结构冗余

这里又分静态冗余和动态冗余。

静态冗余一般是指增加同样功能的部件，同时运行，最后由表决器对结果进行表决，以多数结果作为系统的最终结果。

动态冗余则是做一些多重的设备储备，当系统检测到某一部件失效时，启用相应的新部件代替它进行工作。这里有检测、切换和恢复的过程，所以称之为动态冗余。这些多余的设备储备，可与主模块一起工作，也可以不工作，分别称为热备份和冷备份。冷备份缺点是当主模块失效时，备份系统可能无法及时衔接上，因为备份机无法获取到原来机器上所有的数据。

其实，我们还可以结合以上两种冗余的优缺点，使用混合冗余的方式，对系统进行结构性冗余设计。

信息冗余

添加一些额外的信息用于保证其正确性。例如：纠错码。

时间冗余

类似结构冗余，不过这里是在同一设备上执行重复计算。

故障恢复策略

如果故障已经发生，则需要一定的方法来恢复故障。一般有两种恢复策略：向前和向后。

向前恢复是指不停止当前的计算，而把系统从不连贯的状态恢复为连贯的正确状态，需要有错误的详细说明。例如我们可以在系统发生故障时，把异常信息都捕获到并存储起来备案，然后尽量让系统继续执行。这也是平常最常用的策略。

后向恢复是把系统恢复到之前的一个状态，然后继续执行。这种方法比较简单，但是却造成程序运行的不连贯性，不适应一些高要求系统，如实时系统。

 

软件容错

主要有以下几种方式：

恢复块方法

这种方法是一种动态的故障屏蔽技术，采用的是后向恢复策略。它提供相同功能的主模块和多个备用模块，当主功能计算完成后需要进行验证测试，如果测试没有通过，则会使用备用模块进行计算，如果还是没有通过，则继续使用下一个备用模块。

设计时应该保证实现主块和备用块之间的独立性，使其不会相互影响。

N版本程序设计

此法是一种静态故障屏蔽技术，采用前向恢复策略。

采用多个相同功能的N份程序同时运行，使用表决器进行最后结果的表决。

重点在于：

N版本的程序设计应该使用不同的方法，如不同的设计语言、不同的开发环境和工具。

同时，由于N个程序同时运行，最后同时表决，所以需要解决多个程序间的并发性。

防卫式程序设计

此法的基本思想是在程序中包含错误检测代码。一旦错误发生，程序能撤销错误状态，恢复到一个已知和正确状态中去。包括错误检测、破坏估计和错误恢复三个方面。

这种方式主要是以软件的形式来容错，也就是说软件自身有较强的容错性，较为常用。

集群

集群是由两个以上的节点机（一般是服务器）构成的一种松散耦合的计算节点集合，为用户提供网络服务或应用程序（包括数据库、Web服务和文件服务等）的单一客户视图，同时提供接近容错机的故障恢复能力。

一说到集群，一般会想到使用它来为应用程序提供一种可扩展的高性能设计。但是集群同时还可以为应用程序提供较高的容错能力。以下是集群的分类：

高性能计算科学集群、负载均衡集群、高可用性集群

在实际应用中，这三种基本类型经常会混合使用。

硬件配置

（1）镜像服务器双机

使用两台单独的服务器做镜像服务器，之间使用镜像软件通过网络同步数据。镜像服务器的性能比单一服务器的性能要低，适用对集群系统要求不高的用户，

特点：简单、价格最低廉、可靠性较低、占用网络资源、性能较低。

（2）双机和磁盘阵列柜

此方式同样使用双服务器，同时后端的数据存储使用磁盘阵列柜。阵列柜为双机提供逻辑盘阵访问，并不随意扩展新的物理磁盘。

此方式不需要进行数据的同步，所以性能较镜像服务器要高出很多。但是可能会导致“单点错”，即系统中某一部件或某个应用程序发生故障时，导致所有系统全部宕机。如磁盘阵列如果出错，可能会导致存储的数据全部丢失。

特点：性能较高、可能导致单点错误。

（3）光纤通道双机双控集群系统

使用光纤来组建通道进行连接。允许镜像配置。

特点：扩展性强、费用较高。

随着硬件和网络操作系统的发展。集群技术将会在系统可用性、高可靠性和系统冗余方面逐步提高。

（如以后的集群可以依靠集群文件系统实现对系统中所有文件、设备和网络资源的全局访问，并且生成一个完整的系统映像。）

---

论文阅读总结

可靠性工程

原文链接： http://wenku.baidu.com/view/98b021225901020207409c76.html

该文从工程学的角度来说明了可靠性工程如何开展，并举例说明如何在软件开发过程中应用可靠性工程。

 

概念及发展

简单的定义：基于软件产品的可靠性进行预测、建模、估计、度量及管理。

其目标是提高软件系统的可靠性。为达到这个目的，我们需要明白失效产生的原因。

核心问题：如何开发出高可靠性的软件；另一问题：如何评估已有系统的可靠性。

在软件开发中的应用

可靠性工程贯穿于软件开发生命周期的各个阶段。

 

项目开发计划及需求分析阶段

本阶段中，主要是要明确可靠性需求，建立系统的可靠指标。一般情况下，可靠性工作可如下安排：

1）确定功能概图

功能概图主要描述系统中各功能及其使用环境和被使用的概率。

2）对失效进行定义和分类

3）确实用户的可靠性需求

4）平衡性研究

5）建立可靠性指标

 

软件设计和功能实现阶段

该阶段主要工作：

1）在模块间分配可靠性指标

分解系统为多模块，各模块间分配指标，使得最后计算出的总指标满足需求。

2）按可靠性指标进行设计

有关可靠性设计的内容，参见在上文中内容。

3）根据功能概图集中资源配置

4）控制错误的引入和传播

软件审查（代码审核）、软件测试（单元测试和集成测试）。

5）测试现成软件的可靠性

 

系统测试和现场试运行阶段

该阶段是保证可靠性的最后阶段。主要工作：

1）确实操作概图

操作概图主要描述系统最后可以使用的各操作（命令）及其使用环境和被使用的概率。

2）可靠性增强测试

系统测试、交付测试。

按照操作概图中的概率执行测试用例，模仿用户的应用方式测试。

3）根据测试来证明是否已经达到可靠性指标

收集失效数据，规划室额外的测试。

4）现场可靠性评估

分析数据，分析差异原因。

 

维护阶段

主要工作：

1）规划交付使用后的人员需求。

2）监视现场可靠性，并做出适当的调整。

3）监视并维护新功能引起的失效。

4）分析软件交付后失效的产生原因，指导工程改进，降低引入类似错误的可能性。

 

成功案例

文中以一交换机的研发做为例子，说明可靠性工程的应用，给产品带来了惊人的好处：

问题数下降、维护费用下降、测试件间隔缩短、引入新产品的间隔缩短、客户满意度提升。

原因如下：

⑴把可靠性作为确定是否发行的标准，可避免用户在使用中反映过多问题和进行相应的维护工作。

⑵采用“操作概图驱动”的测试方法，提高了测试效率；20%的操作覆盖了95%的应用，20%的错误导致了95%的实效；先测试20%的使用最频繁的操作可以加速可靠性的提高。

 

结束语

国内外还未能有系统化的可靠性工程学理论。我们需要不断结合实践进行研究和总结，为使可靠性工作成为有计划、有组织和有目标的研究工作而努力。

---

高可靠性测试

原文链接： http://tech.it168.com/a2008/0829/202/000000202483.shtml

该文以作者参与的CraftGS系统为例，讲述了如何在系统中应用测试技术保证软件的高可靠性，这些技术包括：软件验证、软件确认、软件测试管理。

综述

高可靠性软件泛指一类软件：该类软件运行过程中若出现故障会引发重大灾难性事故或经济损失。通常航天型号软件、银行系统软件、医疗行业软件、通讯行业软件等均属此范畴。

作者的CraftGS系统就是可靠性要求较高的一个软件系统，其中各子系统的可靠性指标都在0.95以上。

方案：软件验证技术 + 软件确认技术 + 软件测试管理。

验证技术主要是人工完成，方法有：面对面质询、文档抽查、非正式会议、同行评审等等。

软件确认技术则主要着眼于排除程序代码中的错误。目前支持很好的自动化。

工程质量的把控，主要依靠测试管理，分为：“软件测试团队组织管理、软件测试计划管理、软件缺陷（错误）跟踪管理以及软件测试件管理”四大部分。

 

软件验证技术

主要包含以下方面：

需求规格说明验证

保证用户的所有需求（功能、业务、非功能、约束）都已经被分配到软件需求规格说明的各需求项中。

设计规格说明验证

主要是逐步检查概要设计和详细是否全部分配了之前的分析成果。其中，还要进行数据库设计的验证。

代码验证

包括：代码规范审查、代码审查和代码静态分析。

交付验证

在测试完成后，系统交付客户前，需要进行交付验证和测试。交付验证包括安装验证和使用验证两部分，以确保软件和用户手册匹配。

 

软件确认技术

其实这里是测试技术。有：

单元测试（白盒）

建构桩模块和驱动模块以驱动被测单元（函数、类、模块）运行，使用设计好的测试用例对各单元进行测试。

集成测试（灰盒）

验证各模块组装后的软件是否能达到概要设计规格说明中模块的设计目标；各模块内部是否存在冲突，保模块能否正常工作。一般采用自底向上按集成度由小到大进行集成测试。

系统测试（黑盒）

检测系统是否满足软件需求规格说明中的各需求项，包括：业务需求、功能需求、非功能需求（质量属性）及约束。虽然不涉及代码，但是由于需求项涉及的领域较广，所以测试方法多而杂，如：

功能测试、执行路径测试、可靠性测试、压力测试、可恢复性测试、可移植性测试……等。

这些测试的特点：在一定环境条件下（如：模拟现场或极端条件），设计并运行各种测试用例，根据测试结果数据，评估软件系统是否符合软件需求项的各类要求。

交付测试

交付测试的主要参与者是目标客户，客户参与越多越好。主要进行：安装测试、可用性测试、alpha测试、beta测试等。

 

软件测试管理

软件测试团队组织管理

是否能组建一个合适的测试团队，直接影响到测试工作的进展和质量。作者的CraftGS系统中的测试团队，有资深测试专家、测试人员、兼职人员（同行评审）、测试新手。

软件测试计划管理

其实就是安排好测试的流程。

主要有：软件测试策划、软件测试技术剪裁、测试进度管理、成本管理。

软件缺陷（错误）跟踪管理

跟踪一个错误的全生命周期，确保每一个错误都能及时纠正及不引入新的错误。当测试人员提交错误后，需要督促开发团队及时修正，并在修正完成后进行回归测试。一般使用BUG管理系统即可。

软件测试件管理

努力建设好测试团队的财富库并对测试团队成员进行技能培训以帮助他们能使用好这个财富库。

测试件（Testware）是指测试工作形成的产品，包括：实践中积累的经验教训、测试技巧、测试工具、规格文档及一些通用脚本。

测试件管理工作主要是：建设与培训。

 

结语

目前对高可靠性软件如何实话软件测试技术仍是一个颇不成熟的领域，缺少一种体系化的方法。

本文转自BloodyAngel博客园博客，原文链接：http://www.cnblogs.com/zgynhqf/archive/2010/08/16/1800767.html，如需转载请自行联系原作者