信息系统交付使用后，如何最大限度保障其安全、稳定和可靠地运行就成了信息系统运维的中心工作。而组织对信息系统运维组织与管理工作的必要性和重要性认识不足主要表现为：一是仅从硬件故障的角度考虑运维问题；二是信息应用意识不强；三是缺乏科学规范的运维管理体系，信息系统运维处于无序状态。

本章首先介绍信息系统运维管理，包括管理目标、运维管理主体、运维管理工具、运维管理对象、运维管理制度、运维管理流程和运维管理职能等；接着分析信息系统运维的组织，包括任务、管理职责、人员管理等；然后讨论信息系统运维外包的概念、模式、内容、阶段、方式和风险；最后简要介绍信息系统运维管理的标准。

2.1 信息系统运维管理

信息系统运维管理是指信息系统运维管理主体依据各种管理标准、管理制度和管理规范，利用运维管理系统和管理工具，实施事件管理、问题管理、配置管理、变更管理、发布管理和知识管理等信息系统运维管理流程，对信息系统运维部门、运维人员、信息系统用户、信息系统软硬件和信息技术基础设施进行综合管理，执行硬件运维、软件运维、网络运维、数据运维和安全运维等信息系统运维的管理职能，以实现信息系统运维标准化和规范化，满足组织信息系统运维的需求。

2.1.1 信息系统运维管理框架

信息系统运维管理包括运维管理主体、运维管理工具、运维管理对象、运维管理制度、运维管理流程和运维管理职能等，信息系统运维管理框架如图2-1所示。

1.信息系统运维管理目标

信息系统运维管理的目标包括多个方面，首先是信息系统的目标，即保证信息系统安全、稳定、可靠运行，保证信息系统持续满足组织的需求；其次是流程管理的目标，即实现信息系统运维流程的标准化和规范化，实现信息系统运维工作的集中管理、集中维护、集中监控；最后是成本目标，即控制信息系统运维的成本，包括咨询顾问的人力成本、信息系统运维工具的成本和信息系统运维人员的培训成本等。

2.信息系统运维管理主体

信息系统运维管理的主体是指掌握信息运维管理权力，承担运维管理责任，决定运维管理方向和流程的有关部门和人员，包括信息系统运维管理者、信息系统运维管理部门和信息系统运维外包商。

3.信息系统运维管理对象

信息系统运维管理对象即信息系统运维管理客体，是指信息系统运维管理主体直接作用和影响的对象，包括信息系统运维部门和人员、信息系统供应商、信息系统用户、信息系统软硬件和信息技术基础设施等。

4.信息系统运维管理职能

信息系统运维管理职能是指在信息系统运维管理过程中各项行为内容的概括，是对信息系统运维管理工作一般过程和基本内容所做的理论概括。根据信息运维管理工作的内在逻辑，可以将信息系统运维划分为设施运维、软件运维、数据运维和安全运维等职能。

5.信息系统运维管理流程

信息系统运维管理流程是指为了支持信息系统运维的标准化和规范化，以确定的方式执行或发生的一系列有规律的行动或活动，包括事件管理、事故管理、问题管理、配置管理、变更管理、发布管理和知识管理等。

6.信息系统运维管理工具

信息系统运维管理工具是指用于执行信息系统运维管理工作的运维管理系统和软件，包括外包管理、综合管理、流程管理、安全管理、监控管理和资产管理等工具。

7.信息系统运维管理制度

在信息系统运维过程中，需要建立一整套科学的管理制度、管理标准和管理规范，如信息系统硬件管理制度、信息系统软件管理制度、数据资源管理制度等，以保障信息系统运维工作的标准化和规范化。完善的信息系统运维管理，不仅是运维体系稳定运行的根本保证，同时也是实现运维管理人员按章有序地进行信息系统运维，减少运维中不确定因素，提高工作质量和水平的重要保障。

2.1.2 信息系统运维管理主要流程

作为信息系统服务的一种管理方式，当前大部分信息系统运维管理是基于流程框架展开的。这里的流程是指信息系统运维管理的各种业务过程，运维管理流程将达到以下目标：

（1）标准化：通过流程框架，构建标准的运维流程。

（2）流程化：将大部分运维工作流程化，确保工作可重复，并且这些工作都能有质量地完成，提升运维工作效率。

（3）自动化：基于流程框架将事件与运维管理流程相关联，一旦被监控的系统发生性能超标或宕机，会触发相关事件及事先定义好的流程，可自动启动故障响应和恢复机制；此外，还可以通过自动化手段（工具）有效完成日常工作，如逻辑网络拓扑图、硬件备份等。

信息系统运维管理流程主要包括事件管理、事故管理、问题管理、配置管理、变更管理、发布管理和知识管理等，如图2-2所示。

1.事件管理

信息系统运维事件管理负责记录、快速处理信息系统运维管理中的突发事件，并对事件进行分类分级，详细记录事件处理的全过程，便于跟踪了解事件的整个处理过程，并对事件处理结果统计分析。事件是指引起或有可能引起服务中断或服务质量下降的不符合标准操作的活动，不仅包括软硬件故障，而且包括服务请求，如状态查询、重置口令、数据库导出等，因此又叫事故/服务请求管理。

事件管理流程的主要目标是尽快恢复信息系统正常服务并减少对信息系统的不利影响，尽可能保证最好的质量和可用性，同时记录事件并为其他流程提供支持。事件管理流程通常涉及事件的侦测记录、事件的分类和支持、事件的调查和诊断、事件恢复及事件的关闭。事件管理基本流程模型如图2-3所示。

（1）事件发生和通告。事件发生后，配置项以轮询和通知两种方式产生通告信息，其中轮询是通过管理工具的询问，配置项被动地提供相关信息；而通知是当特定状态满足后，配置项主动产生通告。

（2）事件检测和录入。事件发生后，管理工具通过两种方法对其进行检测，第一种是通过运行在同一系统之上的代理，检测和解析通告信息，并将其发送给管理工具；第二种是管理工具直接读取和解析通告信息的含义。

（3）事件过滤。当检测到事件后，应当对其进行过滤。过滤的目的是确定哪些事件应被通过，哪些事件可以被忽略。例如，连续产生的一系列相同事件通告，只通过第一个到达的通告，其余则可忽略。对于过滤掉的事件应当及时记录到日志文件中。

（4）事件分类。根据事件的重要性，将事件分为信息类、告警类和异常类。信息类事件通常存入日志文件中；告警类事件需要提交给事件关联做进一步分析，以决定如何处理；异常类事件需判定是否需要提交给事故、问题或变更管理中的一个或多个管理流程来处理。

（5）事件关联。事件关联是指通过特定的管理工具将告警类事件与一组事先规定的标准和规则进行比较，从而识别事件的意义并确定相应的事件处理行动。这些标准和规则通常被称为业务准则，说明了事件对业务的影响度、优先级、类别等信息。

（6）响应选择。根据事件关联的结果，可以选择自动响应，报警和人为干预，事故、问题或变更判定等方式处理告警类事件。如果告警类事件及其处理方法已被充分识别和认识，则可以为其定义合适的自动响应方式。如果告警类事件处理需要人为干预，则应该发出报警信息通知相关人员或团队。如果告警类事件处理需要通过事故、问题或变更管理的一个或多个流程完成，则需要启动相应的流程。当初始事件被判定为异常，或是在事件关联中管理工具将一类或一组告警类事件的发生定义为事故时，则应当启动事故管理；在故障尚未发生时，通过对事件进行完备成熟的评估和分析得出问题存在，则直接启动问题管理；当事件被判定为异常时，组织可能依据自身的事故管理和变更管理的策略确定启动哪个流程。

（7）事件关闭。不同类型的事件有不同的关闭形式。信息类事件通常不存在关闭状态，它们会被录入到日志中并作为其他流程的输入，直到日志记录被删除；自动响应的告警类事件通常会被设备或应用程序所自动触发的另一事件关闭；人为干预的告警类事件通常在合适的人员或团队处理完毕评估后关闭；异常类事件通常在成功启动事故、问题或变更管理流程后评估关闭。

（8）事件评估。因为事件发生频率非常高，不可能对每件事件都进行正式的评估活动。如果事件触发了事故、问题或变更管理，评估重点应当关注事件是否被正确移交，并且是否得到了所期待的处理；对于其他事件，则进行抽样评估。

2.事故管理

事故管理流程包括对引起服务中断或可能导致服务中断、质量下降的事件的管理。这包括了用户提交或由监控工具提交的事故。事故管理不包括与中断无关的正常运营指标或服务请求信息。事故管理的主要目标是尽快恢复正常的服务运营，并将对业务的影响降到最低，从而尽可能保证服务质量和可用性要求。

事故管理的流程包括事故识别和记录、事故分类和优先级处理、初步支持、事故升级、调查和诊断、解决和恢复、事故关闭等。事故管理基本流程模型如图2-4所示。

（1）事故识别和记录。通过对所有组件的监控，及时准确地检测出故障或潜在故障，尽可能在未对客户造成影响之前启动事故管理流程。事故记录包含事故基本描述、事故状态、事故类型、事故影响度、事故优先级等信息。

（2）事故分类和优先级处理。事故的分类通常采用多层次结构，一个类别包括多个子类。分类时将事故归入某一类别或某一子类中。分类时可以按事故发生的可能原因分类，也可按相关支持小组进行分类。当同时处理若干事故时，必须设定优先级。优先级通常用数字来表示，通常根据紧急度和影响度确定。其中，紧急度指在解决故障时，对用户或业务来说可接受的耽搁时间；影响度是指就所影响的用户或业务数量和大小而言，事件偏离正常服务级别的程度。

（3）初步支持。初步支持是指服务台在与用户协商并达成解决时限后，依据自己职责和能力优先尝试解决事故。如果用户满意解决结果，则服务台关闭事故；如果无法解决事故或用户不满意，则应执行事故升级，转交给二线或三线支持处理。在初步支持过程中，可借助知识库提供帮助。

（4）事故升级。事故升级是指当前支持人员在规定的时间内不能解决或没有解决某个事故时，便转交给更有经验或更权威的其他人员处理，包括职能性升级和结构性升级两类。职能性升级又称水平升级，是指当前技术人员无法在规定时间内解决事故时，需要具有更多时间、专业技能或访问权限的技术人员参与解决事故；结构性升级又称垂直升级，是指当前机构的级别不足以保证事故能及时、满意地得到解决时，需要更多的高级别机构参与进来。

