IT运维支持和通讯服务项目项目管理制度

IT运维支持和通讯服务项目

项目管理制度

1.1事件管理

LL1总则

1）各项目根据事件的影响和紧急程度确定事件处理优先级别，并基于优先级别确定解决

事件的目标。其中应包括：

•接收请求、记录、优先级分配、分类。

•一线事件解决或转移。

•考虑安全事件。

•事件跟踪和生命周期管理。

•事件验证和关闭。

・一线客户联系。

•事件升级原则及方式。

•事件通知规则

2）事件报告方式包括电话、拜访、传真或者电子邮件，所有事件应在服务台正式记录，

并可检索和分析。

3）二线人员对升级的事件提供解决方案，协助一线关闭事件。

4）项目应建立事件知识库，以确保项目成员可访问经常更新的知识库。知识库中包括技

术专家、以前事件、相关问题、已知错误、配置管理数据库（CMDBX检查清单等

有助于恢复服务的各种信息。

5）应制定重大事件处理流程，确保重大事件能够得到迅速解决。

6）应在证实事件已经解决并且服务已经恢复的时候，事件才能最终关闭。

7）制定事件升级和通知规则，确保各种事件能够得到处理和告知相关干系人。

8）在事件处理过程中,应将处理过程情况及时向本项目及客户及时进行告知、请示、确

认。

1.1.2事件分类

事件类别说明备注

UPS故障：影响数据中心生产运行的UPS故障的现象

空调故障：影响数据中心生产运行的空调故障的现象

消防设备：影响雌中心生产运行的消防设备故障的现象

电池组：影响数据中心生产运行的电池组故障的现象

柴油机：影响数据中心生产运行的柴油机故障的现象

监控系统：影响数据中心生产运行的监控系统故障的现象

通信设备：影响数据中心生产运行的通信设备故障的现象

智能配电柜：影响数据中心生产运行的智能配电柜故障的现象

网络故障：所有可能会影响到用户网络连接的现象

可能会影响到用户n■生软化水装置：影响数据中心生产运行的软化水装置故障的现象

故障产运行或产生负面影响变压器故障:影响数据中心生产运行的变压器故障的现象

的的现象门禁系统：影响数据中心生产运行的门禁系统故障的现象

操作系统：影响基础应用系统的操作系统故障的现象

网络与安全：影响网络与安全的故障现象

服务器：影响基础应用系统的服务器硬件故障的现象

软件：影响软件的故障现象

桌面.影响PC终端的故障现象

IP电话：影响IP电话的故障现象

卫星：影响卫星通讯的故障现象

视频会议：影响视频会议的故障现象

从服务台接收到的业务

业务支持、信息咨询、

处理信息、场地设备技

服务请求

术支持以及办公软硬件

辅助配合、文档需求

资料供应

包括非授权访问、信息

泄密、拒绝服务、病毒保密协议、外来人员管理、门禁卡申请、设备移入移出、不安全操作、拒

安全事件

攻击、恶意入侵、其他绝服务

入侵

投诉与建议，非本部门

其他工作范围发生的但对客备件入库、接受投诉及建议

户造成影响的故障

•二级事件分类请参照附件《BGPITCJTSMT-INGOOl事件分类分级说明》

1.1.3事件分级

1.1.3.1影响程度分类

事件优先级别的判断通常要考虑事件影响程度和事件的紧急程度，SLA的等级也应纳

入考虑之中。

对事件的影响程度分为四个等级：1级事件，II级事件，in级事件和IV级事件。事

件影响程度的划分主要考虑两个维度：事件的影响面积和事件的影响深度。

1.1级事件：

I级事件是指导致特别重大影响或破坏的事件，包括以下情况：

a）造成业务大面积瘫痪，使其丧失业务处理能力，恢复业务正常运行和消除事件负

面影响所需付出的代价十分巨大；

b）产生的影响会波及到一个或多个区域的大部分地区，严重损害所有或大部分客户

的利益。

2.II级事件：

II级事件是指导致重大影响或破坏的事件，包括以下情况：

a）造成业务长时间中断或局部瘫痪，关键业务无法进行，使其业务处理能力受到极

大影响，恢复系统正常运行和消除事件负面影响所需付出的代价巨大；

