从在故障监视过程中发现故障，到（60）以及对故障分析定位，之后进行故障支持和恢复处..

2013年上半年上午试卷综合知识

第 60 题


知识点	故障管理故障管理流程故障监视故障支持和恢复处理故障分析恢复
关键词	故障管理故障
章/节	系统运行管理知识

从在故障监视过程中发现故障，到（60）以及对故障分析定位，之后进行故障支持和恢复处理，最后进行故障排除终止，故障管理形成了包含5项基本活动的完整流程。

A. 故障记录

B. 故障追踪

C. 故障调研

D. 故障判断

相关试题故障及问题管理

第62题

2017年上半年

问题管理和控制的目标主要体现在三点。下列选项中，（）不在问题管理和控制目标的三点内容之列。

第64题

2011年上半年

在系统故障与问题管理中，问题预防的流程主要包括趋势分析和（64）。

第63题

2018年上半年

在故障管理中，有三个描述故障的特征，下列（）不属于这三个特征。

知识点讲解

· 故障管理

· 故障管理流程

· 故障监视

· 故障支持和恢复处理

· 故障分析

· 恢复

故障管理

负责监测、日志、通告用户，（一定程度上可能）自动解决网络问题，以确保网络的高效运行，这是因为故障可能引起停机时间或网络退化等。故障管理在ISO网络管理单元中是使用最为广泛的一个部分。含盖了诸如检测、隔离、确定故障因素、纠正网络故障等功能。设立故障管理的目标是提高网络可用性，降低网络停机次数并迅速修复故障。典型的故障管理系统遵循以下步骤：

故障管理流程

从在故障监视过程中发现故障到对故障信息地调研，再到故障的恢复处理和故障排除，形成了一个完整的故障管理流程。故障管理即包含了故障监视、故障调研、故障支持和恢复以及故障终止5项基本活动，为了实现对故障流程完善的管理，需要对故障管理的整个流程进行跟踪，并做出相应处理记录。故障管理的流程如下图所示。

故障管理流程

故障监视

故障管理流程的第一项基础活动是故障监视，大多数故障都是从故障监视活动中发现的。

监视的考虑因素

不同的系统故障有不同的特征，对系统和整个组织或者企业的业务影响程度可能不同，处理解决的难易度也不同。在进行故障监视时要充分考虑故障的影响度、紧迫性，对影响较大的故障类别进行重点监视，采用更先进的自动化监视管理工具，启动更多的系统监视功能，或者投入更多的人力和物力。这样，在相关部门（服务台、系统本身、用户或者其他IT部门）发现故障时，才能尽快根据影响度设置故障处理优先级，尽快进入管理流程。

故障接触人员

故障接触人员在故障监视的过程中有着重要的影响和作用。为了在监视过程中尽快发现和应对故障，同时防止非规范操作扩大故障对系统和业务的影响，需要对故障的接触人员进行严格管理，故障监视应该针对不同的故障接触人员指定监视职责，制定相关操作手册，而故障接触人员应该严格按照规定执行操作和报告。同时，故障接触人员本身及其活动也应当作为监视的项目。故障接触人员如下。

（1）故障现场接触人员，在故障发生的现场的接触人员包括系统运行值班人员、系统用户，还可能包括服务台。

（2）初级支持人员，为故障提供一线的初级支持的有服务台和初级支持小组。

（3）高级支持人员，故障处理专家小组或者提供系统服务的厂商技术专家。

故障原因分类

美国权威市场调查机构Gartner Group曾对造成非计划宕机的故障原因进行分析，并发表了专门报告，主要可以分成以下三大类。

.技术因素，包括硬件、操作软件系统、环境因素以及灾难性事故。

.应用性故障，包括性能问题、应用缺陷（bug）及系统应用变更。

.操作故障，人为地未进行必要的操作或进行了错误操作。

为了便于实际操作中的监视设置，我们将导致IT系统服务中断的因素由三类扩展成了7类。