（5）调查和诊断。事故在提交给指定的支持小组后，支持人员应该对事故进行调查和诊断工作。具体活动包括确定事故发生的位置及用户需要的帮助；确认事故导致的所有影响，包括影响到的用户数量和规模；识别出由此事故触发的其他事件；通过搜索当前事故/问题记录、已知错误数据库、厂商/供应商错误日志或知识库等，整合相关知识。

（6）解决和恢复。通过对事故的调查和诊断，支持人员制定相关解决方案，并在对该方案进行必要的测试之后提交实施。根据事故性质的不同，实施的行为也有所不同，通常包括指导用户在他们的桌面或远程设备上实施解决方案；服务台实施解决方案，或是远程使用软件控制用户桌面实施解决方案；专业的支持小组实施恢复方案；供应商或厂商解决故障。

3.问题管理

问题管理流程包括诊断事故根本原因和确定问题解决方案所需要的活动，通过相应控制过程，确保解决方案的实施。问题管理还将维护有关问题、应急方案和解决方案的信息，以减少事故的数量和降低影响。问题管理流程的目标是通过消除引起事故的深层次根源以预防问题和事故的再次发生，并将未能解决的事故影响降到最低。

问题管理的流程包括问题检测和记录、问题分类和优先级处理、问题调查和诊断、创建已知错误记录、解决问题、关闭问题、重大问题评估等。问题管理基本流程模型如图2-5所示。

（1）问题检测和记录。问题检测的方法包括：服务台和事故管理等提交的事故需要进一步查明潜在原因；技术支持小组在日常维护工作中发现有尚未对业务产生影响的潜在问题存在；自动化的事件/告警检测工具检测出IT基础设施或应用存在问题；供应商或承包商通告其产品或服务存在的问题；主动问题管理通过趋势分析提交潜在的问题。问题记录包含问题描述、问题状态、问题类型、服务信息和设备信息等。

（2）问题分类和优先级处理。问题的分类原则与事故管理中事故的分类相同。问题优先级处理与事故管理中事故的优先级处理方法相同。

（3）问题调查和诊断。问题调查的技术包括借助于配置管理数据库定义问题的影响级别并调查故障点；问题匹配技术和故障重现技术。问题分析和诊断的常用方法包括时序分析法、KT决策法、头脑风暴法、石川图法、帕累托分析法等。

（4）创建已知错误记录。针对调查和诊断的结果及解决方案创建已知错误记录，并将其存放在已知错误库中，以方便下次发生同样问题时能够快速匹配出已知错误。

（5）解决问题。根据制定出的解决方案，问题管理者组织问题处理人员实施方案。如果解决方案需要对基础设施进行变更，则必须首先提交变更请求，启动变更管理流程。

（6）关闭问题。当变更完成并且解决方案成功实施使得问题解决之后，可正式关闭问题记录，更新已知错误库，将问题状态置成“已解决”。

（7）重大问题评估。重大问题解决之后应当召开重大问题评估会议，需探讨的问题包括：工作中的经验和教训、改进方案、预防措施、第三方责任等。

4.配置管理

配置管理的范围包括负责识别、维护服务、系统或产品中的所有组件，以及各组件之间关系的信息，并对其发布和变更进行控制，建立关于服务、资产及基础设施的配置模型。配置管理的目标是对业务和客户的控制目标及需求提供支持；提供正确的配置信息，帮助相关人员在正确的时间做出决策，从而维持高效的服务管理流程；减少由不合适的服务或资产配置导致的质量和适应性问题；实现服务资产、IT配置、IT能力和IT资源的最优化。

配置管理的流程包括管理规划、配置识别、配置控制、状态记录和报告、确认和审核等。配置管理基本流程模型如图2-6所示。

（1）管理规划。确定配置管理流程的政策、标准和战略，分析现有的信息，确定所需要的工具和资源，制定并记录一份总体计划，其内容包括配置管理的目标和范围，识别相关需求，现行适用的政策和标准，组建配置管理小组，设计配置管理数据库（Configuration Management Database，CMDB）、数据存放地点、与其他服务管理系统的接口和界面，以及其他支持工具等，实施配置管理活动的进度和程序，接口控制与关系管理，与第三方的接口控制和关系管理等。

（2）配置识别。配置识别活动是配置管理流程的基础，它确定了配置结构，定义了配置项的选择标准、命名规范、标签、属性、基线、类别及配置项之间关系等方面的内容。

（3）配置控制。配置控制活动负责对新的或变更的配置项记录进行维护，确保配置管理数据库只记录已授权和可识别的配置项，并且其配置记录与现实匹配。配置控制的政策和相关程序包括许可证控制、变更控制、版本控制、访问控制、构建控制、电子数据及信息的移植和升级、配置项在发布前制定基线、部署控制、安装控制等。

（4）状态记录和报告。配置项在其生命周期内有一个或多个离散状态，每一个状态详细信息和数据都应该被记录。记录的细节包括服务配置信息、配置项实施变更的进展及质量保证检测结果等。配置状态报告是指定期报告所有受控的配置项的当前状态及其历史变更信息。

（5）确认和审核。配置确认和审核是指通过一系列评价和审核确认有且只有授权的、注册的、正确的配置项存在于配置管理数据库中的活动，对于监测出的未授权或未注册的配置项应及时通过变更管理登记注册或将其移除。

5.变更管理

变更管理负责管理服务生命周期过程中对配置项的变更。具体对象包括管理环境中与执行、支持及维护相关的硬件、通信设备、软件、运营系统、处理程序、角色、职责及文档记录等。变更管理流程的目标包括对客户业务需求的变化做出快速响应，同时确保价值的最大化，尽可能减少突发事件、中断或返工；对业务和IT的变更请求做出响应，使服务与业务需求相吻合。

变更管理的流程包括创建变更请求、记录和过滤变更请求、评审变更、授权变更、变更规划、协调变更实施、回顾和关闭变更等。变更管理基本流程模型如图2-7所示。

（1）创建变更请求。变更请求（RFC）由变更发起人负责创建并提交给变更管理者。变更请求可能涉及所有的IT部门，任何相关的人都可以提交一项变更请求。变更发起人虽然可能初步为变更分类和设定优先级，但最终的优先级必须在变更管理中确定。

（2）记录和过滤变更请求。变更管理者负责将接收到的变更请求按一套规范的形式记录成RFC文档。具体信息包括RFC标识号、相关联的问题/错误码、变更影响的配置项、变更原因、不实施变更的后果、变更的配置项当前的和新的版本、提交该RFC的人员/部门的信息、提交RFC的时间。

（3）评审变更。在接收到变更请求后，变更管理者、变更咨询委员会成员及IT执行委员会应从财务、技术及业务三方面对其进行审核，以确立变更的风险、影响度、紧急度、成本及利益等。

（4）授权变更。不同类别的变更有不同方式的授权。标准变更通常有预定的执行流程，不需要得到变更咨询委员会（Change Advisory Board，CAB）和变更管理者的授权，而直接转交“请求实现”处理；次要变更无须提交CAB而直接由变更管理者批准实施；针对实质性变更，变更管理者根据变更风险、紧急度和影响度来决定是否事先征求CAB成员的意见或召开CAB会议；重大变更必须事先得到IT执行委员会的评审，再交由CAB讨论具体实施方案。

（5）变更规划。得到变更授权后，变更咨询委员会成员应当对变更进行规划，同时制定变更进度计划表。变更规划和进度计划表的制定及发布是一个动态和持续的过程。此外，根据组织的变更策略，如果需要以发布包的形式将变更部署到生产环境中去，则应启动发布管理流程实施变更。

（6）协调变更实施。在得到变更授权并完成规划后进入变更实施阶段，具体包括变更构建、测试及实施。变更管理者在整个过程中起监控和协调作用。

（7）回顾和关闭变更。变更成功实施之后，变更管理者应当组织变更管理小组和CAB的成员召开实施后的评估会议。会议上要提交变更结果及在变更过程中发生的任何事故。

6.发布管理

发布管理负责规划、设计、构建、配置和测试硬件及软件，从而为运行环境创建发布组件的集合。发布管理的目标是交付、分发并追溯发布中的一个或多个变更。

发布管理的流程包括发布规划，发布设计、构建和配置，发布验收，试营运规划，沟通、准备和培训，发布分发和安装等。发布管理基本流程模型如图2-8所示。

1）发布规划

发布规划包括协调发布内容，就发布日程安排、地点和相关部门进行协商，制定发布日程安排、沟通计划，现场考察以确定正在使用的硬件和软件，就角色和职责进行协商，获取详细的报价单，并与供应商就新硬件、软件和安装服务进行谈判协商，制定撤销计划，发布制定质量计划，由管理部门和用户共同对发布验收进行规划。

2）发布设计、构建和配置

（1）设计。根据发布策略和规划，为发布进行相应的设计活动。这些活动具体包括明确发布类型，定义发布频率和定义发布方式。

（2）构建。一个发布单元可能会由多个发布组件构成，这些组件中有些可能是自主研发的，有些可能是外购的，发布团队应当整合所有发布组件，并对相关的程序进行规划和文档记录，并尽可能重复使用标准化流程。同时发布团队也需要获取发布所需的所有配置项和组件的详细信息，并对其进行必要的测试，确保构建的发布包中不包含具有潜在风险的项目。

（3）配置。需要发布的所有软件、参数、测试数据、运行中的软件和其他软件，都应处于配置管理的控制之下。在软件被构建应用之前，需要对其执行质量控制审核。有关构建结果的完整记录也要求记录到配置管理数据库（Configuration Management Database，CMDB）中，以确保在必要时按照该配置记录重复构建。

3）发布验收

用户代表应对发布进行功能测试并由IT管理人员进行操作测试。在测试过程中，IT管理人员需要考虑技术操作、功能、运营、绩效，以及与基础设施其他部分集成等方面的问题。测试还应该涉及安装手册、撤销计划。在试运营开始之前，变更管理应安排由用户进行的正式验收及由开发人员签发的开发结束标记。发布应当在一个受控测试环境中验收，并确保该项发布可以被恢复至一个可知的配置状态。这种针对该项发布的基线状态应该在发布规划时明确，并应记录在配置管理数据库中。

4）试运营规划