b）产生的影响波及到一个或多个区域的大部分地区，损害到大部分客户的利益。

3.III级事件:

III级事件是指导致较大影响或者破坏的事件，包括以下情况：

a）使关键业务造成较大的损失，即造成业务中断，影响业务处理能力，恢复系统正

常运行和消除安全事件负面影响所需付出的代价较大；

b）产生的影响波及到一个或多个区域的部分地区，影响到部分客户的利益。

4.IV级事件：

IV级事件是指导致较小影响或者破坏的事件，包括以下情况：

a）造成业务短暂中断，影响业务处理能力，恢复业务正常运行和消除事件负

面影响所需付出的代价较小；

b）产生的影响波及到一个区域的部分区域，影响到部分或个别客户的利益。

1.1.3.2紧急度分类

考虑到事件的相关要素，将事件的紧急度划分为特别紧急，紧急，一般。

1.特别紧急

a）时效性极强，要求在很短时间内恢复的事件；

b）要求服务台响应E寸限为5分钟，工程师解决时限为2小时。

2.紧急

a）时效性强，要求在较短的时间内恢复的事件；

b）要求服务台响应时限为10分钟，工程师解决时限为6小时。

3.一般

a）时效性一般，对恢复时间要求不高；

要求服务台响应时限为20分钟，工程师解决时限为48小时。

1.13.3事件分级

根据事件影响程度和紧急度事件分级如下：

事件优先级影响程服务恢是否为重

紧急度详细定义

豳分类度复时间大事件

*指导致特别重大影响或破坏的事件，时效性极

强，要求在很短时间内恢复的事件，包括以下情况：

a）如电力系统故障要求在30分钟内进行处理。

特别紧<30-60b）如设备多台故障，造成全部业务中断，使其丧失

1级非常高I级是

急分钟业务处理能力，恢复业务正常运行和消除事件负面

影响所需付出的代价十分巨大

c）产生的影响会波及到一个或多个区域的大部分

地区，严重损害所有或大部分客户的利益。

*指导致重大影响或破坏的事件，时效性强，要求

在较短的时间内恢复的事件，包括以下情况：

a汝口设备故障造成客户设备长时间中断或局部瘫

<120分痪，关键业务无法进行，使其业务处理能力受到极

2级高n级紧急否

钟大影响，恢复系统正常运行和消除事件负面影响所

需付出的代价巨大；

b）产生的影响波及到一个或多个区域的大部分地

区，损害到大部分客户的利益。

*指导致较大影响或者破坏的事件，时效性一般，

对恢复时间要求不高，包括以下情况：

<180分

3级中m级f否产生的影响波及到一个或多个区域的部分地区，影

钟

响到部分客户的利益.包括机房场地等方面，如门

禁系统出现故障

<240分*故障处理中程度比较简易，时效性一般，对恢复

4级低IV级否

钟时间要求不高，如：摄像头故障、防火门故障

各项目根据自身情况制定相应的上报和处理流程

1.1.4事件状态

为方便事件状态的跟踪和查询，对事件状态定义如下。

编号状态描述

1待处理已在系统中记录，未派单给工程师

2已派单已分配至工程师，工程师未处理

3处理中工程师正在处理过程中，事件未关闭

4挂起工程师正在处理，调用三线厂商支持或送外修，尚未完毕

编号状态描述

5暂停工程师正在处理，因客户原因暂时无法处理

6待审核事件已关闭，等待项目经理审核

7已归档服务台已审核归档，服务台回访客户结束。

1.1.5事件上报流程

部门事件上报流程统一参考如下：

1.1.6事件处理流程

在事件处理过程中要根据事件影响程度和严重程度将时间处理过程告知受影响的客

户和相应客户主管领导及公司质控中心。

1・1・6・1一级事件处理流程

一级事件上报流程统一参考如下：

1.1.6.2二级事件处理流程

二级事件上报流程统一参考如下:

1.L6.3三级、四级事件处理流程

三、四级事件上报流程统一参考如下：

1.1.7事件升级流程

如果事件未能及时按照预定的时间得以解决或技术能力不足，未能满足用户要求，或

者需要管理层参与，以提供更多资源，则进行事件升级。

1.按照问题的解决时间进度设置升级的时间段，如果在预定时间段，问题没有解决，

