3.事件管理程序
事件管理程序
E-Link-23-03
北京亦霖创智科技有限公司
目 录
尽快解决正常业务中出现的事件,保持运维环境的稳定性。通过对事件进行登记、分类、分级、状态跟踪、关闭确认等手段建立一个事件管理程序的闭环,从而对事件的处理过程进行监控和优化,在成本允许的范围内尽快恢复服务,提高客户满意度。
通过本文档的定义,将建立一个完整的事件管理系统,从而实现:
l 减小突发事件对业务的影响;
l 最优化支持资源,提高工作效率;
l 屏蔽错误事件和服务请求;
l 根据业务轻重缓急解决事件,保障有效运维运营;
l 加强有效监控和及时反馈;
l 提升用户满意度;
l 提供管理信息。
本文档适用于新疆感知信息科技有限公司。
术语 |
缩略语 |
定义 |
事件 |
Incident |
服务台接收到的所有的可记录和可监控的任何事件。 |
事件管理 |
IM (Incident management) |
事件管理程序的目的是尽快解决事件与恢复服务。事件记录的信息决定了其它许多程序的效率。 |
故障 |
Failure |
任何不符合标准操作且引起或可能引起服务中断和服务质量下降的事件。 |
服务请求类事件 |
Service requests |
服务请求类事件指用户希望从服务台得到的支持、咨询、建议或者文档方面的请求。 |
投诉 |
complaint |
由于运维服务质量或者投诉处理本身,没有达到用户或者客户的期望,用户或者客户向运维服务商提出不满意的表示。 |
严重等级 |
Impact Degree |
表明事件对服务所产生的业务影响,它决定了事件的处理顺序和力度。 |
重大事件 |
Major Incident |
严重等级为一级事件为重大事件。 |
信息安全事件 |
Information secury Incident |
所有引起信息的机密性,完整性和可用性缺失的事件都是信息安全事件。 |
服务台 |
Service desk |
指运维服务商的服务台,主要接受事件的申告。 |
l 确保有效协调资源,使事件快速恢复正常服务状态;
l 确保事件管理支持人员的适当技能水平和绩效表现;
l 确保和问题管理、外部供应商等其他角色的有效合作;
l 确保事件的快速恢复;
l 确保正确和广泛地收集和分析事件数据,发现运维和业务相关的问题;
l 确保有关运维服务和用户支持的管理信息的可获得性;
l 提供相关的事件统计报表和趋势分析。
l 接受用户的事件申告,对事件进行确认;
l 确保所有相关事件信息都被正确登记;
l 对登记的事件进行分级和分类;
l 直接为用户提供相应的恢复方案;
l 将事件分派给适当的技术人员;
l 跟踪事件的处理过程以确保在规定的时间内完成处理。
l 接收到服务台分配的服务单
l 第一时间与用户建立联系
l 与用户预约上门服务的时间
l 进行基本故障处理
l 处理一线工程师无法解决的问题
l 二线支持团队无法根据自身对问题的判断,与客户协商申请调用厂商技术支持。
5. 事件管理流程
1) 事件申告信息
事件的来源一般有如下几种:
l 用户通过热线电话、语音邮件、直接访问、信件、传真和电子邮件等方式提交事件申告;
l 运维工程师巡检发现系统故障;
l 监控系统上报故障报警。
2) 提出服务请求
用户提出问题咨询,服务台承接事件咨询,并记录。
3) 创建并记录事件基本信息
服务台应将事件申告信息记录在运维系统中,对于所有事件申告,均应在运维系统中创建新的事件单。
事件记录的基本信息应包括:申报人及其联系方式(姓名、电话或手机、部门等)、故障或服务地点的地点和联系人、涉及系统(故障发生在哪个系统、所属模块)、事件发生的情况描述(事件标题、紧急程度、类型);事件状态等。
4) 接受和筛选
所有用户发起的事件记录单,服务台负责判断是否在服务的范畴之内。首先通过服务级别协议判断是否受理,如果是服务范围之内,再判断是否是事件,如果是变更或需求问题提醒用户走其他的申请。
l 如果不在受理范围内,则由服务台告知事件申报人并退回;
l 如客户仍需提供超出受理范围的支持服务,则转交项目经理协调和确认是否继续提供服务。
1) 事件分类
在接受和记录事件之后,服务台首先根据“事件分类”,对受理的事件进行分类以便安排合适的支持资源进行处理以及后续的监视和报告。
事件分类:咨询、请求、故障。
2) 事件分级
给事件分配优先级,以保证服务团队对事件必要的重视。服务台在给事件分配优先级是应在服务级别协议的基础上充分听取客户的意见和要求,并就事件的优先级的确定与客户达成一致。分级应基于是事件的紧急程度和影响面。事件分为四级:
l 一级事件(重大事件):现有的网络系统停机,或对最终用户的业务运作有重大影响。
l 二级事件:现有网络系统的操作性能严重降级,或由于网络性能失常严重影响用户业务运作。
l 三级事件:网络的操作性能受损,但大部分业务运作仍可正常工作。
l 四级事件:在产品功能、安装或配置方面需要信息或支援。很显然对用户的业务运作几乎无影响,或根本没有影响。
凡重大影响度的事件,都需要管理升级。如是二级影响度的事件,处理时间
超过4小时,则也需要管理升级。根据重大事件的紧急度与影响度,允许重大事件可以先处理后补单。对于关键用户,相应的事件单及电话咨询需要优先处理。
3) 初步支持
服务台根据用户申告事件的具体信息,判断自身能否在预先确定的时间
范围内解决。如果能够解决,则服务台尝试自行处理;如果不能解决,则要根据事件分类及性质进行派单。
l 如果服务台解决了该事件,将事件状态设置为“已解决”。
l 如果服务台未能解决该事件,则将事件派单一线工程师处理。
4) 管理升级
一线工程师对在初步支持中无法解决的事件,升级为二线支持团队处理,事件单流转到二线支持团队。下表是对事件管理升级的默认定义:
|
0小时 |
30分钟 |
4小时 |
12小时 |
2天 |
重大 |
项目经理 |
管理层 |
|
|
|
二级 |
二线支持团队 |
项目经理 |
管理层 |
|
|
三级 |
一线工程师 |
二线支持团队 |
项目经理 |
管理层 |
|
四级 |
|
一线工程师 |
二线支持团队 |
项目经理 |
管理层 |
1) 服务台
服务台在接单后,与客户确认故障内容及处理时间。
l 服务台首先查看知识库,看以前是否有类似事件发生。
l 如果有类似的事件发生,查看知识库里是否已经有事件或类似事件的解决方案或是应急措施等,如果有就参照这些方案组织实施以解决事件。
l 如果没有发生过类似事件,判断自行无法解决或者在规定时间内无法处理完成,则派单给一线工程师。
2) 一线工程师
l 一线工程师接收到服务台分配的服务单后,首先应第一时间与用户建立联系,并尝试通过电话在线解决用户的问题。若通过电话无法解决用户的问题。则与用户预约上门服务的时间。
l 根据用户与工程师确定的上门服务时间,提前打印好服务单,然后按照预约时间上门服务。
l 上门服务完成后,由工程师填写好服务单的内容,然后交给用户确认并签字。
l 工程师回到公司,将服务单的内容录入到并将纸质存档。
l 如果一线工程师无法解决将问题直接转派到二线支持团队。
3) 二线支持团队
如果事件在二线没有得到解决,二线支持团队可以根据自身判断,与客户协商申请调用厂商技术支持。厂商需要在规定的时间内给予回复。
1) 与客户确认处理结果
服务台与客户联系确认问题是否解决,若确认问题已解决后,则在运维系统中关闭事件单。
2) 添加知识库
二线支持团队在确认服务台关闭事件单后,判断是否需要将解决方案添加至知识库中。
重大事件是指紧急程度较高、影响面较广且影响时间长的事件。
对事件进行初步分级,判断是否为重大事件类型,常见类型有系统中断、宕机等。
活动 |
责任人 |
说明 |
---|---|---|
事件发起 |
服务台 |
当服务台接到客户报障后,初步判断故障影响范围,并必须立即启动重大故障处理流程,通知项目经理。 |
事件判断 |
项目经理 |
项目经理接到服务台通知的重大事件单,判断该事件是否属于重大事件范围之内,向公司请求资源并安排一线工程师去现场处理,跟踪整个事件。 |
事件处理 |
一线工程师 |
当一线服务工程师无法在规定的时间范围内解决事件时,迅速发起二线支持的申请,并将服务单填写完成后、通过“事件升级”功能提交到项目经理。 |
二线支持团队/ 原厂商团队 |
二线支持团队/原厂商支持团队在接到项目经理转来的服务单后,将对事件进行调查论断并尝试解决。若二线团队可以解决该事件,则电话通知项目经理事件已经解决,并将服务单填写好处理情况后转回给项目经理审核。若二线团队无法解决该事件,则向公司管理层汇报进展情况并根据需要争取更多的技术支持和资源,二线支持团队的解决过程作为服务单的一个处理阶段记入服务单中。 |
|
事件审核确认 |
项目经理 |
项目经理对该事件的处理情况进行审核确认后,出具《重大事件处理分析报告》给客户,将服务单交给服务台进行后续处理。 |
事件记录和回访 |
服务台 |
在项目经理审核通过后,由服务台负责将事件解决的情况记录到运维系统中(若二线支持团队没有录入时),并对用户进行回访,以确认服务已经全部完成,并将回访信息记入服务单中,最后关闭服务单。 |
事件及时响应率≥90%、事件及时解决率≥90%
事件及时响应率=及时响应的事件数量/事件总数量*100%
事件及时解决率=及时解决的事件数量/事件总数量*100%
《重大事件处理分析报告》
《技术服务单》