试运营规划包括制定日常安排，以及有关任务和所需人力资源的清单，制定有关安装配置项、停止配置项，以及退出使用的具体方式的清单，综合考虑可行的发布时间及所在时区，为每个实施地点制定活动计划，邮寄发布备忘录及与有关方面进行沟通，制定硬件和软件的采购计划，购买、安全存储、识别和记录所有配置管理数据库中即将发布的新配置项。

5）沟通、准备和培训

通过联合培训、合作和联合参与发布验收等方式，确保负责与客户沟通的人员、运营人员和客户组织的代表都清楚发布计划的内容及该计划的影响。如果发布是分阶段进行的，则应该向用户告知计划的详细内容。

6）发布分发和安装

发布管理监控软件和硬件的采购、存储、运输、交付和移交的整个物流流程。硬件和软件存储设施应该确保安全，并且只有经过授权的人员才可以进入。为减少分发所需的时间，提高发布质量，推荐使用自动工具来进行软件分发和安装。在安装后，配置管理数据库中的相关信息应立即进行更新。

7.知识管理

知识管理贯穿于整个服务管理生命周期。广义的知识管理涉及知识管理策略，知识的获取、存储、共享和创新等多个环节。本书仅规定与运维知识识别、分类、提交、过滤、审核、发布、维护等相关的流程细节。知识管理的目标是确保在整个服务管理生命周期中都能获得安全可靠的信息和数据，从而提高组织运维管理决策水平。

知识管理的流程包括知识识别和分类、初始化知识库、知识提交和入库、知识过滤和审核、知识发布和分享、知识维护和评估等。知识管理基本流程模型如图2-9所示。

（1）知识识别和分类。对于组织而言，知识的数量非常多且来源范围非常广。为准确地获取到对自身有价值的知识，组织必须事先对知识进行定义，以便清楚地识别哪些及哪类知识才是自己最需要的，同时也为知识分类做好准备。组织应当对知识来源进行归类。知识的来源包括内部来源和外部来源。知识所覆盖的范围非常广泛，为有效地管理知识，提高知识的使用效率，组织还应当对知识进行必要的分级和分类，以此建立知识目录。分级和分类的依据有很多，例如，按IT基础设施类别可将一级目录分为应用系统、业务操作、系统软件、网络通信、硬件设备、信息安全及其他等，然后再进一步划分二、三级目录；按知识用途将一级目录分为故障解决类、经验总结类、日常操作类等；按知识的使用权限将一级目录分为公共类、私有类、涉密类等。组织应根据自身情况合理选择和建立知识目录。

（2）初始化知识库。组织应当建立知识库来存储已获取的知识，并制定相应的管理策略对其进行维护。知识库是指用于知识管理领域的特殊数据库，它能够为知识管理提供电子化收集、存储和检索知识等功能，从而保证知识安全、可靠、长期地得到存储，同时也为组织成员分享知识提供帮助。

（3）知识提交和入库。知识提交人员可以来自组织中的任何部门。组织应当采取积极的政策和措施鼓励、帮助员工贡献出自己的知识，例如，提供Web录入、E-mail、电话通信、座谈会议及手工文档等方式。此外，组织还应制定统一的知识提交模板，以方便提交人员准确提交知识。知识库通常分为临时知识库和正式知识库。知识提交人员在提交知识时应对所提交的知识按照组织的知识目录结构进行初步的归类。所有提交的知识都应存入临时知识库，待知识审核人员进行审批。

（4）知识过滤和审核。知识管理者对临时知识库中的知识记录进行初步筛选和过滤，去除明显错误和完全无实用性的知识，之前已重复提交、已接受的或已拒绝的，以及仍处于评审状态的知识、不完善的知识。对于过滤的知识记录，知识管理者应当反馈相应的意见和理由给知识提交人员。之后知识管理者负责将临时知识库中的知识分配给相应的知识审核人员进行审批。知识审核人员应当综合考虑知识的正确性、准确性及实用性等因素，对知识进行严格的评审。对于通过审核的知识需进行进一步分类和权限设置等，最后待管理者发布；对于未通过审核的知识，应当给出相应意见和理由，而后由知识管理者负责将其反馈给知识提交人员。

（5）知识发布和分享。知识管理者将通过审核的知识转移至正式知识库并将其发布。发布后的知识可供组织内相应的人员分享。组织成员分享知识的方式有很多，通常可以借助科技手段（如网络检索、视频或语音通信、数字期刊和文档及多媒体会议等）来提高知识分享的效率。

（6）知识维护和评估。知识管理者负责对知识库进行日常维护，并定期对每条知识记录进行详细评定，具体方法包括收集来自用户对知识记录使用的反馈意见，调查和统计知识记录的利用率和解决问题的成功率，定期召开知识评估会议，召集组织内的知识审核人员及聘请各领域知识专家对知识库中的知识记录进行评估。组织应为知识制定合理而有效的评估标准（如优、良、合格、不合格等），以此对知识记录进行考核，并对不同考核结果的知识记录进行相应的处理，例如，对判定为优的知识的提供者进行奖励；对需要改进的知识进行修订；对未达到标准的知识进行删除等。

2.1.3 信息系统运维管理制度

组织启用新的信息系统后，便进入长期的使用、运行和维护期。为保证系统运行期正常工作，就必须明确制定信息系统运维的各项规章制度，建立和健全信息系统管理体制，保证系统的工作环境和系统的安全，只有这样才能保证信息系统为各层管理服务，充分发挥信息资源的作用。信息系统运维的制度具体包括：机房管理制度、数据管理制度、运行日志管理制度及档案管理制度等。

1.机房管理制度

一个较大的系统往往是一个网络系统，除中心机房外，工作站大多安装在各业务人员的办公室，没有专门的机房。因此，专用机房要有一套严格的管理制度，正式行文并张贴在墙上。该制度主要规定操作人员的操作行为，入机房人员的规定，机房的电力供应，机房的温度、湿度、清洁度，机房安全防火等。

2.数据管理制度

系统中的数据是组织极其宝贵的资源，禁止以非正常方式修改系统中的任何数据。

数据备份是保证系统安全的一个重要措施，它能够保证在系统发生故障后能恢复到最近的时间界面上。重要的数据必须每天备份，可使用两套备份设备，单日用A套设备，双日用B套设备。每周定期对备份设备做一次格式化，以便清除备份设备上的坏区。一些系统在发生对数据的重要修改前也应有相应的备份功能，以便保证系统数据的绝对安全。

3.运行日志管理制度

系统运行日志主要为系统的运行情况提供历史资料，也可为查找系统故障提供线索。因此，运行日志应当认真填写、妥善保存。运行日志的内容应当包括时间、操作人、运行情况、异常情况、值班人签字、负责人签字等。

4.档案管理制度

信息系统档案包括系统开发阶段的可行性分析报告、系统说明书、系统设计说明书、程序清单、测试报告、用户手册、操作说明、评价报告、运行日志、维护日志等。这些文档是系统的重要组成部分，要做好分类、归档工作，进行妥善、长期保存。档案的借阅也必须建立严格的管理制度和必要的控制手段。

2.1.4 信息系统运维管理系统

信息系统运维管理系统是站在运维管理的整体视角，基于运维流程，以服务为导向的业务服务管理和运维管理支撑平台，提供统一管理门户，其产品功能涵盖了资源管理、监控管理、性能管理、配置管理、告警管理、日志管理和操作审计等方面，最终帮助运维对象实现信息系统管理规范化、流程化和自动化的全局化管理。信息系统运维管理系统的整体架构如图2-10所示。

1.资产管理

资产管理实现对网络设备、服务器、PC、打印机、各种配件（显示器、显卡、网卡、硬盘）、软件、备品备件等设备资产信息的维护、统计及资产生命周期管理。根据资产信息获取方式的不同，资产管理可分为静态资产信息管理和动态资产信息管理。

1）静态资产信息管理

（1）资产信息维护：包括资产信息的获取与更新、查询、导出和打印。

（2）资产信息分析统计：实现静态资产的统计分析，关键指标为设备利用率。

（3）资产生命周期管理：对资产的采购、入库、维修、借调、领用、折旧、报废等生命周期各阶段的管理功能。

（4）辅助决策：包括预警功能，如资产过保修期预警、资产报废预警等；同时包括基于规则的运维费用的计算，运维费用包括资产维护费用和相关的维护人员费用，能够灵活调整计算规则。

2）动态资产信息管理

动态资产信息管理是在静态资产信息管理的基础上实现资产信息的自动发现和采集，资产信息的自动同步和更新。

2.监控管理

监控管理包括对信息系统相关设备的监控管理，实现视图管理、配置管理、故障管理和性能管理等。

1）视图管理

以图形方式呈现信息系统相关设施的信息。能够动态实时显示各类资源的运行状态，了解资源的分布与状态信息，以及对网络中的资源进行监控。系统一般支持网络拓扑图、机房平面图、机架视图、设备面板图等视图。

2）配置管理

系统实现设备资源、应用、人员和供应商等各类资源信息的维护和分析统计，以及配置信息的下发等功能。具体包括：

（1）资源信息维护：对动态资源信息的自动采集，以及方便的静态资源信息手工录入，并支持对资源信息的更新、同步等维护手段。

（2）资源模型编辑：通过模型的编辑工具，快速实现管理功能的调整。

（3）可视化监控：实现直观的可视化管理，通过形象的展现方式直观展现设备工作情况。

（4）配置信息下发和配置文件管理：对可配置资源管理信息进行下发控制。能够通过一个按钮即可快速批量设置整个信息系统环境的工作模式。能够对网络设备配置文件进行管理，包括配置文件上传、配置文件下载及配置文件比较等功能。

（5）资源信息统计分析：能够对资源信息进行灵活查询与统计，报表统计的结果以图形（如直方图、曲线图、饼图等）或表格方式显示。

3）故障管理

包括告警信息采集、处理、显示、清除和故障定位等功能。具体包括：

（1）实时采集告警信息，对设备资源的运行状态进行任务化的监视，支持设置不同的任务执行策略，完成不同监测粒度的需要。

（2）实现告警的过滤、升级和压缩，并能够对告警过滤、升级和压缩条件进行灵活设置。

（3）系统将用户关心的告警信息以列表、视图、颜色等形式呈现给运维人员，并支持对告警显示过滤条件的灵活设置。

