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

基本术语

1. 事件

ITIL服务支持参考书中对“事件”的定义如下：
从上述定义可以看出，ITIL扩展了“事件”(Incident)这个概念的内涵，它把服务台接收到的几乎所有呼叫——只要这种呼叫是可记录的和可监控的——都称之为“事件”。
根据上述定义，“事件”不仅包括了与软件和硬件有关的错误，还包括服务请求——因为对两者的处理方法是类似的。换句话说，事件管理流程涉及服务的整个生命周期。
服务请求(Service Requests)也可作为“标准服务(standard services)”：它是根据服务级别协议(SLA，Service Level Agreement)提供的；其提供是根据既定程序进行，而这些程序是经过协商的且具有适当的检查和控制功能；它也应该保存在维护记录的地方，如配置管理数据库(CMDB，Configuration Management DataBase)。

服务请求的例子包括：
● 功能方面的问题或请求
● 状态查询
● 口令重置
● 对批处理活动、恢复以及口令认证的请求
● 数据库的提取
● 要求提供具有一定IT技能或服务的新雇员的请求

一个服务请求可能是要求进行一个标准变更，但是只要它属于“标准服务”的范畴，那么就应当由事件管理而不是变更请求流程进行处理。如果被请求的服务不是事先已经定义好的“标准服务”，并且它将改变IT基础设施的状态，那么我们将据此提交一个变更请求(Request For Change，RFC)。变更请求(RFC)并不由事件管理流程处理，而是由变更管理流程负责对其进行正式的处理。

2. 影响度、紧急度和优先级

当同时处理若干事件时，必须设定优先级。优先级是根据错误对用户和正常业务带来的影响的严重程度来确定的。服务台通过与用户进行协商，并根据服务级别协议(SLA)确定事件的优先级。优先级决定了事件得到处理的先后顺序。当事件被提升至二线(第二层)、三线(第三层)或者更高级别的支持小组时，其优先级的维护及调整仍是在与服务台进行协商后确定的。
当然，每个用户都会认为自己的事件应该有最高的优先级，但是用户的要求通常比较主观。为作出一个客观的评价，可与用户按照以下准则进行协商：
影响度(Impact)—— 影响度指就所影响的用户或业务数量而言，事件偏离正常服务级别的程度。重要事件是指那些对用户团体带来非常严重影响的事件。而有些在时间上极度紧迫的需要解决的事件也应当作重要事件来处理。
紧急度(urgency)—— 紧急度指解决故障时，对用户或业务来说可接受的耽搁时间。
优先级(priority)—— 主要基于紧急度和影响度来决定。而对于具有同样优先级的事件，可按解决他们需花费的精力的多少来安排顺序。例如，对某个影响不大且容易解决的故障，可先于一个影响较大且需要大量精力解决的故障。

3. 升级

如果某一事件不能在规定的时间内由一线支持小组解决，那么更多有经验的人员和有更高权限的人员将不得不参与进来。这就是升级，它可能发生在事件解决过程的任何时间和任何支持级别。
升级分为职能性升级和结构性升级。两者的区别如下：
职能性升级(Functional escalation，又称为水平升级、技术升级)：职能性升级意味着需要具有更多时间、专业技能或访问权限(技术授权)的人员来参与事件的解决。这种升级可能会超越部门界限而且可能会包括外部支持者。
结构性升级(Hierarchical escalation，又称为垂直升级、管理升级)：结构性升级意味着当经授权的当前级别的机构不足以保证事件能及时、满意地得到解决时，需要更高级别的机构参与进来。
事件管理经理对事件管理流程负有全部责任，他的目标是要为满足一个事件的职能性升级的需要做好预备工作，以避免结构性升级的发生。

4. 1线、2线和N线支持

上面我们介绍了事件的流程线路或者说职能性升级。事件的处理流程线路是由所需的专业等级、紧急度和权限等因素决定。1线支持(也称为第1层次支持)通常由服务台来提供；而2线支持则通常由管理部门提供；3线支持则多由软件开发人员和系统结构人员提供；4线支持由供应商提供。公司(组织)越小，则可供升级的级别数就越少。在较大的公司(组织)里，事件管理经理可在相关部门指定故障协调人来支持自己的工作。例如，协调人在整个事件管理过程与处于各线的支持机构之间可充当接口的角色。每一个协调人协调他本身所在的支持团队。

目标