.按计划的硬件、操作系统的维护操作时引起的故障，如增加硬盘和进行操作系统补丁等。

.应用性故障，包括应用软件的性能问题、应用缺陷（bug）及系统应用变更等。

.人为操作故障，包括人员的误操作和不按规定的非标准操作引起的故障。

.系统软件故障，包括操作系统死机、数据库的各类故障等。

.硬件故障，如硬盘或网卡损坏等。

.相关设备故障，比如停电时UPS失效导致服务中断。

.自然灾害，如火灾，地震和洪水，等等。

从这7个分类我们可以看出，导致系统服务中断的原因中，软件和人为操作因素占了很大的比例，硬件和设备因素只占很小的比例。

监视项目及监视方法

从以上对故障的原因归类来看，人员、规范操作的执行、硬件和软件是故障监视的重点所在。另外，自然灾害因素由于难以预计和控制，需要进行相关风险分析，可采取容灾防范措施来应对。

（1）对系统硬件及设备的监视包括各主机服务器及其主要部件、专门的存储设备、网络交换机、路由器，等等。对硬件设备监控方法主要是采用通用或者专用的管理监控工具，它们通常具有自动监测、跟踪和报警的功能。

（2）对软件的监视主要针对其应用性能、软件bug和变更需求。对软件的性能监控也可以采一些管理监控工具，但由于应用系统主要面向用户，应用系统的缺陷通常由专门的测试工程师负责监视，或者在使用的过程中由用户方发现并提出。变更需求也是在用户使用和监视二合一的过程中发现的。

（3）需要监视的人员包括系统操作员、系统开发工程师、用户、来访者，甚至包括系统所在机房的清洁工和运输公司的职工，等等。要对他们与系统的接触过程中的行为进行跟踪和记录，防止或者及早发现非标准的操作带来的系统故障或者服务故障。

故障调研

故障信息搜集

如下图所示，故障信息的来源有服务台、系统、用户和其他IT部门。这些信息的搜集方式又分为自动搜集和人工搜集。通常系统本身有相应的故障信息搜集功能，可以通过专门的系统监控软件或者系统日志等方式进行自动搜集。另外，系统运行过程中出现的故障会直接反映在系统的用户一方，或者由相关IT部门在执行系统检查和维护时发现，这类故障信息的搜集方式便属于人工搜集。

故障查明和记录

发生故障时服务台要记录相关信息，但主要是标示客户和用户的一些基本信息如姓名、工作地点和电话号码等，而本节所讲的故障管理才详细记录了故障信息，比如故障发生的时间、故障影响到的服务等。这样做的目的一是便于确认故障影响，二是问题管理可以根据这些信息查找故障原因，三是密切跟踪故障进展。此外，这些信息也是服务级别管理所需要的。

一般来说故障查明和记录活动过程如下图所示。

故障查明和记录

首先，当用户、服务台员工和其他IT部门人员发现某故障时，或者系统检测到某故障时，就将其报告给服务台；服务台将基本信息输入故障数据库并报告给故障处理人员。

接着故障管理人员根据服务台提供的信息和故障数据库信息，判断此故障是否与已有故障相同或相似，如果有就更新故障信息和建立原故障的从属记录，并在必要时修改原故障的影响度和优先级，如果没有则创建新故障记录。

其次，故障管理将给故障一个唯一的编号，记录一些基本的故障分析信息（时间、症状、位置、用户和受影响的服务和硬件等），并补充其他故障信息（与用户的交互信息和配置数据等）。

最后，故障管理需要判断故障是否严重，如果严重就先向管理层报告并告知用户有关情况，再采取进一步行动；如果不严重就直接进入下一步的故障调查和分析。

完整的故障记录应该至少包括以下几项。

.故障编号。

.故障类别。

.记录故障的时间和日期。

.故障记录人（或组）的姓名（或ID）。

.有关用户的姓名、部门、电话和工作地点。

