运维事故报告的内容有哪些(运维事件管理流程)

下面是好好范文网小编收集整理的运维事故报告的内容有哪些(运维事件管理流程)，仅供参考，欢迎大家阅读！

目的

事件管理是负责解决IT服务的事件、故障和客户请求等的运维流程。它的目的是尽快恢复被中断或受到影响的IT服务，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。

为了有效地解决运维服务中产生的突事件，提高运维服务的质量，为客户提供更优质的信息技术服务建立一个完整的事件管理系统，从而实现：

(1)  减小事件对客户业务建设的影响

(2)  最优化支持资源，提高工作效率

(3)  屏蔽错误事件和服务请求

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

(5)  加强有效监控和及时反馈

(6)  提升用户满意度

(7)  提供管理信息

适用范围

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

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

网络与基础设施：如局域网，广域网，机房，电力，空调等；

安全事件：如病毒，攻击，泄露等；

系统数据库：如操作系统，数据库等；

应用系统软硬件：主机，系统，客户网站等；

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

名词术语

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

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

运维服务的事件分类主要包括：网络与基础设施，安全事件，系统数据库，应用系统软硬件和范围内的咨询，协调处理等。

事件分级

一级

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

有害程序事件、网络攻击事件、信息破坏事件、信息内容安全事件、设备设施故障、灾害性事件和其他信息安全事件造成系统大面积瘫痪，影响业务用户数量>=80%；使其丧失业务处理能力，导致业务中断时间>=2小时；系统关键数据的保密性、完整性、可用性遭到严重破坏。

二级

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

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

造成系统长时间中断或局部瘫痪，影响业务用户数量>=50%；中断时间:>=1小时；使其业务处理能力受到极大影响，系统关键数据的保密性、完整性、可用性遭到破坏。

三级

业务系统定义级别为中；有害程序事件、网络攻击事件、信息破坏事件、信息内容安全事件、设备设施故障、灾害性事件和其他信息安全事件造成造成系统影响业务用户数量>=20%；中断时间:>=0.5小时，明显影响系统效率。

四级

业务系统定义级别为低；有害程序事件、网络攻击事件、信息破坏事件、信息内容安全事件、设备设施故障、灾害性事件和其他信息安全事件影响业务用户数量<20%；造成中断时间:<0.5小时，影响系统效率，使系统业务处理能力受到影响。

处理事件原则

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

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

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

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

升级原则

类别

升级策略

职能升级

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

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

层次升级

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

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

流程角色

角色

职责

职能岗位

事件经理

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

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

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

确保事件的快速恢复

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

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

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

各负责人

服务台

（一线）

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

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

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

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

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

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

结束事件，更新信息

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

必要时进行事件升级

客服人员

事件分析员

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

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

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

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

事件的调查和诊断。

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

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

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

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

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

一线：服务台和现场人员

二线：运维部门

三线：供应商和研发团队

流程

事件管理流程

活动

描述

责任人

输入

输出

1报告事件

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

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

监控系统上报故障告警。

用户

申报用户信息

申报的事件信息

用户报告的事件

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

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

服务台

用户报告的事件

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

3事件分类/优先级确定

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

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

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

服务台

服务台

事件记录

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

重大事件

4处理解决事件

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

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

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

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

服务台

运维经理

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

已解决的事件的记录

5关闭事件

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

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

服务台

已解决的事件记录

已关闭的事件记录

6事件后续处理

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

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

服务台

运维经理

已解决事件记录

定期事件报告

定期事件报告

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

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

处理解决流程

活动

描述

责任人

输入

输出

1 分配事件请求

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

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

服务台

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

由服务台负责的事件

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

2 服务台快速处理事件

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

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

服务台

由服务台负责的事件

已解决的事件

3 事件分配确认

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

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

服务台

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

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

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

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

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

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

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

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

已解决的事件

未能解决升级的事件

重大事件

5申请二线支持

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

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

6 事件分配确认

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

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

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

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

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

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

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

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

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

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

已解决的事件

8事件分配确认

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

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

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

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

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

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

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

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

已解决的事件

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

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

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

运维经理

需要协调处理的事件

已解决的事件

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

重大事件处理流程

活动

描述

责任人

输入

输出

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

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

经确认的重大事件

重大事件的记录

安全事件的记录

2 每月报告中报告该事件

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

经确认的重大事件

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

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

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

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

经确认的重大事件

重大事件报告

4 监控重大事件进展

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

三线系统责任人

重大事件报告

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

关闭事件流程

活动

描述

责任人

输入

输出

1记录事件解决方案

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

各事件的解决者

已解决的事件

包含解决方案的事件记录

2与用户确认事件已解决

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

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

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

服务台

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

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

继续跟踪的事件记录

3事件状态标记为关闭

服务台关闭事件记录。

服务台

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

已关闭事件记录

4回访

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

服务台

已关闭事件记录

用户回访调查结果

后续处理流程

活动

描述

责任人

输入

输出

1定期生成事件报告

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

运维经理

所有已关闭事件记录

事件报告

2审阅事件报告

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

运维经理

事件报告

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