（4）系统将这些事件信息通过电子邮件和短信息的方式及时告知相关运维人员，并支持信息发布规则的灵活设置，包括设置首次前转条件、间隔前转条件、延时前转条件、升级前转条件等。

（5）系统提供故障原因分析手段，能够准确定位网络故障的原因，能够自动压缩重复告警，记录告警的重复次数。

（6）系统提供自动和手动的告警清除功能，支持灵活设置自动清除的周期和清除时保留的告警时间窗口。

（7）系统记录故障发生的现象和处理的方法，为管理人员提供故障处理经验库。当故障发生时，能够方便地查看该类故障的处理经验。

4）性能管理

性能管理包括性能数据采集、处理、统计分析和性能门限管理等功能。具体包括：

（1）可采用任务方式对设备进行性能数据采集，性能数据能反映设备的运行情况和运行质量，能够对性能数据采集任务进行灵活的设置。

（2）支持对不同的性能指标进行阈值设置，提供相应的阈值管理和越限告警机制，能够按照对象类型和针对具体对象两种方式设置性能门限。

（3）性能数据可保存到数据库中，实现统计、分析和比较功能，统计、分析和比较的结果能够以图形方式呈现，能生成性能趋势曲线；能够同时选中多个对象，在同一坐标系中进行性能趋势对比，对比曲线应支持直接存为图片。

（4）性能数据趋势分析具备性能门限提醒功能。在性能趋势分析图中，能绘制出该对象的性能门限阈值线。

3.安全管理

通过信息化手段实现安全管理支撑能力，安全管理应包括但不限于通信及操作管理、访问控制、信息安全事件管理及风险评估和等级保护。在具体实施中会依据信息安全管理体系和信息系统安全等级保护的相关国家标准。安全管理功能一般应与事件管理和问题管理相关联。

（1）通信及操作管理。支持防范恶意代码和移动代码；支持依据既定的备份策略对信息和软件进行备份并定期测试；能对网络进行充分的管理和控制，以防范威胁，保持使用网络的系统、应用程序和信息传输的安全；支持对可移动媒体的管理；支持对通过物理媒体、电子消息及业务信息系统交换的信息进行安全控制；具有审计日志、管理员和操作者日志、错误日志等日志功能，并提供对日志信息的保护、分析和呈现。

（2）访问控制。系统支持对网络访问的控制，包括远程用户的鉴别，网络设备识别，诊断和配置端口的物理及逻辑访问控制，网内隔离，网络连接控制和网络路由控制等；支持对应用系统和信息的访问控制，进行统一集中的身份认证、授权和审计。

（3）信息安全事件管理。系统能发现并报告信息安全事件，并对安全事件做出响应；跟踪、记录安全事件及其处理过程；支持对安全事件的统计分析，能够量化安全事件的类型、数量、成本，并支持统计分析结果的输出。

（4）风险评估和等级保护。支持安全风险的评估及评估结果的上报，支持依据评估结果生成相应的等级保护方案，等级保护的方案应可映射到环境、资产、设备、网络、系统等安全系统运维的各个方面，支持等级保护方案的上报。

4.流程管理

流程管理功能应实现IT运维管理中所要求的管理流程，并对其进行监控，确保运维服务质量。流程管理功能要实现两个目标，一是对运维流程进行管控，按照服务等级协议（Service-Level Agreement，SLA）调用必要的资源，保证处理时限，确保服务质量，支持对故障和服务申请的跟踪，确保所有的故障和服务申请能够以闭环方式结束；二是利用运维管理系统固化运维服务的工作流程，提供标准的、统一的服务规范，提供灵活的流程定制功能。

1）事件管理

事件管理负责记录、快速处理IT基础设施和应用系统中的突发事件。事件管理应支持自定义事件级别、事件分类，提供方便的事件通知功能，支持对事件进行灵活的查询统计，并可以详细记录事件处理的全过程，便于跟踪了解事件的整个处理过程。事件管理应支持以下功能：

（1）支持事件记录的创建、修改和关闭。

（2）支持向事件记录输入描述和解决方案信息，支持创建事件记录时自动记录创建时间、创建日期和事件流水号。

（3）支持将事件记录自动分派到相应支持组和个人。

（4）提供对事件记录的查询功能。

（5）支持灵活定制相关报表，可利用历史事件记录生成管理报表。

（6）支持与问题管理、配置管理、变更管理等其他管理流程的集成。

2）事故管理

针对所有事件中的事故事件，运维管理系统应对采集到的事故事件支持以下功能：事故查询、事故与客户信息关联、事故统计、事故确认、事故同步、事故升级、事故清除、事故通知、事故知识库关联等。

（1）事故查询。运维管理系统支持多种条件组合的基本事故查询和统计功能，查询和统计功能针对当前事故和历史事故进行，并且应能根据事故源、事故级别、状态、类型、发生时间等组合条件对事故信息进行过滤查询。

（2）事故与客户信息关联。运维管理系统应支持事故和客户信息的关联，根据事故对象自动获取客户的名称、联系人信息及SLA签约信息，并结合SLA签约信息确定事故的级别和后续处理策略。

（3）事故同步。运维管理系统应具有事故同步的功能，当由于某些因素造成运维管理系统与IT资源的事故信息不同步时，可以启动同步功能，完成事故信息的同步。运维管理系统可以向被管系统主动请求网络的当前活跃事故信息，或者请求某一时间段的事故信息。

（4）事故确认。运维管理系统应提供事故确认的功能。运维管理系统应能对单个事故或符合条件的一组事故进行确认。

（5）事故升级。对单位时间内频次过高或历时过长（门限可由用户设置）的事故自动提高事故级别，从而保证事故信息的有效性。运维管理系统应提供界面，可以由用户对事故升级的条件进行灵活配置。

（6）事故清除。运维管理系统应具有事故清除的功能。事故清除功能应支持两种清除方式：自动清除和手工清除。自动清除是指运维管理系统能自动将超过事故保存时间的历史事故记录删除，而手工清除是指运维管理系统能够对用户选定的事故进行清除。

（7）事故统计。运维管理系统应具有事故统计功能。运维管理系统应能以报表、图形等形式根据事故对象、事故类型、事故级别、事故产生的时间等条件对事故进行分类统计和比较。

（8）事故通知。运维管理系统提供事故通知条件的设置，包括事故时间范围、事故级别、类型、事故设备等。运维管理系统支持查询、增加、删除、修改事故通知条件的功能，允许创建多个通知条件；运维管理系统提供将事故通知条件关联到相关的运维人员的功能，一个事故通知条件应可以关联到多个运维人员，并提供对E-mail和短信通知方式的设置。当出现事故时，运维管理系统会自动根据事故通知条件通过特定手段（如E-mail或短信）通知相关的运维人员。

3）问题管理

问题管理流程的主要目标是预防问题和事故的再次发生，并将未能解决的事件的影响降到最低。系统应支持以下功能：

（1）支持问题记录的创建、修改和关闭，创建问题记录时自动记录创建时间、日期。

（2）支持对事件、问题和已知错误的区分。

（3）支持自动分派问题记录到定义的支持组或个人。

（4）支持对问题记录定义严重等级和影响等级。

（5）支持对问题记录的跟踪和监控。

（6）支持生成可定制的管理报表。

（7）支持向问题记录输入描述和解决方案信息。

（8）提供对问题记录的查询功能。

（9）支持与变更管理、配置管理、事件管理等其他管理流程的集成。

4）配置管理

配置管理负责核实IT基础设施、应用和用户终端环境中实施的变更，以及配置项之间的关系是否已经被正确记录下来，监控IT组件的运行状态，以确保配置管理数据库能够准确地反映现存配置项的实际版本状态。

配置管理相关的内容包括：分析现有信息，确定所需工具和资源，选择和识别配置构架，创建配置项，记录所有的IT基础设施组件及其相互关系（包含组件所有人、状态及可用的文档等），通过认可记录和监控已授权及确认的配置项来确保配置数据库的及时更新，核实配置项的存在性和准确性，根据配置项的使用情况产生趋势和发展的报告，为其他管理流程提供可靠的信息等。

配置管理应追踪和监控基础设施及其状态，记录管理对象的相互关系，为事件、问题与变更管理等提供相关的设备系统信息，应能帮助事件管理、问题管理中的故障和问题正确快速解决，应能帮助评估变更影响并快速解决。

配置管理应确保客户所有配置元素及其配置信息得到有效完整的记录和维护，包括各配置元素之间的物理和逻辑关系。

配置管理子系统应支持以下功能：

（1）支持对配置项的登记和变更管理。

（2）支持对配置项属性的记录，如序列号、版本号、购买时间等。

（3）支持配置项间关系的建立和维护。

（4）支持配置项及其关系的可视化呈现。

（5）支持对配置管理数据库访问权限的控制。

（6）支持对配置项变更的历史审计信息的记录和查询。

（7）支持配置项的状态管理。

（8）支持针对配置项的统计报表。

（9）支持与事件管理、问题管理、变更管理等其他管理流程的集成。

（10）配置管理与其他流程的集成要求。

5）变更管理

变更管理实现所有IT基础设施和应用系统的变更，变更管理应记录并对所有要求的变更进行分类，应评估变更请求的风险、影响和业务收益。其主要目标是以对服务最小的干扰实现有益的变更。系统应支持以下功能：

（1）创建并记录变更请求：系统应支持信息的输入，并确保只有授权的人员方可提交变更请求。

（2）审查变更请求：系统应支持对变更请求进行预处理，过滤其中完全不切实际的、不完善的或之前已经提交或被拒绝的变更请求。

（3）变更请求的分类和划分优先级：系统应支持基于变更对服务和资源可用性的影响决定变更的类别，依据变更请求的重要程度和紧急程度进行优先级划分。

（4）系统应支持对变更请求的全程跟踪和监控，支持在变更全程控制相关人员对变更请求的读、写、修改及访问。

（5）系统应支持将变更请求分派到合适的授权人员。

（6）系统应支持对变更请求的审批流程，并支持对变更请求的通知和升级处理；

（7）系统应提供可定制的管理报表，方便按类型、级别对变更进行统计和分析，对变更实施的成功率、失败率等进行统计和分析。

（8）支持与事件管理、问题管理、配置管理等其他管理流程的集成。

6）发布管理