.回复用户的方式（如电话、电子电子邮件等）。

.故障描述。

.目录。

.影响度、紧迫性和优先级。

.故障状态（待处理中、处理中和终止等）。

.相关的配置信息。

.故障得到解决的日期和时间。

.终止日期和时间。

随着现代技术的发展，现在的故障监测和报告已可由系统自动完成，故障报告的方式和途径也日趋多样化，甚至用户自己都能直接把故障有关情况记录在故障管理系统中，同时通知故障台有关情况。

故障支持和恢复处理

经过故障查明和记录，基本上能得到可以获取的故障信息，接下来就是故障的初步支持。这里强调初步的目的是为了能够尽可能快地恢复用户的正常工作，尽量避免或者减少故障对系统服务的影响。

“初步”包括两层含义：一是根据已有的知识和经验对故障的性质进行大概划分，以便采取相应的措施；二是这里采取的措施和行动不以根本上解决故障为目标，主要目的是维持系统的持续运行，如果不能较快找到解决方案，故障处理小组就要尽量找到临时性的解决办法。

不能通过初步支持来解决的故障在经过故障调查和定位分析后，支持小组会根据更新后的故障信息、提议的权益措施和解决方案以及有关的变更请求，来解决故障并恢复服务，同时更新有关故障信息。

故障分析和定位

故障调查分析

故障的调查分析这一步骤是在故障经由初步支持没有得到解决时进行的。故障的调查分析过程如下图所示。

故障调查过程

一旦故障被分配给某个支持小组，他们应当做好如下工作。

.确认接收故障处理任务，同时指定有关日期和时间。

.正常更新故障状态和历史信息。

.通知客户故障最新进展。

.说明故障当前所处的状态。

.尽可能快地把发现的权益措施提供给服务台和客户。

.参考已知错误、问题、解决方案、计划的变更和知识库等对故障进行评审。

.必要时要求服务台根据协议的服务级别，重新评价故障影响程度和优先级，并在必要时对他们进行调整。

.记录所有相关信息，包括以下内容。

. 解决方案。

. 新增的和修改的分类。

. 对所有相关事件的更新。

. 花费的时间。

.把故障处理责任反馈给服务台以终止故障。

故障定位分析

系统故障中硬件和各类设备的故障定位过程比较典型，下面就主要的硬件故障举例说明故障的定位分析。

（1）中央处理器的故障定位。中央处理器的故障原因主要是集成电路失效。计算机系统均应配备较完善的诊断测试手段，提供详细的故障维修指南，对大部分故障可以实现准确定位。但由于集成电路组装密度很高，一个集成电路芯片包含的逻辑单元和存储单元数以百万计，诊断测试程序检测出的故障通常定位于一个电路模块和一个乃至几个电路卡，维护人员根据测试结果可能在现场进行的维修工作就是更换电路卡。如现场没有相应的备份配件，可以采取降级运行（如多处理机系统可切除故障的处理机，存储器可切除部分有扩展单元等）的手段使系统保持联系运行，如没有补救手段则需要进行停机检修。

（2）外围设备的故障定位。对外围设备的故障检测应采用脱机检测与联机检测两种方式。脱机检测是指外围设备在逻辑上与中央处理机脱离联系（必要时也脱离物理连接）的情况下，对不同外围设备运行特定的测试程序，进行不含接口部分的功能测试，借助设备的面板或专用测试器显示的信息并参阅维修手册来判断故障所在的部位。外围设备的故障有一类是集成电路失效，可通过更换电路卡排除。第一类是各种外设的特殊故障，常见的如磁盘盘面损伤、读写磁头位置偏离或其运载机构不能正常运动、打印机的打印部位损坏或打印纸传递机构故障等，需根据具体情况进行维修。如脱机测试正常而联机却不能正常运行，则应进行针对该设备的联机测试，运行相应的测试程序，测试该设备与中央处理机的接口部位并检验两者之间的协调关系。必要时还可进行摸拟环路测试，即将外围设备至主机之间的输入输出连线构成回路，以确认故障所在部位是否在接口电路。

