定义必要的可靠性

1、定义必要的可靠性赵建华南京大学计算机系 可靠性的定量定义使我们能够精确地平衡客户对可靠性，交付日期和成本的要求，并更加有效地开发和测试产品。失效/错误 失效(failure) 是指系统运行的行为对用户要求的偏离，是面向用户的概念。 只有在系统运行的时候才可能有失效。 错误(fault) 是指在系统运行时引发或可能潜在地引发失效的缺陷。是面向开发的概念。失效严重程度类别（1） 失效严重程度类别 一组单个出现时对用户产生相同影响的失效。 指定失效的严重程度，主要是为了结合失效频率来解决失效的优先级。 分级标准 人员生命，成本，系统能力的影响。 还可能包括一些子标准：额外的运行成本，修复和恢复成本，

2、。失效严重程度类别（2） 不可能精确估算失效的影响。 根据成本划分的失效严重程度类以10倍的关系划分。通常不超过四个级别。失效严重程度类定义1100000210000-10000031000-1000040.95，那么近似计算=(1-R)/tR=1- t 其中表示失效强度，R表示可靠性，t表示时间。可靠性和失效强度的关系 如果要起8小时的可靠性为0.992，那么失效强度应该为每1000小时1个失效。 每1000页打印出现1次失效，可以转换为8页打印的可靠性为0.992。可用性和失效强度（1） 可用性A表示在一段时间内，系统以可接受的状态工作的时间和总时间的比率A = tu/(tu+td) Tu

3、表示正常运行的时间，td表示downtime.Td = tm tu， 其中tm表示每个失效导致的平均停机时间。可用性和失效强度（2） A = 1 / (1+tm ) = (1-A)/A tm 比如：如果产品的可用性必须达到99%，并且停机时间为6分钟，那么失效强度目标大概是每小时0.1个失效。确定被开发软件的FIO（1） 如果产品需要开发软件组件，那么需要为这个组件设定FIO。 首先找出系统中预期的采办组件的FI。 根据操作数据，提供商担保，专家经验来估计。 通过从对应的系统FIO减去采办组件的FI，得到每个系统自记开发的软件的FIO。确定被开发软件的FIO（2） 以Fone Follower

4、为例，如果从硬件提供商那里得到数据，硬件组件的FI是每小时0.1个失效；操作系统在每小时10万次呼叫的情况下，每小时0.4个失效。转换之后得到，采办组件的失效强度为每百万次5次失效。 如果产品的FIO和采办组件的FI有比较大的差别，可以考虑使用其他的组件来替代。 直接累加采办组件的失效强度可以得到总采办FI。 是一种近似的计算方法，但是比较有效。实际的FI低于计算得到的FI。指定策略以满足FIO（1） 选择正确的可靠性策略，在时间和金钱允许的情况下，尽可能提高满足目标的可能性。 可靠性策略的实施主要由系统工程师和系统架构师完成，但是该策略对测试的影响也非常大。 三种策略： 错误预防，错误清除，

5、容错。指定策略以满足FIO（2） 错误预防 应用适当的需求获取方法， 进行需求审查， 实现设计方法 进行设计复查， 建立和执行各种标准， 使用好的需求获取工具和设计工具等。 错误预防的有效性 通过估计进行预防活动之后的剩余错误的比例来度量。指定策略以满足FIO（3） 错误清除 通过代码审查和测试清除错误。 代码审查的有效性由审查之后遗留错误的比例确定。 也许可以通过某种数据模型来估算剩余错误数量。 测试的有效性可以通过测试之前的FI和测试之后的FI的比例来度量。 这样的度量可以改进我们的测试方法。指定策略以满足FIO（4） 容错 容错必须通过设计来实现。 通过预测系统可能会出现哪些失效，并通过

6、冗余设计来对抗这些失效。指定策略以满足FIO（5） 理论上，应该通过平衡各种因素来选择适当的策略：策略的开销，有效性，使用的范围等。 一般可以根据经验选择策略。 超可靠性：每1000小时2000失效；一般测试指定策略以满足FIO（6） 通过操作剖面(Operation profiles)，可以确定将策略的重点放在哪里。 通过产品的前面一个版本的实际失效强度，和FIO比较以确认工作的重点。 投入一定的工作量来改进开发过程。特殊情况 失效的其他划分方法 为组件分配失效强度目标 软件安全性和超可靠性失效的其他划分方法 为满足特殊的目的，可以根据其他的特征对失效进行分组。 组件 操作组 失效类别 作业

7、角色为组件分配FIO（1） 由采办软件组件的FI以及产品的FIO来确定开发部件的失效强度。一般没有折衷过程。 但是，如果有多个不同层次的可选组件，那么我们可以考虑在不同的组件之间进行FI和资金的分配。 首先，将系统划分为适当的组件； 确定组件的失效目标。为组件分配FIO（2） 划分组件 主要依据系统配置的性质，项目管理问题以及管理较多组件的可靠性所需要的工作量或成本。 应该尽可能将系统划分为与现有可以重用的组件相似的组件。（可以更多地重用更加可靠的系统）为组件分配FIO（3） 确定FIO 估计已知的组件值 逐步分配组件的失效强度目标以缩短系统开发时间，降低开发风险或成本 根据组件的FIO，计算

8、系统的FI并和需求比较 修改组件的FIO，直到满足需求。为组件分配FIO（4） 以Fone Follower为例 将整个系统分割成为3个部分：硬件，操作系统，应用程序。 已经确定系统的FIO为100失效/百万次呼叫。 硬件的可靠性为1失效/百万次呼叫 所以操作系统+应用程序的总FI不超过99失效。 对于不同的FIO，同样的软件需要不同的成本和时间。根据选择不同的开发成本和周期，可以得到适当的每个组件的FIO。安全性与超可靠性（5） 软件安全性是软件可靠性的一个子集。 安全性表示避免灾难，而灾难显然是一种特殊的失效。 软件可靠性的理论，方法也都适用于软件安全性。（容错，统计模型，） 软件安全性和超可靠性密切相关。安全性与超可靠性（6） 超可靠性 一般指每执行小时的错误小于10-4次. 一般要求某些操作达到超可靠性，而不是整个系统。 硬件的超可靠性和一般时间相关，但是软件的超可靠性只和执行时间相关。安全性与超可靠性（7） 超可靠性的开发费用，时间，困难都非常