返回本章节索引     阅读下一篇

某电子口岸行业ITIL事件管理流程研讨

事件管理流程研讨

█  目标

本次研讨会的目标：

• 介绍事件管理流程，让参会人员对事件流程有全面、深入的了解。
• 讨论、修正，确认事件管理流程的设计内容，包括：流程、政策、角色、KPI、参考数据等。
• 无法在研讨会上完成的工作，形成后续工作计划，跟踪其完成

█  事件管理的目标

• 事件管理流程的目标：事件管理的主要目标是争取在最短的时间内解决、恢复，尽量避免或减少事件对用户造成影响 。

◆◆事件和问题流程、变更流程关系紧密，往往是问题流程和变更流程的发起来源

█  流程设计依据

ITIL对事件管理流程的要求：

◇在成本允许的范围内尽快恢复IT服务：

• 快速响应事件：已具备，电话、监控系统
• 用户在线获得帮助：无
• 沟通事件解决的状态：已具备
• 与客户确认事件的解决：已具备，目前是值班经理和故障处理人均可进行客户的回访与事件的关闭，事件的解决真实性存在风险

◇进行事件控制：

• 按规范记录事件：不具备，目前是将众多信息存储在一些描述性的字段中，对于数据的统计与分析存在困难
• 就事件的优先级、影响度进行分类：已具备，但目前事件的优先级、影响度与分类的定义不够明确，执行的不好
• 监视并结束事件：已具备
• 进行定期服务流程回顾：已具备，但目前数据规范性不高，流程的回顾分析无法得到多数的关键数据，而回顾结果有限。

◇提供IT管理信息：

• 人力资源利用情况：不具备
• 故障处理情况：不具备，目前没有关闭代码，造成事件的处理结果无法进行可统计的标示记录，对于事件处理结果无法进行分析
• 支持效率：不具备，对于事件的时间记录并不准确

◇通过访谈反馈结果了解各处对当前事件管理流程的改进需求：

• 需要明确统一的分类和等级管理规范
• 需要定义重复事件和关联事件的处理规范
• 需要明确目标时间规范 需要统一升级处理规范
• 需要明确的、中心级别的转派单规范 故障单的分类太技术，对客服人员形成技术壁垒，导致沟通和处理成本上升

█  事件管理流程的角色与职责

◇事件管理流程负责人：

• 全面负责流程的效率和成果
• 建立考核目标，以提升流程的有效性和效率
• 为保障流程的有效性，需争取高级管理层承诺投入足够的资源
• 鉴别和管理关键的流程成功要素
• 控制和带领流程的改进 定义目标、流程、工作流、规范和规则，并与相关人员进行沟通
• 推动事件管理流程的执行

◇事件管理流程负责人：

• 确保对流程的使用者提供适当的教育
• 解决需要跨越职能部门的事件，如有需要，应升级汇报
• 对事件管理流程的有效性和效率进行监控，在需要的时候做出改进
• 召开和主持对事件管理流程改进的季度会议
• 作为事件管理流程对外的代表，对其他流程负责人和管理层汇报流程的状况和进度
• 在适当的情况下，事件管理流程负责人可以把部分责任委任给其他人员执行

◇事件经理：

• 传达流程的新规范和更新的规范
• 确保流程标准和步骤得到遵循
• 鉴别和实施流程的改进建议
• 对事件管理流程的负责人提出改进的建议
• 对于不遵守流程的情形进行处理
• 发生重大故障时协助值班经理进行调度、跟踪等工作
• 出席会议并传达和协调有关事件 定期出事件管理报表

◇值班经理：

• 协调事件管理的日常操作
• 鉴别流程执行过程中的例外和异常情况，并进行管理，负责重大事件的及时响应和处理
• 作为流程的集中联络点，负责协调用户、服务供应商、管理层之间的沟通
• 在需要的时候，按照升级规则中所定义的途径进行升级
• 从事件管理流程的开始到结束进行跟踪
• 确保日常操作中所采集信息的完整性

◇事件分析员：

