20150831 淡然

续上

5         相关定义和说明5.1.  事件的分类

为便于事件的合理分配以及有效汇总、统计和分析事件记录，并为问题、变更管理打好分类基础，事件应得到合理分类。其中一级分类为办公系统终端、基础设施、网络、主机、安全系统、基础应用、业务应用。                               ITSS考试

当影响范围为全体或紧急程度为特急时，此类事件可认为是重大事件，需按照紧急事件流程进行处理。

5.2.  事件的优先级定义

公司事件管理流程中，事件影响范围用于衡量事件所影响业务及用户范围，分为8个等级。事件紧急程度用于衡量事件需要及时解决响应的程度，分为4个等级，根据事件管理流程按照事件影响范围和紧急程度，按照事件优先级的特定计算公式，事件被分为四个优先级：一般(1)、中(2)、高(3)、特高(4)。

5.3.  技术升级时间表

支持 团队 升级 时限 事件 级别	一线支持（服务专员）升级到 二线支持	二线支持 升级到 专家支持	升级到 问题流程
紧急（5级）	无	无	无
高（4级）	2个小时	3个小时
中（3级）	8个小时	12个小时
较低（2级）	24个小时	最终期限前8个小时
低（1级）	48小时	最终期限前8个小时	超过最终时间

5.4.  行政升级时间表

紧急（5级）	升级阀值				/
	报告范围
高（4级）	升级阀值	2个小时	3个小时	超过最终时间
	报告范围	服务专员/一线，被分派工单的二线	被分派工单的服务台/一线/二线，事件经理        ITSS认证	事件经理及管理层
中（3级）	升级阀值	8个小时	12个小时	超过最终时间
	报告范围	服务专员/一线，被分派工单的二线	被分派工单的一线/二线，事件经理	事件经理及管理层
较低（2级）	升级阀值	24个小时	最终期限前8个小时	最终期限前2小时	超过最终时间
	报告范围	服务专员/一线，被分派工单的二线	被分派工单的一线/二线	被分派工单的一线/二线，事件经理	事件经理及管理层
低（1级）	升级阀值	48小时	最终期限前8个小时	最终期限前2小时	超过最终时间
	报告范围	服务专员/一线，被分派工单的二线	被分派工单的一线/二线	被分派工单的一线/二线，事件经理	事件经理及管理层

5.5.  事件的状态

事件处理流程中事件的相关状态定义见下表。

事件的状态	定义
已登记	已由服务专员登记
分派	事件已由一线发出，未被接受
返回	事件分配不当，返回服务专员
一线处理中	已分派到一线处理中
二线处理中	已分派到二线并接受
RFC	已通过RFC提交解决方案
完成	一线/二线已解决事件
结束	事件已关闭（服务专员）

6         事件管理流程描述6.1.  普通事件流程

序号	步骤 名称	责任人	说明
1	事件接受与记录	服务专员	1.   服务专员对来自用户和系统自动产生的事件进行详细记录，其中包括故障/告警/服务请求
2	分类与支持，调度分派	服务专员	1.   在接收到事件后进行分类记录 2.   尝试直接解决用户提出的请求 3.   无法解决则进行调度分派
3	分析处理	一线人员	1.   技术部一线支持人员接受事件，进行调查诊断，尝试解决 2.   事件解决后，记录事件解决方案
4	二线调查诊断	二线人员	1.   二线支持人员接受事件，进行调查诊断，尝试解决 2.   事件解决后，记录事件解决方案 3.   如果二线支持认为需要三线进行处理，即升级为问题 4.   二线支持人员接受到来自服务专员的紧急事件后，根据事件优先级别标准再次确认事件是否为紧急事件 5.   如果优先级确实紧急，则通知相应的管理层，并立即升级到事件经理，紧急事件处理子流程
6	解决和恢复	一线支持 二线支持	1.   在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案并更新事件信息
7	反馈客户/关闭	一线支持 二线支持	1.   服务专员与用户确认事件是否已得到解决，如果解决，事件以成功解决或变通方法解决而关闭；否则，事件以不成功关闭，重新开事件记录，并与原记录作关联，分派到原处理人员继续处理 2.   服务专员在关闭事件的同时必须确认事件单记录的业务恢复时间是否准确 3.   其它由一线或二线人员自行创建的事件单，则由开单人负责关闭
8	审核并提交进入知识库	事件经理	1.   对已关闭的工单进行审核并挑选加入知识库
9	紧急事件处理流程	事件经理	1.   事件经理负责协调紧急事件的处理，具体过程见紧急事件处理子流程

