系统架构设计高级技能 · 软件可靠性分析与设计(三)【系统架构设计师】

系列文章目录

系统架构设计高级技能 · 软件架构概念、架构风格、ABSD、架构复用、DSSA(一)【系统架构设计师】
系统架构设计高级技能 · 系统质量属性与架构评估(二)【系统架构设计师】
系统架构设计高级技能 · 软件可靠性分析与设计(三)【系统架构设计师】

现在的一切都是为将来的梦想编织翅膀,让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.

系统架构设计 · 软件可靠性分析与设计(三)

  • 系列文章目录
  • 一、软件可靠性基本概念★
  • 二、软件可靠性建模★
  • 三、软件可靠性管理★
  • 四、软件可靠性分析★★★
    • [4.1 可靠性指标](#4.1 可靠性指标)
    • [4.2 串联系统(可靠性)](#4.2 串联系统(可靠性))
    • [4.3 并联系统(可靠性)](#4.3 并联系统(可靠性))
    • [4.4 混合系统(可靠性)](#4.4 混合系统(可靠性))
  • 五、软件可靠性设计★★★★
    • [5.1 影响软件可靠性的主要因素](#5.1 影响软件可靠性的主要因素)
    • [5.2 软件的可靠性设计技术](#5.2 软件的可靠性设计技术)
      • [5.2.1 容错设计技术](#5.2.1 容错设计技术)
        • [5.2.1.1 冗余设计 - 容错设计技术](#5.2.1.1 冗余设计 - 容错设计技术)
        • [5.2.1.2 N版本程序设计 - 容错设计技术](#5.2.1.2 N版本程序设计 - 容错设计技术)
        • [5.2.1.3 恢复块方法 - 容错设计技术](#5.2.1.3 恢复块方法 - 容错设计技术)
        • [5.2.1.4 防卫式程序设计 - 容错设计技术](#5.2.1.4 防卫式程序设计 - 容错设计技术)
      • [5.2.2 检错错设计技术](#5.2.2 检错错设计技术)
      • [5.2.3 降低复杂度设计技术](#5.2.3 降低复杂度设计技术)
      • [5.2.3 系统配置技术](#5.2.3 系统配置技术)
        • [5.2.3.1 双机容错技术 - 系统配置技术](#5.2.3.1 双机容错技术 - 系统配置技术)
        • [5.2.3.2 服务器集群技术 - 系统配置技术](#5.2.3.2 服务器集群技术 - 系统配置技术)
  • 六、软件可靠性测试★
  • 七、软件可靠性评价★

一、软件可靠性基本概念★

系统可靠性 是系统在规定的时间内及规定的环境条件下,完成规定功能的能力,也就是系统无故障运行的概率。也就是软件系统在应用或系统错误面前,在意外或错误使用的情况下维持软件系统的功能特性的基本能力。
系统可用性 是指在某个给定时间点上系统能够按照需求执行的概率,也就是系统能够正常运行的时间比例。

软件可靠性 ≠ 硬件可靠性,其区别:

  • 复杂性 ,软件复杂性比硬件高, 大部分失效来自于软件失效
  • 物理退化 ,硬件失效主要是物理退化所致,软件不存在物理退化
  • 唯一性,软件是唯一的 ,每个COPY版本都一样,而两个硬件不可能完全一样。
  • 版本更新周期,硬件较慢,软件较快

软件可靠性的定量描述

软件的可靠性是在软件使用条件、在规定时间内、系统的输入/输出、系统的使用等变量构成的数据表达式。

(1)规定时间:自然时间、运行时间、执行时间,度量软件的可靠性效果最好

(2)失效概率:软件从运行开始算起,运行到某一时间t,出现失效的概率是一个随机函数,称为失效概率。

(3)可靠度:是如软件在规定条件下、规定时间内不失效的概率。

(4)失效强度:单位时间内软件失效的概率。

(5)失效率:也称风险函数或条件失效强度,在运行系统未出现失效的情况下,单位时间软件系统出现失效的概率。

(6)平均无失效时间:软件运行后,到下一次失效的平均时间。更直观地反应软件的可靠度。

可靠性的目标

软件可靠性是指用户对所使用的软件的性能满意程度的期望。可以用可靠性、平均失效时间和故障强度等来描述。

软件可靠性测试的意义

(1)软件失效可能造成灾难性的后果。

(2)软件的失效在整个计算机系统失效中的比例较高。

(3)相比硬件可靠性技术,软件可靠性技术不成熟。

(4)软件可靠性问题会造成软件费用增长。

(5)系统对软件的依赖性强,对生产活动和社会生活影响日益增大。

软件可靠性测试的目的

(1)发现软件系统的缺陷【需求分析、软件设计、系统编码、测试实施】

(2)为软件的使用和维护提供可靠性依据

(3)确认软件是否达到可靠性的定量要求

广义软件可靠性测试 是为了最终评价软件系统的可靠性而运用的建模、统计试验、分析和评价等一系列手段对软件系统实施一种测试。

狭义软件可靠性测试 指为了获取可靠性数据,按预先确定好的测试用例,在软件预期使用环境中,对软件实施的一种测试。

二、软件可靠性建模★

软件可靠性模型 是指 为预计或估算软件的可靠性所建立的可靠性框图和数学模型

一个软件可靠性模型通常(但不是绝对)由以下几部分组成

  • 模型假设

    模型是实际情况的简化或规范化,总要包含若干假设,例如测试的选取代表实际运行剖面,不同软件失效独立发生等。

  • 性能度量

    软件可靠性模型的输出量就是性能度量,如失效强度、残留缺陷数等。在软件可靠性模型中性能度量通常以数学表达式给出。

  • 参数估计方法

    某些可靠性度量的实际值无法直接获得,例如残留缺陷数,这时需通过一定的方法估计参数的值,从而间接确定可靠性度量的值。

  • 数据要求

    一个软件可靠性模型要求一定的输入数据,即软件可靠性数据。

绝大多数的模型包含3个共同假设

  • 代表性假设

    是指可以用测试产生的软件可靠性数据预测运行阶段的软件可靠性行为。

  • 独立性假设

    此假设认为软件失效是独立发生于不同时刻,一个软件失效的发生不影响另一个软件失效的发生。

  • 相同性假设

    此假设认为所有软件失效的后果(等级)相同,即建模过程只考虑软件失效的具体发生时刻,不区分软件的失效严重等级。

软件可靠性(模型分类)模的方法包括

  • 种子法模型
    利用捕获一再捕获抽样技术估计程序中的错误数,在程序中预先有意"播种"一些设定的错误"种子",然后根据测试出的原始错误数和发现的诱导错误的比例,来估计程序中残留的错误数。
  • 失效率类模型
    用来研究程序的失效率
  • 曲线拟合类模型
    用回归分析的方法研究软件复杂性、程序中的缺陷数、失效率、失效间隔时间。
  • 可靠性增长模型
    这类模型预测软件在检错过程中的可靠性改进,用增长函数来描述软件的改进过程。
  • 程序结构分析模型
    是根据程序、子程序及其相互间的调用关系,形成一个可靠性分析网络。
  • 输入域分类模型
    选取软件输入域中的某些样本"点"运行程序,根据这些样本点在"实际"使用环境中的使用概率的测试运行时的成功/失效率,推断软件的使用可靠性。
  • 执行路径分析方法模型
    分析方法与上面的模型相似,先计算程序各逻辑路径的执行概率和程序中错误路径的执行概率,再综合出该软件的使用可靠性。
  • 非齐次泊松过程模型
    是以软件测试过程中单位时间的失效次数为独立泊松随机变量,来预测在今后软件的某使用时间点的累计失效数。
  • 马尔可夫过程模型
  • 贝叶斯模型
    是利用失效率的试验前分布和当前的测试失效信息,来评估软件的可靠性。

三、软件可靠性管理★

软件可靠性管理的各个阶段,如图:

图3_1 软件可靠性管理阶段

四、软件可靠性分析★★★

4.1 可靠性指标

  • 平均无故障时间,MTTF = 1 / λ,λ为失效率
  • 平均故障修复时间,MTTR = 1 / μ,μ为修复率
  • 平均故障间隔时间,MTBF = MTTR + MTTF
  • 系统可用性,MTTF / MTBF = MTTF / (MTTR + MTTF) × 100%

图4_1 可靠性指标

4.2 串联系统(可靠性)


图4_2 串联系统(可靠性)

4.3 并联系统(可靠性)


图4_3 并联系统(可靠性)

4.4 混合系统(可靠性)


图4_4 混合系统(可靠性)

五、软件可靠性设计★★★★

5.1 影响软件可靠性的主要因素

从技术的角度来看,影响软件的可靠性的因素包括:运行环境、软件规模、软件的内部结构、软件的开发方法和开发环境、软件的可靠性投入


图5_1 影响软件可靠性的主要因素

5.2 软件的可靠性设计技术


图5_2 软件的可靠性设计

5.2.1 容错设计技术

5.2.1.1 冗余设计 - 容错设计技术

在一套完整的软件系统之外,设计一种不同路径、不同算法或不同的实现方式方法的模块或系统作为备份,再出现故障时可用冗余部分进行替换。

N版本程序设计和恢复块方法都是基于设计冗余的思想。

5.2.1.2 N版本程序设计 - 容错设计技术

通过设计多个模块或不同的版本,对相同初始条件和相同输入的操作结果,实行多数表决,防止其中某一个模块/版本的故障提供错误的服务。

N版本程序设计是一种静态的故障屏蔽技术,采用前向恢复的策略。

图5_3 N版本程序设计

  • 与通常软件开发过程不同的是,N版本程序设计增加了三个新的阶段:相异成分规范评审、相异性确认、背对背测试

  • N版本程序的同步、N版本程序之间的通信、表决算法(全等表决、非精确表决、Cosmetie表决)、---致比较问题、数据相异性。

5.2.1.3 恢复块方法 - 容错设计技术

选择一组操作作为容错设计单元,把普通的程序块变成恢复快。

恢复块方法是一种动态的故障屏蔽技术,采用后向恢复策略。


图5_4 恢复块方法

  • 设计时应保证__实现主块和后备块之间的独立性__ ,避免相关错误的产生,使主块和备份块之间的共性错误降到最低程度。

  • 必须保证验证测试程序的正确性。

N版本程序设计和恢复块方法对比

对比 N版本程序设计 恢复块方法
硬件运行环境 表决 单机
错误检测方法 多机 验证测试程序
恢复策略 前向恢复 后向恢复
实时性
  • 前向恢复 :使当前的计算继续下去,把系统恢复成连贯的正确状态,弥补当前状态的不连贯情况。
  • 后向恢复 :系统恢复到前一个正确状态,继续执行。

5.2.1.4 防卫式程序设计 - 容错设计技术

N版本程序设计和恢复块方法都是基于设计冗余的思想,这给程序员和处理机都增加了许多工作,而且它们的结构本身又带来了一些问题和困难,例如,多版本程序设计中的相关性错误问题和恢复块方法中的验证测试的设计等。

防卫式程序设计 是一种不采用任何传统的容错技术就能实现软件容错的方法,对于程序中存在的错误和不一致性,防卫式程序设计基本思想通过在程序中包含错误检查代码和错误恢复代码,使得一旦发生错误,程序就能撤消错误状态,恢复到一个已知的正确状态中去

实现策略包括:错误检测、破坏估计和错误恢复三个方面。

5.2.2 检错错设计技术

  • 检错技术 代价低于容错技术和冗余技术,但是不能自动解决故障,需要人工干预

  • 检错技术注重考虑:检测对象、检测延时、实现方式、处理方式四个要素。

5.2.3 降低复杂度设计技术

降低复杂度设计设计思想 :在保证软件功能基础上,简化软件结构、缩短软件结构、缩短程序代码长度、优化软件数据流向、降低软件复杂度、提高软件可靠性

5.2.3 系统配置技术

系统配置技术可分为双机容错技术和服务器集群技术

5.2.3.1 双机容错技术 - 系统配置技术

双机容错技术 是一种软硬件结合的容错应用方案。该方案是由两台服务器和一个外接共享磁盘阵列及相应的双机软件组成在双机容错系统中,两台服务器一般区分为主系统和从系统(备用系统),两台服务器互为主从关系。每台服务器都有自己的系统盘(本地盘),安装操作系统和应用程序。每台服务器至少安装两块网卡,一块连接到网络上,对外提供服务;另一块与另一台服务器连接,用以侦测对方的工作状况。同时,每台服务器都连接在共享磁盘阵列上,用户数据存放在共享磁盘阵列中,当一台服务器出现故障时,另一台服务器主动替代工作,保证网络服务不间断。整个网络系统的数据通过磁盘阵列集中管理,极大地保护了数据的安全性和保密性。

双机容错系统根据两台服务器的工作方式不同,可以有三种不同的工作模式,分别是双机热备模式、双机互备模式和双机双工模式

采用心跳的方法保证主系统与备用系统的联系

  • 双机热备模式 - (一台工作,一台后备)

    正常情况下,一台服务器处于工作状态(主系统),另一台服务器处于监控准备状态(备用系统)。如果没有采用共享磁盘阵列,则用户数据同时往两台服务器中写入,以保证数据的即时同步。当主系统出现故障时,通过双机软件将备用系统激活,保证应用在短时间内完全恢复正常使用。当主系统修复后,可重新接入系统要回自己的应用。

    双机热备模式是目前采用较多的一种模式,典型应用有证券资金服务器或行情服务器等。

    双机热备模式的主要缺点在于,备用系统长期处于后备的状态,存在一定的计算资源浪费。

  • 双机互备模式 - (两台运行相对独立应用,互为后备)

    两台服务器均处于工作状态,为前端客户机提供各自不同的应用服务,并互相检测对方的运行情况。也就是说,两台服务器同时运行,但彼此均设为备用系统。当某一台服务器出现故障时,另一台服务器可以在短时间内将故障服务器的应用接管过来,从而保证了应用的持续性。双机互备模式的主要缺点是对服务器的性能要求比较高。

  • 双机双工模式 - (两台同时运行相同的应用,互为后备)

    双机双工模式是集群(cluster)技术的一种形式,两台服务器均处于工作状态,同时为前端客户机提供相同的应用服务,以保证整体系统的性能,实现负载均衡和互为备份。

5.2.3.2 服务器集群技术 - 系统配置技术

集群技术就是将多台计算机组织起来进行协同工作,它是提高系统可用性和可靠性的一种技术。在集群系统中,每台计算机均承担部分计算任务和容错任务,当其中一台计算机出现故障时,系统使用集群软件将这台计算机从系统中隔离出去,通过各计算机之间的负载转嫁机制完成新的负载分担,同时向系统管理人员发出警报。集群系统通过功能整合和故障过渡,实现了系统的高可用性和可靠性。

集群内个节点服务器通过内部局域网相互通信,若某节点服务器发生故障,这台服务器运行的应用被另一个节点服务器自动接管。

  • 高性能计算集群

    指以提高科学计算能力为目的计算机集群技术,它是一种并行计算集群的实现方法。并行计算是指将一个应用程序分割成多块可以并行执行的部分,并指定到多个处理器上执行的方法。

  • 负载均衡集群

    负载均衡集群在多节点之间按照一定的策略(算法)分发负载。负载均衡建立在现有网络结构之上,它提供了一种廉价有效的方法来扩展服务器带宽,增加吞吐量,提高数据处理能力。负载均衡是一种动态均衡,它通过一些工具实时地分析数据包,掌握网络中的数据流量状况,把任务合理分配出去。

    比较常用的负载均衡实现技术 主要有以下几种:

    1)基于特定软件的负载均衡(应用层) :很多网络协议都支持重定向功能,例如,基于HTTP重定向服务,其主要原理是服务器使用HTTP重定向指令,将一个客户端重新定位到另一个位置。服务器返回一个重定向响应,而不是返回请求的对象。客户端确认新地址然后重发请求,从而达到负载均衡的目的。

    2)基于DNS的负载均衡属于传输层负载均衡技术 :其主要原理是在DNS服务器中为同一个主机名配置多个地址,在应答DNS查询时,DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果,将客户端的访问引导到不同的节点上去,使得不同的客户端访问不同的节点,从而达到负载均衡的目的。

    3)基于NAT的负载均衡 :将一个外部IP地址映射为多个内部IP地址,对每次连接需求动态地转换为一个内部节点的地址,将外部连接请求引到转换得到地址的那个节点,上从而达到负载均衡的目的。

    4)反向代理负载均衡 :将来自Internet上的连接请求以反向代理的方式动态地转发给内部网络上的多个节点进行处理,从而达到负载均衡的目的。

    5)混合型负载均衡

  • 高可用性集群

    在高可用性集群系统中,多台计算机一起工作,各自运行一个或几个服务,各为服务定义一个或多台备用计算机。当某台计算机出现故障时,备用计算机便立即接管该故障计算机的应用,继续为前端的用户提供服务。

六、软件可靠性测试★

  • 软件可靠性测试包括:

    可靠性目标的确定、运行剖面的开发、测试用例的设计、测试实施、测试结果的分析等。

  • 测试步骤:

    定义软件运行剖面(为软件的使用行为建模)一个 => 设计可靠性测试用例 => 实施可靠性测试。

七、软件可靠性评价★

  • 软件可靠性评价3个过程:

    选择可靠性模型、收集可靠性数据、可靠性评估和预测。

  • 选择可靠性模型考虑因素:

    模型假设的适用性、预测的能力与质量、模型输出值能否满足可靠性评价需求、模型使用的简便性。

  • 可靠性数据的收集:

    可靠性数据主要是指软件失效数据,是软件可靠性评价的基础,主要是在软件测试、实施阶段收集的。应采用的解决方法:及早确定所采用的的可靠性模型、制订可实施性较强的可靠性数据收集计划、重视软件测试数据的整理和分析、充分利用数据库来完成可靠性数据的存储和统计分析。

  • 可靠性评估和预测:

    判断是否达到了可靠性目标;如未能达到要再投入多少;在软件系统投入实际运行一年或若干时间后,经过维护、升级和修改,软件能否达到交付或部分交付用户使用的可靠性水平。辅助方法:失效数据的图形分析法、试探性数据分析技术。

相关推荐
58沈剑3 小时前
80后聊架构:架构设计中两个重要指标,延时与吞吐量(Latency vs Throughput) | 架构师之路...
架构
黄焖鸡能干四碗5 小时前
信息化运维方案,实施方案,开发方案,信息中心安全运维资料(软件资料word)
大数据·人工智能·软件需求·设计规范·规格说明书
想进大厂的小王5 小时前
项目架构介绍以及Spring cloud、redis、mq 等组件的基本认识
redis·分布式·后端·spring cloud·微服务·架构
阿伟*rui6 小时前
认识微服务,微服务的拆分,服务治理(nacos注册中心,远程调用)
微服务·架构·firefox
ZHOU西口7 小时前
微服务实战系列之玩转Docker(十八)
分布式·docker·云原生·架构·数据安全·etcd·rbac
deephub9 小时前
Tokenformer:基于参数标记化的高效可扩展Transformer架构
人工智能·python·深度学习·架构·transformer
架构师那点事儿10 小时前
golang 用unsafe 无所畏惧,但使用不得到会panic
架构·go·掘金技术征文
W Y12 小时前
【架构-37】Spark和Flink
架构·flink·spark
Gemini199513 小时前
分布式和微服务的区别
分布式·微服务·架构
ftswsfb19 小时前
【系统架构设计师(第2版)】七、系统架构设计基础知识
系统架构