发布管理负责对硬件、软件、文档、流程等进行规划、设计、构建、配置和测试，以便为实际运行环境提供一系列的发布组件，并负责将新的或变更的组件迁移到运行环境中。其主要目标是保证运行环境的完整性被保护及正确的组件被发布。系统应支持以下功能：

（1）支持发布的分发和安装。

（2）支持与配置管理、变更管理、服务级别管理等流程的集成。

7）知识管理

知识管理流程负责搜集、分析、存储和共享知识及信息，其主要目的是通过确保提供可靠和安全的知识及信息以提高管理决策的质量。知识管理应支持以下功能：

（1）添加知识：提供支持人员提交经验和知识输入的接口或界面，支持Word/Excel/TXT等格式文档作为附件的输入。

（2）支持知识库的更新。

（3）查询知识：提供完善的查询功能，如查询关键字、知识列表等。

（4）提供模糊匹配、智能查询、点击统计等增强功能。

5.综合管理

运维管理系统应在资产管理、监控管理、安全管理、流程管理和外包管理功能的基础上，实现信息系统整体运维信息统计分析，并支持管理决策。

（1）统计分析。运维管理系统应能在收集到的各种事件信息和配置信息的基础上进行综合分析，帮助运维人员进行故障问题的定位。同时，系统应支持在各类管理信息的基础上建立综合分析指标，来反映IT环境的总体运行趋势。运维管理系统应支持通过界面、邮件和短信等多种方式发布分析结果。对分析结果发布的规则可以灵活设置，能够为信息系统运维的不同角色提供不同界面和分析结果。

（2）决策支持。决策支持应该包括数据、模型、推理和人机交互四个部分。系统应支持管理者就信息系统运维相关的人员、费用及资源配置等管理关注的方面制定决策目标，通过建立、维护并运行决策模型，利用综合资产、监控、安全、流程及外包管理的特征数据，借助知识推理功能，以人机交互方式进行半结构化或非结构化决策。

6.外包管理

运维管理系统的外包管理功能是面向信息系统管理者，实现对外包的信息系统运维服务的结果控制管理和过程控制管理。

1）结果控制管理

结果控制管理应支持对外包信息系统运维服务质量和效果的控制。具体包括：

（1）系统应支持对服务级别协议的查询。

（2）系统应支持基于服务级别协议中规定的内容定制并提交服务质量报告。

（3）系统应支持服务级别违例报告。

2）过程控制管理

过程控制管理应实现对信息系统运维服务提供过程的控制。具体包括：

（1）系统应支持查询外包运维工作的详细情况，如事件和问题处理情况、变更执行情况等。

（2）系统应支持服务级别违例相关的服务质量恢复和处理情况的查询及报告。

（3）系统应支持对外包单位和外包运维人员的工作量及绩效进行查询、统计和定期报告。

2.2 信息系统运维的组织

2.2.1 信息系统运维的任务

1.信息系统的日常运行管理

信息系统的日常运行管理工作量巨大，包括数据的收集、例行信息处理及服务工作、计算机硬件的运维、系统的安全管理四项任务。

（1）数据的收集。一般包括数据收集、数据校验及数据录入三项子任务。

如果系统数据收集工作不做好，整个系统的工作就成了“空中楼阁”。系统主管人员应该努力通过各种方法，提高数据收集人员的技术水平和工作责任感，对他们的工作进行评价、指导和帮助，以便提高所收集数据的质量，为系统有效地运行打下坚实的基础。

数据校验的工作，在较小的系统中，往往是由系统主管人员自己来完成的。在较大的系统中，一般需要设立专职数据控制人员来完成这一任务。

数据录入工作的要求是及时与准确。录入人员的责任在于把经过校验的数据送入计算机，他们应严格地把收到的数据及时、准确地录入计算机系统，录入人员并不对数据在逻辑上、具体业务中的含义进行考虑与承担责任，这一责任是由校验人员承担的，他们只需保证送入计算机的数据与纸面上的数据严格一致即可。

（2）例行信息处理及服务工作。常见的工作包括：例行的数据更新，统计分析，报表生成，数据的复制及保存，与外界的定期数据交流等。这些工作一般来说都是按照一定的规程，定期或不定期地运行某些事先编制好的程序，这是由软件操作员来完成的。这些工作的规程应该是在系统研制中已经详细规定好了的，操作人员应经过严格的培训，清楚地了解各项操作规则，了解各种情况的处理方法。组织软件操作人员，完成这些例行的信息处理及信息服务工作，是系统运行中又一项经常性任务。

（3）计算机硬件的运维。如果没有人对硬件设备的运行维护负责，设备就很容易损坏，从而使整个系统的正常运行失去物质基础，这种情况已经在许多单位多次发生。这里所说的运行和维护工作包括设备的使用管理，定期检修，备品备件的准备及使用，各种消耗性材料（如软盘、打印纸等）的使用及管理，电源及工作环境的管理等。

（4）系统的安全管理。这是日常工作的重要部分之一，是为了防止系统外部对系统资源不合法的使用和访问，保证系统的硬件、软件和数据不因偶然或人为的因素而遭受破坏、泄露、修改或复制，维护正当的信息活动，保证信息系统安全运行所采取的手段。信息系统的安全性体现在保密性、可控制性、可审查性、抗攻击性四个方面。

上述四项程序性的日常运行任务必须认真组织，切实完成。作为信息系统的主管人员，必须全面考虑这些问题。组织有关人员按规定的程序实施，并进行严格要求，严格管理。否则，信息系统很难发挥其应有的实际效益。另外，常常会有一些例行工作之外的临时性信息服务要求向计算机应用系统提出，这些信息服务不在系统的日常工作范围之内，然而，其作用往往要比例行的信息服务大得多。随着管理水平的提高和组织信息意识的加强，这种要求还会越来越多。领导和管理人员往往更多地通过这些要求的满足程度来评价和看待计算机应用系统。因此，努力满足这些要求，应该成为计算机应用系统主管人员特别注意的问题之一。系统的主管人员应该积累这些临时要求的情况，找出规律，把一些带有普遍性的要求加以提炼，形成一般的要求，对系统进行扩充，从而转化为例行服务。这是信息系统改善的一个重要方面。当然，这方面的工作不可能由系统主管人员自己全部承担，因此，信息系统往往需要一些熟练精干的程序员。

总之，信息系统的日常管理工作是十分繁重的，不能掉以轻心。特别要注意的是，信息系统的管理绝不只是对机器的管理，对机器的管理只是整个管理工作的一部分，更重要的是对人员、数据、软件及安全的运行维护管理。

2.信息系统运行情况的记录

系统的运行情况如何对系统管理、评价是十分宝贵的资料。人们对于信息系统的专门研究还只是刚刚起步，许多问题有待探讨。即使从某一组织或单位来说，也需要从实践中摸索和总结经验，把信息处理工作的水平进一步提高。而不少单位却缺乏系统运行情况的基本数据，只停留在一般的印象上，无法对系统运行情况进行科学的分析和合理的判断，难以进一步提高信息系统的工作水平。信息系统的主管人员应该从系统运行的一开始就注意积累系统运行情况的详细材料。

在信息系统的运行过程中，需要收集和积累的资料包括以下五个方面。

（1）有关工作数量的信息。例如，开机的时间、每天（周、月）提供的报表的数量、每天（周、月）录入数据的数量、系统中积累的数据量、修改程序的数量、数据使用的频率、满足用户临时要求的数量等反映系统的工作负担、所提供的信息服务的规模及计算机应用系统功能的最基本的数据。

（2）工作的效率。即系统为了完成所规定的工作，占用了多少人力、物力及时间。例如，完成一次年度报表的编制用了多长时间、多少人力；又如，使用者提出一个临时的查询要求，系统花费了多长时间才给出所要的数据；此外，系统在日常运行中，例行的操作所花费的人力是多少，消耗性材料的使用情况如何等。

（3）系统所提供的信息服务的质量。信息服务和其他服务一样，应保质保量。如果一个信息系统生成的报表并不是管理工作所需要的，管理人员使用起来并不方便，那么这样的报表生成得再多再快也毫无意义。同样，使用者对于提供的方式是否满意，所提供信息的精确程度是否符合要求，信息提供得是否及时，临时提出的信息需求能否得到满足等，也都在信息服务的质量范围之内。

（4）系统的维护、修改情况。系统中的数据、软件和硬件都有一定的更新、维护和检修的工作规程。这些工作都要有详细及时的记载，包括维护工作的内容、情况、时间、执行人员等。这不仅是为了保证系统的安全和正常运行，而且有利于系统的评价及进一步扩充。

（5）系统的故障情况。无论故障大小，都应该及时地记录以下情况：故障的发生时间、故障的现象、故障发生时的工作环境、处理的方法、处理的结果、处理人员、善后措施、原因分析。需要注意的是，这里所说的故障不只是指计算机本身的故障，而是对整个信息系统来说的。例如，由于数据收集不及时，使年度报表的生成未能按期完成，这是整个信息系统的故障，但并不是计算机的故障。同样，收集来的原始数据有错，这也不是计算机的故障，然而这些错误的类型、数量等统计数据是非常有用的资料，其中包含了许多有益的信息，对于整个系统的扩充与发展具有重要的意义。

对于信息系统来说，这些信息主要靠手工方式记录。虽然大型计算机一般都有自动记载自身运行情况的功能，但是也需要有手工记录作为补充手段，因为某些情况是无法只用计算机记录的。例如，使用者的满意程度，所生成的报表的使用频率等只能用手工方式收集和记录。而且，当计算机本身发生故障时，是无法详细记录自身的故障情况的。因此，对于任何信息系统，都必须有严格的运行记录制度，并要求有关人员严格遵守和执行。

为了使信息记载得完整、准确，一方面要强调在事情发生的当时、当地由当事人记录。另一方面，尽量采用固定的表格或本册进行登记，而不要使用自然语言含糊地表达。这些表格或登记簿的编制应该使填写者容易填写，节省时间。同时，需要填写的内容应该含义明确，用词确切，并且尽量给予定量的描述。对于不易定量化的内容，则可以采取分类、分级的办法，让填写者选择打钩等。总之，要努力通过各种手段，详尽、准确地记录系统运行的情况。

对于信息系统来说，各种工作人员都应该担负起记载运行信息的责任。硬件操作人员应该记录硬件的运行及维护情况，软件操作人员应该记录各种程序的运行及维护情况，负责数据校验的人员应该记录数据收集的情况，包括各类错误的数量及分类，录入人员应该记录录入的速度、数量、出错率等。

