事件管理与问题管理之争

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

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

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

    了解ITIL的人都知道，事件管理流程包括了6个主要活动：事件查明和记录、归类和初步支持、事件调查和分析、解决事件和恢复服务、事件终止以及负责事件并跟踪、监督、控制和协调解决过程。

    因此，我这样答复事件管理员：“事件的识别，其实也是包含了对事件解决方案的了解，否则如何正确识别呢？不能仅为升级而升级，其他的都不去了解。”

    “我不认同，对解决方案的了解和识别是否正确，我个人认为在事件升级这个概念上说，并不一定重要，惟一重要的，是事件的表述描写以及其类别划分是否一致。”事件管理员说。

    事件管理员的申诉

    事件管理员详细叙述了他的理由：一种现象可以包含多种故障根源，但我们不能因为由于根源不同而表象相同的故障就不升级。

    以前确认过这样一种可能—比如：截止上午10点，服务台接到50起客户报修，而其中有20起相同描述的故障报修。这时，事件就应该及时启动异常事件的报告，而不需要等工程师回来后，事件管理员去了解了问题的解决方案和故障的根源后再‘正确’的升级。哪怕这20起事后得知是客户误报引起，事件也应该提起相应的预警。

    分析原因、查找根源，这些不是事件要去考虑的。不然要问题管理何用？事件管理完全可以把问题管理两岗合一。再如你上面所说，也完全可以在我当天升级完事件报告后的第二天，问题管理去查找服务台的手工报表，查看故障解决方法，也不会有什么积压。

    最后，我个人认为，事件管理报告不仅仅是事件管理的报告类型或手法，同样的，它也是问题管理日常工作所必须的管理报告。

    争论没有形成定论，因为我觉得事件管理员说得也不无道理。我也需要时间来对事件管理流程做一个分析，以找到这个想法存在的理由。

    职责边界

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

    既然已经表述得如此清晰，为什么事件管理还会有“让事件管理在参与问题管理的查访”这样的困惑呢？

    要说清楚这个困惑，还要从客户服务中心的ITIL结构说起（如图1所示）。在客户服务中心实践中，ITIL理论所描述的事件管理职责大部分被实施管理部的服务支持小组替代。由他们来负责事故的快速解决，由服务台、一线工程师、二线工程师等实施管理部的各岗位提供服务支持。

    而事件管理已经从具体执行的位置转向服务流程的管理，所要做的是尽可能快地发现事故，在力所能及的范围内监督服务支持小组尽可能快地处理，并将无法处理的事故尽可能快地升级到问题管理。

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

    于是，事件管理在实际工作中就会遇到一个问题：事件管理该如何处理发现的事故？通过对事件管理的过程进行分析，我们将事故的处理分成两种方式。一种方式是发现即提交升级报告；一种方式是发现后调查分析再提交升级报告。

    前者强调快速、及时，但有一个缺陷：发现即提交的任务完全可以放在实施管理部去执行，因为服务管理部的事件管理发现的再迅速、再及时，也不一定比实施管理部实际操作人员发现更快、更早。

    后者不再强调快速和及时，而是把事件管理中的调查和分析放在首要位置考虑，但这种调查分析是在一定范围内进行，即问题管理提供的解决方案范围。超出部分就转到问题管理，因为追根究底的调查和分析是问题管理的事情。目前事件管理是以前者的方式处理事故，因此当用后者的方式来要求时，事件管理就会在理解上感到“困惑”。

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

    事件管理已经从具体执行的位置转向服务流程的管理，所要做的是尽可能快地发现事故，在力所能及的范围内监督服务支持小组尽可能快地处理，并将无法处理的事故尽可能快地升级到问题管理。

    事件管理与问题管理的基本概念

    事件管理是一个被动性的任务，也就是减少或消除存在或可能存在于IT服务中的干扰因素给IT服务带来的影响，以确保用户可以尽快恢复自己的正常工作。因此，我们要针对事件记录下来并分类，再分配给适当的专业人员来处理；我们也要监控事件的发展；并在事件得到解决之后将其终止。

    如果发生事件则启动事件管理流程对其进行处理；当服务恢复正常，受影响用户恢复工作时，就停止对该事件的处理活动。但是这样做意味着事件发生的根源并不一定都解决了，因而事件还有可能再次发生。

    问题管理调查基础设施和所有可用信息，包括事件数据库，来确定引起事件发生的真正的潜在原因以及提供的服务中可能存在的故障。一旦找到了永久解决这些根本原因的方法，我们就可以发出一个变更请求来消除这些已知错误。在此之后，问题管理会继续跟踪和监控这些基础设施中的已知错误。

    事件管理与问题管理的关系

    事件管理对问题管理来说是一个重要信息提供者。有效的事件记录对成功地进行问题管理来说非常重要，因为这些信息是用于发现问题的。

    问题管理支持事件管理流程的工作。问题管理对问题进行分析，直到找到问题的解决方案；同时问题管理还能为事件管理提供应急措施（通常是在对问题进行研究时找到）来对事件进行处理。

    一旦确定了问题的原因并且定义了一个已知错误，那么提供一个临时修复以阻止事件的再次发生并降低事件的影响。理想的情况下，问题管理还可提供一个变更请求，这会使问题得到最终的解决。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。