20151106   淡然

续上




6. 事件管理流程设计6.1.   前提约定6.1.1.     概念约定

为了方便后续内容的理解，对一些比较关键的概念解释如下：

q  “用户”

指的是某公司IT信息中心内部的所有服务提供者（运维支持人员）和外部的所有服务使用者。                    ITSS考试

q   “客户”

指的是使用某公司IT信息中心提供的各种服务的所有使用者。

q  “IT维护人员”

指的是某公司IT信息中心IT服务的提供者，具体来讲，就是运维部门的支持、运维人员；也包括第三方的支持人员。

q  “角色”

角色是ITIL从实际工作中抽象出来的具体流程环节的执行者，具备一定的职能，被要求一定的能力，并设置相应的考核指标。

一个事件管理流程中可具备多种角色，如：用户、服务台（一线）、突发事件分析员（二线，三线）、事件经理等等，角色把流程要求的各个环节的工作合理的划分、细分，使得资源配置合理，进而流程执行起来更加流畅，并被有效的监督。

角色的划分使得工作责权明确，便于开展IT运维工作。

q  “角色与具体IT维护人员关系”

角色的定义来源于具体的运维人员，但在流程设计和描述中与具体IT维护人员没有直接关系，即流程中描述的是每个角色的具体操作环节和角色之间的关系，在具体流程执行时，将会在具体IT运维人员与流程的角色之间做映射。

一般来说一个运维人员对应一个角色，根据实际的情况，一个具体IT运维人员也可以对应多个角色。如：一个IT运维人员负责日常检查，当发现问题的时候，作为“用户”需要马上电话通知“服务台”的人员记录和分配该突发事件，如果该IT运维人员负责问题发生的系统，那么又将以“一线”的角色开始处理问题。

q  “流程设计”

基于ITIL的事件管理流程设计，是把华星光电IT信息中心实际情况作为输入，通过ITIL指导和加工处理，最终输出基于ITIL的符合华星光电IT信息中心实际情况的事件管理流程的过程。

一般来说，用户的输入是一个空白或已有的具体人员和流程混合在一起的实际流程。经过ITIL处理，把实际工作和人员抽象化，经过讨论和设计，变成与具体人员无关的角色和各种必需的操作环节结合体的流程；最终在流程执行时，把流程中的角色和具体的IT运维人员映射，具体IT运维人员再按照设计出来的流程执行。

整个输入、处理、输出的过程，是顾问和华星光电IT信息中心配合人员共同讨论完成的，这样有助于知识的转移和后续的流程自我优化。

q  “变通方法”

“变通方法”是相对“根本解决方法”而言的，是指没有根本解决一个事件引起的故障，但恢复了事件影响的服务（或业务）的方法。“变通方法”定义本身也说明了：事件管理流程的目的是在规定时间内恢复服务（或业务），而不完全是针对事件本身。比如：用户不能够打印文档，只要提供一台备用打印机就可以恢复打印服务，用户原有的打印机还是故障状态。因此，具体事件管理流程执行时，需要把握好尺度：规定时间内，在服务（或业务）恢复的前提下，再尽可能的去完善方法。

6.1.2.     原则约定

(注：此处涉及的时间需要待服务级别流程确定后再更新，三天为示例)

事件关闭原则：

ITIL中要求，事件的建立和关闭都要由服务台进行，这就是事件管理的闭环原则。

事件的关闭原则具体描述如下：

q  事件必须有责任人，一般情况下事件的责任人由服务台人员担任。

q  事件必须由事件责任人关闭。

q  采用两段式关闭策略，事件处理人员解决事件后，将状态改为“已解决”，相关服务台人员联系用户确认关闭，确保事件处理的闭包（Closed-Loop)

q  对于确实因为条件不具备无法解决的事件或请求，用户坚持不同意的关闭的，升级给服务台经理和突发事件经理，服务台经理与事件经理协商后，联系用户解释后以关闭代码”无法解决”关闭。

结合华星光电IT信息中心的具体情况，定义了以下关闭事件的原则：                    ITSS认证

q  对于非重大事件，由服务台与用户确认并关闭问题。

q  对于重大事件，如特殊事件，可由具体重大故障负责人与用户直接确认，服务台直接关闭该事件。

为落实首问责任制中的事件跟踪、闭环规范，现给出事件闭环操作指导。

1)    已在电话或邮件中与用户确认解决的事件

      规范的操作：关闭相应的交互单和突发事件单.   