3.系统运行情况的检查与评价

信息系统在其运行过程中除了不断进行大量的管理和维护工作外，还要在高层主管的直接领导下，在系统分析员或专门的审计人员会同各类开发人员和业务部门经理共同参与下，定期对系统的运行状况进行审核和评价，为系统的改进和扩展提供依据。系统评价一般从以下三个方面考虑：

（1）系统是否达到预定目标，目标是否需做修改。

（2）系统的适应性、安全性评价。

（3）系统的社会经济效益评价。

对系统定期进行各方面的审计与评价，实际上是看系统是否仍处于有效适用状态。如果审计结果是系统基本适用但需要做一些改进，则要做好系统的维护工作，一旦审计结果确认系统已经不能够满足各项管理需求和决策需求，不能适应组织或组织未来的发展，则说明该信息系统已经走完了它的生命周期，必须提出新的开发需求，开始另外一个新的系统生命周期，整个开发过程又回到系统开发的最初阶段。

2.2.2 信息系统运维管理的职责

明确信息系统运维管理的职责是划分信息系统运维管理职能和进行信息系统运维组织设计的前提。信息系统运维管理的职责可以从运维流程和运维对象两种角度分类，不同的分类视角下，信息系统运维管理的职责是不同的，因此信息系统运维管理职能的划分也不尽相同。

按照运维流程，可以从事件管理、事故管理、问题管理、配置管理、变更管理、发布管理和知识管理七个方面，归纳信息系统运维不同人员的职责，如表2-1所示。

续表

续表

按照运维对象，可以从数据、软硬件、系统管理员等方面，归纳信息系统运维不同人员的职责，如表2-2所示。

2.2.3 信息系统运维人员的管理

1.运维人员管理的内容

运维人员管理的内容包含三个方面，具体如下。

（1）明确各业务人员的任务及职权范围，尽可能确切地规定各类人员在各项业务活动中应负的责任、应做的事情、办事的方式及工作的次序。简单地说，要有明确的授权。

（2）对于每个岗位的工作要有定期的检查及评价，为此，对信息系统运维的每项工作都要有一定的评价指标。这些指标应该尽可能有定量的尺度，以便检查与比较。此外，这些指标应该有一定的客观衡量办法，并且要真正按这些标准去衡量各类工作人员的工作绩效。

（3）要在工作中对工作人员进行培训，以便使他们的工作能力不断提高，工作质量不断改善，从而提高整个系统的效率。

2.运维人员管理的意义

由于信息系统运维所体现的运用先进信息技术为管理工作服务的特点，其工作中必然要涉及多方面、具有不同知识水平及技术背景的人员。这些人员在系统中各负其责、互相配合，共同实现系统的功能。因此，这些人员能否发挥各自的作用，他们之间能否互相配合、协调一致，是系统运行成败的关键之—。系统主管人员的责任就在于对他们进行科学的组织与管理。如果系统主管人员不善于进行这样的组织及管理工作，就谈不上实现组织信息管理的现代化和科学化。在这种情况下，整个系统的运行就会出现混乱。

3.运维人员管理的意识

（1）服务意识：“服务意识”是指信息系统的运维人员在工作过程中所体现的热情、周到地为系统各类用户尽心尽力服务的愿望和意识，它可以通过培养、教育、训练而形成。只有增强和建立了服务意识，做好信息系统的运维和服务才有思想基础及保证。

（2）学习意识：对知识的渴望也是信息系统运维人员必备的素质之一。信息技术发展很快且竞争激烈，作为信息系统的运维人员，需要不断学习，扩充自己的知识宽度和深度，提高信息系统运维的技术水平和服务质量。如果不能随着信息技术的发展而同步提高，势必会在激烈的竞争中被淘汰。作为组织，应为员工提供各种培训及学习的机会，提升员工的工作技能；作为个人，应根据岗位所需和自己的具体情况，积极参加相关知识培训，并培养自学意识，不断拓宽自己的知识面，提高个人的专业水平和运维能力。

（3）创新意识：目前，国内在信息系统运维方面的经验还不是很丰富，而且国外的许多经验也不一定适合中国的国情，因此更需在运维方式和方法等方面进行创新，并在创新过程中不断完善运维和服务。其中从事运维的高端人才还应当积极在信息技术创新方面勇于探索，以免受制于人。

（4）专业意识：是指我们在职业生涯中不断提升自身专业水平的意识。信息系统涵盖的专业范围很广，而当前的信息系统运维人员的专业背景绝大部分为信息技术。要想理解专业用户的需求，更好地为其提供对口的技术支持，就需要运维人员不断学习，了解相关专业的基础知识和最新进展，这样才可能从用户的角度出发，更好地为用户服务。

（5）主动意识：是指运维人员自觉主动做好信息系统运维的观念和愿望。主要包括主动宣传、主动完善、主动预防、主动服务等几个方面。

（6）安全意识：信息系统管理的是组织重要的数据和信息资产，因此安全永远是第一位的，只有在保证安全的前提下，才谈得上应用和共享。要树立足够的安全意识，从管理、技术两大方面加强系统的安全。在管理方面要制定相应的规章制度，规范所有岗位人员的行为，获取应对突发事故的能力和经验，定期修改软件密码，做好日常备份。在技术方面应加强信息系统的防御（黑客、病毒等）、灾难备份等技术的研究和应用，在数据库管理软件、系统软件、应用软件中应具有根据不同的用户赋予不同权限的功能。

（7）团队意识：信息系统的运维涉及许多种硬件、软件，需要各岗位人员（包括管理、技术两大方面的人员）不仅要做好本职工作，更应加强团队协作意识。如果信息系统的管理部门没有建立一支高效、团结的运维队伍，运维人员缺乏团结协作意识，就很难保证系统的良好运行。

4.运维人员的学习培训

由于计算机技术的飞速发展，基于计算机的信息系统对很多员工来讲还是新生事物。因此，在信息系统运维管理过程中，对人员的培训工作是不可缺少的。从长远来看，这种工作将使系统具有不断发展、不断完善的巨大潜力。无论对管理人员还是对计算机技术人员来说，都必须把学习、培训和提高专业素质及业务能力作为自己工作不可缺少的部分。

信息系统的主管人员应该鼓励并组织各类人员进行知识更新和技术学习，给予时间、创造条件使他们能够在完成日常工作的同时，在业务知识和工作能力上不断有所进步。

各类人员的知识更新或业务学习，无疑应该围绕信息系统运维工作的需要来进行。例如，了解所在系统的总体目标、处理特点、业务处理方式、业务处理需要等情况，这对于信息系统工作人员尤为重要。在银行工作的计算机技术人员应该逐步了解银行的业务工作，在工厂工作的信息系统工作人员则应该逐步了解所在工厂的生产及管理情况。另外，对于管理部门的工作人员，则应该逐步了解信息系统的基本构造、原理及使用方法。此外，对于各类人员都需要在工作中进行信息处理系统基本思想方法及工作方法的训练及培养。

总之，在信息系统运维管理中，对各类人员的管理及培养是一个不可忽视的重要问题。

2.3 信息系统运维的外包

信息系统运维的对象包括各种硬件和软件，对这些软硬件的运维工作涉及大量专业性很强的技术，而且这些运维技术更新很快。对信息技术运维人员而言，保持服务能力与技术发展同步，需要不断学习，组织内单一的信息技术运维环境，一般来说不利于信息技术运维人员的成长和发展；对组织而言，招聘或培养掌握复杂信息系统运维技术的专业人员也往往是非常不经济的。因此，为了控制人力成本，保证信息系统的质量和应用效果，信息技术运维全面或局部外包成了组织在有限资源条件下实现效益最大化的必然选择。

2.3.1 信息系统运维外包的概念

外包一词的英文是Outsourcing，即外部寻求资源的意思。外包还没有统一的定义，美国外包协会把外包定义为：外包是通过合约把公司的非核心业务、无增值收入的生产活动包给外部专家；美国外包问题专家Michael Corbett则认为“外包是大组织或其他机构把过去自我从事或预期自我从事的工作转移给外部供应商；而安达信（Anderson）对外包的定义是一个业务实体将原来应在组织内部完成的业务转移到组织外部由其他业务实体来完成，这种行为就称为外包。尽管有许多不同说法，但定义的内涵基本上是一致的。外包是指组织为了将有限资源专注于其核心竞争力，以信息技术为依托，利用外部专业服务商的知识劳动力，来完成原来由组织内部完成的工作，从而达到降低成本、提高效率、提升组织对市场环境迅速应变能力并优化组织核心竞争力的一种服务模式。

信息系统运维外包也称信息系统代维，是指信息系统使用单位将全部或一部分的信息系统维护服务工作，按照规定的维护服务要求，外包委托给专业公司管理。一般认为，外包可以带来成本优势，使信息系统使用单位保持长期的竞争优势。通过实行信息系统运维服务外包托管，可以利用专业公司的信息技术，提高单位信息管理的水平，缩短维护服务周期，降低维护成本，实现信息系统使用单位和信息系统运维服务专业公司的共同发展，还可以使信息系统使用单位信息中心管理工作简单化，将信息中心人员减至最少，使得信息系统使用单位能够专注于自身核心业务的发展，提升自身的核心竞争力。

信息系统运维外包可以给组织带来众多好处，比如：

（1）有利于提高组织竞争力。专业化信息系统运维公司调试设备齐全，运维技术专业、规范，队伍相对稳定，运维人员从业经验丰富，对行业规范的熟悉程度高，所以在信息系统实际运维中动作熟练、观察到位、记录翔实，可向业主方提供优质专业的服务，有利于被服务单位提高自身竞争力。此外，把日复一日的繁杂的信息系统日常运维外包出去，可以把精力集中在管理业主方最核心、最关键的工作上，由此提高业主方的核心竞争力。

（2）借助专业公司的管理流程和工具软件降低信息系统运维的成本。借助专业公司在信息系统管理工具和方法方面的优势来实现组织内部信息系统运维的信息化和规范化，组织无须在信息系统运维的管理流程、管理工具和管理人员的培训方面进行大规模的投资，减少了业主方信息系统运维管理的投资成本，同时也规避了由于人员流失而造成的IT运维管理方法和工具不能继承的风险。

