事件管理 要 了解事件的原因?
学习资料：IT运维管理社区专家讲堂直播300期视频回放事件管理要了解事件的原因?
由于客户服务中心对事件管理的职责范围一直没有形成明确的定位，因此我们在这样一种理论与实践未达到一致的混沌情况下产生了理解上的差异。
事件管理与问题管理之争
由于工作上安排，我曾**一段时间的问题管理员。在一次例行事件升级报告审核中，我发现一份事件升级报告需要进一步了解其产生原因。根据经验，这份报告很可能不属于事件升级的范围，而应该作为内部管理报告提交。
于是，我给事件管理员发了一条消息：“你查一下原因，如果符合管理报告的要求，改提一份内部管理报告给实施管理部。”
“事件管理现在也要开始了解事件的原因？我觉得这已经超出事件管理的范围。现在事件的边界很乱，比如现在的事件升级，要求必须有事件的解决方案才可以提交升级报告。对我来说，多做这一步没花多少额外的精力，但我觉得这样的做法是让事件管理在参与问题管理的查访。”事件管理员这样回复我。
了解ITIL的人都知道，事件管理流程包括了6个主要活动：事件查明和记录、归类和初步支持、事件调查和分析、解决事件和恢复服务、事件终止以及负责事件并跟踪、监督、控制和协调解决过程。
因此，我这样答复事件管理员：“事件的识别，其实也是包含了对事件解决方案的了解，否则如何正确识别呢？不能仅为升级而升级，其他的都不去了解。”
“我不认同，对解决方案的了解和识别是否正确，我个人认为在事件升级这个概念上说，并不一定重要，惟一重要的，是事件的表述描写以及其类别划分是否一致。”事件管理员说。
事件管理员的申诉
事件管理员详细叙述了他的理由：一种现象可以包含多种故障根源，但我们不能因为由于根源不同而表象相同的故障就不升级。
以前确认过这样一种可能—比如：截止上午10点，服务台接到50起客户报修，而其中有20起相同描述的故障报修。这时，事件就应该及时启动异常事件的报告，而不需要等工程师回来后，事件管理员去了解了问题的解决方案和故障的根源后再‘正确’的升级。哪怕这20起事后得知是客户误报引起，事件也应该提起相应的预警。
分析原因、查找根源，这些不是事件要去考虑的。不然要问题管理何用？事件管理完全可以把问题管理两岗合一。再如你上面所说，也完全可以在我当天升级完事件报告后的第二天，问题管理去查**台的手工报表，查看故障解决方法，也不会有什么积压。
最后，我个人认为，事件管理报告不仅仅是事件管理的报告类型或手法，同样的，它也是问题管理日常工作所必须的管理报告。
争论没有形成定论，因为我觉得事件管理员说得也不无道理。我也需要时间来对事件管理流程做一个分析，以找到这个想法存在的理由。
职责边界
在ITIL理论中，对事件管理和问题管理之间区别介绍得非常清楚。“事件管理的主要目标是在事故发生后尽可能快地恢复客户服务，即使采取的是一些应急措施而不是永久性的解决方案”，主要“强调速度”；“问题管理的主要目标是要查明事故发生的潜在原因并找到此事故的方法或防止其再次发生的措施”，“强调质量，把速度放在第二位。”（摘自《IT服务管理－概念、理解与实施》P122）
既然已经表述得如此清晰，为什么事件管理还会有“让事件管理在参与问题管理的查访”这样的困惑呢？
要说清楚这个困惑，还要从客户服务中心的ITIL结构说起。在客户服务中心实践中，ITIL理论所描述的事件管理职责大部分被实施管理部的服务支持小组替代。由他们来负责事故的快速解决，由服务台、一线工程师、二线工程师等实施管理部的各岗位提供服务支持。
而事件管理已经从具体执行的位置转向服务流程的管理，所要做的是尽可能快地发现事故，在力所能及的范围内监督服务支持小组尽可能快地处理，并将无法处理的事故尽可能快地升级到问题管理。
讲到这里，似乎问题已经清楚。事件管理所担心的事故发现无法做到的“快速、及时”并不是其职责所在。但由于客户服务中心对事件管理的职责范围一直没有形成明确的定位，因此我们在这样一种理论与实践未达到一致的混沌情况下产生了理解上的差异。
我觉得 平常的思维方式是要像事件管理好是要先了解事件原因的 对于这个问题是有点困惑 楼主这样一分析，好像清晰了好多 占坑编辑ing
页:
[1]