需要进行事件升级。在设定预定时间段时，应考虑留有足够的时间以进行管理升

级采取必要措施（如引入第三方支持工

2.在事件解决过程中，由于操作失误导致更高等级事件的发生时，需要将事件及时

升级。

3.因为技能或经验的缺乏，需要寻求部门二线专家支持，可以通过服务台或支持工

程师进行人工要求进行事件升级。

1.1.8二线技术支持申请流程

部门设立统一的二线支持电话：xxxxxxxx，当一线工程师无法处理事件需要寻求部

门二级专家支持时，统一通过此支持电话申请。流程如下

1.2周期类服务

现场工程师定期去伊拉克哈法亚机房巡检，巡检机房内的网络设备（路由器、交

换机、防火墙等）和服务器。具体流程如下所示：

1）现场工程师每天对伊拉克哈法亚机房进行例行巡检。填写《附录2.3运维检查

表》。

2）如果机房巡检一切正常，填写《附录2.3运维检查表》，关闭事件，完成巡检。

3）如果机房巡检出现异常，由伊拉克哈法亚现场工程师判断问题或事件是否属于

重大事件。如果属于一般类事件则参见操作手册对事件进行处理。伊拉克哈法亚现场

工程师无法解决则升级到二线工程师共同解决。

4）如果属于重大问题或事件则需要制定重大事件解决方案，并告知甲方领导方案

实施的事件、地点、风险和相应的应对方案，得到甲方领导书面确认后方可实施。实施完

毕后工程师提交《重大故障报告单》并关闭事件。

1.3问题管理

1.3.1目的

主动识别、处置对IT服务造成影响的因素或潜在原因以减少对IT服务运营的影响。

1.3.2总则

1）各项目应制定相应问题管理制度对问题原因的预先识别、分析、管理直至关闭，以减

少对业务的影响。

2）项目一线人员根据日常检查、测试、事故数量?口类型的趋势分析等纠正措施，识别潜

在问题。所有被识别的问题都应该得到记录。

3）在问题得到解决后，应将相关信息应加入问题知识库，同时应升级所有相关文件，如

用户指南和系统文件。

4）记录对服务或问题管理流程的改进，完善已知错误数据集形成知识库，并作为服务改

进计划的输入和为知识分享提供资料。

1.3.3术语

1）问题：引发一个或多个事件的未知因素。

问题通常具有如下特征：

•一组具有一定关系的已结束的事件

•一个重大事件

问题的根本原因找出后即成为已知错误；许多事件往往是有一个问题引起的。

问题管理流程的输出有：

•变更请求

•临时解决措施

•预防性措施

2）已知错误：查明事件原因并且已有临时、应急处理措施的问题。

3)主动问题管理：

•通过改进基础设施以及提出变更请求来阻止可避免事件的发生。

•通过找出基础设施中的薄弱环节来阻止事件的再次发生，以及提出消除这些薄弱环节

的建议。分析基础设施的运行趋势并找出那些潜在事件以防止其发生。

1.3.4问题分类分级

问题的分类分级原则上于事件的分类分级一致。

1.3.5问题状态

为方便问题状态的跟踪和查询，对问题状态定义如下。

编号状态描述

1处理中问题正任处理过程中

2拒绝问题分派被拒绝

3已知错误问题根本原因已找出

4RFC已提交变更请求(RFC)

5关闭关闭

6没有解决问题没有解决

1.3.6问题处理流程

1.相关人员根据各类分析报告进行趋势分析发现潜在问题，并创建问题申请单；或接收

到已知错误，更新和发布已知错误数据集，以便于其他管理程序和相关人员及时了

解相关信息。

流程说明;

序号流程编号流程描述成果物负责人参与人

1.开始流程的起始节点

PRO-1-01

分析各类报问题支持

•依据制发问题的条件定期对各类报告

2.

告，识别问进行趋势分析,发现潜在问题。团队/人员

想

PRO-1-02•若查明某问题的根本原因形成已知错

误后，或在发布管理流程中产生的已问题支持

3.更新已知锦已知错误

知错误，将这些已知错误更新至已知团队/人员

误数据集

错误数据集-

PRO-1-03

发布更新后的已知情误数据集,通知问题支持

