事件管理包含6个主要活动：事件侦测和记礼事件的分类和支持，事件的调查和诊断，事件的解决和恢复，事件的结束，事件的监控。除此之外，事件管理流程还和许多外部流程相关联。通常，与事件管理流程相关联的外部流程有：配置管理、问题管理、变更管理和知识管理等。这些外部流程不一定全部是ISO20000中定义的流程，他们还可以是各个企业的业务流程，由企业根据自身实际需要来制定。

    1.事件侦测和记录

    事件报告的来源有很多。事件侦测记录工作就是要及时的获取事件报告并把这些事件报告完整、准确地记录下来，为事件处理人员提供必要的信息，同时也为事后的统计分析和建立知识库提供帮助。事件报告的来源主要包括：系统监控、电话呼叫、在线报告、技术人员。各事件来源的报告统一汇总到服务台，由服务台进行首先受理，登记事件。

    完整的事件记录应该至少包含以下几项内容：

    · 事件的编号

    · 事件的优先级

    · 事件的现象描述、发生时间、事件分类、事件的处理状态

    · 事件的报告人员姓名、部门、联系电话、邮件地址

    · 事件受理人姓名、部门、工作组、联系电话、邮件地址

    · 事件处理过程日志

    · 事件解决的时间和关闭时间

    有时候，组织常常希望在事件发生的第一时间就能掌握相关的情况，期望能够在事件刚刚发生的时候就能立刻介入。要达到这个目标除了建立一个全面完善的系统监控外，明确的系统监控报警也是一个必要的条件。一个好的监控报警应该至少包含以下几个要素：

    · 报警编号

    · 报警级别

    · 报警时间

    · 报警设备的编号、IP地址

    · 报警系统的系统软件、应用软件的编号名称

    · 报警系统所支持的业务功能代码、名称

    · 报警系统抛出的异常信息及错误代码

    · 响亮醒目的声光警示

    报警信息要输入给服务台，由服务台进行自动记载并形成事件记录。

    2.事件的分类和支持

    事件被记录下来后，还需要进行分类，才能被正确的分派给合适的部门或者是技术支持组，进行下一步的处理。事件的分类是由服务台负责进行的。服务台人员根据事件的现象并参考知识库进行初步的分类。

    事件分类方法有以下几种：

    · 按照业务系统的种类分

    · 按照优先级高低分

    · 按照事件报告来源分

    企业可以根据实际情况选择一种或者是几种分类方法。确定了分类方法后，企业还应该针对各个分类，确定相应的处置措施，形成一线支持手册，并交给服务台参考。

    在具体的事件处置过程中，首先，服务台人员为事件初步选定一个分类项，然后，服务台人员根据优先级定义规则为事件初步选定一个优先级别，接下来，服务台人员根据一线支持手册尝试进行解决。如果无法解决，服务台人员应根据分派规则把事件分派给第二线的技术支持人员进行分析处理。

    通常，以下几种情况可以由服务台人员进行首次解决：

    · 知识库中已经记载的事件类型

    · 事件处理进度查询

    · 业务咨询

    · 标准服务请求

    · 其他服务台人员可以自行解决的事件

    第二线的技术支持人员通常是相关的专业技术人员。专业技术人员可能会分成多个技术支持组，每一个技术支持组有不同的专攻方向。服务台人员会把事件分派给其中一个最相关的技术支持组，技术支持组的人员进行分析和处理，如果技术人员分析后发现事件应该由另一个技术支持组来进行处理，可以向服务台提出转派请求，服务台根据请求把事件重新分派给另一个技术支持组。当二线技术人员经过分析后，仍然无法解决，么应协调第三线技术支持协助解决。第三线支持人员由供应商技术专家和其他第三方人员组成。协调第三线技术支持的工作通常是第二线技术支持人员来做，也可以由服务台来做。这可以根据实际情况选择。

    3.事件的调查和诊断

    二线及三线技术支持人员受理事件后，首先要对事件进行调查和诊断。在事件的调査和诊断过程中，技术人员所要做的事情就是尽快找到事件发生的原因，提出解决措施。

    在实际工作中，事件发生的原因千奇百怪，有的很容易能够定位，但多数情况下，技术支持人员很难立刻查明原因，基至会束手无策。这使得这一阶段成为整个事件管理流程中最耗时的阶段。这也造成了很多事件的恢复时间超出了服务级别协议的规定，带来了损失。因此，在这一阶段有必要采取一些必要的措施，提高效率。一个常见的手段就是事件编制系统诊断排错树，另一个有效的方法就是提供备用系统。

    使用系统诊断排错树可以在紧急情况下，帮助技术人员理清思路，迅速抓住主要环节，排除无关因素，而使用备用系统，可以为事件的调查诊断赢得时间。

    4.事件的解决和恢复

    事件的原因初步确定后，技术支持人员的下一步工作就是着手解决事件。在正式开始之前，技术支持组必须拿出一个完整的解决方案，解决方案除考虑恢复措施外，还应考虑对客户的影响，提出其他部门的相关配合事项。整个方案必须迅速知会所有涉及人员，由各涉及人员协同执行。同时，解决方案应该被完整的记录下来，为事后分析、形成知识库提供参考。

    5.事件的结束

    事件解决后，技术支持人员要立刻通知服务台，服务台通知事件的报告人确认并关闭事件。

    这里要注意以下几点：

    · 必须由事件报告人来关闭事件，技术支持人员不允许关闭事件

    · 关闭事件同时进行满意度回访

    · 记录事件结束时间和恢复时长

    满意度回访工作由服务台来执行，重点关注客户对于事件响应效率、解决效率的满意程度，同时，技术支持人员的服务态度也是回访的重点内容。回访结果应被认真记录并记入效绩考核。

    6.事件处理过程的跟踪和监督

    事件的优先级在整个事件处理过程中不是一成不变的，它是随着事件影响度和影响时间的变化而变化的。关于这二点后续有进一步的说明。当优先级发生变化的时候，必须有二个管理环节能够掌握这一变化，并能够把这个变化的信息及时传递到管理层，确保事件优先级发生变化时，组织能够立即协调相应的资源来满足事件处理的需要。这一管理环节就是事件处理过程的跟踪监督。

    事件处理的跟踪和监督二般由事件经理和服务台负责。事件经理和服务台支持人员在事件处理的全过程中需要不断关注事件处理的最新进展情况、监控事件的处理时长，不断收集关于当前事件的客户报告的广度、密度，并根据这些信息动态的评估事件的影响度和紧急度，进而动态的评估出当前事件的优先级。

    如果事件的影响面扩大了，或者是事件的处理时间超出服务级别协议的规定了，又或者是事件支持人员没有响应，么，事件经理和服务台支持人员就应该动态的提升事件的优先级，同时，启用与相关优先级对应的处置措施。同样的，如果事件的影响度和紧急程度降低了，例如启用了备用系统，么，事件经理和服务台支持人员就应该动态的降低事件的优先级，并发布降级通知。

    事件优先级的升级通常有两种方式：第一是功能性升级；第二是结构性升级。组织可以根据自己的实际情况规定相应的升级规则。