（3）电源部件的故障定位。计算机硬件中的各个部分均有专用的电源部件，电源部件中有一部分是大功率的器件，故障率较高，是硬件中常见的故障部位。在检测中央处理器及各种外围设备时，如发现工作异常，应充分注意到电源部件是可能发生故障的主要部位。

故障终止

解决故障和恢复服务后，就到故障终止阶段了。在这个阶段的输入是上一阶段更新后的故障记录和已解决的故障，采取的行动主要是和客户一起确认故障是否被成功解决，输出的结果为更新的故障信息和故障记录。

在故障得到解决后，服务台应该确保以下工作

.有关用于解决故障的行动的信息是准确易懂的。

.根据故障产生的根本原因对其进行归类。

.客户口头同意故障解决方案和方案执行的最终结果。

.详细记录了故障控制阶段的所有相关信息，比如：

. 客户是否满意和满意度如何。

. 处理故障所花费的时间。

. 故障终止的日期和时间。

故障处理跟踪

服务台负责跟踪和监督所有故障的解决过程。在这个过程中，服务台要做到以下几点。

.监督故障状态和故障处理最新进展及其影响服务级别的状况。

.特别要注意故障处理责任在不同专家组之间的转移。因为这种转移往往导致支持人员之间责任的不确定性从而产生争论。

.更多地注意高影响度故障。

.及时通知受影响的用户关于故障处理的最新进展。

.检查相似的故障。

这样做有助于保证每个故障在规定的时间内或至少尽可能快的时间内得到解决。大规模的服务台甚至可以考虑成立一个专门的故障监测和控制小组。

故障监视

故障管理流程的第一项基础活动是故障监视，大多数故障都是从故障监视活动中发现的。

监视的考虑因素

故障接触人员

（1）故障现场接触人员，在故障发生的现场的接触人员包括系统运行值班人员、系统用户，还可能包括服务台。

（2）初级支持人员，为故障提供一线的初级支持的有服务台和初级支持小组。

（3）高级支持人员，故障处理专家小组或者提供系统服务的厂商技术专家。

故障原因分类

美国权威市场调查机构Gartner Group曾对造成非计划宕机的故障原因进行分析，并发表了专门报告，主要可以分成以下三大类。

.技术因素，包括硬件、操作软件系统、环境因素以及灾难性事故。

.应用性故障，包括性能问题、应用缺陷（bug）及系统应用变更。

.操作故障，人为地未进行必要的操作或进行了错误操作。

为了便于实际操作中的监视设置，我们将导致IT系统服务中断的因素由三类扩展成了7类。

.按计划的硬件、操作系统的维护操作时引起的故障，如增加硬盘和进行操作系统补丁等。

.应用性故障，包括应用软件的性能问题、应用缺陷（bug）及系统应用变更等。

.人为操作故障，包括人员的误操作和不按规定的非标准操作引起的故障。

.系统软件故障，包括操作系统死机、数据库的各类故障等。

.硬件故障，如硬盘或网卡损坏等。

.相关设备故障，比如停电时UPS失效导致服务中断。

.自然灾害，如火灾，地震和洪水，等等。

从这7个分类我们可以看出，导致系统服务中断的原因中，软件和人为操作因素占了很大的比例，硬件和设备因素只占很小的比例。

监视项目及监视方法

故障支持和恢复处理

故障分析

这里主要讨论故障分析内容以及优化调整设置内容，同时还与读者分享故障分析的经验与实例。

故障分析重点内容

故障分析的重点内容包括以下几个方面：

①CPU问题。

②内存和高速缓存。

③磁盘（I/O）资源问题。

④配置参数。

⑤应用系统网络设置。

⑥数据库服务器故障定位。

经验探讨

. 经验举例1。

