针对ITSS紧急事件要实施的相关子流程是哪些
20151106淡然
续上
5.4记录解决方案
图4记录解决方案
流程活动：
序号 | 活动 | 说明 | 角色 |
8.2.3.1 | 确定解决事件的方式 | 确定用什么方式解决事件ITSS考试 | 一线二线支持 |
8.2.3.2 | 借助问题管理？ | 判断是否要借助问题管理彻查原因 | 一线二线支持 |
8.2.3.3 | 注明转问题单原因 | 如果认为需要通过问题管理才能彻底解决故障，可以注明原因，转回协调员安排升级问题 | 一线二线支持 |
8.2.3.4 | 发起变更？ | 判断是否要发起变更 | 一线二线支持 |
8.2.3.5 | 发起请求？ | 判断是否要发起请求 | 一线二线支持 |
8.2.3.6 | 记录解决方案 | 记录初步的故障解决方案 | 一线二线支持 |
5.5实施解决方案
图5实施解决方案
流程活动：
序号 | 活动 | 说明 | 角色 |
8.2.4.1 | 是否有权实施？ | 判断是否有足够的权限独自实施解决方案 | 一线二线支持 |
8.2.4.2 | 实施解决方案 | 如权限足够，则直接实施解决方案 | 一线二线支持 |
8.2.4.3 | 是否发生错误？ | 在实施解决方案的过程发生了错误？ | 一线二线支持 |
8.2.4.4 | 是否需要升级？ | 判断是否要对错误升级 | 一线二线支持 |
8.2.4.5 | 重分派给其他人或支持组 | 针对权限不足或者处理过程发生错误的情况，都应及时把事件单转回协调员处理 | 一线二线支持 |
5.6关闭事件单
图6关闭事件单
流程活动：
序号 | 活动 | 说明 | 角色 |
8.2.5.1 | 确认并更新解决方案 | 确认已解决用户故障，更新解决方案内容 | 一线二线支持 |
8.2.5.2 | 关闭事件单 | 关闭事件单 | 一线二线支持 |
8.2.5.3 | 事件由监控系统引起？ | 事件单关闭后，系统会自动判断事件单是否来自监控系统告警，如果是则返回相关信息到监控系统。 | 系统 |
8.2.5.4 | 事件由日常运维引起？ | 事件单关闭后，系统会自动判断事件单是否来自日常运维单，如果是则返回事件单状态给日常工单。ITSS认证 | 系统 |
5.7紧急事件处理子流程
制定紧急事件处理子流程的目标：
•当紧急事件发生时，尽可能采取措施减少对于业务带来的影响
•确保对紧急情况的有效管理
-加快紧急事件的响应和处理速度
-对紧急情况中的人员及采取的行动加强管理
-加强处理人员与用户之间的沟通和反馈
-对紧急情况妥善处理
流程原则：
•制定各系统应急处理预案
为了确保系统发生重大故障时，能够尽快恢复业务，并充分调动技术力量，在最短时间内排除故障，各系统应该建立相应的应急处理预案，建议预案中的内容至少应涵盖以下方面：
-应急预案启动条件
-应急处理小组负责人和成员联系名单和联系方式
-应急处理步骤
-应急信息通报
-应急善后处理
-应急保障措施（人员、培训、演习、场地等）
•紧急事件及时上报信管部
图7紧急事件处理子流程
流程活动：
序号 | 活动 | 说明 | 角色 |
8.2.6.1 | 召集应急小组，协调应急会议 | 事件经理主持应急会议，并组织讨论、协调各方资源，分析紧急事件处理方案，并将紧急事件情况通报信息部 | 事件经理 |
8.2.6.2 | 判断是否属于应急预案中的事件？ | 应急小组和相关供应商根据紧急事件现象和影响程度，判断是否需要启动相应系统的应急预案？ | 协调员 |
8.2.6.3 | 按照应急预案处理 | 根据各系统制定的应急预案中的实施步骤，处理紧急事件 | 协调员 |
8.2.6.4 | 组织相关部门人员共同分析，制定处理方案并处理 | 应急小组负责组织相关供应商共同分析紧急事件，制定相应的处理方案，处理方案在实施前应得到应急小组和相关领导的认可； 事件处理过程中如果需要中断业务或对系统的IT组件产生变更，则需要按照紧急变更管理流程的定义和要求，提出紧急变更请求 | 协调员 |
8.2.6.5 | 紧急事件解除确认？ | 在紧急事件处理方案实施后，应急小组和相关部门对紧急事件是否解除进行确认 | 协调员 |
8.2.6.6 | 善后处理和通报 | 紧急事件解除后，应急小组向用户、公司相关领导简要报告紧急事件处理过程，解决方法，事件解除时间，业务恢复情况。 紧急事件处理人在流程平台确定事件解决时间，填写解决方案。 紧急事件处理人需要创建一个新问题，将紧急事件处理过程的详细信息记录到问题单中，提交到问题经理，由问题经理组织相关专家进行问题根源的分析ITSS培训 | 协调员 |
待续
本帖关键字：ITSS