• 初步分析请求信息，并尝试解决
• 对于填写不规范的退回提交人
• 创建或者更新事件单
• 必要时张贴和更新快速通报的信息
• 对于不能解决的三级以下（含三级）事件，确定适当的分派给合适的支持人员
• 发现重大事件立即上报值班经理
• 根据已有的应急预案执行简单的解决方案 对事件单进行质监管理

◇事件记录员：

• 接受用户的联系
• 收集基本的联系信息
• 验证用户的基本信息，如有需要，更新用户的资料
• 收集用户的请求信息
• 创建或者更新事件单
• 初步评估请求的优先级 关闭事件单

◇支持人员：

• 第一时间响应事件，进行故障诊断和处理
• 分析事件信息 再次确认事件的优先级，及事件分类 查找相同的症状的事件
• 确定恢复服务所需要的必要条件，并启动适当的行动
• 根据事件的优先级提供有效的解决方案
• 在可能的情况下，产生变通方法 如有需要，与厂家和项目应用处协同合作
• 根据事件管理流程负责人预定义的标准执行复杂的解决方案
• 记录变通方法/解决方案
• 对供应商的服务质量进行评价

█  事件管理流程的角色与人员映射

█  事件管理流程的概要流程图

█  事件检测与记录

█  事件分类与初步支持

█  事件调查与诊断

█  事件解决与恢复

█  事件关闭

█  重大事件

█  事件管理流程的流程接口

◇与变更管理流程：

处理中的事件可以提交变更单，事件单状态变为等待中，系统自动完成关联；变更单关闭后，会将事件单的状态置为已完成；变更执行失败，如果触发事件，需要关联事件单和变更单。

◇与发布管理流程：

处理中的事件可以将事件单状态至为等待中，等待发布更新包或等待程序回退；关闭代码为“变通解决且与其关联的发布单已关闭”，自动提交问题单，系统自动完成关联；关闭代码为“变通解决且与其关联的发布单未关闭”，自动修改与其关联发布单的状态。

◇与问题管理流程：

关闭代码为变通解决和不成功解决的自动提交问题单，系统自动完成关联。

◇与配置管理流程：

在事件分析阶段可关联配置项，系统自动完成关联，并在配置项中可查看关联事件情况。

◇◇与知识管理流程（将来实现）：

事件处理过程中可以随时查看和引用知识库；事件处理完毕后可以提交知识库。

█  总体政策

◇所有对运行系统有影响的事件都会通过事件管理流程处理；将通过流程中定义的标准、规范和指导进行管理。

◇所有报告事件的部门将会参与统一的事件管理流程，不应该有任何例外。

◇所有IT支持人员对严重影响运行的事件所采取的恢复服务的行动，相比其他任何任务具有优先权。

◇事件单在业务恢复后3天内，将会被自动关闭。但是事件等级为1和2的事件单不会被自动关闭，它们必须得到事件提交者的确认后方可关闭。

◇值班经理应对事件的整个处理过程进行实时监控、跟踪，处理升级的事件。

◇事件经理应该定期产生和回顾事件管理报表。对没有解决的事件，应该举行定期的管理会议对这些事件进行评估。

◇流程负责人应该定期对流程进行回顾，以改进事件管理流程。

█  流程维护政策

◇监控的告警规则信息及与事件的关联信息的维护由每天晨会讨论发起，运行支持组执行。

◇事件分类、人员映射配置、关闭代码等配置信息的优化和维护由流程负责人负责对流程回顾，每月提交运行支持组执行修改。（试运行阶段流程负责人每周回顾一次，收集分类、分级意见，不断完善）

█  责任人政策

◇当一个事件被创建后，事件分析员负责这个事件单。

◇当事件单被分派后，支持人员负责此事件单；但是分派方（作出分派的事件分析员或是作出转派的支持人员）有责任通过电话通知被分派的支持人员并要求他接受或是拒绝此事件单。

◇对于紧急或重大事件，来不及建单的事件，事后由当时负责解决事件的支持人员通过电话等方式要求事件分析员协助建单，事后进行处理过程的补录

◇值班经理对重大事件负责，对升级的事件负责

█  事件分派政策

◇事件分析员向支持人员分派事件时，可以直接分派事件到人，同时通知到组和组长

◇支持人员间转派事件时，可以直接到人，同时通知到组和组长

