运维实例文件事件管理5.docx
《运维实例文件事件管理5.docx》由会员分享，可在线阅读，更多相关《运维实例文件事件管理5.docx（17页珍藏版）》请在冰豆网上搜索。
运维实例文件事件管理5
ITSS服务管理体系文件
事件管理程序文件
修改记录
修改时间
版本
修改内容简述
修改人
审核人
一、目的
事件管理流程主要功能是尽快解决日常工作环境中出现的事件，保持IT服务项目的稳定性，其目的包括：
在成本允许的范围内尽快恢复IT服务项目报修故障
1.快速响应服务请求（电话，邮件，ITSM系统，即时通讯工具，现场等）；
2.用户获得服务支持；
3.沟通及跟踪事件处理的状态；
4.和用户确认事件的解决和用户满意度。
1、进行事件控制
1.按规范记录事件；
2.就事件的优先级、影响范围等进行分类；
3.分析，诊断，必要时进行升级；
4.监视并结束事件；
5.进行定期服务回顾。
2、提供IT服务项目管理信息
1.提供一个日常服务接口；
2.人力资源利用情况；
3.故障处理情况；
4.服务支持率。
二、范围
事件管理范围包括在服务工作中产生的操作咨询和故障处理，主要包括：
服务请求和技术咨询：
IT服务项目过程中，安装、部署、配置和使用等技术咨询。
信息化升级、扩容和改造等技术咨询活动。
故障处理：
对IT服务项目的软件和硬件故障进行处理。
信息安全事件：
由于网络、主机和操作人引发的有关信息安全事件。
三、角色、职责权限定义
流程的实现是通过不同的流程角色以及其被赋予的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责，同时也可以将其职责授权给其管理结构之下的人员，因此，以下所提及的管理流程和角色的目的是为了在充分满足流程所需角色的基础上，为具体的实现提供足够的灵活性。
事件管理流程主要分为以下几个职责/角色，分别简述如下：
1、服务台
服务台：
负责接收所有的事件，对事件进行初步的处理，并根据实际情况将事件分派到服务工程师。
1.1职责：
1.在制定的响应时间内响应所有服务台热线电话、ITSM系统、工单等事件报告；
2.完整记录所有接收的时间信息，包括：
记录时间报告人的详细联系方式、事件特征表现、描述、发生时间等；
3.为事件进行适当的分类、为事件分配优先级等属性；
4.尝试使用知识库、初步诊断、分析相关信息等方式解决事件；
5.如果服务台不能解决事件，应当将事件分配给服务工程师；
6.检查事件的处理进度，保持与用户的联系，适时通知事件处理进展；
7.在事件处理过程中，催办事件处理进度；
8.与用户确认时间解决方案及用户满意度反馈，关闭事件。
1.2技能要求：
1.熟悉技术平台和技术环境；
2.较强的沟通能力；
3.对简单的故障要有快速诊断和解决的能力；
4.熟悉事件处理流程。
1.3人员安排：
结合公司实际情况，设置服务台人数，负责受理桌面支持、核心业务系统类支持、非核心业务系统类支持（包括其它应用系统、网络接入等）三大类事件。
在有驻场服务的项目中安排驻场服务经理或驻场服务工程师充当驻场服务台人员，可根据具体驻场情况安排人数。
2、事件经理
事件经理：
通常由服务经理兼任，负责对服务台派单所有事件进行再一步的处理。
同时负责事件解决过程中的协调和监控，以及事件升级的判断以及具体执行。
1.1职责：
1.与服务台及时沟通事件的状态信息；
2.将事件分配给最合适的一线支持服务工程师来处理；
3.检查事件的处理进度，保持与服务台和用户的联系，适时监督事件处理进展；
4.在事件处理过程中，若事件信息不完善等可打回服务台催促其完善信息；
5.负责对重大、紧急事件的解决协调资源，保证故障的最终排除；
6.当事件优先级为紧急或者事件将超过规定的时限，负责按照升级方法对事件进行处理确保有效协调资源，促进各类角色小组（如一线服务工程师、二线服务工程师）快速恢复正常服务；
7.确保和问题管理流程经理的有效合作；
8.确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题。
1.2技能要求：
1.了解技术架构和技术环境；
2.较强的口头表达能力和与用户沟通技巧；
3.处理纠纷的能力；
4.深刻了解事件管理流程；
5.较强的领导能力。
1.3人员安排：
公司的事件经理暂由项目部服务经理担任。
3、一线服务工程师
在ITSS体系中，服务工程师负责对服务台无法解决的事件进行快速有效的分析，提出解决方案以尽快恢复服务，并在必要时提供现场支持。
1.1职责：
1.决定需要采取何种措施恢复服务并实施有效的行动；
2.必要时提供现场支持；
3.根据优先级提供有效的解决方案；
4.更新事件解决信息，已解决的事件转回服务台，由服务台关闭事件；
5.如果一线不能解决这个事件，应当决定选择最合适的二线支持服务工程师来处理。
1.2技能要求：
1.熟悉技术平台和技术环境；
2.较强的沟通能力；
3.快速诊断事件和解决事件的能力；
4.熟悉事件处理流程。
1.3人员按排：
将公司项目部日常维护（包括硬件、软件等）人员纳入一线支持中，按日常所管系统类型或设备类型划分到相应维护支持组中；
服务工程师可根据情况纳入到一线服务支持序列。
4、技术工程师
技术工程师是相关问题领域的专家。
负责提供对服务工程师无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。
1.1职责：
1.进行事件的深入调查研究；
2.根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动；
3.必要时引入供应商的支持；
4.及时提供有效解决方案；
5.与其他技术工程师合作，确定解决方案；
6.已解决的事件转回服务台，由服务台关闭事件。
1.2技能要求：
1.深厚的技术背景，对所维护范畴的技术深入掌握
2.熟悉事件处理流程。
1.3人员安排：
主要由公司技术部各类业务系统及基础设施维护专家组成。
5、岗位与角色映射
事件管理流程
角色
角色分析
说明
成员
服务台
公司服务台
职责：
负责受理各类事件。
结合公司情况，设置服务台人数。
服务台人员
驻场服务台
职责：
负责受理该驻场服务面临的一线服务支持类事件。
根据驻场服务的情况，酌情安排驻场服务经理或驻场服务工程师人员。
根据用户项目具体安排
服务工程师
服务工程师
基础设施维护支持组
职责：
负责用户小型机、PC服务器、存储设备、网络交换机、路由器、防火墙、网络链路等硬件维护工作。
岗位设置：
由公司项目部分派相关基础设施硬件技术支持人员担任。
系统实施人员
应用系统支持组
负责用户各类应用系统及操作系统、中间件、数据库等系统软件的基础维护支持工作。
岗位设置：
由公司项目部分派相关应用系统技术支持人员担任。
桌面支持组
职责：
负责总公司桌面支持工作。
岗位设置：
由公司项目部分派相关桌面技术支持人员担任。
技术工程师
公司二线服务工程师
应用系统运维专家组
职责：
负责用户应用系统包括核心应用系统及非核心应用系统的维护工作。
岗位设置：
由公司技术部各类应用系统资深技术人员担任；以及相关合作厂商的工程师共同担任（如IBM、VMware、Oracle、微软等）。
系统运维人员
基础设施维护专家组
职责：
负责用户小型机、PC服务器、存储设备、网络交换机、路由器、防火墙、网络链路等系统
硬件设备的维护工作。
岗位设置：
由公司技术部基础设施方面各类硬件设备资深技术人员担任；以及相关合作厂商的工程师共同担任（如IBM、HP、EMC、华为等）。
事件经理
公司
职责：
负责服务的督导与监控事件处理过程的正常运转，接收事件的升级通知和处理超时通知等。
岗位设置：
由项目部服务经理兼任。
根据具体项目安排
6、术语
术语
定义
IT服务
公司承诺的对用户提供的系统运行维护服务。
一线支持
服务台支持，主要包括服务热线，初级技术员和驻场技术服务工程师。
二线支持
技术部非驻场工程师提供的软件和硬件技术支持，包括高级技术工程师，以及厂商提供的技术支持。
重大事件
用户合同中规定的重大事件。
7、过程策略
1.1责任人策略
1.用户通过电话，邮件，ITSM系统，即时通讯工具，现场等方式向服务台报告事件，服务台当班人员接到事件报告和服务请求后，及时在ITSM系统内作好记录，服务台当班人员为此事件的负责人。
2.服务台记录事件后，要分析事件是否在受理责任范围内。
如果在受理范围内，由其进行分配给相关事件处理人员，并通知相关运维服务人员，要求运维服务人员回复对分派的事件单是否接受。
3.服务台当前值班人员负责向用户及时通报事件处理情况。
4.事件解决后，服务台当前值班人员及时对申告人进行回访。
1.2分类策略
由于用户提供的信息或许不完整或不正确，可能导致开始的分类与最终的分类有很大的差别。
首先对事件按照基本事件类型进行分类，各类可以对应到相应的支持组，以便准确分配任务。
事件分类：
一次分类
二次分类
说明
合同服务
服务请求
如：
状态查询、重置口令，业务咨询，信息咨询，工单处理等。
应用故障
用户应用出现问题，如错误提示、异常退出、不办理业务，性能下降等。
服务器
应急故障
机房服务器出现硬件故障，如系统停机、异常启动。
网络硬件故障
网络设备出现故障，如交换机故障、路由器故障等。
用户资产
维护
桌面硬件故障
电脑、笔记本、打印机等设备出现故障。
桌面软件故障
电脑、笔记本、打印机等设备出现的软件故障。
综合类
其它类的服务事件。
事件状态：
编号
状态
描述
1
处理
已在系统中记录，未派单给工程师。
2
派单
已分配至工程师，工程师未处理。
3
受理
工程师正在处理过程中，事件还未解决。
4
解决
工程师已解决，服务台还未确认。
5
回访
服务台确认，事件关闭。
1.3优先级策略
给事件分配优先级，以保证支持组对事件必要的重视。
分级应基于事件的紧急程度和影响面。
所有事件都应划分到不同的优先级中，其中划分为重要紧急的事件优先级为最高，根据事件的影响度和紧急度确定事件的优先级，事件优先级分为三级。
事件级别
级别定义
影响业务范围
影响业务程度
业务修复紧急程度
1
影响到用户核心业务系统及及安全，数据存储安全情况。
用户核心业务系统受到影响，数据会造成重大丢失或损坏的肯能性。
重要紧急
2
影响到用户很大一部分业务系统及安全，数据存储安全情况。
用户很大一部分业务系统受到影响，数据会存在丢失及损坏的一般可能性。
紧急
3
影响到用户部分非核心的一般业务系统及安全。
用户一般性业务系统受影响
普通
事件分类与故障等级与技术支持合同相关，如有合同定义，则以合同定义为准。
备注：
时间级别为1-2级的为重大事件，需要走重大事件处理流程。
1.4目标解决时间策略和升级策略
为了更好的控制事件的解决，事件被分类分级，每类事件的解决都设定了目标时间。
升级策略的目的是确保不同优先级的事件分配到合适的资源来解决。
为了达到这个目的，定义了升级策略的时间框架。
当达到其时间界限时，如果事件还未解决，将触发升级机制。
事件升级时间表：
事件级别
事件所处阶段
事件汇报人员范围
项目经理
（处理部门、
服务台）
部门经理
（处理部门、
服务台）
公司领导
业务
管理
部门
电话
邮件
电话
邮件
电话
邮件
电话
重要紧急
事件发现30分钟内
√
√
√
√
√
√
每1小时或有新进展
√
√
√
超15分钟
事件解决后30分钟内
√
√
√
√
√
紧急事件
故障发现30分钟内
√
√
√
√
√
√
每1小时或有新进展
√
√
√
超15分钟
事件解决后30分钟内
√
√
√
√
√
普通事件
故障发现30分钟内
√
√
每1小时或有新进展
√
超1
小时
√
超1
小时
超2
小时
超3
小时
事件解决后30分钟内
√
√
√
8、流程描述
1.1服务台受理服务请求
用户通过热线电话、邮件、即时通讯报告事件，服务台人员记录好相关信息，受理并进入事件处理流程。
服务台需要收集以下信息：
1.来电用户的单位名称、联系人、电话号码等基本信息。
2.影响业务的具体原因、故障现象以及所属优先级。
根据服务等级，故障类型等信息合理安排工程师并进行派单。
如果为重大事件，则需要上报给重大事件经理。
1.2请求记录和分类
对于来自热线电话、邮件、即时通讯收集的信息，服务台记录《工程师服务派工单》中相关信息，通过电话方式申告的需要询问用户详细的事件描述，然后根据用户的描述判断事件的分类、优先级等信息。
如果事件是关于供应商的问题，根据合同协议，直接转二线厂商（或供应商）支持。
若事件比较重大且优先级为重要紧急，则需要报告项目经理和部门经理。
1.3事件经理进行协调和监控
负责对所有事件进行再一步的处理。
同时负责事件解决过程中的协调和监控，以及事件升级的判断以及具体执行。
如果服务请求信息不完善，则进行打回处理，服务台人员完善之后再进行分配派单。
事件经理对事件进行判断，如果是重大事件，立即进入重大事件处理流程，否则进入正常的派单流程。
在整个事件处理过程中，事件经理对整个事件的处理流程以及过程进行跟踪和监督。
1.4工程师受理派单
一线操作岗工程师或二线技术支持岗工程师受理事件后，首先根据用户所描述故障情况，参照《知识库》，对用户进行相应的指导解决。
如果无法通过电话指导用户解决的事件，在征得用户同意的情况下，可以采用远程工具，登录用户计算机来操作解决，甚至上门维护服务。
1.5调查解决故障
现场服务人员（一线、二线）在现场通过标准配置进行比对等方法对故障进行分析，查找出故障原因。
技术服务人员根据故障分析结果确定解决方案，并与用户沟通执行解决方案所需要的时间，确定解决方案的可行性。
若发生的事件一时解决不了，需要与用户约定解决时间。
对于重大故障（故障等级为高或中）须做好数据备份。
若故障处理时涉及一般、重大、紧急的变更，转变更管理流程，参考《变更管理过程》。
事件解决后，故障现场负责人分析若属于影响重大或经常出现的问题，需要通过问题管理进行彻底解决的，转问题管理流程，参考《问题管理流程》。
1.6用户确认
待事件处理完毕，需要与用户确认，若涉及上门服务，还需要用户在《工程师服务单》签字确认并对此次服务做出评价。
1.7配置核对更新
当事件处理后配置项属性需要变更时，则由一线支持提交配置管理负责人进行配置项修改，修改设备台账中系统配置信息，参考《配置管理流程》。
1.8服务关闭
当产生新的解决方案时，需要提交到知识库，对知识库进行相关的维护，该事件服务结束。
1.9用户回访
事件处理后3个工作日内，由服务台对用户进行回访，回访结果并记录。
9、服务报告
项目经理按每月或每季度对事件进行总结并分类，并将报告发给项目实施部门负责人，必要时须提交用户。
事件报告内容包括（不限于）：
1.本月或本季度事件总数。
2.本月或本季度服务响应总数。
3.解决事件总数。
4.与历史报告比较的趋势分析和预测。
10、重大事件处理流程
1.2流程描述
重大事件经理
重大事件经理负责在重大事件期间协调计划、资源和沟通。
这是个临时性的职位。
如果要昼夜不停地处理事件，则可能需要向单个事件分配多个重大事件经理。
扮演重大事件经理角色的职员需要满足下列条件：
1.能够处理重大事件期间产生的压力。
2.有权作出决定的高级管理层。
3.优秀的沟通者，能够与组织中的所有层次的技术IT职员、业务代表和用户交谈。
4.深入了解公司（包括公司如何运作以及相关负责人）的公认人物。
5.准备加班工作，经常是随叫随到。
6.准备旅行并在需要时拜访用户现场，同样是随叫随到。
人员安排：
重大事件经理由事件经理担任。
重大事件恢复小组
重大事件经理，应该收集到目前为止可用的所有信息，并确认当前状况并负责组建恢复小组。
调查和解决重大事件所涉及的技术团队称为“恢复小组”。
该小组通常包含一个或多个技术人员，由同时经过技能培训和问题解决技术培训的资深职员组成。
这个核心小组应该接受使用中的所有关键战略技术的培训，当时如果特定事件要求不同的技能，可以由其他支持人员提供补充。
资深支持人员应该在临时分配的基础上在整个核心小组中轮流。
重大事件恢复计划
重大事件经理应该主持一次与恢复小组、已经参与处理事件的任何团队成员、受影响的经理和其他任何相关技术专家进行的初始计划会议。
该会议的目标应该是同时就恢复计划和沟通计划达成一致。
恢复计划的目标是提供用于服务恢复的有计划和协调的方法。
该计划由重大事件经理所有，并且应该对需要采取的操作、谁应该执行操作以及应该在何时完成操作等事项进行文档记录。
应该在重大事件的整个生命周期中定期更新该计划，确保保留旧版本以用于审核目的。
恢复计划应该包含以下内容：
1.截止目前已知的“问题”的陈述。
2.事件的细分，详细描述组件、接口和可能的问题原因。
3.关于如何检验或排除每个可能的直接原因的高级计划。
4.根据可能性和确认的容易性权衡每个可能的原因，允许向每个可能的原因的调查赋予一个优先级。
5.将在此阶段采取的调查或解决操作（基于所分配的优先级）的详细信息。
6.关于谁将执行调查或解决操作的详细信息。
每个操作的执行时间表，以及下一次恢复团队复查会议的时间。
重大事件沟通计划
重大事件经理应该与包含运维部负责人、项目经理、受影响的业务的用户代表，和合作伙伴一起组建管理小组，定时复查进度。
目的应该是讨论进度，并在需要时提供管理升级上报。
在主持管理审查会议之后，应该同意并签发进度更新声明。
管理小组和恢复小组审查会议通常应该保持独立，以便每个小组集中于与他们的角色相关的问题。
恢复小组应该讨论技术问题，然后为管理小组提供进度报告，后者然后可以集中于资源、上报和沟通问题。
在重大事件期间，沟通的处理本身经常变得非常困难。
沟通计划的目标应该是在事件生命周期中提供所有沟通的协调。
沟通计划应该由重大事件经理所有，并在每次管理小组审查会议时讨论和更新。
该计划应该包括：
1.谁需要定期更新。
2.各方的详细联系信息需要更新。
3.所需的不同类型的更新。
取决于接受沟通的受众，可能需要不同的更新消息。
4.高级管理更新。
5.针对所有职员的更新。
6.针对用户的更新。
7.针对合作伙伴的更新。
8.针对处理重大事件的职员的更新。
9.新闻/媒体声明。
10.针对紧急服务/机构的更新。
11.每种类型的更新的需要频度和下一次更新的到达时间。
12.谁被授权同意每个不同的更新声明的发布。
13.将传递每个更新的机制。
14.下一次管理小组会议的时间。
一旦批准了沟通计划和恢复计划，则应该分配任何需要的附加资源。
所有资源都应该能够访问恢复计划，以便他们能够看到截止目前已完成的操作和他们以及其他资源现在应该做的操作。
一旦重大事件过程已在进行中，计划已得到同意，资源已完成分配，就应该遵循调查、诊断、解决、恢复和终结的标准事件生命周期。
重大事件的不同之处在于事件由重大事件经理所有并紧密协调，并在整个事件生命周期中定期审查和维护恢复和协调计划。
恢复小组应该以定期间隔支持审查会议以讨论进度、更新恢复计划并签发恢复小组进度报告。
重大事件经理可以出席这其中某些审查会议，但是不一定要全部出席。
审查会议之间的间隔视发生的活动量而定。
例如，在调查的紧张阶段，该会议应该比职员只是等待确认解决操作成功时的后续阶段更加频繁。
还应该主持定期的管理小组会议以便向所有各方通气、讨论进度，并决定何时需要管理升级上报。
重大事件经理应该出席所有管理小组进度会议。
同样，审查会议之间的间隔应该视活动量而定。
在重大事件期间执行管理升级上报可能变得必要。
随着事件变得更加关键，随着管理升级上报在合作伙伴和用户中的进行，沿管理链往上上报事件情况是必要的。
这样可以避免诸如高级经理或主管首先从合作伙伴或用户组织的同行那里了解到事件的情况。
沟通计划应该随着管理升级上报或恢复小组成员变更而更新。
重大事件经理负责在发布之前同意或获得所有沟通更新陈述的协议。
重大事件终结
随着重大事件的推进，重大事件经理应该确保定位、分配和协调任何附加资源要求。
有些重大事件可能使得调用组织的业务连续性和服务连续性计划变得必要。
必须考虑到重大事件过程和服务连续性计划如何合作以及职责如何划分。
在重大事件期间，重大事件经理决定何时以及是否应该调用服务连续性计划，以便恢复服务或保留恶意企图情况下的证据。
通常，重大事件经理应该继续负责协调恢复操作、沟通和诸如收集证据和实施临时变通办法等活动。
重大事件过程应该继续伴随常规事件管理流程，直至重大事件终结。
在事件的最后阶段，当已经采取解决操作时，解除恢复小组的部分任务也许是可能的，不过要了解到如果解决方案被证明不成功，他们将被重新召集。
在重大事件终结时，应该通知问题管理，因为执行重大事件后的审查是他们的职责。
11、过程测量指标
通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。
事件管理流程KPI指标设置如下：
序号
衡量指标
指标说明
考核频次
1
事件一次解决率≥80%
不将事件进行职能升级的事件/总事件*100%
月度
2
事件按时解决率≥95%
在SLA的目标之内解决事件/总事件*100%
月度
事件流程负责人每月对事件处理的监控数据进行分析统计，形成服务报告。
升级会员 