事件管理的目标是要在给用户和公司正常的业务活动带来最小影响的情况下，尽快恢复到SLA中定义的正常服务级别。事件管理需要保留事件的有效记录以便能够权衡并改进处理流程，给其他的服务管理流程提供合适的信息，以及正确报告进展情况。
能带来的好处
对于整个业务来说：
● 更及时地解决事件可减少事件对业务的影响；
● 提高用户的工作效率；
● 独立的、面向用户的事件监控；
● 基于SLA的业务管理信息的可用性。
对IT部门来说：
● 改善监控，对SLA的执行情况可进行更为准确的评测；
● 有用的关于服务质量的管理报告和服务级别协议(SLA)报告；
● 更好地和更有效地使用人力；
● 避免事件和服务请求的丢失或被不正确地记录；
● 更准确的配置管理数据库(CMDB)。因为当根据配置项对事件进行注册时对配置管理数据库(CMDB)的检查是必不可少的；
● 提高用户和顾客的满意度。
而在执行事件管理时的失败可能会导致下面一些负面影响：
● 由于无人负责监控和升级事件，事件可能会无谓地加剧并降低服务的等级，事件得不到解决，用户不断地被迫求助于其他部门；
● 专业人员经常会受到用户打来电话的干扰，这意味着他们将不能正常地完成工作。结果是，几个人可能会同时参与到对同一事件的处理工作上，既浪费时间，又可能会得出相互冲突的解决方案；
● 与用户和服务相关的管理信息的缺乏。
由于以上问题，由业务部门和IT部门耗费的成本会比正常的高出许多。

流程

事件管理活动
事件可能由基础设施的任何一个部分引起，且通常是由用户报告的。事件也可能由组织里的其他业务部门或IT部门发现并且通过已建立起的监控系统来自动跟踪应用事件和技术架构事件。
与其他流程之间的关系
1. 配置管理
配置管理数据库(CMDB)在事件管理中有着重要的地位，因为它定义了资源、服务、用户与服务级别之间的关系。例如，配置管理显示基础设施的某一部分由谁来负责，这样当与该部分有关的事件发生时可以迅速地进行追查。
配置管理数据库(CMDB)还有助于确定合适的应急措施，如转移打印队列，将用户转移到另一台服务器等。在进行事件注册时，配置信息也被关联到了事件记录以提供更好的相关错误信息。在有必要的地方，可以更新基础设施的某一相关部分在配置管理数据库(CMDB)中的状态。
2. 问题管理
问题管理流程需要了解事件记录以便查出任何潜在错误。而问题管理通过提供与特定问题有关的信息、已知错误、应急措施以及当前修补方法等来给事件管理流程提供帮助。
3. 变更管理
可通过实施变更来解决事件，如更换监视器等。变更管理为事件管理提供关于预定变更及其状态的信息。此外，不正确的执行变更或者包含错误的变更也可能引发事件。此时，事件管理也可以为变更管理提供关于这类事件的信息。
4. 服务级别管理
服务级别管理流程对与客户签订的有关将要提供的支持的协议进行监控。事件管理必须熟悉服务级别协议(SLA)以便在与用户进行沟通时可用到这些信息。事件记录可用来生成报告来判断是否真正地提供了规定级别的服务。
5. 可用性管理
为了评估服务的可用性，可用性管理流程需要使用由配置管理流程提供的事件记录和状态监控信息。某一服务可被指定为“不可用(Down)”状态，就像配置管理数据库(CMDB)中的一个配置项一样。这种信息可用于判断一种服务真正的可用性以及服务提供者的响应时间。这种能力要求在事件处理的各个过程(从早期的检查到最后的关闭)记录下时间戳(time-stamping)。
6. 能力管理
能力管理流程关注由于能力(capacity)不足导致的事件，如由缺少磁盘空间或响应时间过长导致的事件。业务经理、系统经理或系统本身可将这些事件告知事件管理流程。

活动