◇一个事件需要多人或组同时处理，通过分派事件任务的方式进行

█  事件分类

◇事件分类对事件的SLA控制、知识库管理、事件统计分析、考核指标等有非常关键的作用。

◇将使用三级（CTI）分类对事件现象进行分类和一个“根原因”字段标识来描述故障根源：

█  事件定级

◇事件等级由高到低分为一级、二级、三级、四级和非等级。

◇事件定级根据应用故障和IT故障两种类别分别进行定义。

◇其中应用故障定级主要根据事件影响的项目、影响程度、影响范围和影响时间决定，分别对应一级、二级、三级和四级。

◇IT故障定级主要根据IT类型和影响情况，分别对应二级、三级、四级和非等级，非等级为预警事件。

◇事件等级在事件的生命周期中是可以改变的，关于更改事件单等级的原因和行为应该在事件单中记录。

█  目标解决时间

目标时间的定义与事件等级有关

█  通知策略

◇事件到达类通知：当事件单分派给某个组或某个人时，进行通知。

◇事件单到达分派给某个组时通知组内所有人。 事件单处理完毕后通知事件单建单人。

◇重大事件通知事件经理，并根据重大事件通知列表进行上报通知。

█  上报策略

◇事件单生成后根据下表上报范围进行事件上报。

◇值班经理应依据事件等级进行事件持续上报：一级事件每10分钟进行一次处理情况上报，二级事件每30分钟进行一次处理情况上报，三级事件每60分钟进行一次处理情况上报。四级及以下事件不必上报。

◇事件处理完毕后依据下表上报范围对处理结果进行上报。

█  重大事件定义 

◇事件等级为一级和二级的事件被定义为重大事件。

◇重大事件发生时要求立即通知事件经理。

◇重大事件发生后需要发布H2000快速通报。

◇重大事件要求所有人员必须及时响应和处理，事件经理可召集专家进行会诊。

█  事件升级上报政策（Escalation）

◇升级上报的目的是，对于不同等级的事件，确保分配到合适的资源来解决。

◇事件升级上报触发条件：事件得到响应事件超时、事件找到解决方案时间超时、事件得到恢复时间超时、事件单被转派3次及以上。

◇事件升级后需通知到事件经理。

█  重复事件政策

◇如果被报告的事件与某个已经创建且尚未解决的事件单症状相同，则该事件被认为是重复的

◇事件分析员线需要经过分析后，将引发两个工单的主事件标注为“主事件”，被引发的工单标注为“子事件”

◇主事件调整为“已解决”状态的同时，相关的子事件相应调整为“已解决”状态，主事件关闭后子事件也需要经过确认后才可以关闭。

█  复发政策

◇如果报告的事件与已经关闭的事件相同，该事件被认为是“复发”的事件单。这意味着为了解决事件而采取的解决措施失败了。此时应当创建一个新的事件单，复制原始事件单的内容，并说明这是复发的事件。

█  关闭政策

◇所有事件由事件分析员完成事件回访后关闭 所有关闭代码为“变通解决”和“不成功解决”的事件单关单后自动创建问题单

◇复发的事件如果原来关闭代码为“成功解决”，关单时自动创建问题单

◇复发的事件如果原来关闭代码为“变通解决”或“不成功解决”，关单时不需要创建问题单

█  重开政策

◇已关闭的事件单不允许重新打开，任何人都没有权限重新打开已关闭的事件单

◇如果事件复发，则创建一个新的事件单，并复制原始内容到新创建的事件单中

█  事件管理的KPI

◇一线支持解决事件的比例（%）

◇超时的事件统计 事件单分类的数量统计

◇事件单分级的数量统计

◇等待中的事件统计

◇重大事件数量统计

◇平均事件单解决时间

◇事件分类失误比例

◇周期内事件总数统计（每周、月、季度、半年、全年）

◇目标时间内解决的事件所占比例

◇远程指导事件分析员解决事件所占比例

◇故障平均解决所用成本 转发不当的服务请求占服务请求的比例

█  事件单的输入项

█  事件单的状态

█  事件来源

█  关闭代码

返回本章节索引     阅读下一篇