20151022 淡然

续上

4.6.11  事件解决人角色

事件解决人角色用来标明该事件单最终解决的角色是帮助台、一线还是二线。

[td]

编号	代码	描述
1	帮助台	帮助台最终解决事件
2	一线	4.7   一线支持最终解决事件
3	二线	4.8   二线支持最终解决事件
4	三线	4.9   三线支持最终解决事件

4.9.1   处理是否超时

每个优先级别都对应了解决期限，“处理是否超时”用来标明事件的处理是否已超过了解决期限。

[td]

编号	代码	描述
1	未超时	未超时                                  ITSS考试
2	超时	事件已超出规定的解决时限

4.9.2   故障厂商

用来在事件单中记录是哪个厂商的设备/系统，或者哪个集成商的应用软件发生故障(针对事件分类中的“应用软件”故障)。代码定义参见《资源管理分册》厂商和集成商名称标准（可以根据情况从厂商和集成商两个表中选择一个合适的故障厂商）。

各省可以根据实际情况对厂商名称标准表和集成商名称标准表进行扩充。

4.10    流程概要设计

事件管理概要设计流程图：

图4-1事件管理概要流程

事件管理概要设计流程说明：

[td]

序号	步骤名称	责任人	说明
100.1	事件记录和分类	帮助台	l 帮助台对来自用户和系统自动产生的事件进行详细记录，主要包括来自IT基础架构的故障告警、来自客服和业务部门的客户投诉，也包括来自其它业务部门的服务请求 l 帮助台负责在接收到事件后进行分类转发，对申告/告警/咨询/故障类事件进行分类转发 l 对于初步判断为紧急的事件马上升级到一/二线人员处理 l 对于非业务支撑维护职责范围的事件转给其它相关责任部门
100.2	初始支持	帮助台	l 属于帮助台技能范围内可以处理的事件，帮助台应尝试解决，如果无法解决需及时升级到一/二线支持 l 不属于帮助台职责范围的事件，立即分派到相应的一/二线支持
100.3	一线/二线尝试解决	一线支持/二线支持	l 一线/二线支持人员在接受到由帮助台派发的事件后，进行调查诊断，尝试解决 l 在必要时根据服务协议联系厂商帮助解决并负责核查 l 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决方案 l 事件解决后，在事件管理平台记录事件解决方案并更新事件状态 l 不能解决的事件，转100.4三线尝试解决                            l 指定时限内不能解决的事件，通告事件经理，由事件经理负责协调资源
100.4	三线尝试解决	三线支持	l 三线支持人员接受事件，进行调查诊断，提出解决方案
100.5	紧急事件再确认	一线支持 二线支持	l 一线支持人员接受到来自帮助台的紧急事件后，根据事件优先级别标准再次确认事件是否为紧急事件                                     ITSS认证 l 如果优先级确实紧急，则通知相应的管理层，并立即升级到事件经理，转101紧急事件处理子流程 l 如不是，转100.3一线尝试解决，开始正常事件解决流程
100.6	记录解决方案细节	帮助台 一线支持 二线支持	l 在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案并更新事件信息 l 针对故障，一线/二线支持必须记录业务恢复时间
100.7	关闭事件	帮助台 一线支持 二线支持	l 帮助台与申报用户确认事件是否已得到解决，如果解决，事件以成功解决或变通方法解决而关闭；否则，事件以不成功关闭，重新开事件记录，并与原记录做关联，分派到原处理人员继续处理 l 帮助台在关闭事件的同时必须确认事件单记录的业务恢复时间是否准确 l 其它由一线或二线人员自行创建的事件单，则由开单人负责关闭 l 处理过程对后续工作有指导或参考的，录入知识库
100.8	事件处理的监控	帮助台 事件经理	l 负责监控所有未关闭的事件的处理状况，对接收到的超时告警应及时关注 l 事件经理负责协调资源，保证事件的最终解决
101	紧急事件处理流程	事件经理	l 事件经理负责协调紧急事件的处理，具体过程见紧急事件处理子流程

下表以事件管理概要图中的关键流程活动为主线，与事件管理概要设计中的其它重要内容进行了关联，以帮助各省业务支撑维护部门更好地理解流程设计内容。

[td]