图4-5描述了事件管理流程中的各个步骤。
● 事件的接收和记录：发现并报告事件，同时生成一个事件记录；
● 分类和初步支持：根据事件的类型、状态、影响度、紧急度、优先级、SLA等来对其进行编码。可由此向用户提供建议来解决或处理问题，哪怕这些建议仅仅是临时性的；
● 如果呼叫是关于服务请求的，则启动与处理服务请求有关的程序；
● 匹配：检查一下事件是否是已知的，或是可能与某一现存事件、问题或已知错误有关的，看看是否有解决方案(solution)或应急措施(workaround)；
● 调查和诊断：如果不存在已知的解决方案则需要对事件进行调查；
● 解决与恢复：一旦找到了解决方案，问题便能得到解决；
● 终止：询问用户对问题的解决过程和结果是否满意，如果满意的话，将事件终止；
● 进展监控与跟踪：监控整个事件生命周期，如果估计事件不能及时得到解决或以当前的专业级别无法解决，则进行事件升级。

接收和记录

在大多数情况下事件会由服务台进行记录。所有的事件都应被迅速记录下来，原因如下。
● 记录以前堆积下来的工作通常并不能做到面面俱到；
● 只有记录事件才能监控事件的发展情况；
● 已有的事件记录有助于对新发生的事件进行诊断；
● 问题管理可通过对事件的记录来发现问题的原因；
● 如果所有的来电呼叫都被记录下来，那么对某一事件的影响度的判断会容易一些；
● 如果没有事件记录，那么将不能监控协商好的服务级别是否得到满足；
● 及时地对事件进行记录可以避免在解决问题时出现几个人同时解决同样的问题，或在对某一事件的处理过程中什么工作都没有做等情形。

在什么地方发现事件，决定了谁将报告这个事件。对事件的发现可有以下几种方式。
● 由某一用户发现：用户将此事件报告给服务台；
● 由系统发现：当捕捉到一个应用基础设施或技术基础设施方面的事件，如突破某个关键的临界值时，就将其在事件记录系统中登记为一个事件，并在必要的时候将其转交由某个支持小组处理；
● 由服务台人员发现：该服务台人员确保将事件记录下来；
● 由其他IT部门的人发现：该人在事件记录系统中记录下事件或将其报告给服务台。
要避免对同一事件进行重复记录的情况出现。因此，在记录某一事件时需要进行一项检查来确定是否已有相似的记录。
● 如果有(而且是关于同一事件的记录)：则应该更新事件信息或将事件单独记录后将其关联到主事件记录；如果有必要，可对其影响度和优先级进行一些修正，同时加上一些与事件的发现者相关的信息；
● 如果没有：则增加一条新的事件记录。
尽管第一种情况比第二种情况简单很多，但在两种情况下记录事件的方法是相同的。
● 分配一个事件索引序号：大多数情况下系统会自动分配一个惟一的事件索引序号。通常，在后续沟通过程中用户可使用通过提供的查询序号来引用事件。
● 记录基本的诊断信息：时间、症状、用户、处理问题的人、地点以及受影响的服务或硬件等信息。
● 附加事件信息：包括与事件相关的其他信息(例如一个脚本或交流过程记录)或配置管理数据库中的一些信息(通常以数据库中定义的关系为基础)。
● 警告：如果存在一个具有高影响度的事件，例如某台关键服务器的瘫痪，则应警告其他用户和管理部门。

归类

事件归类的目的是确定事件的种类以便监控和报告。分类的选择越广泛越好。但是，这也需要更高级别的人事委托(commitment)。有些时候会有人试图将几个类别的内容合并到一个单一的表中，这样通常会造成混乱。因此，使用一些简短的列表会更好一些。
在这一节我们将讨论与归类有关的问题。
1. 类别
归类活动的第一步是将事件归入某一类别或某一子类，如按事件发生的可能原因分类或按与事件相关的支持小组进行分类。可参考如下方法进行分类。
● 中央处理器相关：包括接入、系统、应用等的故障；
● 网络相关：包括路由器、集线器、IP地址等的故障；
● 工作站相关：包括显示器、网卡、磁盘驱动器、键盘等的故障；
● 功能和使用相关：服务、能力、可用性、备份、手册等相关故障；
● 组织和程序相关：命令、请求、支持、沟通等；
● 服务请求相关：用户对服务台提出的请求，要求提供支持、交付、信息、建议或文档等。这类事件可以通过一套单独的程序处理，也可以按照与其他事件相同的方式处理。
2. 优先级
在确定事件的类别后，需要确定事件的优先级以确保支持小组对问题予以足够的关注。优先级通常用一个数字来表示。而这个数字通常是根据紧急度(恢复事件的迅速程度)和影响度(如果不及时修复事件，会造成多大的损失)来决定的。
优先级=紧急度×影响度
3. 服务
按照SLA的有关要求，需要用一个列表来标识与事件相关的服务。这个列表同时也提供了按照SLA对相关服务的升级时间。

