2007-2-14 13:37:19

[原创]事件管理的困惑

本文发表于《中国计算机用户》 2007年3月26日第11期管理栏

我曾兼职过一段时间的问题管理，在一次例行事件升级报告审核中，我发现一份报告需要了解其产生原因，根据经验这份报告很可能不属于事件升级的范围，而应该作为内部管理报告提交。

于是，我给事件管理发了一条消息：“你查一下原因，如果符合管理报告的要求，改提一份内部管理报告给实施管理部。”

“事件管理现在也要开始了解事件的原因？我觉得这已经超出事件管理的范围……现在事件的边界很乱，比如现在的事件升级要求必须有事件的解决方案才可以提交升级报告……对我来说多做这一步没花多少额外的精力，但我觉得这样的做法是让事件管理在参与问题管理的查访。”事件管理这么回复。

了解ITIL的知道事件管理流程包括了6个主要活动：事件查明和记录、归类和初步支持、事件调查和分析、解决事件和恢复服务、事件终止以及负责事件并跟踪、监督、控制和协调解决过程。因此，我这样答复事件管理：“事件的识别，其实也是包含了对事件解决方案的了解，否则如何正确识别呢？不能仅为升级而升级，其它的都不去了解。”

“我不认同，对解决方案的了解和识别是否正确，个人认为在事件升级这个概念上说，并不一定重要，唯一重要的，是事件的表诉描写以及其类别划分是否一致，为什么呢？很简单，一种现象可以包含多种故障根源，但我们不能因为由于根源不同而表象相同的故障就不升级。以前。我确认过这样一种可能。比如：截止上午10点，服务台接到50起客户报修，而其中有20起相同描述的故障报修。这时，事件就应该及时启动异常事件的报告，而不需要等工程师回来后，事件管理去了解了问题的解决方案和故障的根源后再’正确’的升级。哪怕这20起事后得知是客户误报引起，事件也应该提起相应的预警。而分析原因，查找根源，这些不是事件去考虑的。不然要问题管理何在？事件管理完全就可以把问题管理两岗合一。再如你上所说，也完全可以在我当天升级完事件报告后。第二天问题管理去查找服务台的手工报表，查看故障解决方法。也不会有什么积压。最后，我个人认为。事件管理报告不仅仅是事件管理的报告类型或手法，同样的，它也是问题管理日常工作所必须的管理报告！……”争论没有形成定论，因为他说的有道理。我也需要时间来对事件管理流程做一个分析，以找到这个想法存在的理由。

在ITIL理论中对事件管理和问题管理之间区别介绍的非常清楚。“事件管理的主要目标是在事故发生后尽可能快地恢复客户服务，即使采取的是一些应急措施而不是永久性的解决方案”，“强调速度”；“问题管理的主要目标是要查明事故发生的潜在原因并找到此事故的方法或防止其再次发生的措施”，“强调质量，把速度放在第二位。”（摘自《IT服务管理－概念、理解与实施》P122）既然已经表述的如此清晰，为什么事件管理还会有“让事件管理在参与问题管理的查访”这样的困惑呢？

要说清楚这个困惑，还要从客户服务中心的ITIL结构说起（见图1）。在客户服务中心实践中，ITIL理论所描述的事件管理职责大部分被实施管理部的服务支持小组替代。由他们来负责事故的尽快解决，由服务台、一线工程师、二线工程师等提供服务支持。而事件管理已经从具体执行的位置转向服务流程的管理，所要做是尽可能快地发现事故，在力所能及的范围内监督服务支持小组尽可能快地处理，并将无法处理的事故尽可能快地升级到问题管理。

讲到这里，似乎问题已经清楚。事件管理所担心的事故发现无法做到的“快速、及时”并不是其职责所在。但由于客户服务中心对事件管理的职责范围一直没有形成明确的定位，因此我们在这样一种理论与实践未达到一致的混沌情况下产生了理解上的差异。

于是，事件管理在实际工作就会遇到一个问题：事件管理该如何处理发现的事故？通过对事件管理的过程进行分析，我们将事故的处理分成两种方式。一种方式是发现即提交升级报告；一种方式是发现后调查分析再提交升级报告。前者强调快速、及时，但有一个缺陷：发现即提交的任务完全可以放在实施管理部去执行，因为服务管理部的事件管理发现的再迅速、再及时，也不一定比实施管理部实际操作人员发现更快、更早；后者不再强调快速和及时，而是把事件管理中的调查和分析放在首要位置考虑，但这种调查分析是在一定范围内进行，即问题管理提供的解决方案范围。超出部分就转到问题管理，因为追根究底的调查和分析是问题管理的事情。目前事件管理是以前者的方式处理事故，因此当用后者的方式来要求时，事件管理就会在理解上感到“困惑”。

之所以将事件管理这个事例拿出来进行分析，是因为我想借此说明一点：实践中事件管理的职责范围发生变化时，一定要明确事件管理和问题管理的界限，并就此与事件管理和问题管理在认识上达成一致，否则就会出现文章开头那样的事件管理疑惑。