交易的响应时间如果很长，远远超过系统性能的需求，表示耗费CPU的数据库操作。例如排序，执行aggregate functions（例如sum、min、max、count）等较多，可考虑是否有索引以及索引建立得是否合理。尽量使用简单的表链接、水平分割大表格等方法来降低该值。

. 经验举例2。

测试工具可以模拟不同的虚拟用户来单独访问Web服务器、应用服务器和数据库服务器，这样，就可以在Web端测出的响应时间减去以上各个分段测出的时间，就可以知道瓶颈在哪里并着手调优。

. 经验举例3。

UNIX资源监控（NT操作系统同理）中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈，也可能是内存访问命中率低。“Swap in rate”和“Swap out rate”也有类似的解释。

. 经验举例4。

UNIX资源监控（NT操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。合理使用的范围在60%～70%。

. 经验举例5。

Tuxedo资源监控中指标队列中的字节数（Bytes on queue），队列长度应不超过磁盘数的1.5～2倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘。

. 经验举例6。

SQL Server资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。注意该参数值是从SQL Server启动后，就一直累加记数，所以运行经过一段时间后，该值将不能反映系统当前值。

优化调整设置

针对上述故障分析的重点内容，需要做相应的优化调整，建议如下。

. CPU问题。

①考虑使用更高级的CPU代替目前的CPU；

②对于多CPU，考虑CPU之间的负载分配；

③考虑在其他体系上设计系统，例如增加前置机、设置并行服务器等。

. 内存和高速缓存。

①内存的优化包括操作系统、数据库、应用程序的内存优化；

②过多的分页与交换可能降低系统的性能；

③内存分配也是影响系统性能的主要原因；

④保证保留列表具有较大的邻接内存块；

⑤调整数据块缓冲区大小（用数据块的个数表示）是一个重要内容；

⑥将最频繁使用的数据保存在存储区中。

. 磁盘（I/O）资源问题。

①磁盘读写进度对数据库系统是至关重要的，数据库对象在物理设备上的合理分布能改善性能。

②磁盘镜像会减慢磁盘写的速度。

③通过把日志和数据库对象分布在独立的设备上，可以提高系统的性能。

④把不同的数据库放在不同的硬盘上，可以提高读写速度。建议把数据库、回滚段、日志放在不同的设备上。

⑤把表放在一块硬盘上，把非簇的索引放在另一块硬盘上，保证物理读写更快。

. 调整配置参数。

①包括操作系统和数据库的参数配置。

②并行操作资源限制的参数（并发用户的数目、会话数）。

③影响资源开销的参数。

④与I/O有关的参数。

. 优化应用系统网络设置。

①可以通过数组接口来减少网络呼叫。不是一次提取一行，而是在单个往来往返中提取10行，这样做效率较高。

②调整会话数据单元的缓冲区大小。

③共享服务进程比专用服务进程提供更好的性能。

负载压力典型问题分析

负载压力测试需要识别的故障问题主要包括：

. 非正确执行的处理。

. 速度瓶颈与延迟。

. 不能达到满意服务水平。

. 接口页面不能正确地装载或者根本不能装载。

当在合理的加载下出现这些类型的问题时，则表示可能有基础性的设计问题，比如说：算法问题，低效的数据库应用程序交互作用等，这些都不是通过简单升级硬件以及调整系统配置就可以解决的问题，此时软件的故障定位和调优将占有更重要的地位。

Web网站故障分析举例

目前Web开发者开始提供可定制的Web网站，例如，像搜索数据之类的任务，现在可以由服务器执行，而无需客户干预。然而，这些变革也导致了一个结果，这就是许多网站都在使用大量的未经优化的数据库调用，从而使得应用性能大打折扣。

我们可以使用以下几种方法来解决这些问题：

. 优化ASP代码。

. 优化数据库调用。

. 使用存储过程。

. 调整服务器性能。

