精华内容
下载资源
问答
  • 产品可靠性三大指标
    千次阅读
    2022-01-16 10:03:07

    一 可靠性指标

    可靠性需求反映了系统在一定条件下无故障地运行的能力。

    计算公式

    可靠性 = 总的有效运行时间 / 总运行时间。

    可靠性分为硬件可靠性和软件可靠性。

    1 硬件可靠性

    硬件可能会出现故障。出现故障的原因是,设备元器件都是有使用寿命的,时间长了元器件就可能坏掉。整机的故障率受所有元器件的故障率的影响。为降低整机故障率,我们就要选用更优质的元器件。

    硬件可靠性可以通过三个指标来评估。

    a 平均无故障时间

    所有设备平均多长时间发生一次故障。

    b 维护响应时间

    如果设备出现故障,就需要维修,维修人员应尽快到达现场,在企服产品中,如果对方承诺提供 7*24 小时维修服务,并且1小时达到现场,那么该公司的维修能力很强。这个指标被称为维护响应时间。

    c 平均维护时间

    维修人员在达到现场后,就应该尽快修好产品。在设计硬件时,就要考虑如何尽快修好。比如,设备电源支持热插拔,如果电源坏了,不用关机也能更换电源,这样维修时间就很短。要多长时间才能修好,这个时间被称为平均维护时间。平均维护时间是指修复一次故障所需的总时间,该时间包含维护响应时间,修好所用的时间等。

    综上所述,硬件可靠性是平均无故障时间、平均维护时间的综合反映。如果一歀硬件产品的可靠性强,那么该产品用的时间长(体现可靠性),并且坏的次数少(体现平均无故障时间),坏了以后维修快(体现平均维护时间)。

    硬件可靠性的提升体现在两方面。一方面,硬件要能稳定运行,无故障。另一方面,设备要支持冗余备份,如系统支持双电源,当一个电源坏了时,另一个仍然可用。

    硬件可靠性还会受环境的影响。硬件对环境的湿度和温度都有要求,不适宜的温度和湿度将造成硬件故障。其要求又分硬件工作时的温度和湿度要求、硬件存放时的温度和湿度要求。

    2 软件可靠性

    软件可靠性和硬件可靠性是类似的,也有平均无故障时间、平均维护时间等指标。

    首先,软件可靠性是建立在硬件可靠性之上的。如果没有硬件的正常工作,软件的正常工作就无从谈起。为了避免硬件故障导致软件不可用,我们将软件安装在多台设备上。此时,如果一台设备坏掉了,也不会影响软件的使用。

    其次,在设计软件的时候应设计一些功能,来提升其可靠性。常见的是设计一些便于排错、便于恢复系统的功能,如定期进行数据备份,这样软件就可以快速从错误中恢复,也避免人为因素造成系统损坏。

    最后,软件可靠性也包括系统的完整性。如果不出现数据丢失,就说明数据完整性比较好。但是系统不同,对完整性的要求也不同。比如,视频直播对数据完整性的要求比较低,偶尔丢失几个数据,并需影响视频的观看。

    二 产品经理工作

    产品经理应与研发人员协商,共同定义可靠性需求。我们将产品经理分为软件产品经理和硬件产品经理,他们的主要工作如下。

    软件产品经理的工作。比如,定义备份功能,如餐饮软件要支持数据备份。这样数据在设备上坏掉后就可快速恢复,并且该恢复功能要有图形界面。定义数据完整性的要求,如说明该业务对数据完整性的要求高不高。

    硬件产品经理的工作。比如,定义硬件规格,如硬件要支持冗余电源,支持双路供电等。再如,定义告警机制。当硬件出现某些故障,可以通过短信、界面和指示灯方式告知用户。

    三 可靠性指标汇总

    可靠性需求

    平均无故障时间

    产品出现故障的时间平均值,如电脑的平均无故障时间为15年,就是说电脑平均算起来,15年出故障。

    平均维护时间

    产品出现故障后平均完成维修的时间,包括在途时间和到达现场的维修时间,如果平均维护时间为0.5小时

    维护响应时间

    从发现故障到开始维修所需要的时间,比如,要求公司支持 7*24 小时随时响应,且1小时内开始维修,这就是对维护响应时间的要求

    可靠性

    可靠性 = 总的有效运行时间 / 总运行时间。如果一项业务的可靠性为99.999%,则在1年时间内,该业务中断5.26分

    硬件环境需求

    温度要求

    分工作时和不工作时的温度要求,如工作温度为 -10摄氏度~40摄氏度

    湿度要求

    过高的湿度也会造成硬件故障,如湿度要求是 0%~95%

    四 可靠性和可用性的异同

    可靠性和可用性的概念很类似。区别是,可靠性是从系统角度讲产品有没有问题,可用性是从用户角度讲产品有没有问题。两者含义类似但视角不相同,产品不可靠并不一定意味着产品不可用。

    比如,服务器硬件如果频繁出现故障,则说明硬件可靠性不好。但可靠性不好,不能说明系统不可用。因为一个设备坏了,其他设备仍可用,所以产品还是可用的。再如,服务器支持双电源冗余备份,如果其中一个电源经常坏,我们可以说系统可靠性不好。但另外一个电源仍能让系统工作,并去影响系统的可用性。

    现在的大多数大型软件系统或物联网系统,都是在硬件不可靠的前提下,提升用户的可用性的。比如,即使某些网络设备坏了,现在的互联网体系也能正常上网,因为数据还可以通过其他设备传输。再如,现在各种云平台也能在任意服务器损坏的情况下,做到不丢失数据和不停止服务,因为一台服务坏了,其他服务器还照常工作。在现实生活中,我们用的网盘没有出现过数据丢失,也是因为在服务器端做了数据备份。

    更多相关内容
  • 软件系统在某种意义上也是一种产品,所以用MTBF、MTTF、MTTR这指标来衡量软件系统的可靠性同样也是合适的。本文着重介绍这指标的定义以及它们之间的关系。
  • 产品可靠性指标预计

    千次阅读 2021-07-23 06:13:49
    假设对某一产品/系统要求的可靠性为...首先将产品可靠性指标自上而下逐级地分配到产品的各个层次,借此落实相应层次的可靠性要求,并使整个与各部分之间的可靠性相互协调。尽量做到既避免出现薄弱环节又避免局部“质...

    假设对某一产品/系统要求的可靠性为:mtbf大于2000h,那么在对此系统立项时,mtbf应该设立怎么样的目标值?如何达到这一目标值,这就关系到可靠性预计和分配。

    开展可靠性预计和分配工作,是确保设计、生产“好”产品的指导性和基础性工作。首先将产品可靠性指标自上而下逐级地分配到产品的各个层次,借此落实相应层次的可靠性要求,并使整个与各部分之间的可靠性相互协调。尽量做到既避免出现薄弱环节又避免局部“质量过剩”而带来浪费。可靠性预计则是自下到上地预计产品各层次的可靠性参数,判断各层次设计是否满足分配的可靠性指标。只有各层次的可靠性分别达到分配的要求,才能保证产品可靠性指标得以实现。对未达到分配指标要求的设计,则能发现其可靠性薄弱环节、设计上的隐患及提供选择纠正措施的指南,并依此改进设计直到满足指标要求为止。在产品设计阶段就应该“设计进”规定的可靠性指标,也就是必须通过开展可靠性预计和分配工作尽早来落实产品的可靠性指标,而不是靠产品既成之后的抽样统计试验结果。

    一、mtbf的设计目标值

    为了使产品满足使用要求,也就是为了使产品的mtbf达到一定的最基本的要求,我们应该在从设计阶段就开始考虑这个要求;很显然,如果要求产品在使用时mtbf为200h,那产品在设计的mtbf就应该比200h大,才有把握保证产品的mtbf满足这一要求。使用时mtbf与设计时mtbf一般情况下满足如下关系:

    b05f1e0479c6829e2d76e9f421ad6bf0.png

    可靠性定量指标mtbf(θ)有诸多参数,它们之间关系上图所示。

    θt(mfhbf)——门限值。根据用户需求或使用要求而定;

    θmav——最低可接收值,一般θmav/θt=1.25,它是考核指标;

    θ1——mtbf检验下限值,在统计测试方案中,当产品mtbf真值接近或等于θ1时,以高概率拒收该产品,一般θ1/θmav =1.25。

    θ0——mtbf检验上限值,在统计测试方案中,当产品mtbf真值接近或等于θ1时,以高概率接收该产品,一般θ0/θ1 =d0;

    按gjb 899测试方案ⅲ,α=β=0.1,d0=d=2;

    θp——mtbf设计值,又称规模值,是《研制任务书》中规定和期望达到的指标;按gjb299预计θp/θo=1.25。

    所以θp/θt=3.9;也就是说,设计目标值最小应该在实现使用要求值的4倍;一般情况下设计值为实现使用要求值的5~10倍。

    二、可靠性模型

    为了定量分配、估计和评价产品的可靠性,建立产品的可靠性模型是一种直观的、有效的方法。可靠性模型包括可靠性方框图和可靠性数学模型。产品典型的可靠性模型有串联模型和并联模型,还有些复杂的模型等等。例如(本例中各参数的意义、各参数与其它可靠性参数之间的关系,随后有详述):

    简单。对很难转换为简单的串并结构模型的分析需采用其他方法,常用的有布尔

    71396bc2ebc28645da320de17e85c5b5.png

    真值法、概率展开分析法、贝叶斯法等;这里不作叙述。

    注:产品的可靠性框图表示产品中各单元之间的功能逻辑关系,产品原理图表示产品各单元的物理关系,两者不能混淆如,某振荡器由电感和电容器组成,从原理图(图a)上看两者是并联关系,但从可靠性关系上看,两者只要其中一个发生故障,振荡器都不能工作,因此是串联模型

    三、可靠性分配

    在产品的设计阶段,就要把要求的mtbf“设计进”产品里。当产品的结构复杂时,将可靠性指标自上而下逐级地分配到各个简单的结构。它是一个由整体到局部,由上到下的分解过程,这个过程就叫做可靠性分配。可靠性分配有许多方法,如等分配法、评分分配法、比例组合法、动态规划法等。

    1、等分配法

    顾名思义,等分就是将失效率分配到各个部件时,是均分的。如一个有两个模块的系统要求mtbf为500h,则分配到每个模块的mtbf都为1000h。??

    2、评分分配法

    在产品的可靠性数据缺乏的情况下,可以请熟悉产品、有工程实际经验的专家,按照影响产品可靠性的几种主要因素(如:复杂度、技术成熟度、重要度及环境条件)进行评分(每一种因素的分值在1~10之间,难度越高评分越高),然后根据评分的结果给各分系统或部件分配可靠性指标。例如某个系统(要求的mtbf为500h)由a/b/c/d四个部件组成,各部件评分如下表:

    5ff3d66fa7a43982f2eef7fcac3206f8.png

    说明:(1)对四个部件(a/b/c/d)按四种因素评分后,填入上表(兰色字迹部份);

    (2)对a部份而言,最后评分为8*9*6*8=3456;b的评分为5*7*6*8=1680;同理c的评分为900、d的评分为1440;最后四部分总分为:7476;紫红色字迹部份。

    (3)对a部份而言,评分系数为3456/7476=0.46;b的评分系数为1680/7476=0.22;c的评分系数为0.12;d的评分系数为0.19;浅紫色部份。

    (4)对整个系统而言,失效率为1/500=0.002;

    所以分配给a的失效率为:0.46*0.002=0.0009,对应的mtbf为1081.6h;

    同理得b/c/d的失效率和mtbf,红色字迹部份。

    3、比例组合法

    四、可靠性预计

    为了达到分配的目标值,首先要知道的是将要设计的系统的可靠度可以达到什么水平。如果系统可以达到的mtbf远大于设计目标,就可以进行研发;如果小于设计目标值,就必须重新设计。那么如何确定将要设计的系统的mtbf值?在产品研发早期阶段各种信息还不足,无法计算,仅能用概略预计法进行可靠性指标预计;

    现推荐一种简便、准确、实用方法,即《简单枚举不完全归纳快速预计法》,简称cw可靠性指标预计法。cw法预计公式:

    λs=λ0。k1。k2。k3。k4。k5。n

    mtbfs=1/λs

    λs——系统失效率

    λ0——电子元器件平均基本失效率,对于国产器件λ0=10-5-10-6(1/h)、对于进口器件λ0=10-7-10-8(1/h);

    k1——降额设计*效果因子,根据降额设计水平不一样,一般取k1=(10--1)×10-2;考虑到产品的体积、重量与成本,一般取k1=10-1;

    k2——环境应力筛选效果因子、产品经过环境应力筛选测试,可靠性将有一定幅度提高,一般k1=0.5--0.1。

    k3——环境影响因子。产品使用于不同环境其取值也不同,k3取值见下表:

    35c90ff6b7e261a731f138e7715280be.png

    k4——机械结构影响因子。在使用中,机械结构件也会产生故障。一般取值k4=1.5--3.5;

    k5——制造工艺影响因子。产品在制造过程中,制造工艺不良也会影响产品可靠性;一般取值k5=1.5--3.5;

    n——系统所含电子元器件数量;

    mtbfs——系统平均故障间隔时间;

    用cw法预计可靠性指标,只需要知道设计中所以用到的电子元器件的个数、电子元器件的产地、系统将要使用的环境(就可以估计出系统的λs,从而得到mtbf);

    *降额设计是一种为了提升产品可靠性而常用的设计方法,此部分内容随后给出说明。这里先给出一个cw法预计实例(例一):

    某陆用移动产品,该产品含有进口电子元器件约为2000个,其固有可靠性指标为:

    λs=λ0·k1·k2·k3·k4·k5·n

    =10-7×10-1×0.5×5×1.5×2×2000

    =15×10-5/h

    mtbf= 1/λ=1/15x10-5=6667h

    在使用过程中,要求mtbf为200h,则设计目标值为800h,6667>800,也就不需要改动了。但用户要求mtbf为2000h(则设计目标值为8000h),对于一个mtbf为6667h的系统(此时的可靠性称为系统的基本可靠性),为了达到mtbf为8000h的要求,就必须提升系统完成任务的能力(也就是提升系统的任务可靠性)。

    展开全文
  • 取二表决系统的可靠性分析为例,详细介绍了Relex软件中可靠性与维修性分析的几种重要方法,讨论了表决系统在元件组成、结构设计和维修性方面的可靠性指标,总结了提高系统可靠性的有效途径。利用Relex可靠性分析...
  • 可靠性是一门有价值的学科,它应用了很多技术,我们可以用来解决问题并开发出可靠的产品。当然这一定存在一些指南和成功经验,但是我们必须要根据企业的实际情况来进行裁剪。其中我们需要关注的领域有企业的规模、...

    1、指南而不是强制要求

    可靠性是一门有价值的学科,它应用了很多技术,我们可以用来解决问题并开发出可靠的产品。当然这一定存在一些指南和成功经验,但是我们必须要根据企业的实际情况来进行裁剪。其中我们需要关注的领域有企业的规模、企业文化、过去的经验、教育背景、市场和要求等。

    即使这本书已经提供了众多不同的技术,但是千万不要认为我们需要采用所有的技术。在这本书的剩余部分所写可以成为指南或者提示。针对具体的项目,我们需要自己来判断哪些经验适用,哪些经验不适用。绝对不能够直接拷贝别人的可靠性大纲,即使是同一个行业的也不行,当然我们也不能够拷贝之前公司的可靠性大纲。他们可以是我们开始时非常有价值的参考,但是当我们试图直接拷贝一个可靠性大纲时只会给我们带来灾难,因为只有切合组织的文化,参与产品项目的人,这个可靠性大纲才会真正起作用。我曾经见过两家企业生产相同的产品,但是他们的可靠性大纲完全不同,但是这两家公司的可靠性大纲执行的都很好。

    我们应该注意的比较重要的事情是不管我们起草了什么样的可靠性大纲,关键是在产品开发流程给定的时间内必须有一个可以测量的指标,而这个可靠性大纲应该保障产品能够获得理想的结果。

    2、什么是可靠性设计

    可靠性早已不是由一个团队来单独开展的活动。产品可靠性指标、风险和活动已经融入到组织的每个流程和功能当中去。高级管理团队的职责就是培训团队清晰的可靠性和质量意识。技术团队必须平衡项目成本、的产品维修保养成本、质量、项目周期、性能和可靠性(有些行业可能还有其它指标)来达到优化产品设计的目的。我们的组织构架必须做到鼓励每个成员来采用合适的可靠性方法和手段。嘉峪检测网认为,可靠性设计作为可靠性工程师的一个职责是来发现性价比高的零部件和风险低的结构设计并把它展示给团队中的其它成员。

    当我1984年开始从事可靠性工作时,可靠性看上去接别人丢过来的东西,当设计工程师完成产品设计后就完全转给可靠性团队来负责。当可靠性团队拿到产品时几乎无法影响产品的设计,所以可靠性工作的重点就是评估产品的可靠性水平。如果产品没有满足可靠性指标要求,我们可以做什么呢?事实上还是销售给户,然后花费多年时间来跟踪产品的性能并纠正那些可以改善的问题。当然,产品会随着时间的推移越来越好了。我曾经的那家公司通常是利用来建立一个反馈机制。最终结果就是不满意,公司在可靠性方面的信誉很差。很不幸的是这样的做法很常见。

    在当今全球经济下,很多行业在比拼可靠性。我们终于意识到“丢过墙”的模式已经不行了。可靠性是设计出来的。没有什么比让设计工程师对他们产品设计的可靠性负责更好的方式了。这种模式现在执行的很好,当我开展可靠性设计演讲时,参加的人员大部分是设计工程师而不是可靠性工程师。可靠性工程师的职责转变为顾问。可靠性工程发现最合适的技术并给设计工程师培训如何使用。可靠性工程师还辅助撰写可靠性大纲,而设计工程师则负责执行可靠性大纲。

    可靠性设计就是如何让设计工程师承担产品可靠性的职责。可靠性部门开始成为指导委员会,帮助制定规章制度,提供方向指导和培训。我把这比作划船比赛。可靠性工程师是船长(划船队的船长通常坐在船头面对船尾,指挥整个船队并协调大家的每个船员的力量和节奏)。设计工程师就是船员。当两者协同工作,整条船就能够在水面上更平稳省力的滑行。

    谁应该参加可靠性设计的课程?

    每次当我提供可靠性设计培训时,我的总是问谁应该参加。当然设计工程师必须参加。那么市场人员需要参加吗?当然,他们需要参加。我们必须让销售、服务、和工厂都应该有相应的代表参加。同事可靠性团队也需要参加。任何人与产品可靠性相关的都必须参加。然而,设计工程师是流程中的关键。他们日常中队产品设计所做的决定会极大的影响产品的可靠性。那么可靠性团队的职责又是什么呢?这个团队需要可靠性工作的领导者和培训者,同时还需要协助制定可靠性指标和撰写可靠性大纲。而日常的可靠性工作则由设计工程师来完成(在可靠性团队的指导下)。

    案例:

    一个通信企业被产品糟糕的可靠性水平所困扰。每次他们在产品测试或者工程发现问题时,测试工程师和工程的工程师都无法获得设计工程师的帮助来解决问题,因为设计工程师都在忙着开发新产品没有时间。你看,他们只关心多快可以把产品推向市场,但是产品是否可靠性不重要。这家企业做了一个很聪明的决定,首席执行官做了个决定,他告诉所有的设计工程师,从现在开发解决问题是他们的职责。你知道发生了什么吗?突然设计工程师开始愿意倾听可靠性团队的声音,于是一个可靠性设计的项目开始在企业内诞生。绝大多数设计工程师喜欢从事新产品设计工作,不喜欢对问题进行改善。不久他们开始从事新项目,他们也有了更好的认识。他们试图成功解决之前项目的问题,这时候他们才真正认同可靠性并为产品可靠性设计而做出努力。

    3、只有把可靠性整合进产品开发才完整

    整合可靠性就是把可靠性技术集成到产品开发流程中来提高产品可靠性水平并降低成本。这意味着我们必须把一些列的技术作为一个项目来考虑,而不只是一堆独立的活动。

    如果我们要建造一个系统,而一些是有不同的零部件或者零组件组成,产品的组成包含了不同的领域(其中主要的有电子、机械、软件、固件、光学和化学等)。所有的这些独立的个体组成了一个系统,当然我们也不能够忽视它们之间的交互关系,并且需要保证我们从系统的角度来考虑可靠性项目。下图中我介绍了三种类型组成的系统,电子、机械和软件。

    对于软件和硬件这尤其合理。绝大多数的公司把软件可靠性和硬件可靠性分离开来而不是当作一个整理看待。当失效发生时,这就会导致大家互相指责而不是合作。
    对于电子和机械这两个领域也同样正确。相比于软件和硬件我们能够看到这两个领域较多的合作。但是在初始时,他们很少会在一起讨论常规的可靠性目标和如何计划对系统的关键部分进行分解。

    产品开发团队只是在机械、电子和软件不同领域的独立的看待可靠性问题。但是只会从系统的交代看到可靠性问题,而他们只会把很小的关注放在机械、电子和软件问题上。希望产品的所有部件可以完美的工作在一起。由于可靠性的度量主要是来执行,工程团队必须在系统和子系统上取得平衡来开发可靠的产品。

    可靠性与成本

    可靠性的重点就是在最小增加开发和制造成本的条件下达成保修和服务成本的降低。在生命周期的特定阶段使用合适的技术会帮助我们来最小化全寿命周期成本。

    为了最小化全寿命周期成本,单位必须做如下两件事情:

    1、从可用的技术中选择最合适的技术并应用到产品寿命周期的合适的阶段

    2、基于具体的信息把这些技术合理的集成到产品寿命周期的不同阶段
    1、项目成本会随着可靠性的提高而增加。当到达某个点后,我们不会从可靠性的投资中获取回报,因为当可靠性达到某个点后就会变的很难再提高。这也是为什么我们需要知道目标在哪,这也就决定了我们公司生产的产品是太可靠了还是不太可靠。嘉峪检测网认为,当产品太可靠了,通常会带来成本的增加,也许并不需要这么高可靠性的产品,他们会考虑更低价格的产品。我们上次购买200美元的搅拌机和烤面包机是什么时候?

    2、当可靠性降低时,维保成本会增加。

    3、软件和制造成本没有关系(也许光盘、说明书和产品生产功能测试成本除外),所以维保费用绝大多数时候分配给硬件。如果软件可靠性并不能够降低成本,为什么还要管它呢,硬度更多的关注硬件可靠性改善来降低成本。我们当然不能够这么做了,主要是以下两个原因:

    A、根据我们的经验,典型系统的软件失效和硬件失效的比值为10:1。只会购买整个系统而不只是硬件。

    B、软可靠性项目并不会直接产生成本降低。相反的,他们会对下面的领域有帮助:
    提高软件和固件可用性会降低维修导致的停机

    提高满意度
    每次当我提供可靠性设计培训时,我的总是问谁应该参加。当然设计工程师必须参加。那么市场人员需要参加吗?当然,他们需要参加。我们必须让销售、服
    务、和工厂都应该有相应的代表参加。同事可靠性团队也需要参加。任何人与产品可靠性相关的都必须参加。然而,设计工程师是流程中的关键。他们日常中队产品
    设计所做的决定会极大的影响产品的可靠性。那么可靠性团队的职责又是什么呢?这个团队需要可靠性工作的领导者和培训者,同时还需要协助制定可靠性指标和撰
    写可靠性大纲。而日常的可靠性工作则由设计工程师来完成(在可靠性团队的指导下)。

    案例:把电子、机械和软件可靠性联系在一起

    我曾经在一个半导体设备公司工作来帮助改善下一代产的可靠性。首先我为三个领域(电子、机械和软件)的团队提供了可靠性设计的培训。然后我们和电子、机械和软件团队的负责人讨论并制定可靠性目标。我们从系统的顶层指标开始并逐步分解到子系统(电子、机械和软件)。每个团队负责他们子系统的可靠性目标并继续分解到更小的单元。我和每个团队负责人一起制定可靠性大纲来保证他们的子系统可以满足既定指标。我们针对每个不同的子系统发布不同的大纲并最终整合到产品的可靠性大纲中去。我和每个团队负责人合作来确保他们在整个产品开发流程中持续跟踪子系统目标。最终每个子系统成功达成目标,从而保证整个产品达成目标。

    4、平衡内部和外部资源

    当我们计划一个可靠性项目时,我们必须决定是招聘全职人员来完成、寻求外部资源的协助,或者两者都是。大多数企业同时选择两者。他们让自己的员工负责日常工作,例如开会以及和设计团队共同协作,而当他们不具备相应的能力或者人力不足时则借助外部资源来执行相应的工作。下面是寻求外部资源协助的前十大理由(排名不分先后)供大家参考:

    1、可靠性专家
    2、可靠性评估
    3、技术风险评估
    4、特殊技能
    5、为工程师提供培训
    6、在起步阶段
    7、企业裁员
    8、引导
    9、在特定地区提供帮助
    10、专家建议

    4.1可靠性专家
    企业需要一个强力的可靠性专家来制定可靠性项目的方向,建立企业的指标并决定选择安排不同类型的人到不同的岗位来保证项目的成功。在第2章我们讨论了可靠性设计的专题,但是只有设计工程师觉得在可靠性专家的领导下才会真正起作用。如果企业缺少这样的可靠性领导者,那么就是时候来引入外部咨询专家来领导企业的团队并提供培训。如果企业已经有了自己的可靠性工程师,企业可以考虑让顾问来培训可靠性团队,后期指定可靠性团队的其中一个成员成为企业可靠性负责人来负责整个企业的可靠性工作。

    4.2可靠性评估
    当我们回顾过去发布的产品时会经常发现产品的可靠性水平需要提高。这并不是一个明确的问题,而是很多小的问题所累积而导致
    的不满。企业需要对可靠性进行更好的预计。如此一来外部机构可以帮助评估企业的薄弱环节。我们把这称为可靠性评估。

    4.3技术风险评估
    如果企业正在进入一个全新的市场或者采用全新的技术,则企业需要保证能够达到规定的可靠性水平。一个很好的例子是决定采用固态硬盘还是传统的机械硬盘。在技术背后所隐藏的可靠性代表着什么?固态硬盘会比传统硬盘更好还是更坏?企业需要一个专家来进行技术风险评估来评估企业所开发的产品可能的可靠性水平。

    4.4特殊技能
    如果要求指定的技术(或者内部决定采用指定的技术),但是企业并不知道如何做,这也是一个合适的理由来引入外部专家。当引入外部专家时采用试验设计技术是很好的一个选择。大多数公司很少开展试验设计,所以基本对试验设计不熟悉,相应的对于如何开展试验设计比较生疏。嘉峪检测网认为,外部专家可以提供手把手的培训课程通过专题研讨会来给大家做培训并进行实践。可靠性领域很宽,很少有人会涉猎所有的领域。即使很优秀的可靠性工程师出现有些问题超出他的能力范围也是很正常的,这时候可以考虑引入外部的专家来进行协助。

    4.5为工程师提供培训
    外部专家不仅可以为企业提供培训课程还可以为企业建立课程培训计划。培训计划应该能够弥补工程师的培训需求的缺口并帮助刚入职的员工快速进入状态。培训计划还必须包含培训培训讲师的环境,从而使得企业从现在就可以为未来的内部培训培养人才。

    4.6在起步阶段
    当一个企业发现自身需要在产品设计领域快速提高时又无法快速招聘或者不太确定需求是短期的还是长期的,这是最好的选择就是聘请外部专家来填补人力缺口。相比于员工招聘,聘请外部专家更加容易(通常我们可以在确定专家候选人后要求对方几天内到位,而他们在到位后可以立即开展工作)。同样如果与外部专家解约也非常简单(在加利福利亚解雇一个全职员工非常困难,法律风险很大,而和顾问解约的风险可以得到极大的降低)。

    4.7企业裁员
    在企业裁员后利用外部顾问可以更高效,而企业也需要持续开发新产品,工作必须有人去执行。由于不需要雇佣全职人员,外部顾问只是在需要的时候才会聘用,进而可以帮助企业降低总体人力成本

    4.8引导
    经常会出现一个人技术都具备但是对于团队的现场引导能力不足。一个很好的例子是失效模式影响分析。大部分工程师都熟悉基本的技术并能够指出产品可能存在的失效来决定如何解决潜在的失效。问题是每个工程师所掌握的技术有所差异,当我们把一个不同职能的工程师团队集中在一个房间就会变的很混乱。这时候我所需要的就是一个强力的领导者来指引大家通过流程来确保每个人的想法被倾听而不是由某个人来主导讨论。我们会在第17章讨论更多的内容。

    4.9在特定地区提供帮助
    当企业某个办事处或者供应商处偶尔需要某个专业技能,这时候聘请当地的顾问也许比派遣一个工程师飞过半个地区去更合理。
    A. 聘请当地的顾问费用更低,不仅可以节省出差费用,而且经常会出现当地的办事处或者供应商区域的薪资水平更低,从而我们从费用更低的当地顾问获益。
    B. 本地的顾问在语言和与当地的交流上更加流畅。某些可靠性顾问机构在全球都有办事处也许在特定区域拥有本地的专家团队。

    4.10专家建议
    如果需要一个专家提供其它观点,聘请一个顾问公司是一个高效的解决方法。在大多数时候,企业的工程师对于他们的方法、计划或者报告都不存在问题,他们只是需要一点点点拨。我就看到一个顾问提了和企业内部工程师同样的建议,但是只是因为他是顾问,而企业或者会更认可顾问说法。

    可靠性整合:引入外部资源来帮助企业内部工程团队
    有些企业对于如何外部不需要很多内部工程师资源来管理外部资源的特定活动依然有一定的顾虑。对于这个问题,非常重要的是在项目开始时就定义好合作内容(内部工程师和外部专家各自的工作内容和职责),如何进行审查,多长时间审查一次。如果这些做好了,那么外部资源会成为企业巨大的财富;如果没有做好,那么管理外部资源将成为企业巨大的累赘。

    5、可靠性能力评估

    在为产品推荐可靠性方案前必须首先评估组织的可靠性能力水平,我们把这称为可靠性能力评估。

    5.1、什么是可靠性能力评估?
    可靠性能力评估师一个对整个组织进行详细评估的方法并且涵盖所有产品开发部门。对组织当前的情况进行评估后制定可执行的可靠性大纲。

    可靠性能力评估并不需要再每个项目开始前完成,但是符合下列条件时需要开展:
    A、 成熟企业由于内部或者现场大量失效而必须极大改善产品可靠性
    B、 成熟企业产品保修成本太高而需要寻找方法来降低
    C、 成熟企业不知道自己产品的可靠性水平或者不知道产品由于何种原因而被退回
    D、 成熟企业试图进去新的市场
    E、 新成立企业开发第一款产品
    F、 成熟企业或者新成立企业从未有过可靠性计划

    5.2开展可靠性评估的动机
    可靠性能力评估可以识别对可靠性有影响的系统变更。它和企业的文化和产品紧密相关。它同时会提供达成目标的一个路线图任务清单。而组织能力和期望可以取得一致。

    打个形象的比喻,当人生命时需要去看医生。在医生没有进行初步诊断前他们无法知道应该如何开药方?对于可靠性项目也一样。除非我们知道哪出了问题和为什么出问题,否则我们无法知道如何解决问题。看病时,医生开的药方取决于病人的症状,当然也包括病人的身体条件。有些病人对于某些药有耐药性,而无法获得比较好的疗效。这对于可靠性项目同样适用。嘉峪检测网认为,有些企业的文化接受某种技术或者某个变更,而有些企业则不。例如,有些企业在统计领域很擅长,可以通过统计理论来很好的解决问题。对于这些企业,加入其它技术例如Weibull分析来解决产品失效时间的问题就和企业的文化非常吻合。然而,如果工程师没有统计的背景,介绍这类的统计技术可能会不被流程所接受。

    5.3、可靠性能力评估步骤
    可靠性能力评估包含如下步骤:
    A、 确定被调查人
    B、 确定调查主题
    C、 制定评分系统
    D、 分析数据
    E、 一起审核结果(检查步骤)
    F、 结果总结
    G、 方案建议
    H、 对特定领域进行深入分析

    5.3.1、确定被调查人
    首先确定谁是合适的被调查人。这很大程度上取决于评估目标。调查就是一个发现问题的过程。评估者的工作就是从被调查者获得最多的信息。推荐把下列人选列入被调查人员名单:
    设计工程师(电子、机械、光学、化学、软件、固件等)
    技术经理
    系统工程师
    生产工程师
    测试工程师(硬件和软件)
    质量和可靠性工程师
    公司质量负责人
    采购
    项目经理
    技术支持/现场服务
    核心供应商
    合同制造商或者原始设计生产商
    注:这个名单可能会由于公司的岗位和职责定义不同而不同

    5.3.2、确定调查主题
    我们必须准备至少20-30个问题来覆盖组织的可靠性不同领域,其中包括管理、设计和制造。下面是几个问题的示例:
    管理:可靠性的目标是如何制定的(可以是年失效率或者保修期内失效率)?
    设计:“失效模式影响分析是如何应用的?
    制造:“面向可制造性的设计是如何开展的?
    注:同一个问题获得团队中不同岗位的反馈非常重要。因为很有可能参与调查的某个人对于实际情况了解不够。例如,如果我们咨询管理层如何设定目标,他们也许回答在每个项目开始时都会执行,具体要求由市场提出并给予工程团队。当我们再咨询工程师时,我们可能会发现其实这样的情况并没有发生。如果某人的反馈和公司情况相左,他们只是想通过调查来表达他们的不满,这时候我们就需要对调查的反馈进行过滤。

    5.3.3、制定评分系统
    我们必须为评估建立评分系统。为了达成此目的就必须为每个反馈进行评分。下面是评分标准的建议。
    5 = 非常有效
    4 = 很有效
    3 = 有效
    2 = 效果较差
    1 = 无效
    0 = 未执行或者执行中断

    • = 无信息、无法评价

    具体的评分和技术的效果直接相关。效果通过技术的执行结果和使用频率进行评估。如果团队某种技术开展的非常好,但是他们很少采用这种技术,那么这种技术仍然不是一个有效的技术。必须注意的是,如果被调查者在流程中并未介入,应该允许他们跳过某问题或者不进行评分,而不是填写评分结果为零,这样就不会对最终的结果产生影响。为了获得综合结果,每个问题必须综合多人的评分结果。

    在某次评估中,我曾经问过一个团队关于“失效模式影响分析有多重要?”的问题,生产工程师反馈失效模式影响分析只是一个分析问题的技术,所以他对于这个问题的评分是2。设计工程师的反馈则认为失效模式影响分析只在对关键设计进行评估是才比较重要,所以他们的评分是3。嘉峪检测网认为可靠性工程师的反馈则认为失效模式影响分析是一个重要的设计技术并且可以应用到所有的设计领域中,所以他们的评分是4。通过对这三个岗位的评分进行平均,最终的评分为3。然而,除了评分以外,我们看到其中存在的问题。如果可靠性工程师认为失效模式影响分析师一个重要的设计技术,为什么设计工程师不经常使用这个技术。如果失效模式影响分析师如此关键的设计技术,他们必然会参与到其中。也许这个技术并不如可靠性工程师所想的那样有效,如果这确实是开发流程中的重要技术,那么我们必须要解决流程中所存在的问题。

    5.3.4、分析数据
    在调查完成后,我们必须对调查结果进行审核并计算每个问题的平均值。当然除了计算平均值外也可以设定相应的权重再进行计算。一旦完成对所有调查结果的计算后需要对每个大类的结果进行总结。

    5.3.5、一起审核结果(检查步骤)
    和团队一起审查分析结果是非常重要的,因为这为他们提供一个额外的机会来进行反馈。这个过程也被大家称为“我们是否是对的?”。这样做的目的是希望保证结果尽可能正确。如果在调查过程中出现疏漏,我们需要正视并给予反馈者额外的机会来进行修正。请注意,如果我们不能够有效的开展评估流程就无法发现组织加粗样式的真实情况,我们就无法为组织设定正确的方向。

    5.3.6、结果总计
    对每个问题的回复进行总结并给予参加调查的每个人提供反馈。我们必须整理所反馈的每一个评分结果。下面的表格是可靠性成熟度矩阵的总结工具。

    5.3.6.1、可靠性成熟度矩阵
    可靠性成熟度矩阵是一个对问题进行归类和总结的方法,同时我们可以用它来和同行业的其它企业进行对比。表格5.1a和5.1b展示了可靠性成熟度矩阵的流程。我们基于Crosby20实际70年代提出的质量矩阵方法来建立了可靠性成熟度矩阵。欢迎使用此矩阵,当然需要根据具体的行业来对矩阵进行修改。
    我们把可靠性成熟度矩阵分成了5个不同的阶段和7个不同的分类来对成熟度进行评估。请仔细阅读每一行的来选择最适合企业的描述。每个阶段的平均值就是企业的总体的成熟度水平。通常,不同的分量成熟度水平评估结果会有所差异,但是同一个企业一个分类的评估结果相差超过2个水平是不正常的。几乎没有企业属于第一阶段的水平。当我们建议企业开展可靠性能力评估,他们都会说“为什么需要这么麻烦,我们早就知道我们可靠性方面什么都没有做了。”。绝大多数企业有可靠性项目的模板,但是通常不会记录那些经验教训。企业都喜欢那些能够引人注目的成功经验。嘉峪检测网认为,通常我们也很少发现企业处于第5阶段的,而第5阶段是预留给那些世界上最优秀的企业,相信这样的企业不会很多(我知道有一家公司处于第5阶段,但是处于竞争优势的考虑不能够和大家分享他们的技术)。第5阶段的企业有他们自己的流程并能够很好的执行,他们不需要通过评估来告诉他们处于哪个阶段,通常也不会邀请外部顾问来对他们进行评估,他们明确了解自己处于什么位置。

    5.3.7、方案建议
    在获得反馈并且确信已经发现了组织的本质后就可以就评估结果进行提供建议了。这也许是评估中最难的部分。这也是经验真正起作用的地方,我们必须对于行业中的优秀案例有很好的理解,并且能够从不同的案例中进行提电子产品检测炼。如果之前没有任何的评估经验,建议在进行第一次评估时邀请一位专家来确保执行流程和最终结论的的正确性。对于评估,需要重点注意的有趋势、流程缺陷、能力不匹配、过度分析和欠分析。从多个方面对组织进行评估,例如优势项目、好的结果和需要努力的地方。没有一个方法或者一套方法能够成就一个可靠性项目。具体的方法需要和产品和组织的文化相匹配。很多公司在我们评估下只是出于第2或者第3阶段,但是他们想了解如何达到低5阶段。首先要说明的是达到第5阶段的组织非常少。第二,在一个产品上提高超过一个阶段也是很难做到的。我们需要设定一个合理的期望,并且在变革中有足够的耐心。

    5.3.8、对特定领域进行深入分析
    在评估过程中吗,某些领域需要进行深入分析。只是一个调查问卷并不能够很好的对企业进行评估并给出建议。我们建议对下列领域进行详细分析。其中部分领域如下:
    审查现场结果
    审查工程良率
    评估关键供应商
    审查设计控制流程
    这些领域的深入分析结果可以加入到评估建议中。

    5.4、100个评估中的发现
    我们已经为超过100个不同的开展可靠性能力评估。基于我们评估,我们发现没有两个是一样的。即使同一的两个不同部门也有很大的差异。当然,如果要对自己的企业进行评估,我们建议对每个部门进行单独评估,而不是假设一个部门可以代表整个企业。基于所有部门的评估结果来决定企业最好和最差的领域。下面两个章节列出了部分结果。在本书的后续章节会进行反复强调,某些甚至会成为一个独立的章节或者某个章节重要的主题的。请参考目录来了解更多信息来选择大家所感兴趣的章节。

    5.4.1、企业做的好的地方
    可靠性预计
    高加速寿命试验
    快速解决问题
    设计准则
    软件问题数据库的跟踪
    软件系统测试

    5.4.2、企业做的不好的地方/需要改善的地方
    目标制定
    可靠性计划
    维修和保修信息缺失
    经验总结流程
    产品可靠性专人负责制
    多个问题追踪系统
    好的可靠性设计方法
    应用统计技术
    软件和硬件的互动

    可靠性整合:明确可靠性项目的目标
    可靠性能力评估推动可靠性项目来引入更多的活动。评估建议可以知道企业未来的可靠性项目方向。在项目的某个合适节点,再次进行可靠性能力评估来了解企业的和目标的距离也是合理的。

    案例:评估建议远离某个市场
    生产试验室的环境测试设备,他们希望使用类似的设备来生产控制设备以进入一个新的市场。实验室设备的可靠性要求低于控制系统。通过评估后,我们展示了他们还未准备好来生产新的产品类别。而新的设备要求在产品发布前可靠性成熟度上至少提高2-3个阶段,这意味着需要对组织进行完全重组(他们并没有准备好为此进行重组)。基于评估建议,他们决定不进入这个新的市场。总体而言,他们节省了巨大的资金并且保护他们的声誉。

    展开全文
  • 其中,可用性指标主要包括产品可靠性、维修性和保障性、可用性,适用性指标涵括煤的标称最大粒度、煤的类别与水分、额定工作能力,使用性能指标采用整系统煤样的损失率、粉碎机细粉质量损失率、整系统制样精密度、...
  •  高可靠性滤波器WKF312803M符合《产品详细规范》的要求,严格按照筛选程序进行100%筛选,保证出厂产品的高可靠性。  WKF312803M 的更多特性与优势:  电磁兼容指标符合GJB151A-97之CE102要求  输入电压1*...
  • 产品可靠性指标是其质量属性中极为重要的部分。产品可靠性越高,所需维修保养的费用就越低,从而可尽量减少用户的开支,并保证用户设备的正常运行。同时,只有具有高可靠性产品,才能在市场上具有真正的竞争力...
  • 论软件的可靠性设计

    千次阅读 2020-12-29 10:19:42
    论软件的可靠性设计 摘要 2019年11月,我所在的软件公司承接了某保险集团下健康险服务实施管理系统的开发工作,本人有幸参与该项目,并担任系统架构师职务,主要负责软件架构设计和可靠性设计的工作。该项目是...

    论软件的可靠性设计

    摘要

            2019年11月,我所在的软件公司承接了某保险集团下健康险服务实施管理系统的开发工作,本人有幸参与该项目,并担任系统架构师职务,主要负责软件架构设计和可靠性设计的工作。该项目是基于集团内网,为全国各省市地区分支机构的健康险专员提供7*24小时的不间断服务。笔者以该项目为例,先简单介绍几种目前比较主流的软件可靠性设计技术,然后讨论可靠性设计技术在项目中的具体应用。项目组结合软件可靠性设计与应用的原则,结合此前类似系统的设计经验,决定对软件系统采用软件容错的N版本程序设计技术,对消息通讯、分层架构模块进行负载均衡设计。经过项目组九个多月的努力,本系统已顺利开发完成,于2020年7月投入生产环境使用。自上线以来未出现重大故障,取得客户和公司领导的一致好评。

    正文

            近年来,随着互联网行业的迅猛发展,公司业务的不断扩张,需求的快速变化以及用户量的持续增加,传统的业务系统已无法满足这样迅猛的业务数据量。在2019年11月,我所在的软件公司承接了某保险集团下健康险服务实施管理系统的开发工作,本人有幸参与该项目,并担任系统架构师职务,主要负责软件架构和可靠性设计的工作。笔者以该项目为例,先简单介绍几种目前比较主流的软件可靠性设计技术,然后讨论可靠性设计技术在项目中的具体应用。项目组结合软件可靠性设计与应用的原则,结合此前类似系统的设计经验,决定对软件系统采用软件容错的N版本程序设计技术,对消息通讯、分层架构模块进行负载均衡设计。

    项目概述

            随着信息技术的蓬勃发展,传统业务系统已无法满足日益增长的业务工作量,对传统系统进行升级改造迫在眉睫。健康服务实施管理系统(Health Service Implementation Management System HSIMS),为企业健康险工作人员提供实时、高效、方便的线上办公服务,如此便利的2B业务系统间接的为健康险消费群体提供了更快更好的产品使用体验。HSIMS系统的建设,充分表现了健康险产品的整个生命周期,系统划分为产品管理、服务管理、协议管理、健康卡管理、供应商管理、服务实施管理、服务反馈管理等多个业务模块。在实际使用时,由健康险专员全程操作,根据岗位职能的不同各自负责不同的业务模块,从而达到高效稳健的业务协作,促进企业的进一步发展。限于篇幅,在此我们不再详细介绍各个模块的具体功能。

            HSIMS稳定可靠的运行也是作为一项重要的验收指标。下面,我将首先介绍几种目前比较主流的软件可靠性设计技术,然后详细介绍HSIMS的分析和设计过程中所采用的可靠性设计技术及其原因。

    可靠性设计技术

            一般来说,被认可的且具有应用前景的软件可靠性设计技术主要有容错设计、检错设计和降低复杂度设计等技术。其中常用的软件容错技术主要有恢复块设计、N版本程序设计和冗余设计三种方法,主要适用于软件失效后果特别严重的场合,恢复块设计就是选择一组操作作为容错设计单元,从而把普通的程序块变为恢复块。一个恢复块中包含有若干功能相同、设计差异的程序块,每一时刻有一个程序块处于运行状态,一旦某程序块出现故障,则用备份程序块予以替换。N版本程序设计的核心是通过设计出多个模块或不同版本,对于相同初始条件和相同输入的操作结果进行多数表决(防止因其中某一软件模块/版本的故障而提供了错误的服务,以实现软件容错)。冗余设计的思路来源于硬件系统,但有所不同。软件冗余设计技术是采用多种不同路径、不同算法或不同实现方法的模块或系统作为备份,在出现故障时进行替换,维持系统的正常运行。;检错设计主要应用于无需在线容错的地方或不能采用冗余设计技术的部分;降低复杂度设计的思想就是在保证实现软件功能的基础上,简化软件结构,缩短程序代码长度,优化软件数据流向,降低软件复杂度,从而提高软件可靠性。除此之外,还有故障树分析(FTA)、失效模式与效应分析(FMEA)等硬件可靠性技术也应用到了软件可靠性设计领域之中。

    影响可靠性要点

            项目启动后,在架构设计工作的开始阶段,我们便意识到软件的可靠性设计对项目有着重要的影响。由于保险系统的复杂性与特殊性,对软件可靠性有着较高的要求,要提高软件产品的可靠性指标,首先要分析影响软件产品可靠性的因素。一般来说影响产品可靠性的原因有如下几点: 

            1、运行环境,软件可靠性定义是相对于运行环境而言的,同样的软件在不同的运行环境下其可靠性是不一样的。不同的用户,操作习惯不同,会影响软件的可靠性。软件的可靠性是软件缺陷和用户的可预测性的一个复杂函数。

            2、软件规模,也就是软件的大小。一个只有几百行代码的软件和一个几千万行代码的软件是不能相提并论的。

            3、软件内部结构,结构对软件可靠性的影响主要是软件的复杂程度,一般来说,结构越复杂的软件,所包含的软件缺陷数就可能越多。在进行软件设计时就要有意识地采用各种降低复杂度的架构策略,如模块化设计,分层设计等等。分而治之的方法是最好的降低复杂度的方法。 

            4、软件的开发环境和开发方法,软件工程表明,软件的开发方法对软件的可靠性有显著地影响。例如,与非结构化开发方法相对,结构化方法可以明显减少软件的缺陷数。

            5、软件的可靠性投入,软件在生命周期中的可靠性投入包括可靠性设计、可靠性测试、可靠性管理和可靠性评价等方面投入的人力、资源、资金和时间等。

    可靠性设计应用

            笔者根据系统本身的特点,结合以上五个影响软件可靠性的因素,对系统做了以下几点可靠性设计:

    • 运行环境方面,使用了微服务组件配合实现可靠性,其中包括:
      1. eureka注册中心:通过定时的心跳信息号推送,让注册中心管理各个微服务的健康状况,保证服务间的调用都是基于良好的服务状态。
      2. Apollo配置中心:全局统一配置,提供配置文件统一管理能力,实现各微服务的统一参数配置以及版本管理,大大降低了手动配置的不稳定性,提升系统可靠性。
      3. Zuul网关:通过使用网关进行请求的转发,对于请求失败或请求异常的情况及时记录日志,统一返回合适的响应报文。
      4. Hystrix熔断组件:当请求多次访问被异常阻塞时,系统会启用熔断机制,将该接口挂起修复,直到其恢复正常再次启用。
      5. Zipkin链路跟踪:提供服务调用和数据库调用的链路跟踪,一个请求可能需要调用很多个服务,而内部服务的调用复杂性,决定了问题难以定位。所以微服务架构中,必须实现分布式链路追踪,去跟进一个请求到底有哪些服务参与,参与的顺序又是怎样,从而达到每个请求的步骤清晰可见,出现问题时可以很快定位问题点,便于运维人员及时处理。
    • 模块划分方面,在项目启动初期,我已经协调架构组和需求组慎重评估对于业务模块的划分,在保证业务划分的基础上也要考虑模块结构不能太复杂,对于业务繁重的模块要考虑部署多个服务实例或者拆分出公共部分简化模块。
    • 定期培训,要求需求测试人员对于测试案例要有足够多的反向案例,开发人员在开发过程中可以更多的进行预防性开发,以提高各自功能的可靠性。

    遇到的问题及解决方案

            在项目推进的过程中,针对可靠性设计还遇到了比较严峻的问题。当集成测试和验收测试都通过后,按照流程顺利的搭建了生产试运行环境,其硬件配置、软件依赖版本均为最终的生产参数。试运行期间出现了严重的服务宕机情况,排查问题加问题修复共计耗时三个小时,最终问题点是因为试运行环境上的某个软件依赖冲突,导致整个服务启动失败。最后经过项目组内部讨论决定延期两周上线,在所有集成测试和验收测试环境完全仿照试运行的服务器配置进行集中的回归测试。两周时间内排查出其余问题点并全部解决。针对这种上线前因为环境问题导致的服务崩溃问题,项目组内部开会讨论分析原因,最终提出可以采用Docker的方式避免这样的问题,Docker可以实现虚拟机隔离应用环境的功能,并且开销比虚拟机小。这样可以很大程度解决环境移植的过程中服务可靠性的问题。

            通过本次项目,对于软件可靠性设计有了更加深刻的经验,尤其在最后试运行期间出现的问题更是对我们项目组的一场挑战,相信经过这次项目的开发与实施,项目组内每位同事都受益匪浅。

    展开全文
  • 本文是为大家整理的可靠性评价主题相关的10篇毕业论文文献,包括5篇期刊论文和5篇学位论文,为可靠性评价选题相关人员撰写毕业论文提供参考。
  • 可靠性设计基本流程

    千次阅读 2018-04-15 12:03:30
    一、可靠性目标认定(Reliablity Goal Setting)。1、首先了解客户需求(Customer needs analysis),根据客户需求,厘清可靠性设计的基本目标。2、对过往的可靠性历史资料进行分析(Reliablity history analysis)。可能...
  • 如何理解“可靠性”和“可用性”?
  • 世界5G展将于11月21日至23日举办,展览面积近20000平方米。...第五代移动通信系统(5G)网络面向移动互联网和物联网,主要涵盖增强型移动宽(eMBB)、超可靠低时延(uRLLC)及海量机器类(mMTC)三大应用场景。e...
  • 文章目录一、功能性:二、可靠性产品在规定的条件下,在规定的时间内完成规定功能的能力、易用性:在指定使用条件下,产品被理解、 学习、使用和吸引用户的能力四、效率性:在规定台条件下,相对于所用资源的...
  • 可靠性数据分析教程总结

    万次阅读 2018-06-19 18:38:37
    常见的可靠性指标及其概率解释 失效分布和平均寿命 剩余寿命 具有年龄t的产品从t开始继续使用下去直到失效为止所经历的时间,记为ξtξt\xi_t Ft(x)=P(ξt⩽x)=P(ξ⩽t+x|ξ>t)=F(t+x)−F(t)1−F(x...
  • 可靠性到底是个啥

    千次阅读 2018-04-11 00:00:00
    像“可靠性”这种被不断提及的名词,如果仔细分辨就会发现里面充斥着各种似是而非的误解和误用。一、持久性、可用性,傻傻分不清我们一般所说的“可靠性”,其实是个比较模糊的概念,里面包含持久性和可用性两个层面...
  • 为什么要有产品产品是任何一种能被提供给市场以满足需要或欲望的东西,就是为制造或建立有形或无形的产品或服务的综合概述,对其中的要素进行控制,使其达到一个预期、合理的范围值,可以理解为万物皆产品,只是...
  • 客观评价-基于指标客观评价-基于模型R&S®UPV音频分析仪小结那么我们现在用哪些评价方法呢?基于深度学习的方法:AutoMOS, QualityNe, NISQA, MOSNetMOSNet(`absolute.mosnet`或`mosnet`)语音质量的感知评估...
  • 网络的可靠性是设计出来的

    万次阅读 2017-08-03 10:42:55
    根据国家标准GB-6583的规定,产品可靠性是指:设备在规定的条件下、在规定的时间内完成规定的功能的能力。对于网络系统的可靠性,除了耐久性外,还有容错性和可维护性方面的内容。 1、耐久性。是指设备运行的无...
  • 数据产品指标设计

    千次阅读 2018-03-31 17:47:53
    在数据产品中,数据指标是根据数据分析得到的一个汇总结果。在生活中,数据指标有很多很多,比如居民消费价格指标,股票价值指数,空气指数,洗车指数,穿衣指数等等。 (2)数据指标分类 A、按...
  • 设备软件可靠性测试

    千次阅读 2017-08-03 10:41:09
    设备为达到连续可运行目标,除了在硬件设计中考虑器件可连续无故障运行外,很重要的方面是软件在各种条件下可经受考验,持续工作。这需要在实现基本功能前提下,在软件中设计一系列容错逻辑去...为了在产品开发的不同
  • 性能指标 1. 响应时间 指某一个请求从发出到接收到响应消耗的时间。 在对响应时间进行测试时,通常采用重复请求方式,然后计算平均响应时间。 2. 吞吐量/吞吐率 指系统在单位时间内可以处理的请求数量,通常...
  • 产品的可靠性设计方法,从表面上看都是技术问题,但实质上包含技术和管理两个... 系统分类: 电子制造 | 用户分类: 可靠性技术 | 来源: 原创 | 【推荐给朋友】 | 【添加到收藏夹】 中小企业提升产品可靠性的几
  • 软件可靠性

    千次阅读 2011-09-14 00:37:32
    软件可靠性的定义   1983年美国IEEE计算机学会对“软件可靠性”作出了明确定义,此后该定义被美国标准化研究所接受为国家标准,1989年我国也接受该定义为国家标准。 该定义包括两方面的含义:  (1)在...
  • 关于软件系统可靠性的几个9问题

    千次阅读 2016-05-18 09:28:45
    今天上班的路上看篇关于一个架构师讲他的重构系统经历的文章,看到个名词,可靠性3个9,4个9。什么东东啊,没听过,上网搜了一下,一般的系统,像传统的电力系统也是有可靠性3个9,4个9之说的,可就是说这是系统可靠性...
  • 可靠性技术在医学仪器中的应用前景分析1 引言 可靠性研究起源于武器系统,经过近半个世纪的发展,已成为一门遍及各学科各行业的工程技术学科,已经从电子产品可靠性发展到机械和非电子产品可靠性,从硬件的...
  • IC 产品的质量与可靠性测试

    万次阅读 2011-01-12 11:15:00
    IC 产品的质量与可靠性测试 (IC Quality & Reliability Test ) 质量(Quality)和可靠性(Reliability)在... 解决了这个问题,质量和可靠性就有了保证,制造商才可以大量地将产品推向市场,客户<b
  • 可靠度及其评估指标

    千次阅读 2010-09-24 07:39:00
    结构在规定的时间内,在规定的条件下,完成预定功能的能力,它包括结构的安全,适用和耐久,当以概率来度量时,称可靠度.
  • 计算机网络可靠性的影响因素

    千次阅读 2014-04-23 16:59:40
    计算机网络的可靠性概念最早是在上世纪70年代出现,它具体是指计算机在给定的时间以及特定的环境内,保证所有业务可靠完成。计算机网络可靠性的决定因素有给定时间、特定环境以及业务完成能力,计算机网络可靠性可以对...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 46,334
精华内容 18,533
热门标签
关键字:

产品可靠性三大指标