4.发布已知错已知错误

相关人员。团队/人员

误数据集

PRO-1-04

创建问题申请单,并对问题信息进行问题支持

5.创建问题申问题申请单

记录与描述.团队/人员

请单

6.结束流程结束他点

2.团队/项目负责人接到问题申清后，在对问题进行初步分类和优先级判断后协调相关团

队/人员分析问题产生的原因，查找可行的问题解决方案并解决问题。

流程说明:

序号流程编号流程描述成果物负责人参与人

1.开始流程的起始节点

PRO-II-O1・记录主动显现所HJH和^动叁现的问

的as支rr

2.id录与分类e(

♦根IttlHIH所《«顿城当打分光.71r睛1队，人员

问也

判断向MS的优先级.

■同胃依友人*r新建的HJS进行小核.

R"唾仇*人确定触JSS是否有效、是苦

是手里同整.优先级的分国足与A■适.

的期佑总项填”虻公先修：

PRO-II-02•如果1词理确认无效.则关即网IS.并

同祖

3.审批与分掘如Ini寺求才；

•根据阿鹿的分类.忙1；”也外派匕；相卜"ei寅人

1句fig

向1S文打闲队/人员.如何尊上抬4不队

/人出发现问膻应透山44他。尿分■所

M决，就把发J可同期”1m人.注

矶拒绝理由并推存共他*jeg支持•阳队

/A«.

•胸JS2支内团队/人兄接受问电.更新问

题状W及id泉实标升蛇诊断可问：

•加制共他团队双人员协助分析、诠断•

则通知例现以友人.由向SSS.近人协

训留源.成立可1»分析〜云:组.举行

同《4根本原闲分析研i才会i义.确定向

PRO-II-03

色的泄在日凶.提供政史新问世变他MJJS支师

4分析与诊断方法，以陵低向电在根本M决ffir对业

M1KK/AM

问吆务产生的，响：

•曲间也产生小本原内及变通方■法及时

更新到问题id录中：

•格问《s根冷近闪及变域方法通如何电

负责人,

•31%何地支用⑷队/人MJL/找利向

86的根4而LM.及时iffi报同Jffitft雷人。

•对十一经拄剂根本燎内的同as.m

酹定解决方案.以便水久解决何必：

•A■找并2m板小ttx决方•案.确保万

案能彻底M决问跑.更新问迎记录中

的女配衿断”.slfir+fnit

•刘断实施上还解决方案/变侬方”、柜

苏需彩通过其他流程（如变曳流程

等,，

-如需殁.提文列相应的流程.并

PRO-11-04交史请求同图文时

5.和诿流叫人员保持沟通.rx同

修决何这<RFO团队/人员

AS的M决状况：

-如不需变变更.计划并组织女的

杆决方案以N决问电1

•加5R1B案第三方介入.则阿图士用闭

队/人出负声与第：方的协四：

•如朱阿咫支将团队/人员便计无法找

列根本解决方案成圾有解决方案但门

前无法实施（如文岫的代价大太），i6

报MIS伏贲人.

向分机报

•♦认同咫是杳被正*用«*决.ftiJRci

PRO-II-05侬“二硫触决.问as负赤人通知问at立告MS

6.

关闭网睡舟团队/人GX闭问题；己如铮误我贡人

■更新己知怙设飨。同*s记录m

7.纬来流程结束予，%

•如果问题的解决涉及到用户的变更，则及时与客户沟通协商解决方法。

1.4变更管理

1.1.1目的

规范所有IT变更，从而保证由于变更而引起的对生产的影响降到最小，提高IT系统

和服务的质量，为业务的快速发展提供更优质的IT服务

1.1.2总则

1）部门及各项目根据公司业务需要或客户需求，制订相应变更管理流程。

2）部门及项目组在组织、开展变更时，应对一下要素进行说明：发起、记录和分类、评

估变更对服务、客户和发布计划的影响、紧急程度、成本、收益和风险、如果没有成

功时可以恢复或修订、备案，如变更请求与受影响的配置项、更新后的实施和发布计

划版本、根据变更的类型、大小和风险，得到变更负责方的认可或拒绝、由负责变更

组件的团队负责人进行实施、测试、验证、取消、结束和评审、时间安排、监控和报

告、与事件、问题、其它变更和配置项记录联系。

3）部门及项目组应将要进行的变更的时间信息及时提供给与变更有关的人员，变更状态

和安排的实施时间应作为变更和发布时间安排的依据。

4）部门及项目组应在变更实施后组织对其效果和改进记录进行评审，评审结果应妥善保

管并作为服务改进计划的输入。实施后评审应检直：变更是否满足目标、客户对结果

是否满意、没有预期之外的负面影响。

5）部门及项目组对变更分析结果和结论采取相应的纠正、预防措施，并保存相关的记录。

1.1.3变更分类

变更分类原则根据事件分类原则保持一致。

1.1.4变更上报

1,重大变更必须提交你提交变更委员会审批，变更事实结束后将变更执行结果上报至变

更委员会备案；

2,变更委员会负责审批高风险的变更，风险高、影响范围大时，变更负责人需要将变更

影响上报至公司和客户；

3,紧急变更委员会负责审批时间紧迫、风险等级高的变更。

1.1.5变更通知

1.对现有业务系统产生影响的变更，例如因实施变更而需要停机或者中止业务，均需在

变更执行前提前通知有关人员做好业务调整，减少对业务的影响，待实施完成后再次

通告；

2.如变更影响到客户使用业务系统，需要以不同的方式通知客户。

1.1.6变更类型

变更类型用于区分变更，提高变更处理的效率。

编号代码描述

指频繁发生、影响范围较小、紧急程度较低、实施风险较小（不会带来重大后果\

1简单变更

实施较简单的变更，如库表大小的改动，crontab时间的修改，文件的删除等。

指涉及影响范围较大（影响客户、业务部门、分公司或者社会影响较大\实施风

2标准变更险较大、实施按复杂的变更。这些变更可以进行充分的计划和测试。如业务割接、

机房搬迁、软件升级等。（需求审批；上线审批）

指如果不进行变更，会立即或正在严重影响业务运行、导致严重影响服务等级或者

3紧急变更带来重大影响的变更，应当得到尽可能快速的处理,减少流程的复杂性，但是又要

有良好的控制。如紧急事件引发的紧急变更。

1.1.7变更风险等级

除简单变更外，项目经理、变更委员会/紧急变更委员会对标准变更和紧急变更根据下

表所列的衡量因素来量化评估实施变更可能带来的风险，该评估结果用于决定是否批准变

更，是否需要更高级别的审批，以及实施完成后的观察期。该评估由项目进行初步评定,

再由变更经理或变更委员会进行最终确定。

风险等级量化评估表如下：

衡量因素条件得分

影响全部用户和全部业务1

影响部门用户和部分业务2

地区n用户数量（受到

实施或取消的影响）影响全部用户3

影响部分用户4

3个或更多支持小组1

2个支持小组2

准备/实施必需的资源

超过1人，相同的支持小组3

1人4

无法测试，变更失败可能性很高1

能支现部分则试，变更失败可能性较高2

变更成功的可能性

有成熟的变更方案，变更失败可能低3

无需测试，变更失败可能性没有4

6天或更长1

2-6天2

变更规划时间

1-2天3

小于1天4

超过2小时或在线/服务断供期1

1-2小时2

变更实施时间

不到1小时3

不到30分钟4

衡量因素条件得分

回退时间超过2小时1

回退难度中等以上（1-2小时）2

回退时间

回退难度适中（1小时或更短）3

易于回退（30分钟或更短）4

根据上表对每个变更进行评估，最终得出风险等级。风险分为四个等级：重大、高、

中、低。不同的风险等级分别有对应的审批级别和实施完成后的观察期，具体定义如下表:

总得分对应风险等级对应审批级别实施完后的观察周期

6-9重大变更委员会、部门经理5-7天

10-13高变更委员会4-5天

14-17中项目经理2-3天

18+低项目经理1天

1.1.8流程主要内容

变更管理流程始于变更的接收，结束于变更的实施和回顾。该流程包含下述主要内容：

•提出变更请求（RFC\评估、分类

变更申请人提出变更请求（RFC）,由项目经理负责检查和完善其内容，通过查询配

置管理数据库，进行风险等级的初步评估；并尽量提出可能与业务发生的关联的影响，

已供决策参考。变更土管井对变更进行分类；如为紧急变更，则需要各项目制定紧急变

更流程并按照紧急变更流程执行；如为简单变更,直接制定变更计划，经变更委员会审

批通过后并安排实施。

•项目经理评估、审批

项目经理接受变更请求（RFC）,如果确定是紧急变更，则快速完成评估、审批。对

标准变更，确定变更风险等级，审阅变更实施计划、测试报告、回退计划和配置项更新

计戈!1,批准或驳回变更申请，如需要更高级别管理层的审批，则根据不同风险级别报批。

•变更委员会（CAB）/紧急变更委员会（EC）评估、审批

项目经理将根据特定的变更请求成立特定的变更委员会（CAB）/EC,成员包括对该

变更的评估和批准提供应有附加价值的技术人员和管理人员，审阅工作包括变更的风险、

对现有服务的影响、实施计划、回退计划和配置项更新计划等，并做出批准与否的决定。

如为紧急变更，则快速完成以上评估、审批。

•管理层审批

对于风险等级为“重大"的变更，在变更委员会审批通过后，必须再由项目经理报请

至部门管理层审批。

•项目经理负责组织制定变更计划、测试

项目经理安排并协调相应资源制定变更计划，包括实施计划、测试计划、回退计划、

配置项更新计划等。应安排对实施计划和回退计划进行测试，随后将测试结果、实施计

划、回退计划、配置项更新计划等提交给上级领导审核。

•协调变更实施

项目经理负责协调资源，准备实施前相关工作,组织人员按计划实施变更，变更主管

监控实施过程和结果，井在必要时进行协调或做出决定。在这阶段可能需要变更经理和

变更委员会成员的帮助。

•回顾和关闭

实施变更后项目经理确保配置项及时得到更新，并协同变更经理负责从技术、管理、

业务角度去回顾变更，确保变更请求（RFC）得到了预期效果，并寻找改进机会或行动

计划，在回顾过程中可能会需要得到变更委员会中相关领域的技术人员的帮助，随后更

新变更记录并关闭变更请求（RFC\

1.1.9紧急变更流程

流程说明:

序号活动/子流程描述成果物负责人参与人

1.开始流程开始流程的起始节点。

L2.1

•变更负责人接收紧急交更申请

2.接受紧急变更申变更负责人

单，分析紧急变更单内容.

请单

•变更负责人接收紧急变更单后，

L2.2判断变更是否为紧急变更：

3.变更负责人

是否案急变更•变更负责人有权ift过或拒也紧

急变更申请.

L2.3•变更负贵人判断是否需要ECAB

4.是否需要ECAB参参与评估审核紧急变更申请单：变更负责人ECAB

与评审•如果需要变更负责人将与ECAB

其他成员共同评估审核紧急变

史申请单•・

•如果变史UJECAB共同.

估审批紧急变更申请单，将由双

L2.4方共同调配紧急变更所而责-h

5.•如果变更负责人判断不，变更负责人ECAB

分配资源

ECAB参与评估审批紧急变更，

将由变更负责人能独调配紧急

变更所需资源。

•变更负贡人接收来自变更执行

人的紧急变更申请电实俺完紫

急变更后通知变更负责人：

•变更负责人对紧急变更结果进评估结果反

L2.5变更执行

6.行评估,审核其是否达到预期结惊、发布申变更负责人

实施后评估人

果：请单

•变加负责人根据评估结果反馈

判断比次紧急变更是否会引起

新的事件、问题或发布.

L2.6•紧急变史实能结束由

7.变更负责人

补充相关单据贡人指导完成相关m据说明.

•紧急变更如果涉及到发布管理.

将在变更实施成功后通知发布

L2.7变更执行

8.管理进行处理：变更负责人

提交发布人

•此it作可由变更£'史更

执行人中的任意角色承担。

•变更执行人接收来自紧急变更

负责人的通知,实施紧急变更：

L1.1变更负责

9.•紧急变更实施完成后，变更执行变更执行人

实施紧急变更人

人更新紧急变更申请的，提交变

更负责人分析.

L3.1

•如果交火负责人判断需要ECAB

参与评估审批紧变更负责

10.参与评估审批紧急变更，双方将ECAB

急变更