可靠性,可用性,可维护性,安全性(RAMS)定义解释_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
可靠性,可用性,可维护性,安全性(RAMS)定义解释
上传于||文档简介
&&可​靠​性​,​可​用​性​,​可​维​护​性​,​安​全​性​(​R​A​M​S​)​定​义​解​释
阅读已结束，如果下载本文需要使用0下载券
想免费下载更多文档？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩1页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢5156人阅读
分布式系统（1）
相信点开这篇文章的读者，一定或多或少接触过“高可靠”“高可用”这些字眼，但是往往或语焉不详，或罗列术语（MTBF、MTTR ...），那么我们到底应该如何定量描述系统的可靠性和可用性指标呢，这些看着很上流的术语到底意味着什么呢？也许，看完这篇文章，您从此也可以和小伙伴们愉快地拽术语了！
硬件故障（Hardware failure）
工业界通常使用“浴盆曲线”来描述硬件故障，具体如下图所示。具体来说，硬件的生命周期一般被划分为三个时期（）：
1)&&&&&&&&The first part is a decreasingfailure rate, known as early failures
2)&&&&&&&&The second part is a constantfailure rate, known as random failures
3)&&&&&&&&The third part is an increasingfailure rate, known as wear-out failures
图1 浴盆曲线（Bathtubcurve）
软件故障（Software failure）
软件故障可以通过每千行代码的缺陷数(Defects/KLOC)进行测量，称为缺陷密度(Defect Density)：
DefectDensity = Number of Defects / KLOC
影响缺陷密度的因素主要有如下几点：
1)&&&&&&&&软件过程（代码评审、单元测试等）
2)&&&&&&&&软件复杂度
3)&&&&&&&&软件规模
4)&&&&&&&&开发团队经验
5)&&&&&&&&可复用代码比例（久经考验的代码）
6)&&&&&&&&产品交付前的测试
平均故障间隔时间（MTBF）
英文全称：Mean Time Between Failure，顾名思义，是指相邻两次故障之间的平均工作时间，是衡量一个产品的可靠性指标。
故障率（Failure Rate）
以下文字摘自wiki，避免翻译失真（）：
Failure rate is the frequency with which an engineered systemor component fails, expressed, for example, in failures per hour. It is often denoted by the Greek letter λ (lambda) and is importantin reliability engineering.
The failure rate of a system usually depends on time, withthe rate varying over the life cycle of the system. Forexample, an automobile's failure rate in its fifth year of service may be manytimes greater than its failure
rate during its first year of service. One doesnot expect to replace an exhaust pipe, overhaul the brakes, or have majortransmission problems in a new vehicle.
In practice, the mean time between failures (MTBF, 1/λ) isoften reported instead of the failure rate. This is valid and useful if thefailure rate may be assumed constant – often used forcomplex units / systems, electronics
– and is a general agreement in somereliability standards (Military and Aerospace). It does in this case onlyrelate to the flat region of the bathtub curve, also called the &usefullife period&.Because of this, it is incorrect toextrapolate
MTBF to give an estimate of the service life time of a component,which will typically be much less than suggested by the MTBF due to the muchhigher failure rates in the &end-of-life wearout& part of the&bathtub curve&.
为便于理解，举个例子：比如正在运行中的100只硬盘，1年之内出了2次故障，则故障率为0.02次/年。
上文提到的关于MTBF和Failure Rate关系值得细细体会，在现实生活中，硬件厂商也的确更热衷于在产品上标注MTBF（个人猜测是因为MTBF往往高达十万小时甚至百万小时，容易吸引眼球）。Failure Rate伴随着产品生命周期会产生变化，因此，只有在前述“浴盆曲线”的平坦底部（通俗点说就是产品的“青壮年时期”）才存在如下关系：
MTBF = 1/λ
平均修复时间（MTTR）
英文全称：Mean Time To Repair，顾名思义，是描述产品由故障状态转为工作状态时修理时间的平均值。在工程学，MTTR是衡量产品维修性的值，在维护合约里很常见，并以之作为服务收费的准则。
图2 硬件MTTR估算
图3 软件MTTR估算
可用性（Availability）
GB/T3187-97对可用性的定义：在要求的外部资源得到保证的前提下，产品在规定的条件下和规定的时刻或时间区间内处于可执行规定功能状态的能力。它是产品可靠性、维修性和维修保障性的综合反映。
Availability = MTBF / (MTBF + MTTR)
关于Availability这个计算公式，很容易理解，这里不多做解释。通常大家习惯用N个9来表征系统可用性，比如99.9%（3-nines availability），99.999%（5-nines availability）。
宕机时间（Downtime）
顾名思义，指机器出现故障的停机时间。这里之所以会提Downtime，是因为使用每年的宕机时间来衡量系统可用性，更符合直觉，更容易理解。
图4 Availability与Downtime对应关系
MTBF不靠谱？
一般来说，服务器的主要部件MTBF，厂商标称值都在百万小时以上。比如：主板、CPU、硬盘为100wh，内存为400wh（4根内存约为100wh），从而可以推算出服务器整体MTBF约25wh（约30年），年故障约3%，也就是说，100台服务器每年总要坏那么几台。
上面的理论计算看着貌似也没啥问题，感觉还挺靠谱。但如果换个角度想想，总觉得哪里不太对劲：MTBF约30年，难道说可以期望它服役30年？先看看希捷的工程师如何解释：
It iscommon to see MTBF ratings between 300,000 to 1,200,000 hours for hard diskdrive mechanisms, which might lead one to conclude that the specificationpromises between 30 and 120 years of continuous operation. This is not thecase! The specification
is based on a large (statistically significant) numberof drives running continuously at a test site, with data extrapolated accordingto various known statistical models to yield the results.
Based on the observed error rate over a few weeks or months,the MTBF is estimated and not representative of how long your individual drive,or any individual product, is likely to last. Nor isthe MTBF a warranty - it is
representative of the relative reliability of afamily of products.
A higher MTBF merely suggests agenerally more reliable and robust family of mechanisms (depending uponthe consistency of the statistical models used). Historically, the field MTBF,which includes all returns regardless of cause, is typically 50-60% ofprojected
看到这里，再联系前文对于Failure Rate的阐述，我知道各位读者有没有摸清其中的门道。其实说白了很简单，这些厂商真正测算的是产品在“青壮年”健康时期的Failure Rate，然后基于与MTBF的倒数关系，得出了动辄百万小时的MTBF。而现实世界中，这些产品的Failure Rate在“中晚年”时期会快速上升，因此，这些MTBF根本无法反映产品的真实寿命。文中也提到，希捷也意识到MTBF存在弊端，因此改用AFR（Annualized Failure Rate），俗称“年度不良率”。
其实，早在2007年，Google和CMU同时在FAST07发表论文，详细讨论了硬盘故障的问题：
CMU《》Google《》
Google采集了公司超过10w块消费级HDD硬盘数据（SATA和PATA，5400转和7200转，7家不同厂商，9种不同型号，容量从80G到400G不等），最终得出如下数据：
Googlefound that disks had an annualized failure rate (AFR) of 3% for the first threemonths, dropping to 2% for the first year. In the second year the AFR climbedto 8% and stayed in the 6% to 9% range for years 3-5.
如果各位读者对于MTBF仍然有疑问，再推荐一份入门材料给大家，《》，其中对于人类的MTBF阐述绝对会让你恍然大悟。
系统可用性
前文的描述其实都是针对单一模块而言，而现实世界中的系统往往是由若干模块组合而成。其实，各个模块之间的关系无非“串联”和“并联”两种（与串并联电路类似），那么整体可用性计算方式就显而易见了。
图5 串联模块
整体可用性计算公式如下：
A = Ax* Ay
图6 并联模块
整体可用性计算公式如下：
A = 1 – (1 –Ax)2
图7 系统模块构成
图8 软硬件抽象分离
图9 模块可用性计算
图10 系统可用性计算
系统设计启发
通过上一小节的示例系统可用性计算，相信各位对于“并联”的威力已经有了非常直观的感受。其实这就是我们做架构设计常说的“容灾”“冗余”，其实在硬件领域也很常见（如双电源、RAID、双网卡）。与此同时，对于“串联”的局限也应该有所体会，只要存在“短板”，整体可用性是上不去的。引申到后台软件系统设计，我个人有以下看法，欢迎大家拍砖：
1)&&&&&&&&“7*24不停机”不切实际
在不少开发人员的心目中，往往认为硬件是很可靠的，但是经过前文的洗礼，应该认识到，其实硬件真的没有我们想象得那么可靠。如果你仅仅围绕两三台服务器打转，可能一两年都未必碰到一次硬件故障，但是如果你维护的是上千台服务器，那么恭喜你，基本每周都会有硬件故障来拜访你。
单机软件的可靠性受限于硬件，因此，言必谈“7*24不停机”本身就是个无稽之谈。随之而来的就是一些根深蒂固的错误观念，比如内存碎片。新人一进公司往往就会被教导：后台开发应该尽量避免使用malloc/free等动态内存分配，因为容易导致内存碎片，随之而来的就是避免使用STL容器等。如果您有幸已经用上了64位系统，那么如果您还能遇到内存碎片，我只能说自求多福了；如果您还在使用32位系统，也不用太担心，今天的glibc也早就不是当年的glibc了，人家也在不断优化内存分配算法，何况kernel都在使用动态内存分配。退一万步讲，即使真的遇到了，那么就到了我想谈的下一个话题
2)&&&&&&&&“可重启”才是好设计
这里所说的“可重启”和很多人心目中的理解可能不太一样，我司相当多的开发人员热衷于共享内存的使用：
进程间通讯重启后数据不丢失
比如应用升级或者程序CORE掉，往往借助所谓“秒起”来完成服务恢复，有些更极端的甚至拦截”段错误”一类信号。其实，无论如何秒起，总归会有部分用户受影响，另外，如果是由于程序错误导致的意外重启，谁能保证共享内存的数据仍然处于正确状态呢？
此外，如果出现机房搬迁、空调故障、供电故障等意外，所谓的共享内存+秒起也只能干瞪眼。
因此，正如上文所说的，通过容灾备份+路由切换实现优雅无缝重启才是好的设计。一般来说，“可重启”进程具备如下特征：
无论exit还是kill，都可以正确重启不使用生命期大于进程的IPC（共享内存、跨进程的mutex等）不使用难以重建的IPC（父子进程共享FD通信等）
那么又该如何优雅重启呢？一般分为两种场景：
有计划的重启（如版本升级）
首先将节点从服务列表中摘除，等待节点流量跌零，发起重启过程（更新文件等），确认服务启动正常后，重新将节点添加至服务列表，逐步引流进行正确性验证（若发现异常，及时摘除）。服务节点依次分批处理，真正实现无缝重启
意外故障发生
服务访问方支持Failover，自动切换备用节点，或者通过Name Service一类设施自动摘除故障节点，人工介入恢复
当然，前面一些看法并非“放之四海而皆准”，在实际设计系统的时候，还是应该因地制宜，选择最适合当时环境的方案。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：99042次
积分：1005
积分：1005
排名：千里之外
原创：16篇
转载：17篇
评论：16条
(5)(1)(2)(3)(2)(4)(5)(3)(2)(1)(2)(1)(1)(1)可靠性和可用性的区别
[问题点数：20分，结帖人chuan122345]
可靠性和可用性的区别
[问题点数：20分，结帖人chuan122345]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
本帖子已过去太久远了，不再提供回复功能。天极传媒：天极网全国分站
您现在的位置：
& >&如何增强服务器内存的可靠性和可用性
如何增强服务器内存的可靠性和可用性论坛 06:00
　　由于大家的注意力大多集中在网站评估的处理能力、网络带宽和存储IOPS(每秒输入输出操作)上，所以很容易忽视的可用性和可靠性。虽然处理器是任何服务器的核心部件，但是工作负载的所有指令和数据都存储在中。
　　在如今的虚拟化数据中心中，单单一台服务器可能运行众多，而每个虚拟机作为一个文件驻留在内存中。但是当新的服务器添置更多更快的内存以满足更大的计算需求时，内存可靠性问题就显得尤为重要。IT人员必须留意内存故障，并充分利用旨在增强内存可用性的服务器特性。
　　如今，服务器采用数TB的64位内存，这些预制模块遵守联合电子设备工程委员会(JEDEC) DDR3和DDR3L(低电压)标准而设计和制造。这样一来，企业很容易从诸多内存厂商购得价位合理的内存，但是遵守标准并不能保证可靠性。
　　内存可靠性面临的最大威胁并不是彻底的故障，不过可能会出现生产缺陷、电事件及其他物理异常引起的故障。确切地说，服务器内存面临的最大威胁来自随机比特错误――某个比特出现自发逆转。要是未加以检查，仅仅一个比特出现错误就会以突如其来、可能灾难性的方式，改动指令或改变数据流。
　　比特错误会自然发生。内存模块的错误率从每兆字节内存每小时大约1比特(有时被标为1010 errors/bit*h)到每兆字节内存每百年1比特(1017 errors/bit*h)不等。这个范围相差得太大了，但随着内存子系统速度变快、电气操作电压变低以及服务器上的内存总量增加，比特被“误解”并影响工作负载的可能性随之变得相当大。
　　其他因素也会加剧单比特错误，比如本底辐射(阿尔法粒子)、寄生电事件(如附近电磁干扰)、糟糕的屏蔽或设计，甚至DIMM插座上的电触点受到破损或质量低劣。
　　增强内存可用性的特性
　　缺少可用内存始终是个问题，而奇偶校验等错误检测技术已存在了好多年。奇偶校验很简单，对于检测单比特错误也很有效，但它纠正不了单比特错误，所以没有大量地于服务器。幸好，现在有或正出现另外许多特性，有助于增强内存可靠性。不妨考虑以下几种方案：
　　ECC。系统厂商们不是依赖奇偶校验，而是依赖纠错码(ECC)技术。ECC立足于奇偶校验的基础上，它使用一种算法，为每64比特的内存创建和存储一个8比特码(每个地址总共72比特)。这种算法和编码让系统得以实时检测和纠正单比特错误，此外还能检测多比特错误，并防止系统使用破损数据。ECC通常是许多通用服务器上采用的确保内存可靠性的默认技术。
　　先进ECC。先进ECC把ECC方法扩大到了多种内存设备，让ECC得以检测和纠正多比特故障，只要这些故障出现在同一个内存设备里面。不过，ECC和先进ECC并不支持任何一种故障切换机制，所以为了排除有问题的内存模块，仍得关闭系统(或依赖其他系统技术)。许多企业级服务器可以提供某种先进ECC。
　　内存错误跟踪。应对内存错误的一方面是，首先密切跟踪内存错误。新兴的服务器设计通过为错误率和位置做一份列表，开始密切跟踪可以纠正的错误。一些服务器还能将错误信息保存在内存模块上的可重写串行存在检测(SPD)内存空间――可以读取该内存空间，以便将来评估和分析。一旦系统能跟踪可以纠正的内存错误，并将该信息转移到系统的管理工具，就有可能通过记下错误率突然增加的DIMM来预测可能发生的内存故障。错误跟踪称得上是更先进的内存可靠性特性的先驱，更先进的特性包括DIMM故障切换或在物理内存空间里面转移数据。
　　热备用内存。热备用概念在磁盘存储领域很常见，但只是最近才在服务器设计流行起来。这是由于系统必须有一定的智能，才能先识别和跟踪可以纠正的内存错误，之后才能决定把数据转移到备用内存模块上。内存错误跟踪方面的技术进步让服务器的内存控制器得以将数据从存在的错误不可接受的DIMM转移到同一通道中的另一个备用DIMM上。这也叫内存插槽备用(rank sparing)。这种方法存在的不足是，为错误发生前一直非生产性的服务器增添内存需要一笔开支。
　　设备标记(Device tagging)。一种内存故障切换技术是基于BIOS的技术，名为设备标记。当系统跟踪到出现错误率增加的内存模块时，系统基本上就能把数据从有问题的内存转移到ECC内存――实际上使用ECC内存作为一个小小的热备用内存。这有望减少内存故障，但同时无法在这部分内存里面进行错误检测和纠正。设备标记被用作一种权宜之计，让系统保持运行，直到有问题的内存模块被换掉为止。
　　内存镜像。完美的内存可靠性技术就是把服务器上内存中内容从一个通道复制到另一个配对通道上。这实际上就是为内存建立了RAID 1机制。如果一个通道的内存里面出现故障，内存控制器就会切换到配对通道上，没有任何干扰;完成修复工作(如果需要修复)后，通道就可以重新进行同步。镜像方法的缺点与存储方面的RAID 1一样;由于内存中的内容被复制，存储容量减少了一半，或者说内存成本实际上翻了一番。
　　如今内存在现代虚拟化服务器中扮演更关键的角色，所以应对和缓解内存错误的破坏性效应显得比以往更为重要。IT专业人员可以使用一系列不断完善的内存可靠性特性，但是他们必须先对内存可用性方面的需求进行更认真地评估，然后再部署拥有的特性可以满足那些需求的服务器。
（作者：论坛责任编辑：许京杨）
天极新媒体&最酷科技资讯扫码赢大奖
* 网友发言均非本站立场，本站不在评论栏推荐任何网店、经销商，谨防上当受骗！
办公软件IT新闻整机　　由于大家的注意力大多集中在服务器的处理能力、网络带宽和存储IOPS(每秒输入输出操作)上，所以很容易忽视的可用性和可靠性。虽然处理器是任何服务器的核心部件，但是工作负载的所有指令和数据都存储在内存中。
　　在如今的虚拟化数据中心中，单单一台服务器可能运行众多，而每个虚拟机作为一个文件驻留在内存中。但是当新的服务器添置更多更快的内存以满足更大的计算需求时，内存可靠性问题就显得尤为重要。IT人员必须留意内存故障，并充分利用旨在增强内存可用性的服务器特性。
　　如今，企业级服务器采用数TB的64位内存，这些预制模块遵守联合电子设备工程委员会(JEDEC) DDR3和DDR3L(低电压)标准而设计和制造。这样一来，企业很容易从诸多内存厂商购得价位合理的内存，但是遵守标准并不能保证可靠性。
　　内存可靠性面临的最大威胁并不是彻底的故障，不过可能会出现生产缺陷、电事件及其他物理异常引起的故障。确切地说，服务器内存面临的最大威胁来自随机比特错误——某个比特出现自发逆转。要是未加以检查，仅仅一个比特出现错误就会以突如其来、可能灾难性的方式，改动指令或改变数据流。
　　比特错误会自然发生。内存模块的错误率从每兆字节内存每小时大约1比特(有时被标为1010 errors/bit*h)到每兆字节内存每百年1比特(1017 errors/bit*h)不等。这个范围相差得太大了，但随着内存子系统速度变快、电气操作电压变低以及服务器上的内存总量增加，比特被“误解”并影响工作负载的可能性随之变得相当大。
　　其他因素也会加剧单比特错误，比如本底辐射(阿尔法粒子)、寄生电事件(如附近电磁干扰)、糟糕的主板屏蔽或设计，甚至DIMM插座上的电触点受到破损或质量低劣。
　　增强内存可用性的特性
　　缺少可用内存始终是个问题，而奇偶校验等错误检测技术已存在了好多年。奇偶校验很简单，对于检测单比特错误也很有效，但它纠正不了单比特错误，所以没有大量地应用于服务器。幸好，现在有或正出现另外许多特性，有助于增强内存可靠性。不妨考虑以下几种方案：
　　ECC。系统厂商们不是依赖奇偶校验，而是依赖纠错码(ECC)技术。ECC立足于奇偶校验的基础上，它使用一种算法，为每64比特的内存创建和存储一个8比特码(每个地址总共72比特)。这种算法和编码让系统得以实时检测和纠正单比特错误，此外还能检测多比特错误，并防止系统使用破损数据。ECC通常是许多通用服务器上采用的确保内存可靠性的默认技术。
　　先进ECC。先进ECC把ECC方法扩大到了多种内存设备，让ECC得以检测和纠正多比特故障，只要这些故障出现在同一个内存设备里面。不过，ECC和先进ECC并不支持任何一种故障切换机制，所以为了排除有问题的内存模块，仍得关闭系统(或依赖其他系统技术)。许多企业级服务器可以提供某种先进ECC，比如IBM ProLiant或戴尔PowerEdge。
　　内存错误跟踪。应对内存错误的一方面是，首先密切跟踪内存错误。新兴的服务器设计通过为错误率和位置做一份列表，开始密切跟踪可以纠正的错误。一些服务器还能将错误信息保存在内存模块上的可重写串行存在检测(SPD)内存空间——可以读取该内存空间，以便将来评估和分析。一旦系统能跟踪可以纠正的内存错误，并将该信息转移到系统的管理工具，就有可能通过记下错误率突然增加的DIMM来预测可能发生的内存故障。错误跟踪称得上是更先进的内存可靠性特性的先驱，更先进的特性包括DIMM故障切换或在物理内存空间里面转移数据。
　　热备用内存。热备用概念在磁盘存储领域很常见，但只是最近才在服务器设计流行起来。这是由于系统必须有一定的智能，才能先识别和跟踪可以纠正的内存错误，之后才能决定把数据转移到备用内存模块上。内存错误跟踪方面的技术进步让服务器的内存控制器得以将数据从存在的错误不可接受的DIMM转移到同一通道中的另一个备用DIMM上。这也叫内存插槽备用(rank sparing)。这种方法存在的不足是，为错误发生前一直非生产性的服务器增添内存需要一笔开支。
　　设备标记(Device tagging)。一种内存故障切换技术是基于BIOS的技术，名为设备标记。当系统跟踪到出现错误率增加的内存模块时，系统基本上就能把数据从有问题的内存转移到ECC内存——实际上使用ECC内存作为一个小小的热备用内存。这有望减少内存故障，但同时无法在这部分内存里面进行错误检测和纠正。设备标记被用作一种权宜之计，让系统保持运行，直到有问题的内存模块被换掉为止。
　　内存镜像。完美的内存可靠性技术就是把服务器上内存中内容从一个通道复制到另一个配对通道上。这实际上就是为内存建立了RAID 1机制。如果一个通道的内存里面出现故障，内存控制器就会切换到配对通道上，没有任何干扰;完成修复工作(如果需要修复)后，通道就可以重新进行同步。镜像方法的缺点与存储方面的RAID 1一样;由于内存中的内容被复制，存储容量减少了一半，或者说内存成本实际上翻了一番。
　　如今内存在现代虚拟化服务器中扮演更关键的角色，所以应对和缓解内存错误的破坏性效应显得比以往更为重要。IT专业人员可以使用一系列不断完善的内存可靠性特性，但是他们必须先对内存可用性方面的需求进行更认真地评估，然后再部署拥有的特性可以满足那些需求的服务器。