运维管理需求0828.docx

运维管理需求0828.docx

《运维管理需求0828.docx》由会员分享，可在线阅读，更多相关《运维管理需求0828.docx（100页珍藏版）》请在冰豆网上搜索。

运维管理需求0828

1服务流程需求

1.1服务管理平台功能描述

服务管理平台应注意实用性和先进性的平衡，充分考虑流程角色与实际组织的映射、流程环节与实际工作的对应、ITIL术语与各省习惯用语的翻译，在保证流程实用性的前提下借鉴ITIL3.0、ISO20000理念，保证规范的先进性。

另外，服务管理平台还应该满足高可靠性、开放性、可扩展性和性能、安全方面的要求。

1.1.1功能模块

系统包括的模块是：

1、服务台；

2、事件管理；

3、问题管理；

4、变更管理；

5、配置管理；

6、发布管理；

1.1.2功能综述

在业务功能层面，服务管理平台应支持事件管理、问题管理、配置管理、变更管理、发布管理和日常运维管理，支持流程的持续改进。

Ø日常运维管理包括值班管理、作业计划管理、机房进出管理和知识经验管理等内容，主要定义和规范日常进行的常规任务和工作。

Ø事件管理记录和管理故障从发生到业务恢复的过程，主要包括来自BOMC业务管理平台的故障告警、来自客服和业务部门的客户投诉，也包括来自其它业务部门的服务请求。

Ø问题管理记录和管理故障根源分析和解决的过程，包括事件处理在业务恢复后仍需进行深入分析的故障、日常维护中发现的尚未影响业务的故障、工作例会上对事件进行趋势分析确定的潜在故障。

Ø配置管理数据库CMDB记录和维护IT基础架构和业务应用的配置项CI、相关属性信息和CI的相互之间的关系。

配置管理是对CMDB的规划、建立、维护和审核过程的管理，保证CMDB的完整性、时效性和权威性，为其它流程提供良好的支撑。

Ø变更管理跟踪和记录变更评估、审批、实施和验证的过程，包括IT基础架构中设备、部件、配置的新增、变更和下线，也包括日常业务需求的新增和变更。

项目性质的业务需求管理不属于变更管理过程。

Ø发布管理跟踪和记录新系统测试、培训、部署、割接上线的过程，包括大版本测试上线发布和日常需求变更的测试、割接。

1.1.3服务台

系统采用B/S结构的用户界面和浏览器界面，为运维值班人员提供了一个完整的值班管理服务平台。

服务台需要实现如下目标：

●建立统一的事件、服务入口，所有的事件都经过服务台进入服务支持流程；

●服务台成为事件的“主人”，负责受理、调派、维护、跟踪、反馈；

●统一服务级别，给用户一个唯一接口来体现IT的服务；

●通过知识库强化服务台一线解决问题的能力，提供更为快捷的解决问题的团队；

1.1.4事件管理功能

1.1.4.1流程目的

事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括：

❑在成本允许的范围内尽快恢复IT服务

-快速响应服务请求（电话/Web/邮件等）

-用户在线获得帮助

-沟通事件解决的状态

-和客户确认事件的解决

-启动应急预案

❑进行事件控制

-按规范记录事件

-就事件的优先级，影响度进行分类

-分析，诊断，必要时进行升级

-监视并结束事件

-进行定期服务流程回顾

❑提供IT管理信息

-人力资源利用情况

-故障处理情况

-支持效率

1.1.4.2流程主要内容

事件管理流程始于事件的接收和报告，结束于事件的解决。

该流程包含下述主要内容：

❑事件检测和记录

这个环节是事件管理流程的起点。

所有用户或系统报告的IT事件必须由此步骤开始。

此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。

在此步骤中将会收集创建事件记录所需的信息。

该环节的关键是信息的准确性和完整性。

❑分类和初步支持

对于每个事件，需要确立优先级和分类。

若没有现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。

❑调查和诊断

若支持人员无法解决事件，可运用自身技能、知识库、诊断工具等进行更加深入的分析以找到恢复服务的临时措施，必要时可调用多名支持人员以寻求解决措施。

❑解决和恢复

支持人员实施事件的解决方案，并将解决完毕的事件转回服务台，由服务台通知用户解决的结果，并得到用户的确认。

❑优先级为紧急的事件（紧急事件）和事件升级

对于紧急事件，服务台应立即提交给一线人员，由一线人员判断，上报给事件经理和相关的管理层，由事件经理决定紧急事件的处理方式，确保其得到最快速的解决。

