ITSS实例文件事件管理流程文件模板文档格式.docx

ITSS实例文件事件管理流程文件模板文档格式.docx

《ITSS实例文件事件管理流程文件模板文档格式.docx》由会员分享，可在线阅读，更多相关《ITSS实例文件事件管理流程文件模板文档格式.docx（19页珍藏版）》请在冰豆网上搜索。

（3）屏蔽错误事件和服务请求

（4）根据客户业务系统的轻重缓急解决事件，保障有效IT系统运营

（5）加强有效监控和及时反馈

（6）提升用户满意度

（7）提供管理信息

2适用范围

事件管理覆盖的范围是运维服务的客户。

事件管理的范围包括以下：

Ø

网络与基础设施：

如局域网，广域网，机房，电力，空调等；

安全事件：

如病毒，攻击，泄露等；

系统数据库：

如操作系统，数据库等；

应用系统软硬件：

主机，系统，客户网站等；

运维服务范围内的咨询，协调处理等。

3名词术语

故障：

任何不属于正常服务运营，导致服务中断或使服务质量明显下降的情况。

事件：

包括故障和运维服务范围内的咨询，协调处理等。

4事件的分类和分级

4.1事件分类

运维服务的事件分类主要包括：

网络与基础设施，安全事件，系统数据库，应用系统软硬件和范围内的咨询，协调处理等。

4.2事件分级

一级

业务系统重要程度级别定义为高；

有害程序事件、网络攻击事件、信息破坏事件、信息内容安全事件、设备设施故障、灾害性事件和其他信息安全事件造成系统大面积瘫痪，影响业务用户数量>

=80%；

使其丧失业务处理能力，导致业务中断时间>

=2小时；

系统关键数据的保密性、完整性、可用性遭到严重破坏。

二级

有害程序事件、网络攻击事件、信息破坏事件、信息内容安全事件、设备设施故障、灾害性事件和其他信息安全事件

造成系统长时间中断或局部瘫痪，影响业务用户数量>

=50%；

中断时间:

>

=1小时；

使其业务处理能力受到极大影响，系统关键数据的保密性、完整性、可用性遭到破坏。

三级

业务系统定义级别为中；

有害程序事件、网络攻击事件、信息破坏事件、信息内容安全事件、设备设施故障、灾害性事件和其他信息安全事件造成造成系统影响业务用户数量>

=20%；

=0.5小时，明显影响系统效率。

4.3处理事件原则

处理事件的原则是尽可能减小对业务的影响；

◆事件管理流程必须包括管理服务事件影响的步骤，比如评估影响、沟通、提供变通方案等,使事件对客户业务活动的影响降至最小；

◆在可能的情况下，应该向客户提供继续进行业务活动的手段，即使降低服务级别，比如禁用一项有错误的功能，目的是将事件对客户业务活动的影响降至最小；

◆当服务级别不能被满足时，应该提前提醒客户，并且对下一步的处理行动达成一致意见。

4.4升级原则

类别

升级策略

职能升级

若一线支持在职责范围内完成事件诊断，仍未找到相应的解决方案，应立即将故障转给二线支持。

若二线支持支持在职责范围内完成事件诊断，仍未找到相应的解决方案，应立即将故障转给三线支持。

层次升级

若接近故障的解决期限，故障仍未能解决，应通知更高一级的管理人员。

按照商定的升级层次和时间，向用户高层管理人员升级。

5流程角色

角色

职责

职能岗位

事件经理

●确保有效协调资源，使事件快速恢复正常服务状态

●确保事件管理支持人员的适当技能水平和绩效表现

●确保和问题管理、外部供应商等其他角色的有效合作

●确保事件的快速恢复

●确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题

●确保有关IT服务和用户支持的管理信息的可获得性

●提供相关的事件统计报表和趋势分析

各负责人

服务台

（一线）

●接受用户的事件申告，对事件进行确认

●确保所有相关事件信息都被正确登记

●对登记的事件进行分级和分类

●直接为用户提供相应的恢复方案

●将事件分派给适当的事件分析员

●跟踪事件处理过程以确保在规定的时间内恢复问题

●结束事件，更新信息

●作为事件的所有者，监控，跟踪所有的事件。

●必要时进行事件升级

客服人员

事件分析员

