ITSS事件管理中各流程的关联是怎样的
本帖最后由 monicazhang 于 2015-10-22 11:37 编辑20151022 淡然续上
4.6.11事件解决人角色 事件解决人角色用来标明该事件单最终解决的角色是帮助台、一线还是二线。
编号代码描述
1帮助台帮助台最终解决事件
2一线4.7 一线支持最终解决事件
3二线4.8 二线支持最终解决事件
4三线4.9 三线支持最终解决事件
4.9.1 处理是否超时 每个优先级别都对应了解决期限，“处理是否超时”用来标明事件的处理是否已超过了解决期限。
编号代码描述
1未超时未超时 ITSS考试
2超时事件已超出规定的解决时限
4.9.2 故障厂商 用来在事件单中记录是哪个厂商的设备/系统，或者哪个集成商的应用软件发生故障(针对事件分类中的“应用软件”故障)。代码定义参见《资源管理分册》厂商和集成商名称标准（可以根据情况从厂商和集成商两个表中选择一个合适的故障厂商）。各省可以根据实际情况对厂商名称标准表和集成商名称标准表进行扩充。
4.10 流程概要设计 事件管理概要设计流程图：图4-1事件管理概要流程事件管理概要设计流程说明：
序号
步骤名称责任人说明
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 事件经理负责协调紧急事件的处理，具体过程见紧急事件处理子流程
下表以事件管理概要图中的关键流程活动为主线，与事件管理概要设计中的其它重要内容进行了关联，以帮助各省业务支撑维护部门更好地理解流程设计内容。
序号
步骤名称子流程和流程相关定义执行原则流程关联
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://ITIL-foundation.cn/thread-52472-1-1.html本帖关键字：ITSS
页:
[1]