优秀的网站设计都会关注这些问题。然而，与静态页面的速度相比，任何数据库调用都会显著地影响Web网站的响应速度，这主要是因为在发送页面之前必须单独地为每个访问网站的用户进行数据库调用。

这里提出的性能优化方案正是基于以下事实：访问静态HTML页面要比访问那些内容依赖于数据库调用的页面要快。它的基本思想是：在用户访问页面之前，预先从数据库提取信息，写入存储在服务器上的静态HTML页面。为了保证这些静态页面能够及时地反映不断变化的数据库数据，必须有一个调度程序管理静态页面的生成。

当然，这种方案并不能够适应所有的情形。例如，如果是从持续变化的大容量数据库提取少量信息，这种方案是不合适的。

每当该页面被调用时，脚本就会提取最后的更新时间并将它与当前时间比较。如果两个时间之间的差值大于预定的数值，更新脚本就会运行，否则，该ASP页面把余下的HTML代码发送给浏览器。

如果每次访问ASP页面的时候都要提供最新的信息，或者输出与用户输入密切相关，这种方法并不实用，但这种方法可以适应以固定的时间间隔更新信息的场合。

如果数据库内容由客户通过适当的ASP页面更新，要确保静态页面也能够自动反映数据的变化，我们可以在ASP页面中调用Update脚本。这样，每当数据库内容改变时，服务器上也有了最新的静态HTML页面。

另一种处理频繁变动数据的办法是借助Microsoft SQL Server 7.0或以上版本的Web助手向导（Web Assistant Wizard），这个向导能够利用Transact-SQL、存储过程等从SQL Server数据生成标准的HTML文件。

Web助手向导能够用来定期地生成HTML页面。正如前面概要介绍的方案，Web助手可以通过触发子更新HTML页面，比如在指定的时间执行更新或者在数据库数据变化时执行更新。

SQL Server使用名为sp_makewebtask的存储过程创建HTML页面，它的参数是目标HTML文件的名字和待执行存储过程的名字，查询的输出发送到HTML页面。另外，也可以选择使用可供结果数据插入的模板文件。

万一用户访问页面的时候正好在执行更新，我们可以利用锁或者其他类似的机制把页面延迟几秒钟。

我们对纯HTML加调度ASP代码和普通的ASP文件进行了性能测试。普通的ASP文件要查找5个不同的表为页面提取数据。为了和这两个文件相比较，对一个只访问单个表的ASP页面和一个纯HTML文件也进行了测试。测试结果如下表所示。

加调度ASP代码和普通ASP代码测试对比

其中TTFB是指“Total Time to First Byte”, TTLB是指“Total Time to Last Byte”。

测试结果显示，访问单个表的ASP页面的处理时间是720.5ms，而纯HTML文件则为427ms。普通的ASP文件和纯HTML加调度ASP代码的输出时间相同，但它们的处理时间分别为3633.67ms和1590ms。也就是说，在这个测试环境下我们可以把处理速度提高43%。

如果我们要让页面每隔一定的访问次数进行更新，比如100次，那么这第100个用户就必须等待新的HTML页面生成。不过，这个代价或许不算太高，其他99个用户获得了好处。

静态页面方法并不能够适合所有类型的页面。例如，某些页面在进行任何处理之前必须要有用户输入。但是，这种方法可以成功地应用到那些不依赖用户输入却进行大量数据库调用的页面，而且这种情况下它将发挥出更大的效率。

在大多数情况下，动态页面的生成将在相当大的程度上提高网站的性能，而且无须在功能上有所折衷。虽然有许多大的网站采用了这个策略来改善性能，但也有许多网站完全由于进行大量没有必要的数据库调用，而表现出很差的性能。

恢复

数据恢复有3个步骤。

（1）反向扫描文件日志，查找该事务的更新操作。

（2）对事务的更新操作执行逆操作。

（3）继续反向扫描日志文件，查找该事务的其他更新操作，并做同样的处理，直到事务的开始标志。

更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5