（现场一线、二线、三线）

●接受服务台转交的事件，对之进行处理。

●确认事件的分类、分级和关联配置项。

●在规定的时间内恢复事件，必要时进行事件升级。

●事件的调查和诊断。

●把事件的影响降到最小，并确保快速恢复到正常服务水平。

●收集及确定恢复方案，根据恢复方案进行IT服务恢复。

●如事件产生了一个问题，提交问题单给问题分析员。

●如事件产生了变更，则提交变更请求给变更管理。

各部门参与事件分析与解决的人员

一线：

服务台和现场人员

二线：

运维部门

三线：

供应商和研发团队

6流程

6.1事件管理流程

活动

描述

责任人

输入

输出

1报告事件

用户通过热线电话、语音邮件、直接访问、信件、传真和电子邮件等方式提交事件申告；

运维工程师巡检发现系统故障；

监控系统上报故障告警。

用户

申报用户信息

申报的事件信息

用户报告的事件

2记录事件请求、维护用户信息

服务台使用系统接受并记录用户提交的事件及用户基本信息。

含有用户信息和事件描述的事件记录

3事件分类/优先级确定

服务台人员参考目前事件分类标准对该事件进行分类；

服务台人员参考事件分级标准确定事件请求的优先级；

如果该事件为重大事件，需要启动应急预案，则根据业务连续性管理规范进行处理。

事件记录

已分类及划定优先级的事件

重大事件

4处理解决事件

服务台分配事件请求，并快速解决服务台能够解决的事件；

一线支持人员解决咨询、询问类事件及简单的故障，一线机房现场支持人员解决现场故障，无法解决时升级事件到二线支持人员；

二线支持人员解决故障类事件,在无法解决时升级到三线，并通报服务台；

运维经理监控所有事件请求并跟踪、协调未解决事件。

一线支持人员

二线支持人员

运维经理

含有分类及优先级的事件记录

已解决的事件的记录

5关闭事件

服务台以多种方式与用户确认是否认可事件的解决方案；

服务台在用户认可后关闭事件记录。

已解决的事件记录

已关闭的事件记录

6事件后续处理

服务台在事件关闭后定期生成事件报告；

运维经理查看事件报告并根据需要转向其他流程。

已解决事件记录

定期事件报告

需要提交安全管理流程处理的事件记录

需要进入问题管理流程的事件记录

6.2处理解决流程

1分配事件请求

服务台查看事件记录和知识库，如果是服务台能快速解决的事件，则服务台自行解决；

如果确定需要转派才能解决的事件，则指派一线现场支持人员解决事件。

已分类并确定优先级的事件记录

由服务台负责的事件

由一线现场支持人员负责解决的事件

2服务台快速处理事件

服务台根据事件分类和描述查找知识库和历史事件记录；

如果有相关的解决方案，则根据历史记录或知识库记载的方案快速解决事件；

解决尚无相关历史记录的事件。

已解决的事件

3事件分配确认

一线支持人员查看被指派的事件请求，如果是自己工作范围内的请求，则接受指派；

如果事件分配错误，则报运维经理重新指派。

由服务台指派给一线支持人员的事件记录

由一线支持人员负责解决的事件

由服务台重新分配的事件记录

4处理事件/提交变更请求

一线支持人员根据事件分类和描述查找知识库和历史事件记录，如果有相关解决方案则根据知识库记载或历史记录解决事件，如无历史记录，一线支持人员调查研究解决该事件，事件的解决方案如需对配置项进行变更则提交变更请求；

一线支持人员解决事件，如果在时限内仍未能解决该事件，则服务台根据已经定义的事件升级规则将该事件升级到运维经理处；

如果是重大事件，则执行子流程重大事件处理流程。

未能解决升级的事件

5申请二线支持

如果一线人员未能解决接受指派的事件，则由二线支持人员解决该事件。

一线人员未能接受的事件记录

指定二线支持人员的事件

6事件分配确认

二线支持人员查看被指派的事件请求，如果是自己工作范围内的，则接受指派；

如果事件分配错误（仅指应用指派错误），则交给运维经理重新指派。

服务台分配给二线支持人员的事件记录

由二线支持人员负责解决的事件记录

由运维经理重新分配的事件记录

7处理事件/提交变更请求

