事件报告人的紧密联系，适时向事件报告 人通知事件处理进展情况；
[0032] 在与事件报告人或用户确认事件已经解决后，关闭事件。
[0033] (2)二线技术/业务支持人员
[0034] 二线技术/业务支持人员负责对服务控制台工作人员无法解决的事件进行快速有 效的分析，并提出解决方案W确保能够尽快地恢复服务。
[0035] 验证从服务控制台工作人员那里升级过来的事件的描述信息，并进一步收集相关 数据或信息来界定事件发生的根源；
[0036] 根据事件的根源分析来决定需要采取何种措施恢复服务；
[0037] 根据事件的优先级来决定具体措施或解决方案的执行时间；
[0038] 实施事件解决方案，在必要的时候提供现场支持；
[0039] 更新事件解决信息，并将已解决的事件转回给服务控制台，由服务控制台工作人 员通知事件报告人或用户，并关闭事件；
[0040] 如果二线技术/业务支持人员不能解决运个事件，应当选择把事件转给=线技术/ 业务支持人员去处理。
[0041] (3)=线技术/业务支持人员
[0042] =线技术/业务支持人员是相关问题领域的专家，负责提供对二线技术/业务支持 人员无法解决的问题进行更深入的调研，找出解决方案并尽快恢复服务。当然不是所有的 =线技术/业务支持人员对所有的问题都很精通，所W可W考虑按照所维护的应用、系统进 行分组，如网络组、服务器组、存储组等。
[0043] 进行事件的深入调查研究；
[0044] 根据W往的经验和专业技能来决定需要采取何种措施恢复服务；
[0045] 及时提供和实施有效的解决方案；
[0046] 必要时寻求服务供应商的维保支持；
[0047] 更新事件解决信息，并将已解决的事件转回给服务控制台，由服务控制台工作人 员通知事件报告人或用户，并关闭事件；
[0048] 如果=线技术/业务支持人员不能在解决时限内解决运个问题，应当将事件及时 升级到管理层。
[0049] (4)事件经理
[0050] 事件经理是管理层对事件管理的直接授权人。作为事件管理流程的负责人，具体 职责如下：
[0051] 负责制定流程的策略、规范和具体实施办法；
[0052] 调度有效资源，并协调解决跨部口的事件；
[0053] 指导并监管日常业务操作服务，W确保流程的执行符合预定的要求和规范；
[0054] 建立对流程执行的度量指标；
[0055] 根据已定义的度量指标来采集数据，并进行报表分析；
[0056] 定期与用户、服务提供商和管理层沟通流程的使用情况；
[0057] 对流程的变更和服务流程改进计划负有完全责任。
[0058] 如图1所示，事件管理流程应起始于事件的接受和报告，结束于事件的解决和关 闭。该中小企业事件管理流程包括W下步骤：
[0059] (1)记录和接受事件
[0060] 是事件流程的起点，所有用户或系统报告的IT事件必须由此开始，目的是快速准 确地发现事件，W协助事件的诊断和解决并通知相关人员，在此步骤中将会收集创建事件 记录所需的信息，该环节的关键是信息的准确性和完整性。记录事件信息的方法包括但不 限于利用计算机或录音电话、网络即时聊天截屏等等。
[0061] 在突发事件管理流程中录入的事件信息项如下表1所示：
[0062] 表1事件信息表项
[0064]
[0065] (2)分类和在线支持
[0066] 事件可W是一个服务请求、信息请求或故障，对于每个事件，需要确立优先级和分 类。若没有发现现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进 行调查。而该环节的关键是需要事件知识库的支持和正确的事件派分。
[0067] 事件管理流程中，优先级是事件管理的一个关键要素，优先级决定处理事件的顺 序及所需的资源。事件优先级可分为四类，如下表2所示：
[0068] 表2事件优先级定义
[0069]
[owo」 服务巧制台的丄作人巧巧預剖米目监巧菅埋干台的肯警爭件或巧端用尸报肯的 事件时，迅速根据事件相关IT系统/设备、网络的关键级别及事件的性质，定义该事件的优 先级别。如果为紧急和棘手的事件，应立即升级到相关的技术或业务部口。事件升级的目的 是确保事件在解决时限内及时通知有关技术人员和领导，引起更多的重视，提供合适的资 源，从而快速找到解决事件的方案。可根据所要求的处理时间定义事件优先级升级规则，包 括不同等级的事件升级到不同级别的人员。当技术或业务部口接受到服务控制台升级上来 的事件后，会根据具体的事件级别在规定的时限内解决。
[0071] 与事件优先级对应的事件解决时限参考表如下表3所示：
[0072] 表3事件解决时限参考表 「00731
[0074] (3)匹配
[0075] 检查一下事件是否是已知的，或是可能与某一现存事件、问题或已知错误有关的， 看看是否有解决方案或应急措施。
[0076] (4)调查和诊断
[0077] 若支持人员无法解决事件，可运用自身技能、知识库、诊断工具等进行更加深入地 分析，W找到恢复服务的临时措施，必要时将寻求很多支持人员的参与，W寻求有效的解决 措施。
[0078] (5)解决和恢复
[0079] 支持人员实施事件的解决方案，并将解决完毕的事件转回服务控制台；由服务控 制台通知用户解决的结果，并得到用户的最终确认信息。
[0080] (6)紧急事件和事件升级
[0081] 对于紧急事件，服务控制台应立即提交给二线或=线的技术/业务支持人员，由二 线或=线人员就目前的事件情况进行合理的判断，在必要的时候上报给事件经理。由事件 经理决定紧急处理的方式，W确保紧急事件能够得到最快速的解决。另外，服务控制台包括 事件状态监控工具，服务控制台还可包括指示灯，对于紧急事件，服务控制台的指示灯会持 续发出闪烁红光W引起关注。
[0082] 当事件处理超过预期时限，将自动升级或由运维人员升级，W引起相关人员和高 层管理人员的重视并参与事件的处理。另外，服务控制台还可包括小型警报器，当事件处理 超过预期时限时，服务控制台的小型警报器会持续发出喃声W引起关注。
[0083] 事件升级具体是指，如果某一事件不能在规定的时间内由一线支持小组解决，那 么更多有经验的人员和有更高权限的人员将不得不参与进来。运就是升级，它可能发生在 事件解决过程的任何时间和任何支持级别。升级分为职能性升级和结构性升级。两者的区 别如下：
[0084] 职能性升级(又称为水平升级、技术升级）：职能性升级意味着需要具有更多时间、 专业技能或访问权限(技术授权)的人员来参与事件的解决。运种升级可能会超越部口界限 而且可能会包括外部支持者。
[0085] 结构性升级（又称为垂直升级、管理升级）：结构性升级意味着当经授权的当前级 别的机构不足W保证事件能及时、满意地得到解决时，需要更高级别的机构参与进来。
[0086] 事件管理经理对事件管理流程负有全部责任，他的目标是要为满足一个事件的职 能性升级的需要做好预备工作，W避免结构性升级的发生。
[0087] 事件的处理流程线路是由所需的专业等级、紧急度和权限等因素决定的。参考图2 的事件升级过程，1线支持通常由服务台来提供、而2线支持则通常由管理部口提供;3线支 持则多由软件开发人员和系统结构人员提供;4线支持由供应商提供。公司（组织)越小，贝U 可供升级的级别数就越少。在较大的公司（组织)里，事件管理经理可在相关部口指定故障 协调人来支持自己的工作。例如，协调人在整个事件管理过程与处于各线的支持机构之间 可充当接口的角色。每一个协调人协调他本身所在的支持团队。
[0088] (7)结束事件
[0089] 当用户确认事件解决后，此时可结束该事件的处理，并在事件处理系统中关闭该 事件，若用户对此解决方案不满意，则对该事件继续进行处理，不能关闭。
[0090] 对一个比较有价值的事件解决方案，要放到事件知识库中，W备W后事件处理时 参考。
[0091] 另外，还可对定期对整个流程进行评估