序号	步骤名称	子流程和流程相关定义	执行原则	流程关联
100.1	事件记录和分类	l 参考“事件性质”、“事件来源”、“所属系统类型”、“事件分类”、“事件优先级”、“事件影响度”、“事件状态”确定以上代码内容	l 参考“所有权原则”，帮助台是该事件的负责人 l 参考“再分派原则”，选择合适的支持组或人员进行分派	l 配置管理：关联相关配置项
100.2	初始支持	l 参考“事件状态”确定代码内容	l 参考“重复事件原则”，对重复事件进行标识 l 参考“升级原则”，及时对事件进行升级
100.3	一线/二线尝试解决	l 参考“事件状态”，并及时修改	l 参考“重复事件原则”，对重复事件进行标识 l 参考“升级原则”，及时对事件进行升级 l 参考“再分派原则”，转派事件单	l 问题管理：参考问题管理记录中的根本原因、变通方法 l 变更管理：参考近期变更管理记录 l 变更管理：必要时提出变更请求，走变更管理流程，一般为紧急变更请求；在变更完成后继续事件处理 l 配置管理：通过配置管理查询配置项的属性和关联信息定位故障原因
100.4	三线尝试解决	l 参考“事件状态”，并及时修改	l 参考“升级原则”，及时对事件进行升级 l 参考“再分派原则”，转派事件单	l 问题管理：参考问题管理记录中的根本原因、变通方法 l 变更管理：参考近期变更管理记录 l 变更管理：必要时提出变更请求，走变更管理流程，一般为紧急变更请求；在变更完成后继续事件处理 l 配置管理：通过配置管理查询配置项的属性和关联信息定位故障原因
100.5	紧急事件再确认	l 参考并再次确定“事件优先级” l 参考“紧急变更子流程”	l 参考“升级原则”，及时对紧急事件升级
100.6	记录解决方案细节	l 在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案并更新事件信息 l 针对故障，一线/二线支持必须记录业务恢复时间 l 参考“事件状态”、“事件影响度”，根据影响度的定义重新确认影响度代码，及时更新事件状态代码		ITSS培训
100.7	关闭事件	l 参考“事件结束代码”、“事件解决人角色”	l 参考“关闭原则”，和用户确认事件的解决和分配相应的结束代码
100.8	事件处理的监控	l 参考“事件的响应时限和解决时限”，关注所有处理中的事件单	l 参考“升级原则”
101	紧急事件处理子流程	l 参考“紧急事件处理子流程”		l 问题管理：优先级为紧急的事件解决完后，需要创建新的问题单

待续http://www.ITILxf.com/thread-52472-1-1.html

本帖关键字：ITSS

展开全部

微信扫一扫，阅读更方便^_^

20151022 淡然

续上

4.6.11  事件解决人角色

事件解决人角色用来标明该事件单最终解决的角色是帮助台、一线还是二线。

[td]

编号	代码	描述
1	帮助台	帮助台最终解决事件
2	一线	4.7   一线支持最终解决事件
3	二线	4.8   二线支持最终解决事件
4	三线	4.9   三线支持最终解决事件

4.9.1   处理是否超时

每个优先级别都对应了解决期限，“处理是否超时”用来标明事件的处理是否已超过了解决期限。

[td]

编号	代码	描述
1	未超时	未超时                                  ITSS考试
2	超时	事件已超出规定的解决时限

4.9.2   故障厂商

用来在事件单中记录是哪个厂商的设备/系统，或者哪个集成商的应用软件发生故障(针对事件分类中的“应用软件”故障)。代码定义参见《资源管理分册》厂商和集成商名称标准（可以根据情况从厂商和集成商两个表中选择一个合适的故障厂商）。

各省可以根据实际情况对厂商名称标准表和集成商名称标准表进行扩充。

4.10    流程概要设计

事件管理概要设计流程图：

图4-1事件管理概要流程

事件管理概要设计流程说明：

[td]