2)    给出了解决方案，但不确定一定解决，还未得到用户确认的事件

      规范的操作：

    （1）突发事件分析员将突发事件状态置为”已解决“。

    （2）服务台在事件”已解决”后的三个工作日内电话或邮件联系用户，确认事件解决情况，用户确认解决后，将事件闭环。

3)    服务台/突发事件分析员自己解决不了，传递给专家或者其他技术支持的事件

规范的操作：

     （1）事件传递后要确定责任人已收到事件传递的通知（确定方式包括但不限于邮件和电话），保证事件及时处理，并将联系技术支持处理的过程记录到活动历史中；

     （2）已收到”已解决“通知后，紧急或者影响大的事件（如：网络不通），要立即联系用户确认解决情况，确认解决后将事件闭环。其余事件必须在事件Resolved后的三个工作日内电话或邮件联系用户，确认事件解决情况，用户确认解决后，将事件闭环。

     （3）如果下班时紧急或者影响大的事件还未解决（如：网络不通），需在下班后将事件号和事件的当前进展通过邮件发送给下一班次的值班人员，并与下一班次的值班人员进行当面交接。

4)    跟踪、闭环要求：

     （1）将每次跟踪的记录、用户确认解决的闭环信息必须写入活动历史中;

     （2）传递给别人的事件闭环后事件单关闭

备注：不限制跟踪的次数，关注闭环结果，除了联系不上用户外，其他在三个工作日内未闭环的均不合格。

重分配原则：

事件的重分配规则具体描述如下：

q  事件的及时、正确分配和接受处理是确保事件在解决时限内解决的关键因素。

q  一线和突发事件分析员可以根据重分配原则重新分配不属于自己运维范围的事件。

升级原则：

制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案

q  服务台/一线支持应及时将不能解决的事件升级到其后一级的支持人员，若未及时升级，事件经理应及时介入，负责协调升级处理

q  各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，服务台应将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理

q  应遵从华星光电的事件升级通报规范

重复事件原则

重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控平台上报的同一个配置项上现象相同的事件或一人、多人申告的同一来源（系统、应用）现象相同的事件。当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重复事件单获得解决。

q  监控平台应该自动过滤重复告警，避免将重复的告警发送到服务管理平台                   ITSS培训

q  如果服务台/一线支持判断到重复事件，则由服务台/一线支持需要将新建的交互单关联到已有的突发事件单

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

本帖关键字：ITSS

20151106   淡然

续上




6. 事件管理流程设计6.1.   前提约定6.1.1.     概念约定

为了方便后续内容的理解，对一些比较关键的概念解释如下：

q  “用户”

指的是某公司IT信息中心内部的所有服务提供者（运维支持人员）和外部的所有服务使用者。                    ITSS考试

q   “客户”

指的是使用某公司IT信息中心提供的各种服务的所有使用者。

q  “IT维护人员”

指的是某公司IT信息中心IT服务的提供者，具体来讲，就是运维部门的支持、运维人员；也包括第三方的支持人员。

q  “角色”

角色是ITIL从实际工作中抽象出来的具体流程环节的执行者，具备一定的职能，被要求一定的能力，并设置相应的考核指标。

一个事件管理流程中可具备多种角色，如：用户、服务台（一线）、突发事件分析员（二线，三线）、事件经理等等，角色把流程要求的各个环节的工作合理的划分、细分，使得资源配置合理，进而流程执行起来更加流畅，并被有效的监督。

角色的划分使得工作责权明确，便于开展IT运维工作。

q  “角色与具体IT维护人员关系”

角色的定义来源于具体的运维人员，但在流程设计和描述中与具体IT维护人员没有直接关系，即流程中描述的是每个角色的具体操作环节和角色之间的关系，在具体流程执行时，将会在具体IT运维人员与流程的角色之间做映射。

一般来说一个运维人员对应一个角色，根据实际的情况，一个具体IT运维人员也可以对应多个角色。如：一个IT运维人员负责日常检查，当发现问题的时候，作为“用户”需要马上电话通知“服务台”的人员记录和分配该突发事件，如果该IT运维人员负责问题发生的系统，那么又将以“一线”的角色开始处理问题。

q  “流程设计”

基于ITIL的事件管理流程设计，是把华星光电IT信息中心实际情况作为输入，通过ITIL指导和加工处理，最终输出基于ITIL的符合华星光电IT信息中心实际情况的事件管理流程的过程。

一般来说，用户的输入是一个空白或已有的具体人员和流程混合在一起的实际流程。经过ITIL处理，把实际工作和人员抽象化，经过讨论和设计，变成与具体人员无关的角色和各种必需的操作环节结合体的流程；最终在流程执行时，把流程中的角色和具体的IT运维人员映射，具体IT运维人员再按照设计出来的流程执行。

