精华内容
下载资源
问答
  • 产品可靠性管理的意义
    千次阅读
    2021-07-18 02:42:20

    摘要:计算机系统的可靠性技术包括硬件冗余、容错、避错技术,这些技术的应用对预防质量问题出现,提高系统稳定性与可靠性具有重要作用。但目前技术应用存在不足,主要表现在专业人员技术水平低、管理工作不到位、相关技术有待提升等方面。为弥补这些不足,应该采取改进和完善措施,提高管理人员技术水平、加强相应的管理工作、促进可靠性技术水平提升。

    关键词:计算机系统 可靠性技术 硬件冗余技术 容错技术

    中图分类号:TP30 文献标识码:A 文章编号:1007-9416(2015)12-0000-00

    计算机系统的有效、稳定运营,离不开可靠性技术的支撑。只有在确保各项技术得到有效应用,并加强管理和监督的前提下,才能取得更好的工作效果,满足计算机系统运行需要,为人们提供更好的服务。但目前可靠性技术的应用中存在一些不足,需要采取完善对策,从而更好适应技术发展与创新的趋势,提高系统服务质量。

    1计算机系统的可靠性技术

    计算机系统可靠性是指系统在规定的时间和条件下,完成规定功能的能力,有效满足系统运营需要,确保系统稳定运行。为促进该目标实现,采用可靠性技术是十分必要的,具体来说,主要的技术措施包括以下几种。

    (1)硬件冗余技术。目前在实际应用过程中,人们常常会利用容错技术提升计算机系统的可靠性和稳定性,通常对冗余结构进行全面分析,然后有针对性的提出改进和完善对策,让系统硬件出现适度冗余。双机结构是目前应用最为普遍的结构,满足具体操作需要。就其组成来看,它包括微同步、任务分组、备用设备等,依靠主机输出控制,获取反馈信息,满足实际工作需要。将反馈信息和运行结果进行比较,当出现不一致的情况时则进行出错分析,某种程度上也发挥管理控制功能。还可以采用主机处理任务,备机备用方法,主机检测出问题时,紧急启用备机并投入工作状态,然后检测维修主机。还可以采用任务分组这种特殊形式,有效利用各种资源,让系统更为顺畅和稳定的运行,提高系统可靠性。

    (2)永久性故障处理。常用一备一用和任务分组两种不同形式进行处理,某个芯片或组成构件出现故障,整个系统不能正常运行和工作,应该认真分析可能存在的问题,并及时采取措施处理。当任务分组没有及时实现系统重组功能时,为完成特定任务,应该加强系统管理,做好检测工作,对故障及时处理,提高系统运行效率。

    (3)暂时性故障处理。首先采用一用一备方式探究,如果系统出现暂时性故障,可利用相关程序屏蔽。顶板串联的三个芯片出现暂时性故障时,利用HC251芯片检验。还可以采用任务型方法、微同步方式检验,查出暂时性故障,有针对性的进行处理。

    (4)容错与避错技术。容错与避错是常用的两项技术措施,也是提升系统可靠性常用的方式方法,为尽量降低故障发生频率,弥补器件自身存在的缺陷与不足,可采用避错法进行处理。要利用高质量材料,科学合理进行设计,加强监督管理,保证计算机系统运行环境良好,及时处理存在的灰尘,让计算机系统在良好的环境中工作。

    2计算机系统可靠性技术的不足

    尽管可靠性技术的应用具有重要现实意义,但目前这些技术应用仍然存在不足,对计算机系统运行可能带来不利影响,需要采取改进和完善对策。

    (1)专业人员技术水平低。一些工作人员的专业技术水平较低,未能熟练掌握计算机系统操作技术,日常养护维修不到位,难以有效处理存在的故障,降低系统的可靠性。或者日常巡视和养护被忽视,对系统运行效率的重视程度不够,制约其功能的有效发挥。

    (2)管理工作不到位。相关的管理制度没有严格落实,对计算机系统运行和维护的管理不到位,没有及时预防可能出现的故障,影响计算机系统有效运行。

    (3)相关技术有待提升。不注重对计算机系统进行升级,软件更新不到位,相应的技术措施没有严格落实,影响系统可靠性提升。

    3计算机系统可靠性技术的提升对策

    为应对可靠性技术应用存在的不足,结合计算机系统运行的需要,笔者认为今后应该采取以下改进和完善对策。

    (1)提高管理人员技术水平。管理人员和操作人员要加强自身学习,掌握各项技术操作策略,有效应用提升系统可靠性的方法,有效开展各项工作,为系统更好运营创造便利,推动系统更好发挥作用。

    (2)加强相应的管理工作。建立完善的计算机系统管理规章制度,并严格落实这些规定,让用户和操作人员开展各项工作时有章可循。对计算机系统日常运行情况进行有效管理,提高系统可靠性。

    (3)促进可靠性技术水平提升。除了采用容错避错技术、硬件冗余技术,还要注重其它技术方式的选用。例如,采用指令信号冗余技术、拦截技术、软件“看门狗”技术、系统自动复位技术等,并熟练掌握各项技术操作流程,让各程序有效运行。将错误程序拦截,避免影响系统有效运行和工作,及时处理系统死机等技术漏洞,有效保障系统更好运行和工作。

    4结语

    为确保计算机系统有效运营和工作,采取可靠性技术是十分必要的。实际工作中应该认识可靠性技术的不足,采取完善和管理对策,达到确保系统有效运行的目的。另外还要加强管理,增强工作人员素质,推动技术更新和升级,为保障计算机系统稳定、有效运行提供技术保障。

    参考文献

    [1]梁瑞虹.探讨高性能计算机的可靠性技术与发展趋势[J].网络安全技求与应用,2014(10),187-188.

    [2]刘源.关于计算机系统的可靠性技术分析[J].电子技术与软件工程,2015(2),188.

    [3]李烈彪,李仙.计算机系统的可靠性技术[J].计算机技术与发展,2007(11),142-144.

    [4]周艳萍.计算机控制系统的可靠性及抗干扰性优化设计[J].软件导刊,2014(2),108-110.

    更多相关内容
  • 完整英文版 IEC 60300-3-11:2009 Dependability management - Part 3-11:Application guide - Reliability centred maintenance(可靠性管理 - Part 3-11:应用指南 - 以可靠性为中心的维护)。IEC 60300-3-11:...
  • 煤矿危险源状态的变化会产生风险,在煤矿的安全管理中,对危险源状态的识别分析对控制危险源状态变化进而切断煤矿事故因果链具有重要意义。首先从系统角度出发,在对煤矿安全风险预控管理中危险源系统时态和状态分析的...
  • 电子设备的可靠性设计电子产品设计可靠性从广泛的意义上讲就是产品可靠性工程,是指为了达到可靠性要求所进行的一系列技术与管理活动,它贯穿了产品的论证、方案、工程研制、生产和使用等寿
  • 电压管理器是一种集成电路,在低电压的情况下它可以用来对处理器进行复位,避免...在一个典型的处理器数据手册中,除了定义1.2V的内核电压、2.5V和3.3V的I/O电压以外,同时也定义了允许的电压变化范围。例如,1.2V的
  •  [关键词]高可靠性软件测试软件验证技术软件确认技术软件测试管理 1引言 高可靠性软件泛指一类软件:该类软件运行过程中若出现故障会引发重大灾难性事故或经济损失。通常航天型号软件、银行系统软件、医
  • 可靠性是一门有价值的学科,它应用了很多技术,我们可以用来解决问题并开发出可靠的产品。当然这一定存在一些指南和成功经验,但是我们必须要根据企业的实际情况来进行裁剪。其中我们需要关注的领域有企业的规模、...

    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个阶段,这意味着需要对组织进行完全重组(他们并没有准备好为此进行重组)。基于评估建议,他们决定不进入这个新的市场。总体而言,他们节省了巨大的资金并且保护他们的声誉。

    展开全文
  • 确保汽车电子产品可靠性已经引发了整个半导体供应链的争夺,并且发现了一系列数据不足,缺乏明确定义的标准以及不一致的知识水平的问题。  可靠的功能安全性,可在恶劣环境中使用18至20年,或在自动出租车或卡车...
  • 可靠性分析.pptx

    2019-11-15 10:07:35
    2.可靠性定义 产品在规定的条件下和规定的时间内,完成规定功能的能力为 可靠性。 在实际中产品可靠性分为固有可靠性和使用可靠性。 a.固有可靠性产品在设计制造中赋予的,产品开发者可控的产品 本身...
  • 参加本次软件可靠性与安全性高级技术研讨会学习主要的收获是学习了对软件可靠性与安全性设计与实现的方法,将会在以后在软件设计的工作中提供重要的帮助。现将软件可靠性与安全性设计与实现的知识点进行梳理记录。防...
  • 本文为《软件可靠性简介》培训课程中摘录的公开内容。

    目录

    一、软件的基本概念

    二、软件的质量特性

    三、软件可靠性定义

    四、软件失效的原因

    五、软件缺陷的形成

    六、软件可靠性与硬件可靠性的区别

    在《可靠性工程师手册》一书中,软件可靠性的内容讲得很少,对于没有基础的人可能不好理解,因此我写了一个系列的文章,希望能帮助理解。

    一、软件的基本概念

    软件(software):指一系列按照特定顺序组织的计算机数据和指令的集合。

    软件工程:指软件开发、运行、维护和引退的系统方法。

    软件工程一直以来都缺乏一个统一的定义,很多学者、组织机构都分别给出了自己的定义。

    一种比较好理解的定义认为:软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件,以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。

    软件工程化:用系统工程方法处理软件生存期的全部过程。本质是软件过程工程化,将软件的生存期过程分阶段的划分规范化,使其有较好的可视性,以便管理和控制,并能不断改进。

    系统工程是为了最好地实现系统的目的,对系统的组成要素、组织结构、信息流、控制机构等进行分析研究的科学方法。

    实现软件工程化之前,开发模式基本是作坊式开发。开发者自编、自导、自演,整个过程别人不了解也无法介入,缺乏技术标准或规范,很少形成文档。比如我经常写一些软件就是这样。

    而软件工程化,设计、编程和测试分开,遵循有关标准和规范进行,整个过程透明、可控。

    二、软件的质量特性


    书上并没有这部分内容,但我们要做好软件,还是得了解软件的质量特性。

    ISO/IEC 25010:2011标准中,表述的软件质量特性模型如下,一共包含了8个特性,分别是功能适应性、性能效率、兼容性、易用性、可靠性、安全性、维护性、可移植性。每个特性下,又有一些子特性,一共31个子特性。

    篇幅原因,每个子特性的具体定义我这里不罗列。我举一些例子,来理解下大的层面:

    功能适用性:软件能够正确、完整地实现用户的需求,提供了相应的功能。

    性能效率:在指定条件下,软件对操作所表现出的时间特性(如响应速度)以及实现某种功能有效利用计算机资源(包括内存大小、CPU占用时间等)的程度。包括软件执行的快慢,比如Excel,数据量一大就很慢。对资源需求多少,吃多少内存等等。容量,指最大极限的满足要求的程度,比如说12306网站在一秒内处理的最大请求。

    兼容性:涉及共存和互操作性,共存要求软件能给与系统平台、子系统、第三方软件等兼容,同时针对国际化和本地化进行了合适的处理。 互操作性要求系统功能之间的有效对接,涉及API和文件格式等。

    两个及两个以上软件进行信息交换,这个叫互操作性,比如我们使用的研发系统和测试系统,它们之间的信息交换。共存性,软件不能对其他产品有害,比如3Q大战时,人为的制造不共存,有你没我,有我没你。

    易用性:对于一个软件,用户学习、操作、准备输入和理解输出所作努力的程度。主要包括易用好理解,能识别、易学习、好操作、对用户错误进行保护、美观、可访问(例如说你有没有考虑残疾人怎么使用这个软件)。说到易用,我就经常吐槽Creo软件的界面实在是难看至极,相比之下,UG就好看很多。

    可靠性:不出故障地完成任务,有一定的容错能力,出故障时易于恢复。本文第三章节会讲到它的定义,这里先不讲。

    安全性:要求其数据传输和存储等方面能确保其安全,包括对用户身份的认证、对数据进行加密和完整性校验,所有关键性的操作都有记录(log),能够审查不同用户角色所做的操作。

    软件安全包括如下:保密,数据只能由授权人员访问;完整,防止未经授权就被修改或访问;不可抵赖,指能够证明已经发生过的事情,日后不可抵赖;可审查,另一翻译为责任,指的是谁的操作,能够追溯到,比如说网上发帖,能够通过IP追踪到背后的人;真实性,比如你说你是个普通应用软件,通过备案等等确实说明了你不是病毒。

    这里我特意提一下,这个定义里的安全,指的是软件本身的安全。由于软件出bug,导致的整机产品出安全问题,是整机方面的安全,要区别一下。

    维护性:当一个软件投入运行应用后,需求发生变化、环境改变或软件发生错误时,进行相应修改所做努力的程度。

    简单来说就是好维护,比如有模块;可以复用,多个系统可以用;好分析、定位问题,问题找到了好更换。我举个最简单的例子,跟圆周率相关的代码,我们常见的做法是前面先定义圆周率:
    #define PI 3.14
    后面的计算使用,就直接用PI,当想改变PI值时,只需要修改这里即可,而不是直接写3.14,导致要修改时后面都得改一遍。这就是一个简单的体现维护性的例子。

    可移植性:把程序从一种硬件配置和(或)软件系统环境转移到另一种配置和环境时,需要的工作量多少。有一种定量度量的方法是:用原来程序设计和调试的成本除移植时需用的费用。比如说游戏《仙剑奇侠传》,一开始只在电脑上,后来被移植到了手机上。

    三、软件可靠性定义

    软件可靠性是指软件在规定条件下和规定时间内,不引起系统失效的能力。

    书上并没有做出多少解释,这里我细化一些表述。

    规定条件,包含的主要是使用者和使用方式。使用者包含了人、软硬件环境。使用方式指使用的任务和功能,以及使用的频度,我在括号里写了软件操作剖面。你可以理解为不同角色使用不同功能的频率,在后面的软件可靠性测试文章中,我会举一个例子,使得大家明白软件操作剖面是个什么意思,这篇文章不讲。

    时间一般有三种,分别是执行时间、日历时间和时钟时间。都什么意思?

    执行时间:运行软件时,计算机系统实际用于执行程序指令的时间。

    日历时间:以年月日计算的编年时间,软件可能处于工作状态,也可能不在工作状态。

    时钟时间:从程序执行开始到程序执行结束完毕所经过的时钟时间,包括等待时间,其它程序执行的时间,但计算机的停机时间不算在内。

    接下来,我们理解几个概念:

    软件可靠性中常用失误、缺陷、故障和失效来描述故障的因果关系。那我们首先得搞懂这几个概念。

    失误(mistake):指可能产生非期望结果的个人行为。一些典型失误:误解或遗漏了用户的需求;软件设计错误,没有完整的实现软件需求;程序设计错误。

    缺陷(defect):指代码中引起一个或者一个以上故障或失效的错误编码,软件缺陷是程序所固有的 。一些典型缺陷:数组越界使用;缓冲区溢出;算法实现不正确。

    讲到缓冲区溢出,多说几句。缓冲区溢出是一种非常普遍、非常危险的漏洞,在各种操作系统、应用软件中广泛存在。利用缓冲区溢出攻击,可以导致程序运行失败、系统宕机、重新启动等后果。更为严重的是,可以利用它执行非授权指令,甚至可以取得系统特权,进而进行各种非法操作。

    故障(fault):指在软件运行过程中,缺陷在一定条件下导致软件出现错误状态,这种错误的状态如果未被屏蔽,则会发生软件失效。一些典型故障:资源泄露;无限递归调用(死循环);操作者意外输入未知命令;在以前没有考虑的条件下采取的意外路径等。

    失效(failure):指程序操作背离了程序的要求。

    软件故障的因果关系如下:

    四、软件失效的原因

    软件失效,是因为在运行过程中遇到了故障,这些故障的产生有内在和外在原因,可以用下面这个图帮助理清。


    我在上图已经举了一些例子。这里再讲下一些案例:

     例如偶然失误,在一些需要计时的软件中,如果我们选用了错误的计时,则随着时间往后,累积误差会越来越大。


    比如我以前想做个水压监测软件,需要用到计时,我们对比几个计时:

    Timer控件,控件不能做精确计时,只能用于粗略计时,而且最小周期不能小于80MS。

    GetTickCount()计时,返回从操作系统启动所经过的毫秒数,返回的是DWORD类型,返回的值代表程序从启动到如今走过的时间。只精确到55ms。DWORD类型的最大值为4294967295,折算成天是49.7。也就是说当服务程序连续跑了50天之后,再调用GetTickCount()的时候就会发生溢出。

    imeGetTime:函数以毫秒计的系统时间。该时间为从系统开启算起所经过的时间。

    QueryPerformanceCounter,Windows 内部有一个精度非常高的定时器, 精度在微秒级。

    RDTSC(Read Time Stamp Counter),直接利用Pentium CPU内部时间戳进行计时的高精度计时手段。由于目前的CPU主频都非常高,因此这个部件可以达到纳秒级的计时精度。(使用起来比较麻烦,且结果返回差值较大)

    黑客攻击案例:CSDN密码外泄门

    这个案例我记得特别清,亲身经历过。2011年12月,CSDN的安全系统遭到黑客攻击,600万用户的登录名、密码及邮箱遭到泄漏。随后,CSDN“密码外泄门”持续发酵,天涯、世纪佳缘等网站相继被曝用户数据遭泄密。天涯网于12月25日发布致歉信,称天涯4000万用户隐私遭到黑客泄露。

    环境异常导致的失效:医院X射线影响内存丢失

    作者为医院急救设计了一个相关程序,在实验室运行良好,但是每次在医院调试都出bug,作者只好到医院去调试,而且是当着急救病人!!!经过漫长的测试终于发现,是由于医院使用的X射线导致电脑内存总是丢失几个 bit 的信息,而导致程序出问题,最终通过把电脑的内存用铅板隔起来解决! 

    五、软件缺陷的形成

    软件缺陷的形成与软件开发过程各个阶段活动都相关,可以简述如下。


    我举一些实际的例子帮助大家理解:

    用户需求环节出错:某出口机器,程序写以50Hz去设计,实际当地使用为60Hz。规格书未明确60Hz要求。

    软件需求分析环节出错:某需求描述,统计每次出水时间,当累计出水达到10分钟后,停止出水。此时常温水、冷水灯保持熄灭状态,同时此三个按键无响应,其他触摸按键可操作。需求不明确,程序员不好理解,理解错误。

    软件设计环节出错:某设备按键开机10s后4s无反应,原因是软件增加开机动画4s内不允许操作按键,但是计数器放到了开机10s后开始计数。

    编码环节出错:某机器每周星期循环运行时,星期一不显示,无法正常自动运行。原因:使用数组时,下标越界,定义了数组tab[7],但实际用到了tab[7];

    软件测试环节出错:某机器电源键关闭电源后制冷功能无法关闭,测试时只关注了电源键关闭,显示已关闭,未关注负载输出未关闭的问题。

    关于软件测试环节出错,我认为很大一个原因在测试用例的设计上存在不足。后面我单独讲讲测试用例的设计。

    开发高可靠的软件,那就是要在这些环节中都控制好。

    六、软件可靠性与硬件可靠性的区别

    软件具有如下特点:
    (1)无形性。产品没有一定的形状,其制作过程的可视性差。
    (2)一致性。产品一旦成型后,无论复制多少份,均完全一致,无散差。
    (3)不变性。软件产品形成后,无论存放和使用多久,只要未经人为改动,就不会变化,不存在老化和损耗问题。
    (4)易改进性。软件产品通常比硬件产品容易改进。
    (5)复杂性。软件的运行路径通常很多,特别是大型软件,逻辑组合变化复杂,功能也相对复杂。

    软件可靠性和硬件可靠性的区别如下,非常清晰:

    硬件产品

    软件产品

    是物理实体,有散差,会自然老化,且存在使用耗损

    是思维逻辑的表示,无散差,不会自动变化,只是其载体硬件可变

    研制和生产过程的可见性好,便于控制

    设计和编码过程的可见性差,难控制

    产品故障不只是设计故障,生产过程、使用过程和物料变化均能造成内部故障

    产品缺陷均为开发过程中的设计缺陷,复制过程不会直接而只能通过载体或环境造成内部缺陷

    若产品的零部件及其结合部均无故障,且各组成部分之间是协调配合的,则产品无故障;若有故障,就会在运行中暴露

    程序是指令序列,即使每条指令本身都是正确的,程序运行状态通常很多,也很难保证指令的动态组合完全正确,故通常存在缺陷; 仅当具备一定的系统状态和输入条件时,缺陷才暴露出来

    系统行为通常可用连续函数描述,故障有物理原因,有前兆

    程序运行状态的数学模型是离散型的,缺陷的形成无物理原因,失效无前兆

    研制、生产、使用、备料和管理过程都会产生缺陷,均需加强控制

    一般应在开发过程中采取技术和管理措施来确保可靠性

    同一品种规格的不同零部件的适当冗余可提高可靠性

    容错设计中冗余设计不能相同,必须保证其设计相异性;否则,将严重影响容错效果

    可靠性参数估计有物理基础

    可靠性参数估计无物理基础

    使用中出现故障后产品维修通常是修复失效的零部件状态,可靠性只能尽量保持,但不能提高

    使用中发生失效后软件维护通常要修改软件,产生新版本;只要维护过程合理,可以提高可靠性

    维修性设计适当时,维修某个零部件一般不会波及他处,或受影响部位较明显、易确定

    维护时修改一处常常会影响他处,波及面不易分析;如果分析不清楚,就不能保证修改结果完整、正确

    维修分级,其中基层级快速维修是维修性要求所必需的

    维护过程复杂,一般需由专业软件人员进行

    产品本身可能有危险;安全关键产品的安全性可单独加以分析评估,一般也必须单独加以分析评估

    产品本身无危险,但对于系统安全性可能有影响,因而可能是安全关键的;不能孤立地单独分析评估软件安全性

    本文为《软件可靠性简介》培训课程中摘录的公开内容,关注微信公众号“永恒之地”,后台回复“软件可靠性”,下载培训课件。

     

    展开全文
  • 电力系统可靠性是电力系统运行的一项重要的衡量指标。传统的电力系统可靠性指标反映了电力系统元件或网络的可用度,但是没有反映出其经济成分。本文提出一种对电力系统配电网络进行评估的新指标——经济可靠性,不仅...
  • 论软件的可靠性设计

    千次阅读 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可以实现虚拟机隔离应用环境的功能,并且开销比虚拟机小。这样可以很大程度解决环境移植的过程中服务可靠性的问题。

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

    展开全文
  • 确保汽车电子产品可靠性已经引发了整个半导体供应链的争夺,并且发现了一系列数据不足,缺乏明确定义的标准以及不一致的知识水平的问题。 可靠的功能安全性,可在恶劣环境中使用18至20年,或在自动出租车或...
  • 软件可靠性测试方法与目的

    千次阅读 2021-07-23 15:12:31
    深入研究软件可靠性模型对于预测评估软件的可靠性具有十分重要的意义。软件可靠性测试是指为了保证和验证软件的可靠性要求而对软件进行的测试。其采用的是按照软件运行剖面(对软件实际使用情况的统计规律的描述)对...
  • 系统可靠性分析与设计

    千次阅读 2022-04-23 22:34:46
    可靠性分析与设计的重要内容是建立可靠性模型,以及可靠性指标的预计与分配。在系统分析与设计过程中,系统分析师及相关人员要反复地进行可靠性预计和分配,并不断深化,以选择合适的方案,预测系统可靠性水平,找出...
  • 研究了无功功率对电力系统可靠性的影响,涉及无功功率短缺及由无功电源故障引起的相关的电压稳定性问题,定义了无功功率缺乏引出的的可靠性指标。并以太原220kV电网为例,用传统的切负荷方法和无功功率就地补偿的方法...
  • 软件可靠性工程.doc

    2022-07-02 14:31:38
    于是有诸多相关术语,如软件可靠性度量、软件可靠 性设计、软件可靠性建模、软件可靠性测试、软件可靠性管理等。 2 狭义 指软件无失效运行的定量度量,尤其是那些面向用户的定量度量。主要有: 软件可靠度:表示软件...
  • 站点可靠性工程(SRE)支持该存储库包含用于管理服务的所有SRE(站点可靠性工程)原理和指南。什么是SRE? SRE是一种软件工程方法,用于管理系统,应用程序和服务的操作。 我们使用软件作为工具来管理系统,解决问题...
  • 本文是为大家整理的可靠性评价主题相关的10篇毕业论文文献,包括5篇期刊论文和5篇学位论文,为可靠性评价选题相关人员撰写毕业论文提供参考。
  • 电子设备的可靠性预计

    千次阅读 2021-05-22 00:55:53
    01—电子可靠性预测的一般程序1、先划分可靠性预计单元,后建立系统可靠性模型。预计单元在电路功能上相对独立,其可靠性模型一般为串联结构。2、计算各预计单元内元器件的工作失效率。对于采用元器...
  • 为铁路当局和铁路支持行业提供一个流程,该流程将能够实施一致的方法来管理可靠性、可用性、可维护性和安全性,由首字母缩写词 RAMS 表示。 RAMS 要求的规范和演示过程是本标准的基石。 它旨在促进对 RAMS 管理的...
  • BS EN 50126-1:2017 Railway Applications - The Specification and Demonstration of Reliability, Availability,Maintainability and Safety (RAMS) - Part 1:Generic RAMS Process(铁路应用 - 可靠性、可用性...
  • 可用性和可靠性

    千次阅读 2021-06-14 21:42:55
    可用性关注可用时长,可靠性关注故障频率。
  • 性能测试之稳定性测试(可靠性测试)概念首先来说说性能测试:性能是软件的一种非功能特性,他关注的不是软件是否完成了特定的功能,而是软件在完成特定功能是展示出来的及时性。及时性从不同的视角代表不同的指标:...
  • TCP协议之如何保证传输的可靠性

    千次阅读 2020-01-12 04:32:35
    TCP协议之如何保证传输的可靠性?我们先看下TCP的头部图片和TCP头部的字段 /*TCP头定义,共20个字节*/ typedef struct _TCP_HEADER { short m_sSourPort; // 源端口号16bit short m_sDestPort; // 目的端口号...
  • 选取合适的软件可靠性度量,对于软件质量保证及项目管理有着重要意义。现有的软件可靠性度量选取方法没有考虑软件完整性级别这个重要的设计属性。完整性级别表示软件特性的取值范围,该范围对将系统风险保持在可容忍...
  • 软件安全性与软件可靠性

    千次阅读 2020-06-25 21:57:35
    在功能安全强调软件安全性的时候,往往与软件可靠性密不可分,航空领域一般讲究可靠性,而轨道交通领域和汽车领域通常讲究安全性,那么对于软件而言,安全性与可靠性到底是怎么的关系与区别,很多人存在这方面的疑惑...
  • 软件可靠性测试概念与应用

    千次阅读 2022-05-23 23:17:26
    一、软件可靠性测试的概念: 1、软件可靠性分析方法有: 2、可靠性测试的使用场景: 3、可靠性测试过程五个步骤: 4、可靠性预测的目的: 5、可靠性测试的目的 6、可靠性测试要求 7、可靠性测试条件 8、软件可靠性的...
  • 首先,从制造系统的组成和运行原理的系统角度出发,阐述了生产任务执行状态,生产设备退化状态和生产产品质量状态之间的关系,多状态制造系统的任务可靠性的涵义是定义。 其次,提出了扩展状态任务网络(ESTN),以...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 299,472
精华内容 119,788
热门标签
关键字:

产品可靠性管理的意义