当事件处理超过预期时限，将自动通知处理人员和相应管理层，以引起相关人员和管理人员的重视和参与。

❑结束事件

当用户确认事件解决后，此时可结束该事件。

1.1.4.3与其他流程的关系

❑和问题管理流程的关系

事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为紧急的事件解决并恢复服务后做为问题进行进一步的分析和处理。

❑和配置管理流程的关系

需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。

❑和变更管理流程的关系

服务台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。

在事件的解决过程中，必要时需要发起变更请求来解决事件。

❑和知识库的关系

事件得到解决后，解决的过程中所获得的经验以及相关解决方案可以进入知识库，作为知识保存，为后续的工作提供指导。

1.1.4.4事件工单信息项

序号

信息项

说明

1

事件ID

事件单流水号（系统自动产生）

2

请求人信息

事件申报人的信息，包括：

姓名、省/分公司、部门、电子邮件、办公电话、手机（手工填写）

3

登记时间

在服务台生成事件记录的时间（系统自动产生）

4

地点

事件发生的地点（手工填写）

5

事件发生时间

针对故障：

指的是业务中断的实际时间（可能早于登记时间，需要手工填写）

针对其它：

缺省值等于登记时间

7

事件性质

参见“事件性质”定义

8

事件来源

参见“事件来源”定义

10

事件优先级

参见“事件优先级”定义

11

事件完成期限

对应每一个事件优先级，系统根据流程相关定义中“事件解决时限”自动设定最终的完成期限（系统自动产生）

12

所属系统类型

参见“所属系统类型”定义

13

事件分类

参见“事件分类”定义

14

事件标题

事件的简要描述（手工填写）

15

事件描述

对于整个事件内容的详细描述（手工填写）

16

事件解决人

事件的最终解决人（手工填写）

17

事件状态

参见“事件状态”定义

18

分配对象（责任人）

被分配的技术支持组和人员（手工填写）

19

事件日志

反映事件信息项的变化历史，如一个事件在处理过程中事件状态变化的时间点等信息（系统自动产生）

20

解决方案

事件解决方案的描述（手工填写）

24

事件结束代码

参见“事件结束代码”定义

25

重复事件标记

标记为重复事件（手工填写）

25

处理是否超时

根据系统“SLA服务级别”设定判断（系统自动产生）

26

事件解决人角色

参见“事件解决人角色”定义

27

实际开始时间

记录事件状态到XX处理中的时间（系统自动产生）

28

实际完成时间

记录事件已解决的时间（系统自动产生）

29

故障厂商

参见附录C厂商和集成商名称标准（手工填写）

30

关联配置项

记录出现故障的配置项代码（系统手工关联选择）

31

关联的问题单号

记录由事件引发问题时，关联的问题单号（手工填写）

32

关联的变更单号

记录由事件引发变更时，关联的变更单号（手工填写）

1.1.4.5事件来源

1.1.4.6事件性质

事件性质定义为如下五类事件：

编号

代码

描述

1

客户投诉

2

系统故障

指因业务支撑系统错误或反映支撑系统部分或全部功能不能正常使用的报障

监控管理平台上报的影响系统正常使用的告警

3

业务可用性告警

业务服务管理平台上报的用户体验和业务影响告警

4

平台告警

监控平台自动产生的没有影响到系统正常使用的告警

5

服务咨询

指对系统操作、业务流程等方面的求助和询问

1.1.4.7所属系统类型

定义业务系统。

当事件发生时，应该由服务台初步定位是哪个系统及子类出现问题，由一、二线进行进一步的明确。

这个部分如事件分类一样，用户可以自定义系统类型。

如：

业务系统

子类

BOSS系统

营销管理

渠道管理

客户服务

产品管理

客户管理

订单与服务请求管理

服务开通

资源管理

综合采集

融合计费

综合帐务

综合结算

合作伙伴管理

基础功能

统计报表

一级BOSS

其它

客服系统

经营分析

容灾系统

BOMC

其它系统

1.1.4.8事件分类

事件分类代码用于标识故障或申告的具体原因，由支持人员在处理过程中填写。

在制作统计报表时，可以通过和所属系统类型代码的结合来统计分析故障或申告。

事件的分类层次设计不超过三层，第一级分类，称之为“类别”，第二级分类，称之为”子类”，第三级分类，称之为”条目”。

表1．事件分类

类别

子类

条目

系统硬件

小型机

PC服务器

路由器

网络交换机

磁盘阵列

存储光纤交换机

磁带库

安全设备

系统软件

操作系统

数据库

中间件

集群软件

备份软件

系统管理软件

安全软件

应用软件

进程

