定义必要的可靠性南大计算机系

定义必要的可靠性南大计算机系第一页，共四十页，2022年，8月28日可靠性的定量定义使我们能够精确地平衡客户对可靠性，交付日期和成本的要求，并更加有效地开发和测试产品。第二页，共四十页，2022年，8月28日失效/错误失效(failure)是指系统运行的行为对用户要求的偏离，是面向用户的概念。只有在系统运行的时候才可能有失效。错误(fault)是指在系统运行时引发或可能潜在地引发失效的缺陷。是面向开发的概念。第三页，共四十页，2022年，8月28日失效严重程度类别（1）失效严重程度类别一组单个出现时对用户产生相同影响的失效。指定失效的严重程度，主要是为了结合失效频率来解决失效的优先级。分级标准人员生命，成本，系统能力的影响。还可能包括一些子标准：额外的运行成本，修复和恢复成本，…。第四页，共四十页，2022年，8月28日失效严重程度类别（2）不可能精确估算失效的影响。根据成本划分的失效严重程度类以10倍的关系划分。通常不超过四个级别。失效严重程度类定义1>100000210000-10000031000-100004<1000第五页，共四十页，2022年，8月28日失效严重程度类（3）根据对系统能力的影响划分失效严重程度类。失效严重程度类定义1用户不能进行一项/多项关键操作。2用户不能进行一项/多项重要操作3用户不能进行一项/多项操作，但是有不久方法4一项或多项操作中的小缺陷第六页，共四十页，2022年，8月28日失效强度（1）失效强度是表示可靠性的一种简单直观的方式。起初是指单位时间内出现失效的次数。对于软件来说，执行时间是软件的度量方式。虽然使用执行指令数目来度量软件的失效强度更加准确，但是和系统其他部分的度量不兼容。第七页，共四十页，2022年，8月28日失效强度（2）有时，将失效强度表示为每个自然单位出现的失效数目更加方便。比如打印机输出的页数，交易数目，电话呼叫次数等。每打印10000页出现一次失败，每100000次电话出现电话掉线，…失效强度的单位也可以用来表示可靠性。第八页，共四十页，2022年，8月28日失效强度（3）如果系统的成功执行要求所有组件的成功执行，那么系统失效强度就是所有组件的失效强度的总和。第九页，共四十页，2022年，8月28日过程（1）为了为每个产品系统分析定义必要的可靠性，我们需要为产品定义进行了严重程度分类的失效为所有相关的系统选择一种通用的度量为每个测试的系统建立失效强度目标。对于所开发的软件产品，针对该软件我们必须找出所开发软件的失效强度目标。指定策略以满足所开发软件的失效强度目标第十页，共四十页，2022年，8月28日定义失效根据用户的需要，对程序行为创建消极需求。通过说明系统不应该做的事情来给出失效的定义。这些消极需求（错误的行为）应该根据失效严重程度类别列出。而这些类的划分方法对每个项目都有所不同。我们可以根据情况选择特定的严重程度类划分标准。第十一页，共四十页，2022年，8月28日定义失效Fonefollower的失效严重程度类失效严重程度类定义1导致不能转发呼叫的失效。2导致不能输入要转发的呼叫号码的失效3使系统管理困难，但是可以用别的方法代替的失效4引起不方便的失效第十二页，共四十页，2022年，8月28日选择通用度量可靠性的度量方式可以选择自然单元。一个产品可能具有多种自然单元，每个自然单元和一组重要的功能相联系。此时可以选择时间作为失效强度的基础。一般时间？执行时间？如果平均计算机使用时间的变化不大，可以使用一般时间来替代执行时间。否则可以将执行时间调整为一般时间。第十三页，共四十页，2022年，8月28日建立失效强度目标(FIO)需要给每一个被测试的系统建立相应的失效强度目标。对超系统（或独立的产品），直接设定失效强度目标。对于某个组件，将超系统的FIO减去其他组件的FIO，得到它的FIO。如果组件属于多个系统，那么取最小值为其FIO。为每个采办组件建立FIO。第十四页，共四十页，2022年，8月28日建立失效强度目标（2）超系统（或独立产品）的FIO的确定依赖于产品特性，用户/客户的具体需求和期望。需要考虑实效强度（可靠性），开发时间，开发成本等。考虑和这个产品竞争的产品。考虑和这个产品相关的其他系统的FIO。第十五页，共四十页，2022年，8月28日建立失效强度目标（3）对于某个版本，根据当前的开发技术水平，以及新功能的个数，失效强度，开发时间，开发成本的乘积基本上是一个常量。需要在这三者之间取得平衡。同时，对于不同的产品，这三者之间的关系未必一样。可以通过以往的数据来知道三者之间的精确关系，以指导决策。第十六页，共四十页，2022年，8月28日建立失效强度目标（4）建立失效强度目标时的参考信息。失效影响FIO时间数百人死亡，10亿美元以上损失10-9114000年1-2人死亡，1百万美元左右的损失10-6114年大约1000美元的经济损失10-36周大约100美元的经济损失10-2100小时大约10美元的经济损失10-110小时大约10美元的经济损失11小时第十七页，共四十页，2022年，8月28日建立失效强度目标（5）一般用单个用户的方式给出可靠性数据，便于市场开发专家将它和需求联系起来。对于FoneFollower，我们可以定为每10000个呼叫有一次失效。如果用户用最严重的失效（1类失效）表示需要的失效强度，那么应该将用户的SFIO除以最严重失效的比率。（因为经验显示这样的比率是确定的）FIO是对所有的操作而言的，而不是对于少数关键操作而言的。第十八页，共四十页，2022年，8月28日建立失效强度目标（6）在规划FIO的时候，需要用户的参与。可以使用户感到满意；可以更加准确地了解用户的需求。如果产品的客户数量少，那么可以要求客户一起工作。如果产品有大量的小用户，则需要对用户随机采样，提供一定的鼓励等。第十九页，共四十页，2022年，8月28日可靠性和失效强度的关系有时，需要在可靠性与失效强度之间进行转换 =-lnR/t R=exp(-t)如果R>0.95，那么近似计算

