服务器制造商都在极力宣扬他们的系统有多么可靠，但是如何衡量他们系统的可靠性？这就很难说了。要取得这些厂商的定性信息并非难事，这些数据看起来都在说明他们的系统是最可靠的--但是证明他们的系统经得起测试考验的目标型量化指标是什么呢？这种数据很难获得，但是它确实存在。
　　Laura DiDio在创办自己的信息技术智能咨询公司以前，曾经在Yankee Group担任服务器分析师，她经常会对全球服务器厂商的首席信息官进行调研，了解他们的各种服务器平台在一年时间内宕机的次数。DiDio目前仍然在继续这项调研工作，她向笔者提供了信息技术智能咨询公司服务器硬件和操作系统可靠性调研的用户数据和一些自己的看法。
　　信息技术智能咨询公司所做的调研是建立对400多位企业C级别高管的调研基础之上的，这些高管都来自全球20个国家的代表性行业和平台制造商。这项调研看起来不仅反映出在这些地区运行的平台有多少种不同情况的断电和宕机，而且还总结了这些断电和宕机发生的时间长短和这些地区系统管理员的经验水平。意料之中的是，使用最经得起市场考验的系统，最富经验的系统管理员和最成熟的平台的企业宕机时间也是最少的。
　　信息技术智能咨询公司服务器可靠性调研将由硬件或者软件故障导致的服务器断电计算在内。DiDio表示，位于第一级别的断电宕机来自于"愚蠢的员工"，比如说某人意外关闭服务器，然后又快速的加以纠正。位于第二级别的断电宕机是导致系统30分钟到4小时之间的宕机。出现混乱的应用软件或者某些补丁出错都是导致第二级别断电损耗的原因。这些通常都需要1个以上的系统管理员来找到问题症结所在，通常也至少需要1个以上的管理员到现场来解决系统的物理故障。位于第三级别的断电宕机是最糟糕的一种，也是企业级服务器中最少见的一种，他们通常需要4小时以上的时间才能解决。这些故障会导致数据丢失，也经常会引发无法使用应用软件的最终用户的愤怒。
　　在这些接受信息技术智能咨询公司服务器可靠性调研的用户中，IBM公司运行AIX系统的Power Systems（包括上一代的System p和pSeries机型）在所有使用这些平台的用户中，每年的平均宕机时间是最少的。AIX系统的用户报告称每年第一级别的事故平均发生率为0.42，第二级别的事故发生率为0.34，第三级别宕机的事故发生率为0.12。因此至少在2009年，i平台比起在Power系统上运行的AIX平台要略逊一筹。
　　I平台的数据与信息技术智能咨询公司服务器可靠性调研中在PA-RISC或安腾系统上运行的HP-UX平台或者在Sparc服务器上运行的Solaris平台的数据非常接近。在上一代的PA-RISC系统上运行HP-UX 11i v3平台每年的第一级别事故发生率为0.60,第二级别的事故发生率为0.43，第三级别宕机的事故发生率为0.10;在安腾服务器上运行的HP-UX平台数据要略高一些，每年的第一级别事故发生率为0.65,第二级别的事故发生率为0.48，第三级别宕机的事故发生率为0.14。在Sparc服务器上运行的Solaris操作系统，据用户反馈每年的第一级别事故发生率为0.59,第二级别的事故发生率为0.49，第三级别宕机的事故发生率为01.10。
　　当你对信息技术智能咨询公司追踪的断电宕机情况进行计算，你会发现运行AIX系统的Power Systems每年的平均意外宕机时间不到15分钟，是去年报告数据的一半。在PA-RISC和安腾服务器上运行的HP-UX操作系统在PA-RISC服务器上的平均意外宕机时间为36分钟，在安腾服务器上的平均意外宕机时间为39分钟。Solaris系统也在这个范围之内，每年平均意外宕机时间为35.4分钟，但是根据信息技术智能咨询公司的调研结果显示，上一代的Sparc机型在2009年的宕机数据有些偏高。
　　有趣的是据信息技术智能咨询公司统计数据显示，运行Mac OS操作系统的服务器每年的平均宕机时间为37.4分钟。
　　微软公司的Windows Server 2003和Windows Server 2008操作系统平台则得分不佳，不过这些系统正在不断改进。2008年信息技术智能咨询公司的调研显示，受访者反馈他们的Windows系统每年的平均意外宕机时间为3.77小时，但是2009年这个时间降低了35%，缩短为2.42小时。尽管Windows服务器的宕机时间较长，但是第二级别或者第三级别的服务器事故平均发生率却并不高，今年由这些高级别断电宕机导致的总体断电比例仅为29%。那些使用IBM Power-AIX服务器的用户反馈他们的事故中有19%来自第二级别或第三级别，Power-i的用户反馈来自第二级别或第三级别的事故发生率也接近21%。Solaris的用户反馈说他们的断电故障中有25%是第二级别或第三级别。
　　DiDio在服务器可靠性调研中了解到的其他有趣现象是系统管理员的经验水平和他们为服务器打补丁所花费的时间也起到很大作用。在UNIX用户中系统管理员的平均工作经验为12.7年（AS.400-i用户的平均工作经验为11年），在所用系统用户的工作经验方面是最丰富的，Windows系统管理员的平均工作经验为7年，Linux系统管理员的平均工作经验为为四年，Mac OS服务器管理员的平均工作经验为三年。
　　DiDio说"UNIX和AS/400管理员的经验水平相当于主任技师或者修理汽车的A级机械师的级别"。
　　DiDio还补充说商用Linux系统在文件方面得到了大幅改进，这在系统管理员为服务器打补丁所花费的平均时间上有所反馈。Linux用户反映说他们为服务器打补丁花费的平均时间，根据Liunx系统版本的不同大概为15到19分钟。Ubuntu今年在所有Linux系统中的改进是最大的。Power服务器打补丁的平均时间大概为11分钟，不管他们运行的是AIX系统还是i系统，运行Solaris系统的服务器打补丁时间大概为31分钟，而HP-UX服务器打补丁时间为33分钟。根据被调研用户打补丁的平均时间来看，运行Windows Server 2003操作系统的服务器平均打补丁时间为32分钟，Windows Server 2008系统打补丁的时间平均为38分钟。
　　DiDio表示"我们从中得出的经验教训是公司不应该忽视培训和认证的重要性。否则就是耍小聪明，犯大糊涂"。
　　一些测试方法主要分以下几种：
　　压力测试：已知系统高峰期使用人数，验证各事务在最大并发数（通过高峰期人数换算）下事务响应时间能够达到客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反应（如：宕机、应用异常中止等）。
　　Ramp Up 增量设计：如并发用户为75人，系统注册用户为1500人，以5％－7％作为并发用户参考值。一般以每15s加载5人的方式进行增压设计，该数值主要参考测试加压机性能，建议Run几次。以事务通过率与错误率衡量实际加载方式。
　　Ramp Up增量设计目标： 寻找已增量方式加压系统性能瓶颈位置，抓住出现的性能拐点时机，一般常用参考Hits点击率与吞吐量、CPU、内存使用情况综合判断。模拟高峰期使用人数，如早晨的登录，下班后的退出，工资发送时的消息系统等。
　　另一种极限模拟方式，可视为在峰值压力情况下同时点击事务操作的系统极限操作指标。加压方式不变，在各脚本事务点中设置同集合点名称（如：lr_rendzvous("same");）在场景设计中，使用事务点集合策略。以同时达到集合点百分率为标准，同时释放所有正在Run的Vuser。
　　稳定性测试：已知系统高峰期使用人数、各事务操作频率等。设计综合测试场景，测试时将每个场景按照一定人数比率一起运行，模拟用户使用数年的情况。并监控在测试中，系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会出现波动或随测试时间增涨而增加。系统是否会在测试期间内发生如宕机、应用中止等异常情况。
　　根据上述测试中，各事务条件下出现性能拐点的位置，已确定稳定性测试并发用户人数。仍然根据实际测试服务器（加压机、应用服务器、数据服务器三方性能），估算最终并发用户人数。
　　场景设计思想：
　　从稳定性测试场景的设计意义，应分多种情况考虑：
　　针对同一个场景为例，以下以公文附件上传为例简要分析场景设计思想：
　　1）场景一：已压力测试环境下性能拐点的并发用户为设计测试场景，目的验证极限压力情况下测试服务器各性能指标。
　　2）场景二：根据压力测试环境中CPU、内存等指标选取服务器所能承受最大压力的50%来确定并发用户数。
　　测试方法：采用1)Ramp Up-Load all Vusers simultaneously
　　2)Duration-Run Indefinitely
　　3)在Sechedule-勾选Initalize all Vusers before Run
　　容错性测试：通过模拟一些非正常情况（如：服务器突然断电、网络时断时续、服务器硬盘空间不足等），验证系统在发生这些情况时是否能够有自动处理机制以保障系统的正常运行或恢复运行措施。如有HA（自动容灾系统），还可以专门针对这些自动保护系统进行另外的测试。验证其能否有效触发保护措施。
　　问题排除性测试：通过原有案例或经验判断，针对系统中曾经发生问题或怀疑存在隐患的模块进行验证测试。验证这些模块是否还会发生同样的性能问题。如：上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli性能监控对OA系统性能的影响等等。
　　测评测试是用于获取系统的关键性能指标点，而进行的相关测试。主要是针对预先没有明确的预期测试结果，而是要通过测试获取在特定压力场景下的性能指标（如：事务响应时间、最大并发用户数等）。
　　评测事务交易时间：为获取某事务在特定压力下的响应时间而进行的测试活动。通过模拟已知客户高峰期的各压力值或预期所能承受的压力值，获取事务在这种压力下的响应时间。
　　评测事务最大并发用户数：为获取某事务在特定系统环境下所能承受的最大并发用户数而进行的测试活动。通过模拟真实环境或直接采用真实环境，评测在这种环境下事务所能承受的最大并发用户数。判定标准阈值需预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。
　　评测系统最大并发用户数：为获取整个系统所能够承受的最大并发用户数而进行的的测试活动。通过预先分析项目各主要模块的使用比率和频率，定义各事务在综合场景中所占的比率，以比率方式分配各事务并发用户数。模拟真实环境或直接采用真实环境，评测在这种环境下系统所能承受的最大并发用户数。判定标准阀值预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。取值标准以木桶法则为准（并发数最小的事务为整个系统的并发数）。
　　评测不同数据库数据量对性能的影响：针对不同数据库数据量的测试，将测试结果进行对比，分析发现数据库中各表的数据量对事务性能的影响。得以预先判断系统长时间运行后，或某些模块客户要求数据量较大时可能存在的隐患。
　　问题定位测试在通过以上测试或用户实际操作已经发现系统中的性能问题或怀疑已存在性能问题。需通过响应的测试场景重现问题或定义问题。如有可能，可以直接找出引起性能问题所在的代码或模块。
　　该类测试主要还是通过测试出问题的脚本场景，并可以增加发现和检测的工具，如开启Tivoli性能监控、开启HeapDump输出、Linux资源监控命令等。并在场景运行过程中辅以手工测试。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。