6.2.  紧急事件流程

序号	步骤名称	说明
1	召集应急小组，协调应急会议	1. 事件经理主持应急会议，并组织讨论、协调各方资源，分析紧急事件处理方案； 2. 与此同时，事件经理还需将紧急事件上报上级公司信息部门。
2	判断是否属于应急预案中的事件？	1.   应急小组和相关厂商根据紧急事件现象和影响程度，判断是否需要启动相应系统的应急预案； 2.   如果没有应急预案，则进入4组织相关专家共同分析紧急事件，制定处理方案并处理； 3.   如果有应急预案，则进入3按照应急预案处理。
3	按照应急预案处理	1.   根据各系统制定的应急预案中的实施步骤，处理紧急事件。
4	组织相关厂商共同分析，制定处理方案并处理	1.   应急小组负责组织相关厂商共同分析紧急事件，制定相应的处理方案； 2.   处理方案在实施前应得到应急小组和相关领导的认可； 3.   事件处理过程中如果需要中断业务或对系统的IT组件产生变更，则需要按照紧急变更管理流程的定义和要求，提出紧急变更请求。
5	紧急事件解除确认？	1.   在紧急事件处理方案实施后，应急小组、相关专家和相关部门对紧急事件是否解除进行确认； 2.   紧急事件如果没有解除，则重新进入4组织相关专家共同分析紧急事件，制定处理方案并处理； 3.   如果解除，则进入6紧急事件善后处理和总结分析。
6	善后处理和通报	1.   紧急事件解除后，应向申告方、公司相关领导简要报告紧急事件处理过程，解决方法，事件解除时间，业务恢复情况； 2.   对于影响度为高的紧急事件，必须提交《重大事件报告》；      ITSS培训            3.   紧急事件的处理人需要创建一个新问题，将紧急事件处理过程的详细信息记录到问题单中，提交到问题经理，由问题经理组织相关专家进行问题根源的分析。

待续http://ITIL-foundation.cn/thread-52453-1-1.html

本帖关键字：ITSS

20150831 淡然

续上

5         相关定义和说明5.1.  事件的分类

为便于事件的合理分配以及有效汇总、统计和分析事件记录，并为问题、变更管理打好分类基础，事件应得到合理分类。其中一级分类为办公系统终端、基础设施、网络、主机、安全系统、基础应用、业务应用。                               ITSS考试

当影响范围为全体或紧急程度为特急时，此类事件可认为是重大事件，需按照紧急事件流程进行处理。

5.2.  事件的优先级定义

公司事件管理流程中，事件影响范围用于衡量事件所影响业务及用户范围，分为8个等级。事件紧急程度用于衡量事件需要及时解决响应的程度，分为4个等级，根据事件管理流程按照事件影响范围和紧急程度，按照事件优先级的特定计算公式，事件被分为四个优先级：一般(1)、中(2)、高(3)、特高(4)。

5.3.  技术升级时间表

支持 团队 升级 时限 事件 级别	一线支持（服务专员）升级到 二线支持	二线支持 升级到 专家支持	升级到 问题流程
紧急（5级）	无	无	无
高（4级）	2个小时	3个小时
中（3级）	8个小时	12个小时
较低（2级）	24个小时	最终期限前8个小时
低（1级）	48小时	最终期限前8个小时	超过最终时间

5.4.  行政升级时间表

紧急（5级）	升级阀值				/
	报告范围
高（4级）	升级阀值	2个小时	3个小时	超过最终时间
	报告范围	服务专员/一线，被分派工单的二线	被分派工单的服务台/一线/二线，事件经理        ITSS认证	事件经理及管理层
中（3级）	升级阀值	8个小时	12个小时	超过最终时间
	报告范围	服务专员/一线，被分派工单的二线	被分派工单的一线/二线，事件经理	事件经理及管理层
较低（2级）	升级阀值	24个小时	最终期限前8个小时	最终期限前2小时	超过最终时间
	报告范围	服务专员/一线，被分派工单的二线	被分派工单的一线/二线	被分派工单的一线/二线，事件经理	事件经理及管理层
低（1级）	升级阀值	48小时	最终期限前8个小时	最终期限前2小时	超过最终时间
	报告范围	服务专员/一线，被分派工单的二线	被分派工单的一线/二线	被分派工单的一线/二线，事件经理	事件经理及管理层