（3）提高服务质量、降低故障率。信息系统运维服务外包后，由于信息系统运维服务开始计价，信息系统运维服务成本从隐性成本转变成显性成本，信息系统运维服务外包公司提供的账单使组织能够了解信息系统运维服务成本的来源。了解其来源，可采取有效的针对性措施来规避成本。另外，由于服务计费，信息系统运维服务公司为了自身生存需要，更希望降低单次服务成本，由此追求服务方式的标准化和规范化；同时，为了达到与客户约定的服务水平协议要求，提高客户满意度，不断追求自身服务品质的提高，这使得客户的服务质量得到有效保障。

（4）降低业务部门隐性成本。故障率的降低使得业务部门的信息系统可用性大为提高，业务部门有更多的时间使用信息系统开展业务，这大大降低了由于信息系统故障频繁可能引发的业务部门隐性成本。

2.3.2 信息系统运维外包的模式

在信息技术运维外包过程中，组织可能全部或部分将信息技术运维工作外包给其他信息系统运维外包服务公司，因此存在完全外包和部分外包两种信息系统运维外包模式。

1.完全外包模式

组织通过与其他组织签署运维外包协议，将所拥有的全部信息技术资源的运维工作外包给其他组织，即外包组织为本组织提供完全的信息系统运维服务，组织的信息技术部门负责运维外包的管理工作，完全外包模式如图2-11所示。

2.部分外包模式

组织对所拥有的一部分信息技术资源自行运维；同时，通过与其他组织签署运维外包协议，将所拥有的另一部分信息技术资源的运维工作外包给其他组织。一般情况下，组织信息技术部门负责运维工作和外包管理，即组织的信息技术部门和外包组织共同向组织提供信息系统运维服务，部分外包模式如图2-12所示。在部分外包模式下，根据运维服务是否涉及各组织的核心业务、关键任务等因素，对外包服务管理的具体要求各不相同。对涉及核心业务或关键任务的外包服务，需要对外包服务的过程和结果进行精细化管理；对只涉及非核心业务和非关键任务的外包服务，只需要对外包服务的结果进行粗放型管理。

2.3.3 信息系统运维外包的内容

根据具体的维护环节和所出现的大部分问题分析，信息系统运维外包主要包括桌面支持外包、IT基础架构外包和应用系统外包。

1.桌面支持外包

目前，许多品牌计算机专业服务商的售后服务部门正日益摆脱从属厂家的地位，开始走商业利润最大化之路，发展成为专业服务商。部分技术服务公司从大型组织集团客户服务体系（提供售后维修服务等）的成本服务中心成功转型，成为面对各类行业客户的独立的第三方专业技术服务提供商，大力开展IT运维外包业务，这类公司的出现逐渐使硬件厂商把服务部门从成本中心转化为利润中心。

信息技术桌面指的是员工在工作场所使用的一系列用于信息处理、通信和计算的设备，包括计算机软硬件和其他的相关设备，对它们的管理是每个使用信息技术桌面的单位机构最日常的工作。具体地说，就是办公环境的维护，详细的工作包括：

（1）系统初始检查。在办公环境刚刚建立或准备建立之时，可提供对全局环境的检查，并得出最佳适合于单位的方案或找出不合理性、出现的问题。

（2）硬件故障解决。对计算机、笔记本、打印机等办公设备的故障进行定位和处理。

（3）硬件扩容升级。对不满足于办公环境的设备进行升级或更换处理。

（4）软件系统支持。对系统软件、一般运用软件进行维护，如选型、安装、使用、优化等，进行技术指导和处理，并可实现对系统的监控来实现维护的零距离。

（5）防病毒系统的支持。进行防病毒安全方面的技术处理，如查杀病毒、防病毒软件的解决方案，病毒防范安全策略等。

（6）网络系统的支持。对简单网络状况进行全局维护，并做出定制的优化和故障处理。

（7）日常维护管理。管理组织中各IT系统的资源资产情况，实现组织的财务部门进行更加方便的数据交互；规范和明确运维人员的岗位职责和工作安排，提供绩效考核量化依据，提供解决经验与知识的积累与共享手段，实现完善的IT运维管理，为组织提高经营水平和服务水平。

（8）咨询服务。对于以上的服务环节提供相应的咨询服务，但在维护合同签署之后依据合同实行。

2.基础架构外包

基础架构所涉及的内容包括网络设备、组织通信系统（如邮件）、数据库系统、服务器设备及系统、安全设备及系统、存储设备及系统等系统化但又是基础化的系统平台及设备配件，是组织IT信息化所依赖的基础和根本。

这类外包的业务以互联网数据中心（Internet Data Center，IDC）外包最为主要，市场的份额也是较大的。其次，重点行业用户对网络系统的运营维护外包服务的认知度和接受度明显上升，大型网络安全、存储系统外包也正在逐渐占据重要地位。将安全和存储外包给更专业和权威的机构不但能使IT基础架构的外来危险、数据损失风险较低，还能简化内部人员的结构，节省人员费用。

这类业务包括以下几方面：

（1）系统、服务器维护支持。UNIX、Linux、Windows Server等较大型系统的安装、调试、维护、优化，并对小型服务器至SUN、IBM等高端服务器进行维护。

（2）软件、服务调试。对邮件系统、ISA、Exchange、Lotus、AD、Web、FTP等较常用软件和服务的维护及技术支持（需要对UNIX、Linux及平台下的各项服务也比较熟悉，因为很多组织所使用的系统不只是Windows平台。）。

（3）网络系统维护。对整体网络环境进行检测并优化，简化网络管理，提高网络整体性能和办公效率。

（4）系统迁移。设备更新时，对系统、软件、数据进行迁移，实现简捷而安全的迁移，降低对业务的影响。

（5）数据库维护支持。对DB2、Oracle、SQL Server、MySQL等数据库的维护。

（6）数据存储和容灾管理。对系统和业务数据进行统一存储、备份和恢复，找到更符合组织的存储方案和存储安全策略，并实施全方位的服务。

（7）安全系统的支持。针对内外网安全隐患进行安全分析和安全处理，使组织内部安全性提高。

（8）网站支持。对组织进行量身定制业务网站、门户网站等一系列网站业务，并提供维护和升级支持。

（9）咨询服务。对于以上的服务环节提供相应的咨询服务，但在维护合同签署之后依据合同实行。

3.应用系统外包

应用系统外包与应用服务提供商（Application Service Provider，ASP）密切相关。ASP的理念和模式与云计算很接近，就是集中为组织搭建信息化所需要的所有网络基础设施及软件、硬件运行平台，负责所有前期的实施、后期的维护等一系列服务，使得组织无须购买软硬件、建设机房、招聘IT人员，只需前期支付一次性的项目实施费和定期的ASP服务费，即可通过互联网享用信息系统。中小组织用户通过采购ASP服务，可减少IT硬件设备的采购，减少IT支持人员的雇佣，提高应用系统的灵活性和稳定运行能力。

最典型的运用有邮件系统、中小型ERP、CRM（客户关系管理）、SCM（供应链管理）等的ASP服务。

2.3.4 信息系统运维外包的阶段

信息部门在以前常常以一个被动的、孤立的、分散的“救火队”的身份在进行信息系统运维管理，随着信息技术的发展，这种方式早已不适应现在复杂的信息系统运维环境。此外，从风险规避的角度来看，信息系统外包需要有一个循序渐进的过程。因此IT界提出了各个阶段信息系统运维外包服务内容。

第一阶段：分别与各个应用软件系统的开发商签订维护合同，确保软件系统的正常升级。由于应用系统很少存在建设完成后就不再改动的情况，要确保应用系统始终都处于最佳使用状态，就要通过签订维护合同从法律途径来确保系统的正常升级和完善。在这一阶段，要注意收集系统的维护频率、完成时间、维护质量等信息，作为评价维护工作的基础数据，也作为后续维护工作的重要依据。

第二阶段：对硬件进行外包，特别是打印机、服务器、计算机、网络设备等硬件维护外包。一旦设备过了保质期，出现硬件损坏的概率就会增大，但外包服务商可以轻松解决这个问题，同时也可大大减少信息部门的日常维护工作量，减少信息部门人员，降低组织成本，提高人力资源的利用率。

第三阶段：根据第一、二阶段的维护情况，逐步考虑信息运维的整体外包，如数据资源运维、安全的运维等。通过第一、二阶段的维护外包情况的总结，制定详细的、具有可操作性的运行维护服务外包合同。在这一阶段，尽管大部分的工作已经外包，但本单位的信息部门仍需要参与到各项维护工作中，加强对维护情况的跟进，对出现的问题及时进行完善。

2.3.5 信息系统运维外包的方式

根据客户对信息系统运维需求的不同，服务承包方主要提供如下几类服务外包方式：

（1）设备保修。对客户已经超出保修期的设备，可以提供设备保修服务，在设备出现故障后，按照约定对故障设备进行维修。

（2）备件支持。对客户关键业务系统相关设备可以提供备件服务，在设备故障时，先使用备件恢复应用系统运行，在设备维修完成后再换回。

（3）现场值守。在客户没有日常维护人员时，可以派遣技术人员驻守现场，直接负责信息系统的维护工作。

（4）电话咨询。提供全天候的电话咨询服务，及时通过电话解决客户问题。

（5）现场专家服务。遇到用户无法解决的信息系统故障情况，承包方可以派出相关专家进行信息系统现场故障解决。

2.3.6 信息系统运维外包的风险管理

信息系统运维服务外包作为一种新的信息系统服务业务运营模式，具有明显的优势。可以通过选择专业的运维服务商，运用不断更新的信息技术来满足自己的业务需求；可以将组织原本存在的信息管理部门委托给服务商，精简机构，节约成本等。

1.风险分类

业主方运维外包的风险主要来源于以下四个方面：

（1）外部环境不确定性，如政治风险、自然风险、市场风险等。

（2）运维外包决策的复杂性，如运维外包可行性的研究，运营方的选择，与运营方的权责界定等问题。

（3）运维外包双方的关系复杂性，如双方组织的文化差异、沟通不力风险、信息泄露及人力资源风险等运维外包特有风险。

（4）运维工作本身的复杂性，如技术风险、设备风险、安全风险、运维管理风险和验收风险等。

2.风险分析

运维服务外包是一个复杂的过程，存在许多风险，这些风险主要表现在：