二线支持人员根据事件分类和描述查找知识库和历史事件记录，如果有相关解决方案则根据知识库记载或历史记录解决事件，如无历史记录，二线支持人员调查研究解决该事件，事件的解决方案如需对配置项进行变更，则提交变更请求；

如果二线人员未能解决接受指派的事件，则由三线支持人员解决该事件。

二线人员未能接受的事件记录

指定三线支持人员的事件

8事件分配确认

三线支持人员查看被指派的事件请求，如果是自己工作范围内的，则接受指派；

如果事件分配错误，则交给运维经理重新指派。

三线支持人员

二线人员分配给三线支持人员的事件记录

由三线支持人员负责解决的事件记录

9处理事件/提交变更请求

三线支持人员根据事件分类和描述查找知识库和历史事件记录，如果有相关解决方案则根据知识库记载或历史记录解决事件，如无历史记录，三线支持人员调查研究解决该事件，事件的解决方案如需对配置项进行变更，则提交变更请求。

10协调处理未解决事件/事件重新分配

运维经理协调解决所有由一线、二线升级的事件和监控中发现需要协调解决的事件直至解决事件；

如果事件不能得到解决，则应立即提交到问题管理流程。

需要协调处理的事件

需要提交问题管理流程的事件

6.3重大事件处理流程

1处理事件/提交变更请求

二线支持人员根据事件分类和描述查找知识库和历史事件记录，处理重大事件，需要时提出变更请求。

经确认的重大事件

重大事件的记录

安全事件的记录

2每月报告中报告该事件

二线支持人员记录重大事件，并在每月的服务报告中报告该事件；

每月的服务报告，对重大事件的记录

3通知网络、系统负责人/三线

二线支持人员负责将重大事件通知网络、系统负责人/三线；

并负责协助三线解决事件。

重大事件报告

4监控重大事件进展

对重大事件进行监控和回顾。

三线系统责任人

服务改进计划，包括对重大事件的回顾和分析

6.4关闭事件流程

1记录事件解决方案

各事件解决者记录已解决的事件的解决方案。

各事件的解决者

包含解决方案的事件记录

2与用户确认事件已解决

服务台以多种方式与事件申报者联系，由事件申报者认可该事件的解决方案；

若事件申报者认可该事件解决方案，则关闭事件；

若事件申报者不认可该解决方案，则由服务台继续跟踪。

已记录解决方案的事件记录

事件申报者认可的可关闭的事件记录

继续跟踪的事件记录

3事件状态标记为关闭

服务台关闭事件记录。

已关闭事件记录

4回访

服务台对事件申报者进行本次服务的回访调查。

用户回访调查结果

6.5后续处理流程

1定期生成事件报告

服务台定期生成事件报告。

所有已关闭事件记录

事件报告

2审阅事件报告

运维经理审阅事件报告，通过事件报告识别问题，并将问题提交到问题管理流程。

提交到问题管理流程的事件记录

7与其他流程的关系

配置管理

需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。

问题管理

事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为高的事件解决并恢复服务后作为问题进行进一步的分析和处理。

变更管理

服务台应了解变更管理流程中目前正在进行的变更信息，监测因变更引发的事件。

在事件的解决过程中，必要时需要发起变更请求来解决事件。

服务级别管理

服务级别管理流程对SLA协议完成情况进行持续监控，事件流程相关人员必须全面了解SLA协议内容，以便在与用户进行沟通的时候可用到这些信息。

有关事件记录的报告可用来判断是否真正地提供的规定级别的服务。

可用性管理

为了评估服务的可用性，可用性管理流程需要使用配置管理流程提供的事件记录和状态监控信息，例如事件处理期间导致的某项服务的“不可用”状态。

能力管理

能力管理流程关注由于能力（Capability）不足导致的事件，例如系统处理能力不足导致的处理响应时间过长。

8审核

定期对事件管理全流程进行审核。

9度量

详细指标参见《运维服务KPI指标体系》

10参考文件

GB/T28827.1-2012《信息技术服务运行维护第1部分:

通用要求》

ISO/IEC20000-1：

2005《IT服务管理体系要求》

ISO/IEC20000-2：

2005《IT服务管理体系实践指南》

ITSS.1—2015信息技术服务运行维护服务能力成熟度模型