5.5.  事件的状态

事件处理流程中事件的相关状态定义见下表。

事件的状态	定义
已登记	已由服务专员登记
分派	事件已由一线发出，未被接受
返回	事件分配不当，返回服务专员
一线处理中	已分派到一线处理中
二线处理中	已分派到二线并接受
RFC	已通过RFC提交解决方案
完成	一线/二线已解决事件
结束	事件已关闭（服务专员）

6         事件管理流程描述6.1.  普通事件流程

序号	步骤 名称	责任人	说明
1	事件接受与记录	服务专员	1.   服务专员对来自用户和系统自动产生的事件进行详细记录，其中包括故障/告警/服务请求
2	分类与支持，调度分派	服务专员	1.   在接收到事件后进行分类记录 2.   尝试直接解决用户提出的请求 3.   无法解决则进行调度分派
3	分析处理	一线人员	1.   技术部一线支持人员接受事件，进行调查诊断，尝试解决 2.   事件解决后，记录事件解决方案
4	二线调查诊断	二线人员	1.   二线支持人员接受事件，进行调查诊断，尝试解决 2.   事件解决后，记录事件解决方案 3.   如果二线支持认为需要三线进行处理，即升级为问题 4.   二线支持人员接受到来自服务专员的紧急事件后，根据事件优先级别标准再次确认事件是否为紧急事件 5.   如果优先级确实紧急，则通知相应的管理层，并立即升级到事件经理，紧急事件处理子流程
6	解决和恢复	一线支持 二线支持	1.   在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案并更新事件信息
7	反馈客户/关闭	一线支持 二线支持	1.   服务专员与用户确认事件是否已得到解决，如果解决，事件以成功解决或变通方法解决而关闭；否则，事件以不成功关闭，重新开事件记录，并与原记录作关联，分派到原处理人员继续处理 2.   服务专员在关闭事件的同时必须确认事件单记录的业务恢复时间是否准确 3.   其它由一线或二线人员自行创建的事件单，则由开单人负责关闭
8	审核并提交进入知识库	事件经理	1.   对已关闭的工单进行审核并挑选加入知识库
9	紧急事件处理流程	事件经理	1.   事件经理负责协调紧急事件的处理，具体过程见紧急事件处理子流程

6.2.  紧急事件流程

序号	步骤名称	说明
1	召集应急小组，协调应急会议	1. 事件经理主持应急会议，并组织讨论、协调各方资源，分析紧急事件处理方案； 2. 与此同时，事件经理还需将紧急事件上报上级公司信息部门。
2	判断是否属于应急预案中的事件？	1.   应急小组和相关厂商根据紧急事件现象和影响程度，判断是否需要启动相应系统的应急预案； 2.   如果没有应急预案，则进入4组织相关专家共同分析紧急事件，制定处理方案并处理； 3.   如果有应急预案，则进入3按照应急预案处理。
3	按照应急预案处理	1.   根据各系统制定的应急预案中的实施步骤，处理紧急事件。
4	组织相关厂商共同分析，制定处理方案并处理	1.   应急小组负责组织相关厂商共同分析紧急事件，制定相应的处理方案； 2.   处理方案在实施前应得到应急小组和相关领导的认可； 3.   事件处理过程中如果需要中断业务或对系统的IT组件产生变更，则需要按照紧急变更管理流程的定义和要求，提出紧急变更请求。
5	紧急事件解除确认？	1.   在紧急事件处理方案实施后，应急小组、相关专家和相关部门对紧急事件是否解除进行确认； 2.   紧急事件如果没有解除，则重新进入4组织相关专家共同分析紧急事件，制定处理方案并处理； 3.   如果解除，则进入6紧急事件善后处理和总结分析。
6	善后处理和通报	1.   紧急事件解除后，应向申告方、公司相关领导简要报告紧急事件处理过程，解决方法，事件解除时间，业务恢复情况； 2.   对于影响度为高的紧急事件，必须提交《重大事件报告》；      ITSS培训            3.   紧急事件的处理人需要创建一个新问题，将紧急事件处理过程的详细信息记录到问题单中，提交到问题经理，由问题经理组织相关专家进行问题根源的分析。

待续http://ITIL-foundation.cn/thread-52453-1-1.html

本帖关键字：ITSS