|
|
|
从在故障监视过程中发现故障到对故障信息地调研，再到故障的恢复处理和故障排除，形成了一个完整的故障管理流程。故障管理即包含了故障监视、故障调研、故障支持和恢复以及故障终止5项基本活动，为了实现对故障流程完善的管理，需要对故障管理的整个流程进行跟踪，并做出相应处理记录。故障管理的流程如下图所示。
|
|
|
|
|
|
|
|
|
|
故障管理流程的第一项基础活动是故障监视，大多数故障都是从故障监视活动中发现的。
|
|
|
|
|
|
不同的系统故障有不同的特征，对系统和整个组织或者企业的业务影响程度可能不同，处理解决的难易度也不同。在进行故障监视时要充分考虑故障的影响度、紧迫性，对影响较大的故障类别进行重点监视，采用更先进的自动化监视管理工具，启动更多的系统监视功能，或者投入更多的人力和物力。这样，在相关部门（服务台、系统本身、用户或者其他IT部门）发现故障时，才能尽快根据影响度设置故障处理优先级，尽快进入管理流程。
|
|
|
|
|
|
故障接触人员在故障监视的过程中有着重要的影响和作用。为了在监视过程中尽快发现和应对故障，同时防止非规范操作扩大故障对系统和业务的影响，需要对故障的接触人员进行严格管理，故障监视应该针对不同的故障接触人员指定监视职责，制定相关操作手册，而故障接触人员应该严格按照规定执行操作和报告。同时，故障接触人员本身及其活动也应当作为监视的项目。故障接触人员如下。
|
|
|
|
（1）故障现场接触人员，在故障发生的现场的接触人员包括系统运行值班人员、系统用户，还可能包括服务台。
|
|
|
|
（2）初级支持人员，为故障提供一线的初级支持的有服务台和初级支持小组。
|
|
|
|
（3）高级支持人员，故障处理专家小组或者提供系统服务的厂商技术专家。
|
|
|
|
|
|
美国权威市场调查机构Gartner Group曾对造成非计划宕机的故障原因进行分析，并发表了专门报告，主要可以分成以下三大类。
|
|
|
|
.技术因素，包括硬件、操作软件系统、环境因素以及灾难性事故。
|
|
|
|
.应用性故障，包括性能问题、应用缺陷（bug）及系统应用变更。
|
|
|
|
.操作故障，人为地未进行必要的操作或进行了错误操作。
|
|
|
|
为了便于实际操作中的监视设置，我们将导致IT系统服务中断的因素由三类扩展成了7类。
|
|
|
|
.按计划的硬件、操作系统的维护操作时引起的故障，如增加硬盘和进行操作系统补丁等。
|
|
|
|
.应用性故障，包括应用软件的性能问题、应用缺陷（bug）及系统应用变更等。
|
|
|
|
.人为操作故障，包括人员的误操作和不按规定的非标准操作引起的故障。
|
|
|
|
.系统软件故障，包括操作系统死机、数据库的各类故障等。
|
|
|
|
|
|
.相关设备故障，比如停电时UPS失效导致服务中断。
|
|
|
|
|
|
从这7个分类我们可以看出，导致系统服务中断的原因中，软件和人为操作因素占了很大的比例，硬件和设备因素只占很小的比例。
|
|
|
|
|
|
从以上对故障的原因归类来看，人员、规范操作的执行、硬件和软件是故障监视的重点所在。另外，自然灾害因素由于难以预计和控制，需要进行相关风险分析，可采取容灾防范措施来应对。
|
|
|
|
（1）对系统硬件及设备的监视包括各主机服务器及其主要部件、专门的存储设备、网络交换机、路由器，等等。对硬件设备监控方法主要是采用通用或者专用的管理监控工具，它们通常具有自动监测、跟踪和报警的功能。
|
|
|
|
（2）对软件的监视主要针对其应用性能、软件bug和变更需求。对软件的性能监控也可以采一些管理监控工具，但由于应用系统主要面向用户，应用系统的缺陷通常由专门的测试工程师负责监视，或者在使用的过程中由用户方发现并提出。变更需求也是在用户使用和监视二合一的过程中发现的。
|
|
|
|
（3）需要监视的人员包括系统操作员、系统开发工程师、用户、来访者，甚至包括系统所在机房的清洁工和运输公司的职工，等等。要对他们与系统的接触过程中的行为进行跟踪和记录，防止或者及早发现非标准的操作带来的系统故障或者服务故障。
|
|
|
|
|
|
|
|
如下图所示，故障信息的来源有服务台、系统、用户和其他IT部门。这些信息的搜集方式又分为自动搜集和人工搜集。通常系统本身有相应的故障信息搜集功能，可以通过专门的系统监控软件或者系统日志等方式进行自动搜集。另外，系统运行过程中出现的故障会直接反映在系统的用户一方，或者由相关IT部门在执行系统检查和维护时发现，这类故障信息的搜集方式便属于人工搜集。
|
|
|
|
|
|
发生故障时服务台要记录相关信息，但主要是标示客户和用户的一些基本信息如姓名、工作地点和电话号码等，而本节所讲的故障管理才详细记录了故障信息，比如故障发生的时间、故障影响到的服务等。这样做的目的一是便于确认故障影响，二是问题管理可以根据这些信息查找故障原因，三是密切跟踪故障进展。此外，这些信息也是服务级别管理所需要的。
|
|
|
|
|
|
|
|
|
|
首先，当用户、服务台员工和其他IT部门人员发现某故障时，或者系统检测到某故障时，就将其报告给服务台；服务台将基本信息输入故障数据库并报告给故障处理人员。
|
|
|
|
接着故障管理人员根据服务台提供的信息和故障数据库信息，判断此故障是否与已有故障相同或相似，如果有就更新故障信息和建立原故障的从属记录，并在必要时修改原故障的影响度和优先级，如果没有则创建新故障记录。
|
|
|
|
其次，故障管理将给故障一个唯一的编号，记录一些基本的故障分析信息（时间、症状、位置、用户和受影响的服务和硬件等），并补充其他故障信息（与用户的交互信息和配置数据等）。
|
|
|
|
最后，故障管理需要判断故障是否严重，如果严重就先向管理层报告并告知用户有关情况，再采取进一步行动；如果不严重就直接进入下一步的故障调查和分析。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
随着现代技术的发展，现在的故障监测和报告已可由系统自动完成，故障报告的方式和途径也日趋多样化，甚至用户自己都能直接把故障有关情况记录在故障管理系统中，同时通知故障台有关情况。
|
|
|
|
|
|
经过故障查明和记录，基本上能得到可以获取的故障信息，接下来就是故障的初步支持。这里强调初步的目的是为了能够尽可能快地恢复用户的正常工作，尽量避免或者减少故障对系统服务的影响。
|
|
|
|
“初步”包括两层含义：一是根据已有的知识和经验对故障的性质进行大概划分，以便采取相应的措施；二是这里采取的措施和行动不以根本上解决故障为目标，主要目的是维持系统的持续运行，如果不能较快找到解决方案，故障处理小组就要尽量找到临时性的解决办法。
|
|
|
|
不能通过初步支持来解决的故障在经过故障调查和定位分析后，支持小组会根据更新后的故障信息、提议的权益措施和解决方案以及有关的变更请求，来解决故障并恢复服务，同时更新有关故障信息。
|
|
|
|
|
|
|
|
故障的调查分析这一步骤是在故障经由初步支持没有得到解决时进行的。故障的调查分析过程如下图所示。
|
|
|
|
|
|
|
|
一旦故障被分配给某个支持小组，他们应当做好如下工作。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.参考已知错误、问题、解决方案、计划的变更和知识库等对故障进行评审。
|
|
|
|
.必要时要求服务台根据协议的服务级别，重新评价故障影响程度和优先级，并在必要时对他们进行调整。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
系统故障中硬件和各类设备的故障定位过程比较典型，下面就主要的硬件故障举例说明故障的定位分析。
|
|
|
|
（1）中央处理器的故障定位。中央处理器的故障原因主要是集成电路失效。计算机系统均应配备较完善的诊断测试手段，提供详细的故障维修指南，对大部分故障可以实现准确定位。但由于集成电路组装密度很高，一个集成电路芯片包含的逻辑单元和存储单元数以百万计，诊断测试程序检测出的故障通常定位于一个电路模块和一个乃至几个电路卡，维护人员根据测试结果可能在现场进行的维修工作就是更换电路卡。如现场没有相应的备份配件，可以采取降级运行（如多处理机系统可切除故障的处理机，存储器可切除部分有扩展单元等）的手段使系统保持联系运行，如没有补救手段则需要进行停机检修。
|
|
|
|
（2）外围设备的故障定位。对外围设备的故障检测应采用脱机检测与联机检测两种方式。脱机检测是指外围设备在逻辑上与中央处理机脱离联系（必要时也脱离物理连接）的情况下，对不同外围设备运行特定的测试程序，进行不含接口部分的功能测试，借助设备的面板或专用测试器显示的信息并参阅维修手册来判断故障所在的部位。外围设备的故障有一类是集成电路失效，可通过更换电路卡排除。第一类是各种外设的特殊故障，常见的如磁盘盘面损伤、读写磁头位置偏离或其运载机构不能正常运动、打印机的打印部位损坏或打印纸传递机构故障等，需根据具体情况进行维修。如脱机测试正常而联机却不能正常运行，则应进行针对该设备的联机测试，运行相应的测试程序，测试该设备与中央处理机的接口部位并检验两者之间的协调关系。必要时还可进行摸拟环路测试，即将外围设备至主机之间的输入输出连线构成回路，以确认故障所在部位是否在接口电路。
|
|
|
|
（3）电源部件的故障定位。计算机硬件中的各个部分均有专用的电源部件，电源部件中有一部分是大功率的器件，故障率较高，是硬件中常见的故障部位。在检测中央处理器及各种外围设备时，如发现工作异常，应充分注意到电源部件是可能发生故障的主要部位。
|
|
|
|
|
|
解决故障和恢复服务后，就到故障终止阶段了。在这个阶段的输入是上一阶段更新后的故障记录和已解决的故障，采取的行动主要是和客户一起确认故障是否被成功解决，输出的结果为更新的故障信息和故障记录。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
服务台负责跟踪和监督所有故障的解决过程。在这个过程中，服务台要做到以下几点。
|
|
|
|
.监督故障状态和故障处理最新进展及其影响服务级别的状况。
|
|
|
|
.特别要注意故障处理责任在不同专家组之间的转移。因为这种转移往往导致支持人员之间责任的不确定性从而产生争论。
|
|
|
|
|
|
|
|
|
|
这样做有助于保证每个故障在规定的时间内或至少尽可能快的时间内得到解决。大规模的服务台甚至可以考虑成立一个专门的故障监测和控制小组。
|
|
|