4. 支持小组
如果服务台不能在事先规定的时间内解决事件，就要决定应该由哪个支持小组来负责处理该事件。这种转移(也被称为职能性升级)通常是按已分配好的事件所属的类别来进行的。如果对各个类别进行了定义，就不得不考虑支持小组的结构问题。
合理的事件处理转移机制对有效的事件管理非常重要。因此，关于事件管理流程质量的关键绩效指标应该是“被恰当转移的事件的数量”。
5. 时间表
以优先级和服务级别协议(SLA)为基础，受影响的用户将会被通知预计解决问题的最长时间(生命周期)，以及什么时候可进行进一步的升级。系统应该记录下这些时间。
6. 事件索引号
告知用户的事件索引号以便其以后根据此索引号来查询事件。
7. 工作流状态
事件状态表明了其在事件工作流中的位置。事件状态的例子有：
● 新建
● 已接收
● 已计划
● 已分配
● 激活状态
● 已暂停
● 已解决
● 已终止


匹配
对事件进行分类之后，要检查以前是否发生过类似的事件。如果发生过，则查看是否存在解决方案和应急措施。如果新事件与某一问题或某一已知错误具有相同症状，那么就可将事件与这些已知的问题或错误进行关联。

调查与诊断
服务台将那些没有快速解决方案或超过他们专业水平的事件安排给具有更高专业水平和技术能力的支持小组。此支持小组将对事件进行调查并尽量加以解决。如不能解决，则将其转交给其他的支持小组。

解决与恢复
成功完成对事件的分析和解决之后，负责解决问题的支持小组在系统中记录下事件的解决方案。对某些解决方案来说，须向变更管理提交一个变更请求(Request For Change, RFC)。在最不理想的情况下，如果没有找到合适的解决办法，那么事件将一直处于待解决(Open)状态。

终止
一旦实施完毕解决方案，支持小组把事件回交给服务台。然后服务台联系事件的报告人以确认事件是否解决好。如果服务台可以确认事件已经得到了很好的解决，那么它就终止该事件；否则事件管理流程需要在适当的地方重新开始处理。
在终止事件的过程中，必须要对事件的记录进行更新以反映事件的最终分类和优先级，受影响的服务、用户和客户，以及导致事件发生的组件(CI)等。

进度跟踪与监控
作为所有事件的拥有者，服务台负责对事件的发展情况进行监控以及通知用户事件的状态。用户在某一状态发生改变后可能会做出适当的反馈，如在预期的事件周期内发生的进一步的事件转交或变更等。在对事件进展进行跟踪和监控时，可能会出现将事件进行职能性升级，转交给其他支持小组来处理，或进行结构性升级，以加强处理事件的力度的情况。

流程控制

流程控制以对不同目标群体的报告为基础。事件经理负责这些报告，同时负责拟定报告接收者清单和报告分发日程表。报告可以非常详细或者按照以下角色定制：
事件经理——报告需要包括：
● 找出处理过程中遗漏的环节；
● 找出与服务级别协议(SLA)有冲突的地方；
● 对事件处理保持跟踪；
● 确定事件的发展趋势。
一线IT管理人员——给支持小组管理人员提供报告以方便他们对各自小组的控制。这类报告需要以下信息：
● 事件解决的进展情况；
● 事件在各个支持小组的周转时间。
服务级别管理人员——提供给这些人员的报告主要包括所提供的服务质量方面的信息。服务级别管理经理需要所有为提供服务级别报告给客户时所需要的信息。提供给客户的报告应该提供在事件管理流程中服务级别协议得到遵守情况的相关信息。
其他服务管理流程的流程经理——对其他流程的经理的报告将主要是提供信息。例如，事件管理应该提供如下事件记录方面的信息：
● 已记录和已报告的事件的数量；
● 已解决的事件的数量，并按照解决时间进行细分；
● 将事件按照不同时期、来自不同客户、由不同支持小组处理以及根据服务级别协议(SLA)对其的处理结果等方式进行分类的情况；
● 按类别和优先级以及支持小组对事件的分类情况。

关键成功因素