序号	步骤名称	责任人	说明
100.1	事件记录和分类	帮助台	l 帮助台对来自用户和系统自动产生的事件进行详细记录，主要包括来自IT基础架构的故障告警、来自客服和业务部门的客户投诉，也包括来自其它业务部门的服务请求 l 帮助台负责在接收到事件后进行分类转发，对申告/告警/咨询/故障类事件进行分类转发 l 对于初步判断为紧急的事件马上升级到一/二线人员处理 l 对于非业务支撑维护职责范围的事件转给其它相关责任部门
100.2	初始支持	帮助台	l 属于帮助台技能范围内可以处理的事件，帮助台应尝试解决，如果无法解决需及时升级到一/二线支持 l 不属于帮助台职责范围的事件，立即分派到相应的一/二线支持
100.3	一线/二线尝试解决	一线支持/二线支持	l 一线/二线支持人员在接受到由帮助台派发的事件后，进行调查诊断，尝试解决 l 在必要时根据服务协议联系厂商帮助解决并负责核查 l 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决方案 l 事件解决后，在事件管理平台记录事件解决方案并更新事件状态 l 不能解决的事件，转100.4三线尝试解决                            l 指定时限内不能解决的事件，通告事件经理，由事件经理负责协调资源
100.4	三线尝试解决	三线支持	l 三线支持人员接受事件，进行调查诊断，提出解决方案
100.5	紧急事件再确认	一线支持 二线支持	l 一线支持人员接受到来自帮助台的紧急事件后，根据事件优先级别标准再次确认事件是否为紧急事件                                     ITSS认证 l 如果优先级确实紧急，则通知相应的管理层，并立即升级到事件经理，转101紧急事件处理子流程 l 如不是，转100.3一线尝试解决，开始正常事件解决流程
100.6	记录解决方案细节	帮助台 一线支持 二线支持	l 在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案并更新事件信息 l 针对故障，一线/二线支持必须记录业务恢复时间
100.7	关闭事件	帮助台 一线支持 二线支持	l 帮助台与申报用户确认事件是否已得到解决，如果解决，事件以成功解决或变通方法解决而关闭；否则，事件以不成功关闭，重新开事件记录，并与原记录做关联，分派到原处理人员继续处理 l 帮助台在关闭事件的同时必须确认事件单记录的业务恢复时间是否准确 l 其它由一线或二线人员自行创建的事件单，则由开单人负责关闭 l 处理过程对后续工作有指导或参考的，录入知识库
100.8	事件处理的监控	帮助台 事件经理	l 负责监控所有未关闭的事件的处理状况，对接收到的超时告警应及时关注 l 事件经理负责协调资源，保证事件的最终解决
101	紧急事件处理流程	事件经理	l 事件经理负责协调紧急事件的处理，具体过程见紧急事件处理子流程

下表以事件管理概要图中的关键流程活动为主线，与事件管理概要设计中的其它重要内容进行了关联，以帮助各省业务支撑维护部门更好地理解流程设计内容。

[td]

序号	步骤名称	子流程和流程相关定义	执行原则	流程关联
100.1	事件记录和分类	l 参考“事件性质”、“事件来源”、“所属系统类型”、“事件分类”、“事件优先级”、“事件影响度”、“事件状态”确定以上代码内容	l 参考“所有权原则”，帮助台是该事件的负责人 l 参考“再分派原则”，选择合适的支持组或人员进行分派	l 配置管理：关联相关配置项
100.2	初始支持	l 参考“事件状态”确定代码内容	l 参考“重复事件原则”，对重复事件进行标识 l 参考“升级原则”，及时对事件进行升级
100.3	一线/二线尝试解决	l 参考“事件状态”，并及时修改	l 参考“重复事件原则”，对重复事件进行标识 l 参考“升级原则”，及时对事件进行升级 l 参考“再分派原则”，转派事件单	l 问题管理：参考问题管理记录中的根本原因、变通方法 l 变更管理：参考近期变更管理记录 l 变更管理：必要时提出变更请求，走变更管理流程，一般为紧急变更请求；在变更完成后继续事件处理 l 配置管理：通过配置管理查询配置项的属性和关联信息定位故障原因
100.4	三线尝试解决	l 参考“事件状态”，并及时修改	l 参考“升级原则”，及时对事件进行升级 l 参考“再分派原则”，转派事件单	l 问题管理：参考问题管理记录中的根本原因、变通方法 l 变更管理：参考近期变更管理记录 l 变更管理：必要时提出变更请求，走变更管理流程，一般为紧急变更请求；在变更完成后继续事件处理 l 配置管理：通过配置管理查询配置项的属性和关联信息定位故障原因
100.5	紧急事件再确认	l 参考并再次确定“事件优先级” l 参考“紧急变更子流程”	l 参考“升级原则”，及时对紧急事件升级
100.6	记录解决方案细节	l 在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案并更新事件信息 l 针对故障，一线/二线支持必须记录业务恢复时间 l 参考“事件状态”、“事件影响度”，根据影响度的定义重新确认影响度代码，及时更新事件状态代码		ITSS培训
100.7	关闭事件	l 参考“事件结束代码”、“事件解决人角色”	l 参考“关闭原则”，和用户确认事件的解决和分配相应的结束代码
100.8	事件处理的监控	l 参考“事件的响应时限和解决时限”，关注所有处理中的事件单	l 参考“升级原则”
101	紧急事件处理子流程	l 参考“紧急事件处理子流程”		l 问题管理：优先级为紧急的事件解决完后，需要创建新的问题单

待续http://www.ITILxf.com/thread-52472-1-1.html

本帖关键字：ITSS

展开全部

微信扫一扫，阅读更方便^_^