数据

参数

代码

接口

客服设备

排队机

CTI服务器

CCS

IVR服务器

配套设施

UPS

空调

其它

1.1.4.9事件优先级

优先级是事件管理的一个关键要素，优先级决定处理事件的顺序及所需的资源，事件优先级可分为四级（紧急、高、中、低）。

1.1.4.10事件状态

事件状态代码表明事件所处的处理状态，事件状态如下：

编号

代码

描述

1

已登记

新开事件记录或事件已创建

2

分配到服务台

事件已分配给服务台人员

3

分配到一线

事件已分配到一线支持，一线还未响应

4

分配到二线

事件已分配到二线支持，二线还未响应

5

分配到三线

事件已分配到三线支持，三线还未响应

6

一线处理中

一线支持人员已接手处理事件

7

二线处理中

二线支持人员已接手处理事件

8

三线处理中

三线支持人员（厂商）已接手处理事件

9

已解决

事件已解决，支持人员联系用户验证事件是否获得解决

10

关闭

事件已关闭

1.1.4.11事件流程设计

大的流程是服务台---》一线支持---》二线支持----》三线（预留接口可先不考虑）----》触发其他流程（预留接口）

序号

步骤名称

责任人

说明

100.1

事件记录和分类

服务台

❑服务台对来自用户和系统自动产生的事件进行详细记录，主要包括来自IT基础架构的故障告警、来自客服和业务部门的客户投诉，也包括来自其它业务部门的服务请求

❑服务台负责在接收到事件后进行分类转发，对申告/告警/咨询/故障类事件进行分类转发

❑对于初步判断为紧急的事件马上升级到一/二线人员处理

❑对于非业务支撑维护职责范围的事件转给其它相关责任部门

100.2

初始支持

服务台

❑属于服务台技能范围内可以处理的事件，服务台应尝试解决，如果无法解决需及时升级到一/二/三线支持

❑不属于服务台职责范围的事件，立即分派到相应的一/二/三线支持

100.3

一线/二线尝试解决

一线支持/二线支持

❑一线/二线支持人员在接受到由服务台派发的事件后，进行调查诊断，尝试解决

❑在必要时根据服务协议联系厂商帮助解决并负责核查

❑对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决方案

❑事件解决后，在事件管理平台记录事件解决方案并更新事件状态

❑不能解决的事件，转100.4三线尝试解决

❑指定时限内不能解决的事件，通告事件经理，由事件经理负责协调资源

100.4

三线尝试解决

三线支持

❑三线支持人员接受事件，进行调查诊断，提出解决方案

100.5

紧急事件再确认

一线支持

二线支持

❑一线支持人员接受到来自服务台的紧急事件后，根据事件优先级别标准再次确认事件是否为紧急事件

❑如果优先级确实紧急，则通知相应的管理层，并立即升级到事件经理，转101紧急事件处理子流程

❑如不是，转100.3一线尝试解决，开始正常事件解决流程

100.6

记录解决方案细节

服务台

一线支持

二线支持

❑在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案并更新事件信息

❑针对故障，一线/二线支持必须记录业务恢复时间

100.7

关闭事件

服务台

一线支持

二线支持

❑服务台与申报用户确认事件是否已得到解决，如果解决，事件以成功解决或变通方法解决而关闭；否则，事件以不成功关闭，重新开事件记录，并与原记录做关联，分派到原处理人员继续处理

❑服务台在关闭事件的同时必须确认事件单记录的业务恢复时间是否准确

❑其它由一线或二线人员自行创建的事件单，则由开单人负责关闭

❑处理过程对后续工作有指导或参考的，录入知识库

100.8

事件处理的监控

服务台

事件经理

❑负责监控所有未关闭的事件的处理状况，对接收到的超时告警应及时关注

❑事件经理负责协调资源，保证事件的最终解决

101

紧急事件处理流程

事件经理

❑事件经理负责协调紧急事件的处理，具体过程见紧急事件处理子流程

1.1.4.12关键流程衡量指标

为了控制流程的质量，必须为流程设置衡量指标。

通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。

表2．事件管理KPI指标

序号

衡量指标

指标计算说明

1

事件总数

数量：

在事件单中根据以下条件过滤

1.【重复事件标记】为空

2.【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’

3.【事件发生时间】在统计周期内

2

事件成功关闭的数量/比率

数量：

在事件总数中过滤【事件结束代码】＝‘成功解决’or‘变通方法解决’

比率：

数量/事件总数×100%

3

规定时间内解决的事件数量/百分比

数量：

