ITIL事件流程需要制定哪些流程原则（ITIL先锋论坛原创）
本文由长河、陈贺、傅盛原创，张翼、王岩校对。
我们对ITIL事件流程的原则建议以及参考例子，可以参见以下几大分类：
1. 常规原则
[*]所有IT和相关组织事件管理范围内发生的事件，都应该记录在服务管理平台中，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相应的附件；
[*]所有IT支持人员对优先级为紧急和高的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有优先处理级别；
[*]应该每月产生事件管理报表，包含对考核指标的统计，以及相应的报表。并对重复发生的事件和变通方法解决的事件，应该举行定期的事件管理会议对这些事件进行评估；
[*]应该定期对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进事件管理流程。
2. 流程关联原则2.1 和问题管理的关联
[*]支持人员在处理事件的过程中，如发现事件背后隐藏的问题，应创建问题单，问题单必须和事件单建立关联；
[*]支持人员在解决事件的过程中，可以通过问题记录查找相应的解决方案；
2.2 和变更管理的关联
[*]事件处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求单（变更单必须和事件单建立关联），变更完成后，继续事件单的处理；
[*]紧急事件（优先级为紧急的事件，下同）的处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提出紧急变更请求，变更完成后，补录紧急变更单，并和紧急事件单建立关联；
2.3 和配置管理的关联
[*]事件处理过程中，可以通过配置管理查询相关的配置项信息以及该配置项历史上发生的事件、问题或变更，来帮助故障的定位；
[*]事件处理过程中，如果可以将故障定位到某个配置项，则必须将事件单与该配置项关联；
3. 所有权原则
[*]所有权原则用来确保每个事件在任何时段都有适当的人员负责，应该制作事件管理中各角色在各环节中承担不同责任的RACI模型；
[*]由IT用户申报的事件单，服务台坐席是该事件的责任人，必须确保事件得到有效跟踪与解决，并负责事件单的关闭；
4. 再分派原则
[*]事件的再分派原则是确保事件在服务目标时段内处理和解决的重要因素。因此，应当尽量减少事件单再分派的几率。事件单可以分派给服务台组，但分配给一、二线时，只能够分派到个人。
[*]事件单的重分派次数不应该超过5次（从服务台派单开始计算）；
[*]超出分派次数，通知事件经理；
[*]各分支机构人员提交工单给服务台组；
[*]服务台可以将事件单分配给其他服务台人员、一线支持人员；
[*]一线支持人员可以将事件单重新再分配给服务台（驳回）、其他一线及二线支持人员；
[*]二线支持人员可以将事件单重新再分配（驳回）给其他一线人员、二线支持人员和厂商人员；
5. 重复事件原则
[*]重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控平台上报的同一个配置项上现象相同的故障，或者一人/多人申告的同一来源（系统、应用）现象相同的事件。
[*]当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。
[*]监控平台应该自动过滤重复告警，避免将重复的告警发送到服务管理平台；
[*]重复的事件信息必须被标识，并且不计入事件流程的关键衡量指标；
[*]如果服务台可以判断到重复事件，则由服务台对重复事件标识，否则由一、二线支持人员负责重复事件的处理；
[*]重复事件与原事件单关联；
[*]在原有事件单获得解决时，所有的重复事件单获得解决。
6. 关闭原则事件工单关闭环节的基本原则：谁开单，谁负责关闭。
[*]各分支机构人员提交的工单，最后由提交人关闭；
[*]服务台通过电话、邮件、微信、QQ等方式受理的事件工单，由服务台和IT用户确认解决后进行关闭；
[*]二线人员自行创建的事件单，由创建人关闭；
[*]监控平台产生的告警，由服务台人员（机房值班人员）根据监控平台的反馈确认后关闭；
[*]优先级为紧急的事件工单由事件经理进行关闭；
[*]事件处理人员在解决完成事件时，根据实际解决情况填写事件的结束代码，采用临时措施恢复服务时，结束代码为“变通方法解决”。服务台负责和IT用户再次确认事件的解决；
[*]由IT用户认可获得关闭的事件单的结束代码为“成功解决”关闭；
[*]采用临时措施恢复服务时，结束代码为“变通方法解决”；
[*]已解决的事件单如果没有得到IT用户的认可，则首先关闭该事件单，结束代码修改为“不成功”，同时创建一个新的事件单重新分配到原处理人员继续处理，并通知事件经理，服务台通过线下的方式让用户了解不成功的工单后续处理情况；
[*]已关闭的事件单原则上不允许重开。如果事件重复发生，则创建一个新的事件单，并与已关闭的重复工单进行关联。
7. 升级原则制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。
[*]优先级为紧急的事件，由一线再次确认，如果确认了优先级为紧急，则升级到事件经理，启动紧急事件处理流程，并通知相应的管理经理；
[*]优先级为高的事件，一线人员在解决时限的50%内未解决，则要求立即升级到二线人员进行处理；
[*]优先级为中、低的事件，处理时间超过解决时限的80%时，由服务台对处理人进行督促，要求将规定时间内不能解决的事件升级（一线升级到二线，二线升级到三线）；
[*]各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定解决时限，服务台系统应自动将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理；
[*]服务台人员主动监督优先级为中和低的事件处理情况，应及时将不能解决的事件升级；事件经理并对未及时升级的事件及时介入，负责协调升级处理；事件经理通过对事件的抽查和对超时解决的事件统计情况对服务台人员的主动性进行监督。
8. 典型事件原则典型事件包含如下特征：
[*]首次发生，且没有完善的标准处理方法；
[*]与业务或者其他类型设备有较强的关联性；
[*]有较重大或重大的潜在风险；
符合以上条件的事件单均需要提交事件处理报告。
9. 持续改进原则
[*]流程负责人负责定期对事件管理流程的执行情况进行评审，提出改进建议和方案；
[*]定期召开例会，对事件管流程的KPI报表进行讨论，提出改进建议；
[*]定期召开例会，与其他各流程经理讨论并调整影响服务效率和质量的因素；
[*]事件经理在例会中组织针对典型事件进行讨论，并制定标准解决方案。
10.紧急事件判定原则紧急事件包含以下特征：
[*]已经产生重大经济损失的事件；
[*]对于已经严重影响生产系统的事件；
[*]事件的紧急程度极高，必须在7×24小时范围内立即进行处理；
[*]满足以上条件的事件为紧急事件，必须进入紧急事件流程进行处理。
11. 紧急事件处理原则
[*]来自监控管理人员电话通知的紧急事件，需要告知事件经理，同时按照紧急事件处理流程进行线下处理；
[*]所有紧急事件可以进行线下处理，处理完毕后，由事件受理人根据处理情况进行补充记录；
[*]紧急事件执行首问责任制，即首先接到事件的人负责整个事件的处理过程。
IT运维管理社区原创文章，禁止任何形式的转载，侵权必究！
页:
[1]