成功地进行事件管理需要：
● 一个及时更新的配置管理数据库(CMDB)来帮助评估事件的影响度和紧急度。虽然评估影响度和紧急度所需的信息同样也可从用户那里得到，但是这种方式得到的信息会少一些，而且可能会非常主观，此外收集信息的时间也可能很长；
● 一个知识库(例如一个及时更新的问题数据库或已知错误数据库)来帮助识别事件，以及可用来解决这些事件的既有解决方案和应急措施。知识库中还可以是供应商和其他第三方的数据库；
● 一个适当的自动系统用于记录、跟踪和监控事件；
● 与服务级别管理流程之间的紧密联系以确保合适的优先级和解决时间。

绩效指标

评估流程的绩效需要明确定义目标以及为实现这些目标所设定的可测量的指标。这些指标通常被称为绩效指标。绩效指标由事件经理定期(如每周)报告，以获得一些可据此判断事件发展趋势的历史数据。
事件管理流程的关键绩效指标举例如下：
● 事件的总数；
● 平均解决时间；
● 按优先级计算的平均解决时间；
● 在SLA的目标之内解决的事件所占的百分比；
● 由一线支持解决(不将事件转交)的事件所占的百分比；
● 每个事件的平均支持成本；
● 每个服务台工作站或每个服务台员工平均解决的事件数；
● 不需拜访用户就解决的事件数；
● 初步分类正确的事件数量(或所占的比例)；
● 正确转交的事件数量(或所占的比例)。

职责和角色
流程的执行涉及公司的多项职能或多个部门，故只有当与流程的各项活动相关的责任和权限被清晰地描述，它才可能成功运作。从灵活性的角度考虑，利用基于角色的方法可能会比较合适。当公司规模较小或为降低成本时，可将多个角色合并。例如，许多公司将变更管理和配置管理的角色合并。

1. 事件经理
事件经理负责以下事项：
● 监控事件处理流程的效率和效果；
● 控制支持小组的工作；
● 为改进工作提供建议；
● 开发并维护事件管理系统；
在许多公司里，事件经理的角色被指派给了服务台经理。
2. 支持小组人员
一线支持小组负责记录、分类、匹配、转交、解决(除指派给其他支持小组之外的)和终止事件。
其他的支持小组主要参与调查、诊断和恢复工作。这取决于对事件设定的优先级。

成本和可能产生的问题

成本

与事件管理相关的成本包括初始执行成本(如对流程和过程的定义以及相互间的沟通)、培训和指导人员(客户和支持人员)成本，以及选择和购买支持流程的工具的成本等。对工具的选择可能相当耗费时间。另外，还有与人事和工具使用相关的成本。这些成本在很大程度上取决于事件管理的结构、活动范围和责任，以及与该流程有关的场所的数量等。

可能产生的问题

对事件管理的导入和执行可能会受到以下问题的影响：
● 用户和IT人员故意避开事件管理程序—— 如果用户不经过一系列的处理过程而是自己解决错误或者直接联系一些专业人员帮助他来解决，那么与此事件相关的一些信息可能就不会完整，而这些信息对问题管理、配置管理的成功实施非常重要。此外，IT部门也不会得到服务级别以及错误数量等信息，这会导致管理报告不能充分地反映当前情况。
● 事件处理超载和堆积—— 如果事件的数量过多，就可能出现一种还没有来得及对每个事件进行有效的记录，下一个事件又来了的情况。这将导致不能清楚地描述事件，同时也可能导致不能成功地对事件进行分配和转交。因而对解决事件就会变得事倍功半。因此，适当具有某些技能和能力以及资源是必要的。此外，单单强调从头到尾的“通路”也能导致下游工作流的问题。
● 升级—— 如果事件不能得到及时解决或者需要更高层次的专业资源才能解决，就会进行事件升级。过多的升级可能会打乱专业技术人员的正常工作而产生负面影响。
● 定义和协议不清晰—— 如果支持的服务和产品以及支持的级别在服务目录里没有清楚的定义或者没有符合服务级别协议(SLA，Service Level Agreements)、运作级别协议(OLA，Operational Level Agreements)以及支持合同(UC，Underpinning Contracts)，那么事件管理将很难达到客户和用户所期望的要求。
● 缺少管理层的承诺(commitment)—— 用基于流程的方法解决事件需要管理层和工作人员的一致共识。因为，如果在一个公司内部导入这种方法需要对现在的工作方法做重大改变，那么可能会在公司内部受到严重的抵制。