（1）组织成本有可能增加。运维外包合同的价格相对固定，但在合同执行过程中，外包商可能会增加这样那样的附加服务，这些都是在合同中没有的，组织只好照单全收，从而导致组织运维成本增加。

（2）组织对服务商的依赖和外包合同缺乏灵活性可能降低组织的灵活性。组织之所以选择信息系统运维外包，就是希望将自己不擅长的业务交给专业服务商去做，从而达到专注核心业务、节约成本的目的。而组织一旦选择了运维服务外包，就有可能切断了组织学习所处商业领域技术的最新发展及应用途径的机会，形成对服务商的依赖。同时，外包合同通常是中长期的，外包时间越长，组织对服务商的依赖越大。

（3）可能会泄露组织的商业机密。信息技术已经渗透到组织业务的方方面面，不仅非核心业务，而且核心业务也离不开信息技术的支持，服务商完全有可能通过运维外包而接触到组织的商业秘密。一旦外包服务商和组织之间的关系以合同形式加以固定，组织内部的信息技术业务或资源交由外包商管理之后，组织便无法对外包的内容进行直接控制，也得不到来自外包商服务人员的直接报告，加之合同中双方权利、义务的界定不清，失控的风险显而易见。因此，将信息系统运维业务外包出去势必会带来“信息安全”的风险，可能造成业务知识流失或商业秘密泄露。

（4）对外包商缺乏恰当的监管。组织与外包商两者毕竟是相互独立的经济实体，没有任何的隶属关系，虽然组织可以在一定程度上影响外包商的人员调配、资金投入等决策，但仍不能完全保证组织对外包商的有效监管。

3.风险识别

信息系统外包风险评估是在风险识别的基础上，按照一定的参数和方法对风险清单中的风险进行系统评估的过程，主要评估产生的风险的严重程度及给业主方可能带来的损失大小。信息系统运维外包的风险评估方面的方法很多，如风险矩阵法、层次分析法、蒙特卡罗法、关键风险指标法、压力测试法等。

4.风险规避

在复杂的信息系统运维外包过程中，风险无处不在，存在风险并不可怕，只要我们有足够的风险防范意识并采用恰当的风险规避措施，就可以防患于未然。

1）核算外包成本，控制额外支出

组织实施运维服务外包成本核算，就可以清楚了解外包是否能够降低成本，提高利润，以避免高成本风险。外包成本包括显性成本和隐性成本，其中因为隐性成本不好估计，往往造成外包成本大大高于最初的预计成本。因此，核算和控制外包的综合成本十分必要，这其中尤其要考虑到一些隐性成本。

外包执行过程中，由于情况的变化可能会要求外包商做一些原合同中没有规定的额外工作，这会产生额外费用。签订合同前，应充分考虑这些因素，在合同中加以体现，防止外包商漫天要价，从而控制组织外包的成本。

2）组织仍需不断学习

运维服务外包并不意味着组织可以一包了之，不再需要信息管理人员，不用学习相关知识。因为运维服务外包的目的并不是把一个运维项目包出去，而是为了让这个项目为组织的日常运作服务。选择了运维服务外包的同时，一定不能切断组织学习所处商业领域技术最新发展及应用的机会，不管外包项目的大小，都需要保留一部分原先信息管理部门的精英来应对外包后可能发生的各种情况。组织相关高层应该在组织内部倡导良好的信息技术学习氛围，以使组织更好地适应变化的信息环境。

3）选择合适的外包商

选择一个合适的外包商对于信息系统运维外包的成功与否至关重要。组织应通过各种途径，充分了解、评估和确定合适的服务商。主要从技术实力、经营管理状况、财务状况、信誉程度、文化背景等方面对服务商进行评估。

选择了合适的外包商之后，在合同的执行期间，应该重视对外包商的管理。成立监管小组，定期、不定期地对合约的执行情况进行监督，及时补充修改组织的业务需求，及时与外包商进行谈判、磋商等。另外，在对外包商进行管理的同时，还需积极发展与外包商的关系。基于信任、交流、满意与合作的长期互动的关系对于运维外包的成功是非常关键的。

4）签订完整而灵活的外包合同

一份完整而灵活的外包合同是外包能否成功的基石，不同的外包目的和类型，需要不同的外包合同，但一般的外包合同主要包括规定的服务、合同的期限、费用、移交、绩效的标准、争议的解决、保证和责任、合同的终止、其他条款。除一般条款外，还要考虑保密条款、知识产权问题，这对防止商业泄密及知识产权的盗用是相当重要的。

在长期的外包合同执行期间，组织很可能会经历自己独特的增长和变化，所以合同条款应该具有一定的灵活性。需求分析应该对增长和变化做出分析，制定合同时可考虑加入以下内容使合同更灵活：需求变更、价格调整方法、争议解决机制、有关额外服务的条款、合同终止时双方的责任与义务。

2.4 信息系统运维管理标准

运维服务管理是对信息系统整个生命周期的管理，包括信息技术部门内部日常运营管理及面向用户服务的管理。因此，信息系统运维管理涉及人、组织架构、管理、流程及技术等诸多方面，是围绕着技术、人和业务流程三个基本元素展开的。业务目标是保证信息系统正常、可靠、高效、安全地运行，为业务部门提供优质服务。技术指各种管理手段；人员指信息技术支持部门各级员工及面向的用户；流程指信息系统运维的各种业务过程。因此，信息系统运维需要遵照一定的规范、标准对运维服务中的人员、技术、流程进行组织、量度和控制，这几方面互相协调、配合才能够提高运维服务的效率和质量。当前较为典型的信息系统运维管理标准有ITIL、ITSM和COBIT等。

2.4.1 ITIL

信息技术基础设施库（Information Technology Infrastructure Library，ITIL）是英国政府中央计算机与电信管理中心（Central Computer and Telecommunications Agency，CCTA）在20世纪90年代初期发布的一套IT服务管理最佳实践指南。在此之后，一些主流IT资源管理软件厂商在进行一系列的实践和探索的基础之上，总结了IT服务的最佳实践经验，形成了一系列基于流程的信息系统维护的方法标准，用以规范信息系统运维服务的水平，并在2000—2003年期间推出了新的ITIL V2.0版本，这就是目前的ITIL标准。

ITIL为组织的信息系统运维服务管理实践提供了一个客观、严谨、可量化的标准和规范，组织的IT部门和最终用户可以根据自己的能力和需求定义自己所要求的不同服务水平，参考ITIL来规划和制定其IT基础架构及服务管理，从而确保运维服务管理能为组织的业务运作提供更好的支持。对组织来说，实施ITIL的最大意义在于把IT与业务紧密地结合起来，从而让组织的IT投资回报最大化，克服信息系统运维服务质量提升的阻力，提高运维资源利用率，降低成本，提高适应变化的灵活性，科学地管理运维风险，最终实现信息系统运维目标以支持组织战略转型。

2.4.2 ITSM

信息技术服务管理（IT Service Management，ITSM）参考模型是HP公司以ITIL为基础并结合该公司多年的IT管理实践而开发的IT服务管理方法论。自2000年1月份发布2.0版本以来，该方法论在HP公司的努力推广下，在世界范围内得到了一定程度的认可。

系统主要由服务台/事件管理、变更管理、问题管理、配置管理、服务级别管理、计划任务管理、知识管理及统计报表管理等内容组成，同时需要支撑业务系统的工作流系统，表单自定义系统和用户、权限管理系统等后台支持系统组。

（1）服务台的功能：主要是接收用户的运维服务申请，能够及时响应用户的服务申请，跟踪服务的进度，采集用户的反馈意见；自身不能解决的申请将转交到二线或三线进行处理。

（2）事件管理：通过利用事件管理流程，能够确保支持资源集中在最紧迫并且可能对业务产生重大影响的问题上。

（3）问题管理：问题管理流程的根本目的是消除或减少事件的发生，此流程分析发生在生产环境的事件，确定最常发生或具有重大影响的事件，找出根本原因，然后生成变更请求。

（4）变更管理：变更管理控制和管理整个IT运行环境中的一切变更，并和配置管理建立接口。变更的分类包括：常规变更、非常规变更。

（5）配置管理：配置管理用于描述、跟踪、控制和汇报IT基础架构中所有设备或系统的管理流程，实现识别和确认系统的配置项，记录和报告配置项状态及变更请求，检查配置项的正确性和完整性等。

（6）服务级别管理：服务级别管理是指组织在可以接受的成本条件下，就信息系统运维服务的质量所做出的包括谈判、定义、评估、管理和改进等在内的一系列管理活动。

（7）计划管理：通过本模块实现人员的值班安排，巡检计划的制定、分派、执行、任务提交、审核及关闭。

（8）统计报表：对以上管理数据进行统计输入形成各种报表。

（9）知识库：将成熟可行的运维解决方案录入知识库，进行数据共享，方便查询，快速排除故障，从而达到提高用户“自助式服务”能力的目的。

2.4.3 COBIT

信息系统和技术控制目标（Control Objectives for Information and Related Technology，COBIT）目前已成为国际上公认的IT管理与控制标准。该标准为IT治理、安全与控制提供了一个一般适用的公认框架，以辅助管理层进行IT治理。COBIT是基于已有的许多架构建立的，如SEI（Software Engineering Institute）的能力成熟度模型（Capability Maturity Model，CMM）对软件组织成熟度五级的划分，以及ISO9000等标准。COBIT在总结这些标准的基础上重点关注组织需要什么，而不是组织需要如何做。它不包括具体的实施指南和实施步骤，它是一个控制架构，而非具体过程架构。

COBIT覆盖整个信息系统的全部生命周期（从分析、设计到开发、实施，再到运营、维护的整个过程），从战略、战术、运营层面给出了对信息系统的评测、量度和审计方法，起到了组织目标与信息技术治理目标之间的桥梁作用，在业务风险、控制需求和技术观点之间建立了一种有机联系。COBIT框架如图2-13所示。

COBIT完全基于信息技术准则，反映了组织的战略目标。信息技术资源包括人、应用系统、信息、基础设施等相关资源，信息技术管理则是在信息技术准则指导下对信息技术资源进行规划处理。COBIT将信息技术过程归并为四个控制域：计划与组织、获取与实施、发布与支持，以及监测与评估，在这四个方面确定了34个处理过程和318个详细控制目标，通过定义这些目标，可以实现业务对信息技术的有效控制。此外，每个过程还有相应的评审工具。