通过事件管理流程,IT服务人员要在给用户和公司正常的业务活动带来最小影响的情况下，尽快恢复到SCA中定义的正常服务级别。

    事件，即在某一服务中不属于标准操作(standard operation)的并能导致、或可能导致这个服务的中断或服务质量下降的任何事件。

    从上述定义可以看出，ITIL扩展了“事件”这个概念的内涵，它把服务台接收到的几乎所有呼叫—— 只要这种呼叫是可记录的和可监控的—— 都称之为“事件”。

    根据上述定义，“事件”不仅包括了与软件和硬件有关的错误，还包括服务请求—— 因为对两者的处理方法是类似的。换句话说，事件管理流程涉及服务的整个生命周期。

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

    图1给出了一个水平流程的事件管理的例子。在这个例子中，公司(组织)提供有效的管理并控制事件工作流。

    当同时处理若干事件时，必须设定优先级。优先级是根据错误对用户和正常业务带来的影响的严重程度来确定的。服务台通过与用户进行协商，并根据服务级别协议(SLA)确定事件的优先级。优先级决定了事件得到处理的先后顺序。当事件被提升至二线(第二层)、三线(第三层)或者更高级别的支持小组时，其优先级的维护及调整仍是在与服务台进行协商后确定的。

    当然，每个用户都会认为自己的事件应该有最高的优先级，但是用户的要求通常比较主观。为作出一个客观的评价，可与用户按照以下准则进行协商：

    影响度—— 影响度指就所影响的用户或业务数量而言，事件偏离正常服务级别的程度。重要事件是指那些对用户团体带来非常严重影响的事件。而有些在时间上极度紧迫地需要解决的事件也应当作重要事件来处理。

    紧急度—— 紧急度指解决故障时，对用户或业务来说可接受的耽搁时间。

    优先级—— 主要基于紧急度和影响度来决定。而对于具有同样优先级的事件，可按解决他们需花费的精力的多少来安排顺序。例如，对某个影响不大且容易解决的故障，可先于一个影响较大且需要大量精力解决的故障。

    事件管理具有降低影响度和紧急度的手段和措施，例如交换硬件或指派另一打印队列。事件的影响度和紧急度在此事件的生命周期中也有可能发生改变，例如当事件影响了更多的用户或事件发生在危急时刻。

    如果某一事件不能在规定的时间内由一线支持小组解决，那么更多有经验的人员和有更高权限的人员将不得不参与进来。这就是升级，它可能发生在事件解决过程的任何时间和任何支持级别。

    升级分为职能性升级和结构性升级。两者的区别如下：

    职能性升级意味着需要具有更多时间、专业技能或访问权限(技术授权)的人员来参与事件的解决。这种升级可能会超越部门界限而且可能会包括外部支持者。

    结构性升级意味着当经授权的当前级别的机构不足以保证事件能及时、满意地得到解决时，需要更高级别的机构参与进来。

    事件管理经理对事件管理流程负有全部责任，他的目标是要为满足一个事件的职能性升级的需要做好预备工作，以避免结构性升级的发生。

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

    事件管理效益

    事件管理的目标是要在给用户和公司正常的业务活动带来最小影响的情况下，尽快恢复到SLA中定义的正常服务级别。事件管理需要保留事件的有效记录以便能够权衡并改进处理流程，给其他的服务管理流程提供合适的信息，以及正确报告进展情况。

    对于整个业务来说：

   ● 更及时地解决事件可减少事件对业务的影响；

    ● 提高用户的工作效率；

    ● 独立的、面向用户的事件监控；

    ● 基于SLA的业务管理信息的可用性。

    对IT部门来说：

    ● 改善监控，对SLA的执行情况可进行更为准确的评测；

    ● 有用的关于服务质量的管理报告和服务级别协议(SLA)报告；

    ● 更好地和更有效地使用人力；

    ● 避免事件和服务请求的丢失或被不正确地记录；

    ● 更准确的配置管理数据库(CMDB)。因为当根据配置项对事件进行注册时对配置管理数据库(CMDB)的检查是必不可少的；

    ● 提高用户和顾客的满意度。
 
    而在执行事件管理时的失败可能会导致下面一些负面影响：

    ● 由于无人负责监控和升级事件，事件可能会无谓地加剧并降低服务的等级，事件得不到解决，用户不断地被迫求助于其他部门；

    ● 专业人员经常会受到用户打来电话的干扰，这意味着他们将不能正常地完成工作。结果是，几个人可能会同时参与到对同一事件的处理工作上，既浪费时间，又可能会得出相互冲突的解决方案；

    ● 与用户和服务相关的管理信息的缺乏。

    由于以上问题，由业务部门和IT部门耗费的成本会比正常的高出许多。

    事件管理与其他流程之间的关系

    图3描述了事件管理流程的输入、输出及其活动。

    事件可能由基础设施的任何一个部分引起，且通常是由用户报告的。事件也可能由组织里的其他业务部门或IT部门发现并且通过已建立起的监控系统来自动跟踪应用事件和技术架构事件。

    1. 配置管理

    配置管理数据库(CMDB)在事件管理中有着重要的地位，因为它定义了资源、服务、用户与服务级别之间的关系。例如，配置管理显示基础设施的某一部分由谁来负责，这样当与该部分有关的事件发生时可以迅速地进行追查。

    配置管理数据库(CMDB)还有助于确定合适的应急措施，如转移打印队列，将用户转移到另一台服务器等。在进行事件注册时，配置信息也被关联到了事件记录以提供更好的相关错误信息。在有必要的地方，可以更新基础设施的某一相关部分在配置管理数据库(CMDB)中的状态。

    2. 问题管理

    问题管理流程需要了解事件记录以便查出任何潜在错误。而问题管理通过提供与特定问题有关的信息、已知错误、应急措施以及当前修补方法等来给事件管理流程提供帮助。

    3. 变更管理

    可通过实施变更来解决事件，如更换监视器等。变更管理为事件管理提供关于预定变更及其状态的信息。此外，不正确的执行变更或者包含错误的变更也可能引发事件。此时，事件管理也可以为变更管理提供关于这类事件的信息。

    4. 服务级别管理

    服务级别管理流程对与客户签订的有关将要提供的支持的协议进行监控。事件管理必须熟悉服务级别协议(SLA)以便在与用户进行沟通时可用到这些信息。事件记录可用来生成报告来判断是否真正地提供了规定级别的服务。

    5. 可用性管理

    为了评估服务的可用性，可用性管理流程需要使用由配置管理流程提供的事件记录和状态监控信息。某一服务可被指定为“不可用(Down)”状态，就像配置管理数据库(CMDB)中的一个配置项一样。这种信息可用于判断一种服务真正的可用性以及服务提供者的响应时间。这种能力要求在事件处理的各个过程(从早期的检查到最后的关闭)记录下时间戳(time-stamping)。

    6. 能力管理

    能力管理流程关注由于能力不足导致的事件，如由缺少磁盘空间或响应时间过长导致的事件。业务经理、系统经理或系统本身可将这些事件告知事件管理流程。

    作为基础的事件记录

    事件的接收和记录，在大多数情况下事件会由服务台进行记录。所有的事件都应被迅速记录下来，原因如下。

    ● 记录以前堆积下来的工作通常并不能做到面面俱到；

    ● 只有记录事件才能监控事件的发展情况；

    ● 已有的事件记录有助于对新发生的事件进行诊断；

    ● 问题管理可通过对事件的记录来发现问题的原因；

    ● 如果所有的来电呼叫都被记录下来，那么对某一事件的影响度的判断会容易一些；

    ● 如果没有事件记录，那么将不能监控协商好的服务级别是否得到满足；

    ● 及时地对事件进行记录可以避免在解决问题时出现几个人同时解决同样的问题，或在对某一事件的处理过程中什么工作都没有做等情形。

    在什么地方发现事件，决定了谁将报告这个事件。对事件的发现可有以下几种方式。

    ● 由某一用户发现：用户将此事件报告给服务台；

    ● 由系统发现：当捕捉到一个应用基础设施或技术基础设施方面的事件，如突破某个关键的临界值时，就将其在事件记录系统中登记为一个事件，并在必要的时候将其转交由某个支持小组处理；

    ● 由服务台人员发现：该服务台人员确保将事件记录下来；

    ● 由其他IT部门的人发现：该人在事件记录系统中记录下事件或将其报告给服务台。

    要避免对同一事件进行重复记录的情况出现。因此，在记录某一事件时需要进行一项检查来确定是否已有相似的记录。

    ● 如果有(而且是关于同一事件的记录)：则应该更新事件信息或将事件单独记录后将其关联到主事件记录；如果有必要，可对其影响度和优先级进行一些修正，同时加上一些与事件的发现者相关的信息；

    ● 如果没有：则增加一条新的事件记录。

    尽管第一种情况比第二种情况简单很多，但在两种情况下记录事件的方法是相同的。

    ● 分配一个事件索引序号：大多数情况下系统会自动分配一个惟一的事件索引序号。通常，在后续沟通过程中用户可使用通过提供的查询序号来引用事件。

    ● 记录基本的诊断信息：时间、症状、用户、处理问题的人、地点以及受影响的服务或硬件等信息。

    ● 附加事件信息：包括与事件相关的其他信息(例如一个脚本或交流过程记录)或配置管理数据库中的一些信息(通常以数据库中定义的关系为基础)。

    ● 警告：如果存在一个具有高影响度的事件，例如某台关键服务器的瘫痪，则应警告其他用户和管理部门。

    另外，要进行事件的归类。事件归类的目的是确定事件的种类以便监控和报告。分类的选择越广泛越好。但是，这也需要更高级别的人事委托(commitment)。有些时候会有人试图将几个类别的内容合并到一个单一的表中，这样通常会造成混乱。因此，使用一些简短的列表会更好一些。

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