在事件总数中过滤【处理是否超时】＝‘未超时’and【事件结束代码】＝‘成功解决’or‘变通方法解决’

比率：

数量/事件总数×100%

4

规定时间内响应的事件数量/百分比

数量：

在事件总数中过滤（【实际开始时间】－【登记时间】）<优先级对应的响应时限

比率：

数量/事件总数×100%

5

平均解决时间

完成的事件：

在事件总数中过滤所有【事件状态】＝‘已解决’or‘关闭’的事件

平均解决时间：

累加完成事件的（【实际完成时间】－【登记时间】）/完成的事件数量

6

一线解决率

数量：

在事件总数中过滤所有【事件解决人角色】＝‘一线’

比率：

数量/事件总数×100%

7

超时未解决的事件数量

数量：

在事件总数中过滤【处理已超时】＝‘超时’and【事件状态】！

＝‘关闭’or‘已解决’

8

事件的一次解决率

数量1：

在事件总数中过滤【事件结束代码】＝‘成功解决’or‘变通方法解决’

数量2：

在事件总数中过滤【事件结束代码】＝‘不成功’

比率：

（数量1－数量2）/数量1×100%

9

计划外业务中断时长

完成的事件：

在事件总数中过滤所有【事件状态】＝‘已解决’or‘关闭’的事件

【中断时长】分别对应到融合计费、综合帐务、客户服业务系统的子类，进行分类统计

10

客户投诉响应及时率

投诉总数：

在事件总数中过滤所有【事件来源】＝‘客服转单’

响应时间：

【事件状态】变为’xx线处理中’的时间与建单时间的差值

数量：

在投诉总数中过滤所有’响应时间<预定值’

比率：

数量/投诉总数×100%

11

客户投诉处理及时率

投诉总数：

在事件总数中过滤所有【事件来源】＝‘客服转单’

处理时间：

【事件状态】变为’已解决’的时间与建单时间的差值

数量：

在投诉总数中过滤所有’解决时间<预定值’

比率：

数量/投诉总数×100%

1.1.5问题管理功能

1.1.5.1流程目的

事件管理主要是被动应付突发事件和故障，故障消除、业务恢复后事件管理应结束。

如需进行进一步分析，找出故障深层原因和根本解决方案，通过变更请求（RFC）、变通方法或建议的预防性措施来防止同类故障的再次发生，应启动问题管理流程。

问题管理流程的根本目的是消除或减少生产环境中事件发生的数量和严重程度，从而为企业建立一个稳定的IT环境，提高IT服务的可用性。

其目的包括：

❑分析并确定事件的根本原因，找到最终解决方案，以防止此类事件再次发生

❑提高IT服务的可靠性，降低IT支持成本

1.1.5.2流程主要内容

问题管理流程着重于消除事件或减少事件发生，确定事件的根本原因。

主要活动包括分析事件、找出问题、分派问题、确定根本原因以及找出解决方案、回顾及关闭，以消除事件或在其发生时降低对用户或业务的影响。

其主要内容如下：

❑分析事件

定期分析事件，找出潜在问题。

❑生成问题记录

在系统中生成问题记录并把所有相关事件与此记录关联起来

❑分派

根据问题内容将问题记录分派给适当的技术小组。

❑根本原因分析

被分派的小组人员将调查问题以期找出其原因，提出解决方案、变通方法或预防性措施，以消除产生原因，或在重发时使其影响力最小化。

记录必须被更新以反映它是已定位原因状态，并且把任何变通方法、避免或最小化负面影响的动作行为也记录下来。

❑开发、确认、提出实施解决方案

对问题的解决方案进行评估、测试，提出变更请求（RFC）或实施具体的解决方案。

❑回顾及关闭

对问题的解决方案进行回顾，确认解决方案达到了预期的效果。

确认问题的信息记录填写完整，提交知识库，并关闭问题记录。

1.1.5.3与其他流程的关系

❑和事件管理的关联

-事件在恢复服务后仍需后续分析处理的，应结束事件单，创建问题单（问题单必须和事件单建立关联）

❑和变更管理的关联

-问题处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求单（变更单必须和问题单建立关联），变更完成后，继续问题单的处理

❑和配置管理的关联

-问题处理过程中，可以通过配置管理查询相关的配置项信息

-问题处理过程中，如果可以将根本原因定位到某个配置项，则必须将问题单与该配置项关联

❑和知识管理的关联

-问题处理完成后，均应整理提交到知识库中（问题单必须和知识单建立关联），以便在省内和全国共享

1.1.5.4问题工单信息项

问题单包含如下信息项：

表3．问题信息项

