运维管理系统流程设计含事件管理故障管理问题管理知识管理.docx
- 文档编号:6334227
- 上传时间:2023-01-05
- 格式:DOCX
- 页数:30
- 大小:262.49KB
运维管理系统流程设计含事件管理故障管理问题管理知识管理.docx
《运维管理系统流程设计含事件管理故障管理问题管理知识管理.docx》由会员分享,可在线阅读,更多相关《运维管理系统流程设计含事件管理故障管理问题管理知识管理.docx(30页珍藏版)》请在冰豆网上搜索。
运维管理系统流程设计含事件管理故障管理问题管理知识管理
运维管理系统流程设计(含事件管理、故障管理、问题管理、知识管理)
运维管理主要为IT人员提供统一的协同式工作环境。
通过IT流程的梳理及固化,实现IT内部纵向、横向,以及其他专业的有效协同。
通过与各类IT专业工具的集成,为IT人员提供日常工作的集中处理环境,实现各项IT工作的规范化、标准化、集中化处理,提高IT人员工作的效率质量。
1.1事件管理
事件管理流程是对IT生产环境中导致IT服务中断或潜在中断的事件进行管理,快速恢复IT服务能力的管理流程。
事件的来源包括IT用户报告的事件、监控系统自动转发的事件、客服系统自动转发的IT类事件等。
它的目的是尽快恢复被中断或受到影响的IT服务,是以恢复服务为首要目的,可能采取临时解决方案,而不在于查找根本原因。
主要业务环节包括事件的登记、事件的分配、事件的处理、事件的升级和事件关闭等。
1.1.1管理目标
事件管理流程的主要功能是尽快解决出现的事件,保持业务支撑系统的稳定性,其目的包括:
⏹确保各类IT事件能够在成本允许的范围内,按照事件的优先级,快速、有序地解决,从而减少IT服务中断造成的影响。
Ø多渠道快速响应服务请求(电话/Web/邮件/即时通信工具等)。
Ø根据事件的优先级,影响度进行综合分类排序,如果判断事件优先级是紧急,则启动紧急事件管理流程进行处理。
Ø为客户提供及时的事件处理状态信息。
Ø监控事件处理过程,必要时进行管理和技术升级。
⏹确保IT事件处理过程中的关键信息能正确记录,为后续事件处理提供知识支持,为流程持续优化提供准确的数据信息。
Ø按规范记录事件信息及解决过程信息。
Ø服务台及后台技术资源利用情况。
Ø服务台、技术支持团队的工作效率。
1.1.2业务需求点
登记各种渠道上报的事件,并对其进行分类和分级;按照对业务的影响程度和优先级分配事件;支持工程师解决该事件,并记录详细的解决方案;对超期事件进行升级处理;事件处理的解决方案可以形成知识,为后续工作提供参考;对历史事件进行趋势分析,形成问题;根据事件记录考核相关人员的绩效;对于重复上报的事件,能够进行关联处理;对事件处理的过程进行跟踪审计;事件单能够和问题单、故障单等其他流程工单关联。
1.1.3流程设计
1.1.3.1流程图
图:
事件管理流程泳道图
1.1.3.2流程表单项
以下为事件流程表单信息项,实施时可结合的实际需要进行表单的信息项进行增删:
序号
信息项
说明
1
事件ID
事件单流水号。
2
请求人信息
事件申报人的信息,包括:
姓名、部门、电子邮件、办公电话、手机。
3
登记时间
在服务台生成事件记录的时间
4
地点
事件发生的地点。
5
事件发生时间
针对事件:
指的是业务中断的实际时间(可能早于登记时间,需要调整确认)。
针对其它:
缺省值等于登记时间。
6
业务恢复时间
针对事件的业务恢复实际时间。
7
事件来源
参见“事件来源”定义。
8
用户事件提交渠道
参加”用户事件提交渠道”定义。
9
事件影响度
参见“事件影响度”定义。
10
事件优先级
参见“事件优先级”定义。
11
事件完成期限
对应每一个事件优先级,系统根据流程相关定义中“事件解决时限”自动设定最终的完成期限。
12
所属系统类型
参见“所属系统类型”定义。
13
事件分类
参见“事件分类”定义。
14
事件标题
事件的简要描述。
15
事件描述
对于整个事件内容的详细描述。
16
事件解决人
事件的最终解决人。
17
事件状态
参见“事件状态”定义。
18
分配对象
被分配的技术支持组和人员。
19
事件日志
反映事件信息项的变化历史,如一个事件在处理过程中事件状态变化的时间点等信息。
20
解决方案
事件解决方案的描述。
21
业务中断时长
造成业务计划外中断的时间长度。
22
事件结束代码
参见“事件结束代码”定义。
23
重复事件标记
标记为重复事件。
24
重复事件ID
重复事件中主事件ID。
25
处理是否超时
参见“处理是否超时”定义。
26
实际完成时间
记录事件已解决的时间。
27
事件厂商
参见附录C厂商和集成商名称标准。
28
关联配置项
记录出现事件的配置项代码。
29
关联的问题单号
记录由事件引发问题时,关联的问题单号。
30
关联的故障单号
记录由事件引发故障时,关联的故障单号。
1.1.3.3主要活动说明
序号
步骤名称
责任人
说明
100.1
事件记录和分类
服务台
服务台对来自用户和系统自动产生的事件进行详细记录
服务台负责在接收到事件后进行分类转发,对申告/告警/咨询/故障类事件进行分类转发
对于初步判断为紧急的事件马上升级到一/二线人员处理
对于非业务支撑维护职责范围的事件转给其它相关责任部门
100.2
初始支持
服务台
属于服务台技能范围内可以处理的事件,服务台应尝试解决,如果无法解决需及时升级到一/二线支持
不属于服务台职责范围的事件,立即分派到相应的一/二线支持
100.3
一线/二线尝试解决
一线支持/二线支持
一线/二线支持人员在接受到由服务台派发的事件后,进行调查诊断,尝试解决
在必要时根据服务协议联系厂商帮助解决并负责核查
事件解决后,在事件管理平台记录事件解决方案并更新事件状态
指定时限内不能解决的事件,通告事件经理,升级为故障管理流程
100.5
紧急事件再确认
一线支持
二线支持
一线支持人员接受到来自服务台的紧急事件后,根据事件优先级别标准再次确认事件是否为紧急事件
如果优先级确实紧急,则通知相应的管理层,并立即升级到事件经理,转101紧急事件处理子流程
如不是,转100.3一线尝试解决,开始正常事件解决流程
100.6
记录解决方案细节
服务台
一线支持
二线支持
在事件得到解决后,各线支持人员负责详细记录事件解决过程及方案并更新事件信息
针对故障,一线/二线支持必须记录业务恢复时间
100.7
关闭事件
服务台
一线支持
二线支持
服务台与申报用户确认事件是否已得到解决,如果解决,事件以成功解决或变通方法解决而关闭;否则,事件以不成功关闭,重新开事件记录,并与原记录做关联,分派到原处理人员继续处理
服务台在关闭事件的同时必须确认事件单记录的业务恢复时间是否准确
其它由一线或二线人员自行创建的事件单,则由开单人负责关闭
处理过程对后续工作有指导或参考的,录入知识库
100.8
事件处理的监控
服务台
事件经理
负责监控所有未关闭的事件的处理状况,对接收到的超时告警应及时关注
事件经理负责协调资源,保证事件的最终解决
101
紧急事件处理流程
事件经理
事件经理负责协调紧急事件的处理,具体过程见紧急事件处理子流程
1.1.3.4角色及职责说明
1.1.3.5事件经理
事件经理负责事件解决过程中的协调和监控,事件升级的判断和具体执行。
职责:
❑负责对事件的解决协调资源,保证事件的最终排除。
❑确保和问题管理流程经理的有效合作。
❑确保正确和广泛地收集和分析事件数据,发现IT和业务相关的问题。
1.1.3.6服务台人员
服务台人员负责接收所有的事件,对事件进行初步的处理,并根据实际情况将事件分派到合适的二线支持工程师。
与服务台一起工作进行事件处理的技术人员定义为一线人员。
职责:
❑负责24×7的值班和系统监控。
❑响应客户投诉工单、热线电话、邮件、传真等事件报告。
❑完整记录所有接收的事件信息,包括:
记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等。
❑对事件进行适当的分类、为事件分配优先级等。
❑尝试使用工具对事件进行初步诊断,分析相关信息并解决问题。
❑对服务台解决不了的事件,分配给最合适的二线支持小组/人员来处理。
❑检查事件的处理进度,保持与事件报告人的联系,适时通知事件处理进展。
❑与用户确认事件解决结果,关闭事件。
1.1.3.7二线支持人员
二线支持人员是燃气行业内部相关问题领域的专家。
负责提供对一线支持人员无法解决的问题进一步进行调研,找出解决方案并尽快恢复服务。
在省公司的实际情况中,技术人员一般会按照所维护的应用、系统进行分工,如:
网络支持、主机支持、应用支持等。
这些技术人员都可以映射为二线支持人员,在流程中不明确区分。
职责:
❑验证事件的描述和信息,进一步收集相关信息。
❑进行深入调查研究或协调厂商支持,提供有效的解决方案。
❑实施事件解决方案。
❑更新事件解决信息,将已解决的事件转回服务台。
1.1.3.8三线支持人员
包括应用开发厂商的后端研发团队、提供远程支持的设备厂商、或厂商的现场服务。
职责:
❑提供远程接入方式的支持,协助进行事件诊断及恢复。
❑必要时提供现场支持和深入调查研究,提供有效的解决方案。
参与重大事件解决方案的实施。
1.1.3.9与其他流程关系
⏹与监控系统的交互
监控系统发现故障或异常后,可以通过事件管理的接口将重大故障自动传递到事件管理,注册为一个事件,并能自动填写事件ID、配置项、事件标题、事件描述、优先级、最终期限等。
主要功能包括:
✧支持监控系统/其他系统自动生成事件的接口,并将监控到的故障信息填写到相应的事件单中。
✧支持与监控系统的双向同步。
即当事件关闭时,自动确认监控系统中的相关告警。
而监控系统中的告警消除后,应能自动关闭事件。
✧监控系统的后续相同告警可以追加的方式添加到事件单中。
⏹与客服系统的交互
客服系统在处理用户事件时,如果认为应当由IT服务部门解决,可以通过接口将用户事件自动传递到事件管理,注册为一个事件,并能自动填写事件ID、配置项、事件标题、事件描述、优先级、最终期限等。
主要功能包括:
✧支持客服系统自动生成事件的接口,并将客服系统中记录的信息填写到相应的事件单中。
✧作为客服系统的子流程,处理结束后通知客服系统,由客服系统和用户做最终的确认。
✧客服系统中相同事件的后续信息可以追加的方式添加到事件单中。
⏹与问题管理的交互
对于重大事件或者统计分析得到的事件发生趋势,可以产生相应的问题记录。
主要功能包括:
✧支持通过重大事件生成问题记录单,将事件中的相应信息自动拷贝到问题单中。
✧支持问题单和事件单的关联,一个问题单可以关联多个事件单。
✧当关闭问题单时,应能够自动通知关联的所有事件单。
⏹与知识库管理的交互
✧在任何环节都可以查询知识库系统。
✧在关闭事件时,可以将解决方案标记为备选的知识,提交给知识管理审核。
1.1.4流程功能
1.1.4.1各种渠道事件登记
登记各种渠道上报的事件工单,并对其进行分类和分级。
✧WEB方式,由请求人通过运维监控管理平台自助填写事件工单并提交,并在表单上填写请求分类和紧急程度。
✧电话方式,请求人拨打服务台统一热线,由服务台受理后代发事件工单。
✧邮件方式,请求人可编写固定格式的请求邮件发送到运维监控管理平台的系统邮箱中,邮件接口程序解析后生成事件工单。
✧即时通信,请求人通过在线客服模块与服务台工作人员在线点对点沟通并由服务台人员代发事件工单。
1.1.4.2根据影响程度和优先级分配事件
根据事件工单填写的影响程度和优先级,分配紧急的和影响范围大的事件单给专人优先处理。
1.1.4.3事件处理过程记录
流程引擎对事件的每个处理环节保存该环节的处理信息,包括环节派发时间、处理开始时间、处理结束时间、处理人、处理结果、处理意见。
并以图形的方式展示整个事件的处理过程。
1.1.4.4对超期事件进行升级处理
根据事件的紧急程度,设定事件工单业务超时时间,在达到超时时间时可根据预设规则进行升级,包括:
通知当前人、通知服务请求管理员、通知当前人上级领导、将工单转办其他人。
1.1.4.5事件处理的解决方案可以形成知识
在事件回顾环节配置知识库关联规则,回顾人可点击“入知识库”按钮对事件处理结果进行知识入库。
1.1.4.6对历史事件进行趋势分析,形成问题
可定期统计历史事件单,获取还存在问题的事件并发起问题工单进行关联跟踪,分析角度包括:
统计长期未处理完成的事件、统计大量重复发生的事件、统计影响严重的事件单、统计解决方案为变通解决的事件。
1.1.4.7考核支持工程师的绩效
配置事件考核报表,统计支持工程师的绩效,包括:
支持工作量、支持效率、重复处理情况、请求人反馈满意度
1.1.4.8关联处理重复事件单
在每个办理环节,均可以对当前工单进行重复关联,当选择重复关联时,本单将同步原重复单的处理状态:
1)原单正在处理,则本单锁定等待原单处理完成后本单同步完成,并通知请求人
2)原单已处理完成,则本单直接结束并通知处理结果给请求人
1.1.4.9对事件处理的过程进行跟踪审计
在事件管理流程最后增加“处理审批”环节,进行事后跟踪审核处理。
1.1.4.10事件单能够和问题单、故障单等其他流程工单关联
事件处理结果,可选择“发起问题跟踪”或者“发起变更解决”的选项,当选择该两个选项的其中之一后,进入子工单启动环节,可设置为人工启动也可以设置为自动启动,从而启动关联的问题单或者故障单进行关联处理。
1.2故障管理
主要由事件/问题人工升级到故障管理流程,分配给故障经理进行跟进处理,由系统自动记录故障处理/分派过程,故障的关闭由升级人进行。
故障管理流程即上节事件管理流程图中的紧急事件处理子流程。
1.2.1流程设计
1.2.1.1流程图
图:
故障管理流程泳道图
1.2.1.2流程表单项
以下为故障流程表单信息项,实施时可结合的实际需要进行表单的信息项进行增删:
序号
信息项
说明
1
故障ID
故障单流水号。
2
请求人信息
故障升级人的信息,包括:
姓名、部门、电子邮件、办公电话、手机。
3
登记时间
生成故障记录的时间
4
地点
故障发生的地点。
5
故障发生时间
针对故障:
指的是业务中断的实际时间(可能早于登记时间,需要调整确认)。
针对其它:
缺省值等于登记时间。
6
业务恢复时间
针对故障的业务恢复实际时间。
7
故障影响度
参见“故障影响度”定义。
8
故障完成期限
要求故障的完成期限。
9
所属系统类型
参见“所属系统类型”定义。
10
故障分类
参见“故障分类”定义。
11
故障标题
故障的简要描述。
12
故障描述
对于整个故障内容的详细描述。
13
故障解决人
故障的最终解决人。
14
故障状态
参见“故障状态”定义。
15
分配对象
被分配的技术支持组和人员。
16
故障日志
反映故障信息项的变化历史,如一个故障在处理过程中故障状态变化的时间点等信息。
17
解决方案
故障解决方案的描述。
18
业务中断时长
造成业务计划外中断的时间长度。
19
故障结束代码
参见“故障结束代码”定义。
20
重复故障标记
标记为重复事件。
21
重复故障ID
重复故障中主故障ID。
22
处理是否超时
参见“处理是否超时”定义。
23
实际完成时间
记录事件已解决的时间。
24
故障厂商
参见附录C厂商和集成商名称标准。
25
关联配置项
记录出现故障的配置项代码。
26
关联的问题单号
记录由事件引发问题时,关联的问题单号。
27
关联的事件单号
记录由事件引发故障时,关联的事件单号。
1.2.2流程功能
1.2.2.1故障处理过程记录
流程引擎对故障的每个处理环节保存该环节的处理信息,包括环节派发时间、处理开始时间、处理结束时间、处理人、处理结果、处理意见。
并以图形的方式展示整个故障的处理过程。
1.2.2.2对超期故障进行升级处理
根据故障的紧急程度,设定故障工单业务超时时间,在达到超时时间时可根据预设规则进行升级,包括:
通知当前人、通知服务请求管理员、通知当前人上级领导、将工单转办其他人。
1.2.2.3故障处理的解决方案可以形成知识
在故障回顾环节配置知识库关联规则,回顾人可点击“入知识库”按钮对事件处理结果进行知识入库。
1.2.2.4对历史故障进行趋势分析,形成问题
可定期统计历史故障单,获取还存在问题的事件并发起问题工单进行关联跟踪,分析角度包括:
统计大量重复发生的故障、统计影响严重的故障单、统计解决方案为变通解决的故障。
1.2.2.5考核支持工程师的绩效
配置故障考核报表,统计支持工程师的绩效,包括:
支持工作量、支持效率、重复处理情况、请求人反馈满意度
1.2.2.6关联处理重复故障单
在每个办理环节,均可以对当前工单进行重复关联,当选择重复关联时,本单将同步原重复单的处理状态:
3)原单正在处理,则本单锁定等待原单处理完成后本单同步完成,并通知请求人
4)原单已处理完成,则本单直接结束并通知处理结果给请求人
1.2.2.7对故障处理的过程进行跟踪审计
在故障管理流程最后增加“处理审批”环节,进行事后跟踪审核处理。
1.2.2.8故障单能够和问题单等其他流程工单关联
故障处理结果,可选择“发起故障跟踪”的选项,当选择该两个选项的其中之一后,进入子工单启动环节,可设置为人工启动也可以设置为自动启动,从而启动关联的问题单进行关联处理。
1.3问题管理
问题管理流程是确定某一事件或具有相同症状的一组事件的根本原因,制定和实施解决方案,从而防止事件再次发生的管理流程。
问题管理流程的目的是找出事件根本原因,尽可能的给出解决方案或者临时应对措施。
主要业务环节包括问题的登记、问题的审核、问题的分配、问题的处理、问题回顾和问题关闭等。
1.3.1管理目标
问题管理流程的目标是降低生产环境中事件发生的数量和严重程度,从而为企业建立一个稳定的IT环境,提高IT服务的可用性。
其目的包括:
⏹分析并确定事件的根本原因,找到最终解决方案,以防止此类事件再次发生。
⏹通过对已知错误进行标识,最小化不能被消除事件的影响。
⏹提高IT服务的可靠性,降低IT支持成本。
⏹问题管理过程得到正确记录,满足审核和统计的管理要求。
1.3.2业务需求点
登记紧急事件和事件分析整理出来的问题,并对其进行分类和分级;按照对业务的影响程度和优先级分配问题;分析该问题的根本原因,并记录已知错误、详细变通方案或者生成变更请求单;对超期问题进行升级处理;问题处理的解决方案或者变通方案可以形成知识库,为后续工作提供参考;能够将问题分析产生的变通方案发布到帮助台和所有用户;能够分析回顾问题解决方案的效果;根据问题记录考核支持工程师的绩效;对问题处理的过程进行跟踪审计;问题单能够和事件单、变更单等其他流程工单关联;支持问题信息在集团和省公司IT服务管理系统之间的纵向传递。
1.3.3流程设计
1.3.3.1流程图
图:
问题管理流程泳道图
1.3.3.2流程表单项
序号
信息项
描述
1
问题ID
为每个问题分配一个唯一的序列号。
2
请求人信息
问题请求人的信息,包括:
姓名、省/分公司、部门、电子邮件、办公电话、手机。
3
登记时间
生成问题记录的时间。
4
地点
记录问题发生的地点。
5
问题来源
参见“问题来源”定义。
7
所属系统类型
参见“所属系统类型”定义。
8
问题分类
参见“问题分类”定义。
9
问题标题
简单描述问题。
10
问题描述
详细描述问题内容。
11
问题优先级
参见“问题优先级”定义。
12
问题拒绝原因
详细描述拒绝问题原因,并推荐其他专家或专家组。
13
变通方法
详细记录问题的变通方法。
14
问题原因
详细记录问题产生的根本原因。
15
重复问题标记
标记为重复问题,用已有标题号标注。
16
重复问题ID
为重复问题分配一个序列号,并且关联相应的问题ID。
17
问题状态
参见“问题状态”定义。
18
问题经理
该问题对应的问题经理。
19
问题处理专家
负责该问题的问题处理专家。
20
问题日志
反映问题处理过程中问题信息项的变化历史,包括分配的人员,状态等信息。
21
实际开始诊断时间
问题状态更新为“分析中”的时间。
22
实际诊断结束时间
问题状态更新为“已有解决方案”的时间。
23
解决方案
问题解决方案的详细描述。
24
问题结束代码
参见“问题结束代码”定义。
25
问题无法解决原因
解释问题无法解决的原因。
26
关联配置项
记录问题的配置项代码。
27
关联的事件单号
记录引发该问题的事件单号。
28
关联的变更单号
记录由问题发变更时,关联的变更单号。
29
关联的知识号
记录问题对应的知识单号(系统自动填写。
)
30
问题关闭时间
当问题状态更新为“结束并关闭“的时间。
1.3.3.3主要活动说明
序号
步骤名称
责任人
说明
200.1
问题确定与记录
问题处理专家/问题经理
对事件研究、维护提出以及趋势分析发现的潜在问题,在系统中进行记录,并对问题信息进行描述
问题处理专家创建的问题,如果需要,应提交给问题经理确认;否则应抄送问题经理备案
问题经理创建的问题,可与200.2环节合并,直接分派给问题处理专家
200.2
问题确认与分派
问题处理专家/问题经理
问题处理专家提交上来的问题,问题经理应对其进行审核确认,确定问题是否需要继续处理。
如果问题确认无效,则关闭问题,并通知请求者
问题经理创建或审核的问题,分派给相应问题处理专家;问题处理专家创建的问题,可以自行处理或分派给现场厂商
200.3
分析并诊断问题/提供变通方法
问题处理专家/厂商
问题处理专家/厂商接受问题,更新问题状态并记录实际开始诊断时间
如需其他问题处理专家协助分析、诊断,则通知问题经理,由问题经理协调资源,成立问题分析小组,举行问题根本原因分析研讨会议,并确定问题的潜在原因,提供或更新问题变通方法,以降低问题在根本解决前对业务产生的影响
将问题产生根本原因及变通方法及时更新到问题记录中
将问题根本原因及变通方法通知问题经理
如果预计无法找到问题的根本原因,及时通报问题经理
200.4
开发、确认实施解决方案
问题处理专家/厂商
对于已经找到根本原因的问题,需要确定解决方案,以便永久的解决
问题处理专家或厂商推荐并测试根本性解决方案,并确保这些方案彻底解决问题,更新问题记录中的实际诊断结束时间
问题处理专家判断实施上述解决方案/变通方法是否需要通过其他流程(如变更流程等)
如需要,提交到相应的流程,并和该流程人员保持沟通,了解问题的解决状况;
如不需要变更,计划并组织实施解决方案。
如需要第三方介入,则问题处理专家负责与第三方的接口与协调
如问题处理专家预计在无法找到根本解决方案或虽有解决方案但目前无法实施(如实施的代价太大),通报问题经理
200.5
问题监控
问题经理/问题处理专家
问题经理和问题处理专家负责问题分析、诊断、解决过程中的跟踪和监控:
在问题找到根本原因或解决方案之后,根据需要,向服务台或问题请求人员通报该问题的解决情况,以帮助和提高问题的解决率
对于问题处理专家认为无法找到根本原因或虽有解决方案,但目前无法实施(如实施的代价太大等),问题经理协调问题
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 管理 系统 流程 设计 事件 故障 问题 管理知识