Changes for page 21 信息化中心运维服务ITIL事件管理程序

Last modified by superadmin on 2024/10/30, 21:07

From version < 5.1

edited by superadmin
on 2024/10/30, 21:07

To version < 4.1 >

edited by superadmin
on 2024/10/30, 21:06

Change comment: 上传新附件1730293586680-286.png

Raw
Rendered

Summary

Page properties (3 modified, 0 added, 0 removed)

Details

Page properties

Title

...	...	@@ -1,1 +1,0 @@
1		-21 信息化中心运维服务ITIL事件管理程序

Parent

...	...	@@ -1,1 +1,0 @@
1		-G 参考资料.ITIL实施项目资料.ITIL实施项目流程设计方案集.事件管理.WebHome

Content

@@ -1,645
          +1,0 @@
--= **1. 文档介绍** =
--
--== 1.1 文档简介 ==
--
-- 本文档是信息化中心调度室(以下简称调度室)制定的事件管理流程策略文件。通过制定该流程，可以帮助调度室管理IT运维，有效降低或消除相应突发事件的数量，提高IT系统和服务的质量，使运维部门向业务人员和相关用户提供更优质的IT服务，为用户提供更优质的IT服务，并且可以为有效地实施其他相关ITSM管理流程，如问题管理奠定基础。
--
--
--== 1.2 文档用途 ==
--
--本文档作为事件管理流程的流程文件，读者对象为与事件管理流程相关的所有技术与管理人员。
--
-- 本文档所描述的流程在IT服务管理中有许多作用，举例如下：
--
--* 减小突发事件对业务的影响
--* 最优化支持资源，提高工作效率
--* 屏蔽错误事件和服务请求
--* 根据业务轻重缓急解决事件，保障有效IT运营
--* 加强监控和及时反馈
--* 提升用户满意度
--* 提供管理信息
--
--=   =
--
--=   =
--
--= **2. 概述** =
--
--事件管理流程是为业务尽快恢复正常工作状态而设计，其关心的重点是快速响应、快速恢复，使故障对业务的影响最小化。
--
--事件管理流程受事件触发和驱动，所谓事件，是指发生了非常规的运作情况，包括系统崩溃、软件故障、任何影响用户业务操作和系统正常运作的故障、以及影响业务流程或违背服务水平协议的情况。事件也包括用户的日常服务请求。不是所有的事件都由用户产生，监控管理平台产生的告警也可引发事件。
--
--通常由服务台负责记录事件相关信息，向用户提供对已知错误的处理方法，报告事件和尽快恢复服务，目的是在事件管理阶段获得尽可能高的事件解决率。
--
--事件管理的责任是记录与分类、调查与诊断、解决与恢复、关闭事件、跟踪由事件产生的问题管理流程进度、最终解决事件。
--
--
--== 2.1 流程目的 ==
--
--事件管理流程的主要功能是尽快解决事件恢复业务，保持各个IT业务系统的稳定性，满足事先与业务客户之间所约定的服务级别标准，其目的包括：
--
--* 在成本允许的范围内尽快恢复服务
--
--* 快速响应服务请求（电话/Web/邮件等）
--* 用户在线获得帮助
--* 沟通问题解决的状态
--* 和客户确认事件的解决
--
--* 进行事件控制
--
--* 按规范记录事件
--* 就事件的优先级、紧急性和严重性进行分类
--* 分析，诊断，必要时进行升级
--* 监视并结束事件
--* 进行定期管理流程分析回顾
--
--==   ==
--
--== 2.2 事件策略 ==
--
--=== 2.2.1 事件分类 ===
--
--|**类别**|**子类**|**维护所属**|**备注**
--|(% rowspan="5" %)三网业务系统|家庭宽带|信息站|
--|办公宽带|信息站|
--|家庭电话|信息站|
--|办公电话|信息站|
--|数字电视|数字电视部|
--|(% rowspan="11" %)安全生产类系统|调度电话|基础网络部|
--|安全监测数据联网系统|自动化部|
--|综合自动化系统|自动化部|
--|机房监控系统|自动化部|
--|工业电视系统|自动化部|
--|应急指挥系统|自动化部|
--|综合调度系统|自动化部|
--|综合调度显示系统|自动化部|
--|煤化工能源管理系统|自动化部|
--|煤化工生产联网监测系统|自动化部|
--|安防监控系统|自动化部|
--|(% rowspan="24" %)经营管理类系统|兖矿集团财务公司资金集中管理信息系统|应用系统部|
--|兖矿云考勤系统|应用系统部|
--|呼叫中心系统运维|应用系统部|
--|短信平台系统|应用系统部|
--|电子招投标系统|应用系统部|
--|物资商城系统|应用系统部|
--|MDM主数据系统|应用系统部|
--|SRM系统|应用系统部|
--|ERP系统|应用系统部|
--|合同管理系统|应用系统部|
--|计划生育系统|应用系统部|
--|人力资源管理系统|应用系统部|
--|养老保险系统|应用系统部|
--|国资监管系统|应用系统部|
--|坚果云系统|应用系统部|
--|三网融合系统（综合电信系统）|应用系统部|
--|总医院PACS系统|应用系统部|
--|计划统计系统|应用系统部|
--|经营调度系统|应用系统部|
--|煤炭交易系统|应用系统部|
--|审计系统|应用系统部|
--|OA系统|应用系统部|
--|网站系统|应用系统部|
--|电邮系统|应用系统部|
--|(% rowspan="7" %)其他业务系统|骨干网络|基础网络部|
--|专网系统|基础网络部|
--|运营商专线|基础网络部|
--|公安国安审计系统|基础网络部|
--|视频会议系统|基础网络部|
--|机房基础环境|基础网络部和信息站|
--|云系统|应用系统部|
--
--表2-2-1 事件分类表
--
--
--=== 2.2.2 事件分级 ===
--
--
--|**影响范围**|**定义示例**
--|1级  严重|造成多站点整体通信故障，大面积骨干传输网中断，多个集团级应用系统整体瘫痪，主要通信枢纽节点多点断线等情况之一的故障级别。
--|2级  高|造成个别站点整体通信故障，单个集团级应用系统瘫痪，主要通信枢纽个别节点断线，骨干传输网络个别节点故障等情况之一的故障级别。
--|3级  中|造成个别站点区域内部网络、通信、数字电视系统多点故障，个别被服务单位内部多个应用系统瘫痪等情况之一的故障级别。
--|4级  低|造成个别站点区域内局部网络、通信、数字电视故障，个别被服务单位内部个别系统故障等情况之一的故障级别。
--
--|**紧急程度**|**定义示例**
--|1级  紧急|故障发生突然，需要马上恢复，紧急
--|2级  高|故障发生突然，需要恢复，高
--|3级  中|系统仍可使用或无需马上解决，中
--|4级  低|系统仍可使用或任何时候解决都行，低
--
--
--事件分级结论
--
--|**影响范围**
--**紧急程度**|**1级 严重**|**2级 高**|**3级 中**|**4级 低**
--|**1级 紧急**|紧急（级别1）S1|紧急（级别1）S1|严重（级别2）S2|重大（级别3）S3
--|**2级 高**|紧急（级别1）S1|紧急（级别1）S1|严重（级别2）S2|重大（级别3）S3
--|**3级 中**|严重（级别2）S2|严重（级别2）S2|一般（级别4）S4|一般（级别4）S4
--|**4级 低**|重大（级别3）S3|重大（级别3）S3|一般（级别4）S4|无故障（级别5）S4
--
-- S1为最高级需优先处理，S2为次高级第二处理，S3为严重级第三处理，S4为一般级第四处理，S5为最低级最后处理。
--
--
--
--(% style="text-align:center" %)
--[[image:1730293263926-449.png]]
--
--===   ===
--
--=== 2.2.3 事件解决时间 ===
--
--|**优先级**|**响应时间**|**处理时间**|**事件单关闭**
--|S1|立即|2小时|12小时
--|S2|5分钟|4小时|24小时
--|S3|30分钟|6小时|48小时
--|S4|60分钟|8小时|72小时
--|S5|—|24小时|7*24小时
--
--
--=== 2.2.4 事件升级 ===
--
--* **事件响应升级要求**
--
--|**事件优先级**|**项目负责人**|**部门主管**|**中心分管副主任**|**主任**
--|S1|5分钟|15分钟|30分钟|1小时
--|S2|15分钟|30分钟|1小时|2小时
--|S3|1小时|2小时| |
--|S4|2小时| | |
--|S5|8小时| | |
--
--* **事件上报时间**
--
--|(((
--**故障**
--
--**级别**
--)))|**5分钟内**|**15分钟内**|**30分钟内**|**1小时内**|**3小时内**|**4小时内**|(((
--**通报**
--
--**周期**
--)))
--|1级|项目负责人|部门负责人|分管副主任|主任| | |15分钟
--|2级| |项目负责人|部门负责人|分管副主任|主任| |30分钟
--|3级| | |项目负责人| |部门负责人|分管副主任|1小时
--
--目前只针对1-3级故障进行上报处理。
--
--=   =
--
--=   =
--
--= **3. 流程范围** =
--
--交付中心事件管理范围是对用户的IT生产环境中发生的问题进行管理，并采取主动性预防措施来降低事件数量。
--
--=   =
--
--=   =
--
--= **4. 流程详述** =
--
--== 4.1事件管理的主要流程 ==
--
--
--(% style="text-align:center" %)
--[[image:1730293333450-951.png]]
--
--
--事件管理触发后，由调度员（服务台）担任事件的管理和协调的职责，负责事件的跟踪、协调资源、对违反SLA进行预警、事件升级。
--
--==   ==
--
--== 4.2 事件接听与记录 ==
--
--本阶段描述事件的初始检测。事件可通过电话或电子邮件向服务台人员发出事件请求，也可以由监控管理系统的警报而引发。
--
--所有事件都要进行记录，以便能够在它们的整个生命周期中跟踪、监视和更新它们。然后可将该信息用于问题管理、报告、流程优化和规划。
--
--服务台作为事件单一的联系点，在事件整个生命周期中持续关注其执行情况。
--
--
--|**活动**|**描述**|**责任人**|**输入**|**输出**
--|判断是否事件|(((
--该活动是事件的起源，对客户提交的请求需要优先判断是服务请求范畴，还是事件范畴？若是服务请求，则进入服务请求管理过程。
--
--若是事件，创建事件单。
--)))|服务台|用户的请求|被记录的事件
--|记录事件摘要和详情|(((
--该活动的主要目的是对事件的症状进行记录。
--
--任务1：记录主题摘要
--
--任务2：记录内容及详细描述
--)))|服务台|被记录的事件|新建的事件
--|判断是否重大事件|确认是否重大事件，若是则进入重大事件处理过程|服务台| |重大事件
--|引导客户联系业务维护人员进行沟通|(((
--该活动的主要目的是处理不在SLA范围的事件。
--
--任务1：引导客户联系业务维护人员
--
--任务2：或委婉拒绝客户
--)))|服务台| |已关闭的事件
--
--
--== 4.3 分类与派单 ==
--
--服务台人员对事件进行初步分类并确定事件的优先级。然后指派合适的工程师进行处理，对于自己能够处理的事件也可以分派自己作为事件处理人。
--
--
--|**活动**|**描述**|**责任人**|**输入**|**输出**
--|事件分类|该活动的目的是将事件进行分类，以便分派合适的事件处理人员。|服务台|新建的事件|新建的事件(分类确定)
--|明确优先级|对事件内容进行影响分析，确定影响范围和紧急程度，明确事件优先级|服务台|新建的事件|新建的事件(优先级确定)
--|尝试直接解决|(((
--需要尝试直接解决的情况主要有两种：
--
--1、知识库拥有匹配度很高的解决方案。
--
--2、咨询、查询类的事件
--
--任务1：将事件分派给自己
--)))|服务台|新建的事件|处理中的事件
--|分派事件|将事件分派给相应的工程师进行进一步的处理|服务台|新建的事件|已分派的事件
--
--
--== 4.4 事件调查与分析 ==
--
--一线维护人员受理(响应)事件请求，如有需要对事件进行重新分类，查询知识库，判断是否有文档记载的解决办法可以快速解决事件并关闭。如果没有，需要根据本身的知识技能对事件进行深入调查和诊断，尝试解决和恢复。
--
--|**活动**|**描述**|**责任人**|**输入**|**输出**
--|受理请求|(((
--确认分派给自己的事件单是否隶属自己职责范围之内，时间上是否可以保证。如果有困难和服务台进行沟通，必要时请求转派其他工程师。
--
--任务1：受理事件
--
--任务 2：申请重新分派事件
--)))|一线维护人员|已分派的事件|处理中的事件/已分派的事件
--|调查诊断|(((
--对事件请求进行诊断以提供解决措施。
--
--如果需要备件，和备件库管理员沟通调配。
--)))|一线维护人员|处理中的事件|处理中的事件
--
--==   ==
--
--== 4.5 二线资源调度 ==
--
--一线维护人员在事件处理过程中如果需要分派技术主管或二线专家，需要先要和二线资源管理岗电话沟通（如果本团队有相应资源找交付经理，如果本团队没有资源找服务台），反应当前事件处理情况和对二线资源的需求。由二线资源管理岗协调、最终确定二线工程师的人选和时间安排。一线工程师将事件分派到该二线工程师。
--
--|**活动**|**描述**|**责任人**|**输入**|**输出**
--|调度二线|根据一线提供的需求，调度二线工程师。|二线资源调度岗| |
--|转派事件|(((
--根据二线资源调度岗提供的二线支持人员，进行事件转派。
--
--任务1：转派事件
--)))|一线维护人员|处理中的事件|处理中的事件/已分派的事件
--| | | | |
--
--
--== 4.6 协作与升级二线 ==
--
--处理事件时，需要团队有非常好的协作。比如在处理过程中有重复的事件出现，需要各个工程师的处理步骤和经验共享。而且事件在处理过程中往往需要备件、供应商、二线的配合，共同完成。
--
--如果在协调过程中超出工程师沟通范围，可以请求项目经理、交付经理介入，进行协调调度。
--
--
--|**活动**|**描述**|**责任人**|**输入**|**输出**
--|添加任务|(((
--如需要协调配合，将事件分解成多个任务，分别指派个合适的工程师分步解决。
--
--输入任务摘要(标题)，选定该任务的执行人，填写任务的具体内容，设定该任务必须完成的时间并提交。
--
--任务1：新建并分派任务
--)))|一线工程师/二线工程师/二线专家|处理中的事件|处理中的事件（已分派的任务）
--|执行任务|(((
--如果工程师收到分派的任务， 填写任务执行结果。
--
--任务1：完成任务
--)))|一线工程师/二线工程师/二线专家|已分派的任务|已完成的任务
--|受理请求|(((
--二线工程师接受分派的事件，针对事件内容和一线工程师进行沟通。
--
--任务1：受理事件
--)))|一线工程师/二线工程师/二线专家|已分派的事件|处理中的事件
--|调查诊断|根据自己的经验技能对事件进行调查诊断。如果需要备件，和备件库管理员沟通调配。|一线工程师/二线工程师/二线专家|处理中的事件|处理中的事件
--| | | | |
--
--
--
--== 4.7 事件解决与恢复服务 ==
--
--工程师解决事件并恢复服务，记录解决的时间。需要详细记录解决执行的操作步骤或变通方法；实施完毕后对解决进行确认。
--
--|**活动**|**描述**|**责任人**|**输入**|**输出**
--|恢复服务|采用解决方案或者变通方案恢复服务，详细记录操作步骤，录入解决方案。|一线工程师/二线工程师/二线专家|处理中的事件|已解决的事件
--|创建知识库|(((
--如果是采用解决方案解决的事件，对解决方案进行梳理，如果认为可以提供参考，提交解决方案到知识库。
--
--任务1：创建知识（可选）
--)))|一线工程师/二线工程师/二线专家|已解决的事件|已解决的事件（新建的知识）
--|创建问题|(((
--如果采用变通方案恢复的服务，而故障真正原因并没有解决，需要创建问题单，继续后续处理。
--
--任务1：创建问题
--)))|一线工程师/二线工程师/二线专家|已解决的事件|已解决的事件（新建的问题）
--| | | | |
--
--==   ==
--
--== 4.8 满意度调查后关闭事件 ==
--
-- 对于已解决的事件，在和用户确认成功解决后，才可以关闭事件。同时对客户进行满意度调查，记录用户对这次服务的评价，记录客户需求与意见。为后续事件管理流程优化改进积累建议。
--
--|**活动**|**描述**|**责任人**|**输入**|**输出**
--|确认事件解决|(((
--与工程师沟通确认故障现象是否消除，是否恢复使用。如果成功消除，则说明事件解决完毕。进入下一步，满意度调查。
--
--如果故障现象未消除，则说事件未能解决，如果工程师已结束任务，需要回退给工程师重新解决。
--
--任务1：退回事件到处理中环节
--)))|服务台|已解决的事件|已解决的事件/处理中的事件
--|满意度调查|服务台在和用户沟通确认事件是否解决之后，针对本事件的处理工程师，请求用户给予评价，记录下用户的意见。|内部考核部|已解决的事件|已解决的事件（记录满意度调查结果）
--|关闭事件|对事件进行关闭。|服务台|已解决的事件|已关闭的事件
--| | | | |
--
--
--== 4.9 事件的超时与监控 ==
--
--  在事件处理过程中，由项目负责人、服务台负责对整体事件流程的超时、监控。及时和二线资源管理岗沟通，及时向领导层汇报。监控整个事件处理过程。
--
--==   ==
--
--== 4.10 重大事件 ==
--
--
--重大事件过程——存在重大事件过程是为了处理那些需要超出常规事件过程所提供的响应的严重事件。虽然这些事件仍然遵循常规事件生命周期，但是重大事件过程的触发提供了这些高优先级的事件所需要的增强的协调、上报、沟通和资源。
--
--重大事件的处理要求是：集中相关资源，优先处恢复服务，事后补单。
--
--===   ===
--
--=== 4.10.1 重大事件处理流程 ===
--
--(% style="text-align:center" %)
--[[image:1730293469519-422.png]]
--
--===   ===
--
--=== 4.10.2 重大事件的定义 ===
--
--重大事件过程在如下情况下提供附加的跨部门协调、资源、管理参与和沟通：即这些情况下的事件影响或潜在影响使得超出常规事件管理流程所提供的响应变得必要。事件管理过程中，优先级最高的事件被视为重大事件。
--
--一旦确定某个事件是重大事件，事件经理应该立即通知涉及的所有各方：问题管理、可用性管理、服务级别管理、服务连续性管理、IT 管理、受影响的业务负责人以及中心领导值班人。
--
--**~ **
--
--=== 4.10.3 重大事件处理小组组长 ===
--
--重大事件处理小组组长负责在重大事件期间协调计划、资源和沟通。这是个临时性的职位，通常由分管副主任或者项目负责人担任。
--
--扮演重大事件处理小组组长角色的职员需要满足下列条件：
--
--* 能够处理重大事件期间产生的压力。
--* 有权作出决定的副主任以上级别。
--* 优秀的沟通者，能够与组织中的所有层次的技术 IT 职员、业务代表和客户交谈。
--* 深入了解中心（包括信息化中心如何运作以及相关负责人）的公认人物。
--* 准备加班工作，经常是随叫随到。
--* 准备到现场并在需要时拜访客户现场，同样是随叫随到。
--
--
--=== 4.10.4 重大事件处理小组 ===
--
--处理小组组长，应该收集到目前为止可用的所有信息，并确认当前状况并负责组建处理小组。
--
--调查和解决重大事件所涉及的技术团队称为“处理小组”。该小组通常包含一个或多个技术人员，由同时经过技能培训和问题解决技术培训的资深职员组成。这个核心小组应该接受使用中的所有关键战略技术的培训，当时如果特定事件要求不同的技能，可以由其他支持人员提供补充。资深支持人员应该在临时分配的基础上在整个核心小组中轮流。
--
--===   ===
--
--=== 4.10.5 重大事件恢复与沟通 ===
--
--处理小组组长应该主持一次与处理小组、已经参与处理事件的任何团队成员、受影响的经理和其他任何相关技术专家进行的初始计划会议。该会议的目标应该是同时就恢复计划和沟通计划达成一致。
--
--处理小组组长应该与包含 IT 经理、受影响的业务经理和合作伙伴以及客户管理的管理小组一起定期复查进度。管理小组会议的目的应该是向所有各方通气，讨论进度，并在需要时提供管理升级上报。
--
--管理小组和处理小组审查会议通常应该保持独立，以便每个小组集中于与他们的角色相关的问题。处理小组应该讨论技术问题，然后为管理小组提供进度报告，后者然后可以集中于资源、上报和沟通问题。
--
--在重大事件期间，沟通的处理本身经常变得非常困难。沟通计划的目标应该是在事件生命周期中提供所有沟通的协调。
--
--===   ===
--
--=== 4.10.6 重大事件的终结 ===
--
--随着重大事件的推进，处理小组组长应该确保定位、分配和协调任何附加资源要求。
--
--重大事件过程应该继续伴随常规事件管理流程，直至重大事件终结。在事件的最后阶段，当已经采取解决操作时，解除处理小组的部分任务也许是可能的，不过要了解到如果解决方案被证明不成功，他们将被重新召集。
--
--在重大事件终结时，将处理过程记录、方案补录入系统。
--
--重大事件终结之后，处理小组组长需要对事件的发生、处理过程、结果，进行回顾总结经验。作为汇报依据和经验积累。
--
--=   =
--
--=   =
--
--= **5. 人员和角色** =
--
--流程的实现是通过不同的流程角色及其被赋予的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责，同时也可以将其职责授权给其管理结构之下的人员。事件管理流程主要分为以下几个职责/角色，分别简述如下：
--
--==   ==
--
--== 5.1 事件管理流程负责人 ==
--
--事件流程负责人从宏观上监控流程，确保事件流程被正确的执行。当流程不能够适应实际运维情况时，流程负责人必须及时的对此进行分析，找出缺陷，进行改进，从而实现可持续提高。
--
--职责:
--
--1. 确定管理流程的衡量指标
--1. 确保事件流程能够取得管理层的参与和支持
--1. 确保事件流程符合公司实际状况和公司 IT发展战略
--1. 总体上管理和监控流程，建立事件流程实施、评估和持续优化机制
--1. 确保事件流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时的对此进行分析、找出缺陷、进行改进（例如增加或合并流程的角色），从而实现可持续提高
--1. 保持与其他流程负责人的定期沟通
--
--==   ==
--
--== 5.2 部门受理人 ==
--
--部门受理人负责事件解决过程中的协调和监控，以及故障升级的判断、升级过程中的具体执行和协调。
--
--职责：
--
--1. 检查事件记录的处理进度，保持与事件报告人的联系
--1. 将事件分派给最合适的工程师来处理
--1. 负责对事件的解决协调资源，保证故障的最终排除；
--1. 当事件优先级为紧急且需要协调处理时，负责按照紧急事件处理方法对事件进行处理，确保有效协调资源，促进支持工程师快速恢复正常服务
--1. 审核事件处理流程的合理性
--1. 确保和问题管理流程经理的有效合作
--1. 确保正确和广泛地收集和分析事件数据，为问题管理提供来源
--
--==   ==
--
--== 5.3 服务台人员 ==
--
--服务台人员负责接收所有的事件，对事件进行初步的记录，并根据实际情况将事件分派到合适的工程师。
--
--职责：
--
--1. 在指定的响应时间内响应所有服务台热线电话、邮件、传真、告警信息等事件报告
--1. 完整记录所有接收的事件信息，包括：记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等
--1. 为事件进行适当的分类
--1. 审核事件记录信息的完整和正确性
--1. 负责7×24的电话支持和系统监控
--
--==   ==
--
--== 5.4 一线、二线资源 ==
--
--工程师负责提供对服务台人员无法解决的事件进一步进行调研，找出解决方案并尽快恢复服务。
--
--一线工程师负责处理事件，如果是设备损坏需要更换设备的，使用备件库资源，进行更换。
--
--二线资源含二线工程师及二线专家。二线工程师的技术能力一般要强于一线工程师，平时大部分也参与项目中，事件一般由一线工程师处理，有难度或者处理不了的升级到二线工程师处理。二线专家是公司在某技术方向的专家，一般不参与项目的具体工作，当二线工程师不能解决时或该方向没有二线工程师才会参与到事件的解决中。
--
--职责:
--
--1. 验证事件的描述和信息，进一步收集相关信息
--1. 对于事件信息不正确和不完整的工单，可以和服务台沟通后进行补充。
--1. 根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动。
--1. 对于需要由供应商进行解决的事件，联系供应商参与事件处理。
--1. 根据优先级提供有效的解决方案。
--1. 实施事件解决方案。
--1. 更新事件解决信息，已解决的事件转回服务台，由服务台关闭事件。
--1. 更新事件记录，确保事件状态代码真实反映事件状态。
--1. 当事件优先级为需要协调处理时，提请事件经理根据协调处理。
--1. 进行事件的深入调查研究。
--1. 对于分派不正确的事件，转回服务台重新分派。
--
--==   ==
--
--== 5.5 部门负责人 ==
--
--二线资源管理岗对二线资源的调度负责。二线工程师对应资源调度岗为交付经理，二线专家资源调度岗为服务台。
--
--职责:
--
--1. 接受来自服务台或者二线的事件请求
--1. 进行事件的深入调查研究
--1. 根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动
--1. 提供事件根源和最终解决方案
--
--
--== 5.6 厂商 ==
--
--厂商支持人员是相关领域的专家，负责提供对二线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。
--
--职责:
--
--=   =
--
--=   =
--
--= **6. 与其他流程的关系** =
--
--
--(% style="text-align:center" %)
--[[image:1730293586680-286.png]]
--
--**服务台**
--
--服务台充当许多 IT 流程的初始入口，包括事件管理流程。对于许多其他 IT 流程，服务台只是向它们传递请求；但是对于事件管理流程，服务台和事件管理流程之间的联系要紧密得多。
--
--服务台充当业务和 IT 之间的接口，在此处是充当业务和事件管理流程之间的接口。
--
--服务台值班员负责事件管理流程的日常协调。服务台执行记录、分类和事件管理的初始支持阶段。然后，当事件分配到问题解决小组时，服务台通过监视和跟踪所有事件保留所有权职责。
--
--如果服务台运作成功，则许多服务请求和事件可以得到处理和解决而无需越过服务台功能之外。
--
--就事件管理流程的客户满意度而言，服务台是一个关键组件。
--
--**问题管理**
--
--事件与问题管理关系密切，但是在支持组织内，各自的侧重点却大相径庭。
--
--事件管理关注尽可能快地还原常规服务，而问题管理却侧重于识别并解决基础问题及其根本原因。
--
--事件管理为问题管理提供识别根本问题的存在性所需要的许多信息。问题管理会分析事件统计数字，从而识别所发生的多个事件或特定类型的事件的增长趋势。
--
--相应地，问题管理寻求解决这些事件的根本原因以防止它们再次发生。
--
--问题管理还会维护有关现有问题和已知错误的信息，包括已知的应对方案和解决办法。事件管理利用该信息提供更快的事件解决。
--
--问题管理还负责在主要事件得到解决后，对其进行审查。在这些审查期间，目标是识别根本原因根源以便防止任何事件重现，识别可用于对任何事件重现给出提前警告的触发因素，以及识别事件的解决质量以便改进今后的反应。
--
--**变更管理**
--
--当事件管理识别出需要配置项变更的解决操作时，这些变更将在变更管理流程的控制下进行部署。
--
--变更管理流程提供的控制可减少所需撤销的更变数量，并能确保在需要时，记录有关的撤销计划。协调的变更测试减少了由变更部署导致的后续事件的机会。
--
--变更管理还为事件管理提供关于最近的变更、受影响的配置项和变更原因的有用信息。
--
--**配置管理**
--
--配置管理提供在整个事件管理流程中使用的至关重要的信息。配置管理数据库 (CMDB) 包含可用于以下用途的信息：
--
--* 提供和检查请求者详细信息。
--* 提供关于配置项 (CI) 的信息。
--* 通过指示受特定 CI 的故障影响的服务和 SLA 协助事件分类。
--* 识别 CI 间的关系和依赖性。
--* 识别完全相同或相似的 CI 以用于比较目的。
--* 识别其它途径及应对方案。
--* 记录由于 RFC 导致的配置项变更。
--
--**发布管理**
--
--事件管理识别出的有些解决操作要求需要作为发布进行整合和实施的变更。这些发布由发布管理流程协调和管理。
--
--与变更管理类似，发布管理提供有效的计划、测试和协调，确保这些发布能够在产生最少事件的情况下实施。
--
--**服务级别管理**
--
--服务级别管理为事件管理提供正确分类型事件所需要的至关重要的信息。关于业务关键性和服务级别指标的信息允许事件管理流程设置事件优先级，并准确定位最需要的支持资源。
--
--事件管理为服务级别管理提供关于服务指标违背的信息。
--
--
--
--= **7. 衡量指标** =
--
--为了较好地控制事件管理流程的质量，必须为事件管理流程设置考核指标，通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。
--
--事件管理流程的关键衡量指标如下：
--
--|**编号**|**衡量指标**|**计算方法描述**
--|1|事件总数|当前事件的总数，用于了解系统中记录的事件数量。
--|2|重大事件数量/比率|重大事件数量以及占事件总数的比例，用于了解重大事件的发生率。
--|3|事件成功关闭的比率|以解决方案或者变通解决办法成功关闭的事件数量，以及占总数量的比率，用于了解事件成功处理情况。
--|4|超时响应的事件数量/比率|超过ＳＬＡ指定的时间要求的事件数量，以及占总数量的比率，用于衡量事件的管控能力。
--|5|平均解决时间|服务团队解决事件的平均时间，用于衡量对事件的处理能力。
--|6|服务台解决率|服务台解决事件的比例，用于衡量服务台的处理能力。
--|7|一线解决率|一线工程师解决事件的比例，用于衡量一线工程师的处理能力。
--|8|二线解决率|二线工程师及专家解决事件的比例，用于衡量二线的处理能力。
--|9|厂商解决率|厂商解决事件的比例，用于衡量厂商的处理能力。
--
--=   =
--
--=   =
--
--= **8. 流程持续改进** =
--
--每个流程的改进计划由流程经理初步整理后，与各交付经理沟通协商，了解个交付经理的的新需求。运用运维工具，提高事件处理的解决率，加强工具的投入，提高事件的平均解决时间，将报告汇总到服务改进计划中。
--
--
--
--= **9. 相关文件和记录** =
--
--TSD10 《运维服务问题管理程序》
--
--TSD06 《运维服务配置管理程序》
--
--TSD08 《运维服务发布管理程序》
--
--TSD12 《运维服务变更管理程序》
--
--《项目服务总结报告》
--
--
--

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司