序号

信息项

描述

1

问题ID

为每个问题分配一个唯一的序列号（系统自动产生）

2

请求人信息

问题请求人的信息，包括：

姓名、省/分公司、部门、电子邮件、办公电话、手机（手工填写）

3

登记时间

生成问题记录的时间（系统自动产生）

4

地点

记录问题发生的地点（手工填写）

5

问题来源

参见“问题来源”定义

6

问题优先级

参见“问题优先级”定义

7

所属系统类型

参见“所属系统类型”定义

8

问题分类

参见“问题分类”定义

9

问题标题

简单描述问题（手工填写）

10

问题描述

详细描述问题内容（手工填写）

11

问题拒绝原因

详细描述拒绝问题原因，并推荐其他专家或专家组（手工填写）

13

问题原因

详细记录问题产生的根本原因（手工填写）

14

重复问题标记

标记为重复问题，用已有标题号标注（手工填写）

15

问题状态

参见“问题状态”定义

16

问题经理

该问题对应的问题经理

17

问题处理专家

负责该问题的问题处理专家

18

厂商人员

负责该问题的厂商人员

19

问题日志

反映问题处理过程中问题信息项的变化历史，包括分配的人员，状态等信息（系统自动产生）

20

实际开始诊断时间

问题状态更新为“分析中”的时间（手工填写）

21

实际诊断结束时间

问题状态更新为“已有解决方案”的时间（手工填写）

22

解决方案

问题解决方案的详细描述（手工填写）

23

问题结束代码

参见“问题结束代码”定义

24

问题无法解决原因

解释问题无法解决的原因（手工填写）

25

关联配置项

记录问题的配置项代码（手工填写）

27

关联的事件单号

记录引发该问题的事件单号（手工填写）

28

关联的变更单号

记录由问题发变更时，关联的变更单号（手工填写）

29

关联的知识号

记录问题对应的知识单号（系统自动填写）

30

问题关闭时间

当问题状态更新为“结束并关闭“的时间（手工填写）

1.1.5.5问题来源

根据问题的不同来源对问题分类如下：

编号

代码

描述

1

事件研究

事件恢复服务后提出的问题，以便进行事件的根本原因分析。

业务恢复后，相应事件应结束关闭，以免影响事件处理时长。

如果事件对应的潜在故障原因后后续规避措施仍需继续研究，应启动问题管理流程，创建问题单。

例如：

某日发生了一起集群无法切换的事件，导致某台主机发生故障后，没有切换到备用主机中去，从而影响了业务，事件处理人员在采取了手工切换的替代措施后，恢复了服务。

为了分析为什么会发生该事件，以及查看其他的集群是否也存在类似的问题，此时可以提出一个问题记录，以便对该事件进行研究分析。

2

维护提出

技术专家在日常维护工作中提出的问题。

日常维护中发现的潜在故障如果没有影响到业务，应启动问题管理流程，创建问题单。

例如：

维护专家在日常维护中发现，目前的数据库版本可能会存在着死锁、心跳不一致等方面的问题，此时就可以提出一个问题记录，以便研究分析，避免日后发生故障。

3

趋势分析

分析事件记录找出的问题。

常规的工作分析会上确定的、需要深入研究的任务落实到维护专家后，应启动问题管理流程，创建问题单。

例如：

在定期的会议中，对计费类的事件进行分析后发现，上周该类型的事件比平常的时候多了30％，超过了规定的阀值，这表明计费系统有可能存在着一些潜在的隐患，此时就可以提出一个问题记录，以找出问题的原因并解决。

1.1.5.6问题优先级

问题的优先级是问题处理专家解决问题的参照标准，对于关键优先级的问题，管理层应该优先协调资源进行这些问题的解决。

结合中国移动的实际情况，问题的优先级定义如下：

编号

代码

描述

1

关键

从如下方面考虑，问题是否：

●影响到关键业务（如：

综合帐务、定单管理、电话呼叫中心等）

●影响范围极大（如：

一个关键地区或半数以上非关键地区）

●紧迫程度最高（如：

必须马上着手处理）

●问题处理后可大幅节省投资、人力，有效提高服务质量和维护效率

2

重要

从如下方面考虑，问题是否：

●影响到较关键业务（如：

综合采集、融合计费、产品管理等）

●影响范围较大（如：

一个以上非关键地区）

●紧迫程度较高

●问题处理后可有效节省投资、人力，一定程度提高维护质量

3

普通

从如下方面考虑，问题是否：

●影响到非关键业务

●有一定影响范围

●问题处理后对维护质量和效率的提升有限