整个输入、处理、输出的过程，是顾问和华星光电IT信息中心配合人员共同讨论完成的，这样有助于知识的转移和后续的流程自我优化。

q  “变通方法”

“变通方法”是相对“根本解决方法”而言的，是指没有根本解决一个事件引起的故障，但恢复了事件影响的服务（或业务）的方法。“变通方法”定义本身也说明了：事件管理流程的目的是在规定时间内恢复服务（或业务），而不完全是针对事件本身。比如：用户不能够打印文档，只要提供一台备用打印机就可以恢复打印服务，用户原有的打印机还是故障状态。因此，具体事件管理流程执行时，需要把握好尺度：规定时间内，在服务（或业务）恢复的前提下，再尽可能的去完善方法。

6.1.2.     原则约定

(注：此处涉及的时间需要待服务级别流程确定后再更新，三天为示例)

事件关闭原则：

ITIL中要求，事件的建立和关闭都要由服务台进行，这就是事件管理的闭环原则。

事件的关闭原则具体描述如下：

q  事件必须有责任人，一般情况下事件的责任人由服务台人员担任。

q  事件必须由事件责任人关闭。

q  采用两段式关闭策略，事件处理人员解决事件后，将状态改为“已解决”，相关服务台人员联系用户确认关闭，确保事件处理的闭包（Closed-Loop)

q  对于确实因为条件不具备无法解决的事件或请求，用户坚持不同意的关闭的，升级给服务台经理和突发事件经理，服务台经理与事件经理协商后，联系用户解释后以关闭代码”无法解决”关闭。

结合华星光电IT信息中心的具体情况，定义了以下关闭事件的原则：                    ITSS认证

q  对于非重大事件，由服务台与用户确认并关闭问题。

q  对于重大事件，如特殊事件，可由具体重大故障负责人与用户直接确认，服务台直接关闭该事件。

为落实首问责任制中的事件跟踪、闭环规范，现给出事件闭环操作指导。

1)    已在电话或邮件中与用户确认解决的事件

      规范的操作：关闭相应的交互单和突发事件单.   

2)    给出了解决方案，但不确定一定解决，还未得到用户确认的事件

      规范的操作：

    （1）突发事件分析员将突发事件状态置为”已解决“。

    （2）服务台在事件”已解决”后的三个工作日内电话或邮件联系用户，确认事件解决情况，用户确认解决后，将事件闭环。

3)    服务台/突发事件分析员自己解决不了，传递给专家或者其他技术支持的事件

规范的操作：

     （1）事件传递后要确定责任人已收到事件传递的通知（确定方式包括但不限于邮件和电话），保证事件及时处理，并将联系技术支持处理的过程记录到活动历史中；

     （2）已收到”已解决“通知后，紧急或者影响大的事件（如：网络不通），要立即联系用户确认解决情况，确认解决后将事件闭环。其余事件必须在事件Resolved后的三个工作日内电话或邮件联系用户，确认事件解决情况，用户确认解决后，将事件闭环。

     （3）如果下班时紧急或者影响大的事件还未解决（如：网络不通），需在下班后将事件号和事件的当前进展通过邮件发送给下一班次的值班人员，并与下一班次的值班人员进行当面交接。

4)    跟踪、闭环要求：

     （1）将每次跟踪的记录、用户确认解决的闭环信息必须写入活动历史中;

     （2）传递给别人的事件闭环后事件单关闭

备注：不限制跟踪的次数，关注闭环结果，除了联系不上用户外，其他在三个工作日内未闭环的均不合格。

重分配原则：

事件的重分配规则具体描述如下：

q  事件的及时、正确分配和接受处理是确保事件在解决时限内解决的关键因素。

q  一线和突发事件分析员可以根据重分配原则重新分配不属于自己运维范围的事件。

升级原则：

制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案

q  服务台/一线支持应及时将不能解决的事件升级到其后一级的支持人员，若未及时升级，事件经理应及时介入，负责协调升级处理

q  各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，服务台应将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理

q  应遵从华星光电的事件升级通报规范

重复事件原则

重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控平台上报的同一个配置项上现象相同的事件或一人、多人申告的同一来源（系统、应用）现象相同的事件。当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重复事件单获得解决。

q  监控平台应该自动过滤重复告警，避免将重复的告警发送到服务管理平台                   ITSS培训

q  如果服务台/一线支持判断到重复事件，则由服务台/一线支持需要将新建的交互单关联到已有的突发事件单

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

本帖关键字：ITSS