=(1-R)/t R=1-t其中表示失效强度，R表示可靠性，t表示时间。第二十页，共四十页，2022年，8月28日可靠性和失效强度的关系如果要起8小时的可靠性为0.992，那么失效强度应该为每1000小时1个失效。每1000页打印出现1次失效，可以转换为8页打印的可靠性为0.992。第二十一页，共四十页，2022年，8月28日可用性和失效强度（1）可用性A表示在一段时间内，系统以可接受的状态工作的时间和总时间的比率 A=tu/(tu+td)Tu表示正常运行的时间，td表示downtime. Td=tmtu，其中tm表示每个失效导致的平均停机时间。第二十二页，共四十页，2022年，8月28日可用性和失效强度（2）A=1/(1+tm)=(1-A)/Atm比如：如果产品的可用性必须达到99%，并且停机时间为6分钟，那么失效强度目标大概是每小时0.1个失效。第二十三页，共四十页，2022年，8月28日确定被开发软件的FIO（1）如果产品需要开发软件组件，那么需要为这个组件设定FIO。首先找出系统中预期的采办组件的FI。根据操作数据，提供商担保，专家经验来估计。通过从对应的系统FIO减去采办组件的FI，得到每个系统自记开发的软件的FIO。第二十四页，共四十页，2022年，8月28日确定被开发软件的FIO（2）以FoneFollower为例，如果从硬件提供商那里得到数据，硬件组件的FI是每小时0.1个失效；操作系统在每小时10万次呼叫的情况下，每小时0.4个失效。转换之后得到，采办组件的失效强度为每百万次5次失效。如果产品的FIO和采办组件的FI有比较大的差别，可以考虑使用其他的组件来替代。直接累加采办组件的失效强度可以得到总采办FI。是一种近似的计算方法，但是比较有效。实际的FI低于计算得到的FI。第二十五页，共四十页，2022年，8月28日指定策略以满足FIO（1）选择正确的可靠性策略，在时间和金钱允许的情况下，尽可能提高满足目标的可能性。可靠性策略的实施主要由系统工程师和系统架构师完成，但是该策略对测试的影响也非常大。三种策略：错误预防，错误清除，容错。第二十六页，共四十页，2022年，8月28日指定策略以满足FIO（2）错误预防应用适当的需求获取方法，进行需求审查，实现设计方法进行设计复查，建立和执行各种标准，使用好的需求获取工具和设计工具等。错误预防的有效性通过估计进行预防活动之后的剩余错误的比例来度量。第二十七页，共四十页，2022年，8月28日指定策略以满足FIO（3）错误清除通过代码审查和测试清除错误。代码审查的有效性由审查之后遗留错误的比例确定。也许可以通过某种数据模型来估算剩余错误数量。测试的有效性可以通过测试之前的FI和测试之后的FI的比例来度量。这样的度量可以改进我们的测试方法。第二十八页，共四十页，2022年，8月28日指定策略以满足FIO（4）容错容错必须通过设计来实现。通过预测系统可能会出现哪些失效，并通过冗余设计来对抗这些失效。第二十九页，共四十页，2022年，8月28日指定策略以满足FIO（5）理论上，应该通过平衡各种因素来选择适当的策略：策略的开销，有效性，使用的范围等。一般可以根据经验选择策略。超可靠性：每1000小时<0.1失效；使用容错技术，广泛的需求和设计评审高度可靠：每1000小时0.1-10失效；要求相当广泛的需求和设计评审，可能需要一些容错。商品化：每1000小时10-2000失效；指导需求或带有操作剖面和评判标准的设计评审。原型：每1000小时>2000失效；一般测试第三十页，共四十页，2022年，8月28日指定策略以满足FIO（6）通过操作剖面(Operationprofiles)，可以确定将策略的重点放在哪里。通过产品的前面一个版本的实际失效强度，和FIO比较以确认工作的重点。投入一定的工作量来改进开发过程。第三十一页，共四十页，2022年，8月28日特殊情况失效的其他划分方法为组件分配失效强度目标软件安全性和超可靠性第三十二页，共四十页，2022年，8月28日失效的其他划分方法为满足特殊的目的，可以根据其他的特征对失效进行分组。组件操作组失效类别作业角色第三十三页，共四十页，2022年，8月28日为组件分配FIO（1）由采办软件组件的FI以及产品的FIO来确定开发部件的失效强度。一般没有折衷过程。但是，如果有多个不同层次的可选组件，那么我们可以考虑在不同的组件之间进行FI和资金的分配。首先，将系统划分为适当的组件；确定组件的失效目标。第三十四页，共四十页，2022年，8月28日为组件分配FIO（2）划分组件主要依据系统配置的性质，项目管理问题以及管理较多组件的可靠性所需要的工作量或成本。应该尽可能将系统划分为与现有可以重用的组件相似的组件。（可以更多地重用更加可靠的系统）第三十五页，共四十页，2022年，8月28日为组件分配FIO（3）确定FIO估计已知的组件值逐步分配组件的失效强度目标以缩短系统开发时间，降低开发风险或成本根据组件的FIO，计算系统的FI并和需求比较修改组件的FIO，直到满足需求。第三十六页，共四十页，2022年，8月28日为组件分配FIO（4）以FoneFollower为例将整个系统分割成为3个部分：硬件，操作系统，应用程序。已经确定系统的FIO为100失效/百万次呼叫。硬件的可靠性为1失效/百万次呼叫所以操作系统+应用程序的总FI不超过99失效。对于不同的FIO，同样的软件需要不同的成本和时间。根据选择不同的开发成本和周期，可以得到适当的每个组件的FIO。第三十七页，共四十页，2022年，8月28日安全性与超可靠性（5）软件安全性是软件可靠性的一个子集。安全性表示避免灾难，而灾难显然是一种特殊的失效。软件可靠性的理论，方法也都适用于软件安全性。（容错，统计模型，…）软件安全性和超可靠性密切相关。第三十八页，共四十页，2022年，8月28日安全性与超可靠性（6）超可靠性一般指每