由 superadmin 于 2024/10/29, 16:47 最后修改
Show last authors
1 = **1. 文档介绍** =
2
3 == **1.1 编写目的** ==
4
5 本文档编写的目的是有效地解决XX铁道总公司运营总部通号中心IT运维服务部（以下简称“IT运维服务部”）在IT环境下的突发事件，提高IT系统运行的稳定性和服务的质量，为业务的快速发展提供更优质的IT服务，并且可以有效地帮助实施其他相关服务管理流程，如问题管理、变更管理等流程。
6
7 通过本文档的定义，将建立一个完整的事件管理系统，从而实现：
8
9 1. 快速恢复服务
10 1. 确保每个事件和服务请求都得到完满的处理
11 1. 减小突发事件对业务的影响
12 1. 最优化支持资源，提高工作效率
13 1. 根据业务轻重缓急解决事件，保障有效IT运营
14 1. 加强有效监控和及时反馈
15 1. 提升用户满意度
16 1. 提供管理信息
17
18 == ==
19
20 == **1.2 适用范围** ==
21
22 本流程适用于IT运维服务部的IT运维团队。本文档所规定的IT服务是指IT运维服务部的IT运维团队所提供的运维服务。
23
24 管理范围指的是IT运维服务部的IT运维团队的所辖范围内的运维，受理范围为辖内的客服上报的事件请求与主动监控事件。具体说明如下：
25
26 1. IT人员监测或检查到事件（如：值班人员主动监控发现的故障）
27 1. 客服报告的事件（如：用户上报给客服的事件，再由客服转为IT运维团队的事件）
28
29 = =
30
31 = =
32
33 = **2. 术语、定义和缩略语** =
34
35 |(% style="width:82px" %)**术 语**|(% style="width:123px" %)**缩略词**|(% style="width:1132px" %)**定 义**
36 |(% style="width:82px" %)事件|(% style="width:123px" %)Incident|(% style="width:1132px" %)任何不符合标准操作且引起或可能引起服务中断和服务质量下降的事件。
37 |(% style="width:82px" %)事件管理|(% style="width:123px" %)(((
38 IM
39
40 (Incident Management)
41 )))|(% style="width:1132px" %)事件管理流程的目的是尽快解决事件与恢复服务。事件记录的信息决定了其它许多流程的效率。
42 |(% style="width:82px" %)重大事件|(% style="width:123px" %) |(% style="width:1132px" %)影响等级为一级的事件为重大事件。
43 |(% style="width:82px" %)影响等级|(% style="width:123px" %) |(% style="width:1132px" %)表明事件对服务所产生的业务影响，它是事件的处理优先级的一个重要影响因素。
44 |(% style="width:82px" %)临时措施|(% style="width:123px" %)Workarounds|(% style="width:1132px" %)临时措施是解决事件的临时修复方法或技术，目的是使用替代措施暂时消除客户对服务的依赖和减少事件对客户的影响，该事件的永久解决措施有赖于对该事件潜在问题的最终解决。通过临时措施，客户能够在没有中断的情况下继续使用服务。临时措施通常会使用户的工作方式发生变化，比如从使用另一台PC、使用早期版本的软件、或临时提供更多的磁盘空间。
45
46
47
48 = **3. 内容** =
49
50 == **3.1 流程介绍** ==
51
52 === **3.1.1 流程解释** ===
53
54 事件管理流程设立的主要功能是尽快解决IT环境下的生产/运行中出现的事件，确保IT环境的稳定性。通过对事件进行登记、分类、分级、状态跟踪、关闭确认等手段建立一个事件管理流程的闭环，从而对事件的处理过程进行监控和优化，在成本允许的范围内尽快恢复服务，提高客户满意度。
55
56 事件管理流程还提供一个日常接口，提供关于服务状态的信息更新，定期对事件信息进行统计和分析，了解事件的分布和发展趋势，努力降低事件响应时间和解决时间，提供优质无间断的IT服务。
57
58 === ===
59
60 === **3.1.2 业务价值** ===
61
62 1. 用户业务尽快恢复
63 1. 内部团队协作加强
64 1. 服务质量控制和改进
65 1. 减少与避免故障对业务所造成的影响
66 1. 提高响应、团队、沟通和资源管理效率
67 1. 加强对供应商的管理
68 1. 集中精力管理关键业务信息
69
70 === ===
71
72 === **3.1.3 流程机制** ===
73
74 1. 在IT运维服务部的实际生产与运行环境中，所有发生的事件都会通过事件管理流程来进行处理，将通过流程中定义的标准、原则和机制进行管理。
75 1. 所有报告事件的部门/用户将会参与统一的事件管理管理流程，不应该有任何例外。
76 1. 所有支持人员对优先级1和2的事件所采取的恢复服务的行动，相比其他任务具有优先权。
77 1. 应该定期（每月）产生和回顾事件管理报表。对没有解决的问题，应该举行定期的问题管理会议，对这些问题进行评估。
78 1. 应该定期（每半年）对流程进行回顾，以改进事件管理流程。
79
80 ==== ====
81
82 ==== **3.1.3.1 责任人机制** ====
83
84 对事件进行有效管理的一个重要因素是定义责任人机制，以确保每个事件在任何时段都有适当的人员负责。
85
86 1. 当一个事件被创建后，事件记录员负责记录与跟踪此事件单。
87 1. 事件单被分派/转派后，事件受理员 (2/3线)负责接收此事件单，但是分派方（做出分派的事件记录员或是做出转派的事件受理员）有责任通知被分派的事件受理员并要求他接受或是拒绝此事件单。
88 1. 事件单被分派/转派后，事件受理员（2/3线）接收此事件单后，即成为此事件单的当前责任人，但事件记录员仍是此事件的整体负责人，有义务对事件的处理状态进行跟踪和推动，并及时向用户反馈事件处理进展。
89 1. 采用首问负责制，由事件的首要受理人或者创建人负责客户可能的查询。
90
91 ==== ====
92
93 ==== **3.1.3.2  分派机制** ====
94
95 事件分派原则是确保事件在服务目标时段内处理和解决的重要因素。
96
97 1. 服务台一线支持人员在规定的一线处理时限内，可按情况选择转给其他在值服务台一线支持人员进行处理。
98 1. 服务台一线支持人员在规定的一线处理时限内不能解决事件时，原则上根据事件分类分派到相应二线支持人员。
99 1. 支持人员如判断事件需要第三方支持，原则上不在系统中进行事件单的分派，事件单仍保持在相应的一线或二线支持人员处。第三方处理完毕后，由相应一线或二线支持人员负责更新事件单状态、解决方案等相关信息。
100
101 ==== ====
102
103 ==== **3.1.3.3 再分派机制** ====
104
105 再分派又称转派，指第一次分派后被分派对象，将事件单分派给其他部门或个人。
106
107 再分派机制是另一项关键的原则，它确保事件单不被过于频繁的相互转派，以至于无法在规定时间内得到解决。
108
109 1. 同组的事件单再分派不被监控；
110 1. 任何跨组的事件单再分派将会报告给事件经理；
111 1. 事件再分派超过2次，事件单将升级给事件经理；
112
113 ==== ====
114
115 ==== **3.1.3.4  优先级划分** ====
116
117 事件的优先级表明了该事件或问题对运维对象（游戏产品）的业务影响。它是评定事件处理优先等级的一个重要指标。所有事件都将分配到三个优先级中的一个。优先级从 1 (优先级最高) 到 3 (优先级最低) 。优先级的划分一般情况下，是由事件的“影响度”和“紧急度”共同决定。
118
119 影响度是指受影响业务系统的关键程度，通常根据受影响的客户数量，可能造成的业务损失程度，或是业务系统的重要程度来决定。紧急度是指解决事件所需要的速度。需要指出的是：一个高影响度的事件并不一定非常紧急，反之亦然。
120
121 除此之外，还可以参考下列因素中的一个或几个可以用来定义优先级：
122
123 1. 服务中断的时间和范围
124 1. 受影响的服务
125 1. 发生的次数
126 1. 问题没有解决的时间的长短
127
128 优先级在事件的生命周期中是可以改变的。关于更改事件单优先级的原因和行为应该在事件单中记录。根据IT运维服务部的业务实际情况，综合考虑影响度、紧急度等多方面因素，得出事件的优先级定义如下表所示：
129
130 说明：优先级为1的事件为重大事件。 优先级1、2、3分别对应重度、中度与轻度的故障等级定义；
131
132 |**优先级**|**定 义**
133 |**1**|会使在线业务系统立即停止服务的故障，或影响在线业务系统的服务，但不会使服务直接停止的故障
134 |**2**|会使后台支持系统立即停止服务的故障
135 |**3**|会影响后台支持系统的服务，但不会使服务直接停止的故障
136
137 ==== ====
138
139 ==== **3.1.3.5 目标解决时间机制** ====
140
141 为了更好的控制事件的解决，整个流程被分解成几个组成部分。每个流程的阶段都设定了目标时间。事件管理的目标时间如下表所示：
142
143
144 |**事件目标时间**|(((
145 **一线响应时间**
146
147 [创建-分派]（含初步支持）
148 )))|(((
149 **事件被分派并得到接受**
150
151 [分派-分派被接收]
152 )))|(((
153 **事件得到解决时间**
154
155 [接受分派-解决]
156 )))
157 |优先级1|5~-~-10分钟|10~-~-15分钟|30分钟
158 |优先级2|10~-~-15分钟|30分钟|1小时
159 |优先级3|15分钟|30分钟|2小时
160
161 所有超出目标时间的事件单将体现在每周、每月的统计报表中。同时，事件经理将得到通知。
162
163 详细的事件目标解决时间可参考附件《4.3事件分类表》
164
165 ==== ====
166
167 ==== **3.1.3.6  升级机制** ====
168
169 升级机制的目的是，对于不同优先级的事件，确保分配到合适的资源来解决。为了达到这个目的，定义了升级机制的时间框架。当达到下列时间时，如果事件还未解决，将触发升级机制。
170
171 从事件单被创建之后所经过的时间作为触发事件升级的标准。
172
173 |**事件升级机制**|(((
174 **项目经理**
175
176 **/开发项目负责人**
177 )))|(((
178 **维护工程师**
179
180 **/开发工程师**
181 )))|**维护经理 **
182 |优先级1|10分钟|15分钟|30分钟
183 |优先级2|5分钟 |10分钟 |30分钟
184 |优先级3|10分钟 |15分钟 |1小时
185
186 ==== ====
187
188 ==== **3.1.3.7 通知机制** ====
189
190 通知机制的目的是将影响到服务可用性的事件的有关信息及时通知给关键的IT人员和用户。通知将告知相关的IT员工和IT管理者，通知相关信息如下：
191
192 **通知方式：**
193
194 * 事件发生时，告知事件导致了服务的中断（描述受影响的服务以及预计恢复时间）
195 * 受影响服务恢复时，告知服务已恢复，回到可用状态
196 * 优先级1的将通过电话+email方式通知；
197 * 优先级2和3的将通过email方式通知
198
199 **标准通知内容：**
200
201 * 事件的简要描述
202 * 受到影响的服务
203 * 预计恢复服务的时间（尽可能准确）
204 * 联系服务台咨询以获取更多信息的方法
205
206 具体的事件通知机制如下：
207
208 |**事件通知机制**|**项目经理**|**维护经理**|**产品经理**|**副总监**
209 |优先级1|5-10分钟|15-20分钟|20-30分钟|30-60分钟
210 |优先级2|10分钟|15分钟|30分钟|60分钟
211 |优先级3|15分钟|30分钟|60分钟|90分钟
212
213
214 具体的事件通知矩阵如下：
215
216 |**状态** |用户|事件记录员|(((
217 事件受理员
218
219 （二线）
220 )))|(((
221 事件受理员
222
223 （三/N线）
224 )))|事件经理|事件负责人
225 |待处理|√ | √ | | | |
226 |已分派| | | √ | √ | |
227 |受理中| |√| |* （职能升级） | *（结构升级） |
228 |挂起| |√ | | | |
229 |已解决|√|√| | | |
230 |关闭|√| | | | |
231
232 注：“*”表示选择性通知
233
234 ==== ====
235
236 ==== **3.1.3.8 重复机制** ====
237
238 重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控系统上报的同一个配置项上现象相同的事件或一人/多人申告的同一来源（系统、应用）现象相同的事件。当被报告的事件与某个已经创建且尚未解决的事件单相同时，则该事件被认为是重复的。
239
240 由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，应创建新的事件单，复制原有事件单内容，并标识为“重复”的事件，原始事件将被标注为“主事件”。在原有事件单得到解决时，所有的重复事件单也同时获得解决。
241
242 ==== ====
243
244 ==== **3.1.3.9  复发机制** ====
245
246 如果报告的事件与已经关闭的事件相同，该事件被认为是“复发”的事件单。这意味着为了解决事件而采取的解决措施失败了。此时应当创建一个新的事件单，复制原始事件单的内容，并说明这是复发的事件。
247
248 ==== ====
249
250 ==== **3.1.3.10 事件关闭机制** ====
251
252 事件被解决后，需要对此事件进行关闭操作。事件单的关闭应当符合以下原则：
253
254 1. 事件单的关闭必须由一线支持（值班组工程师）负责完成，但是事件经理可以超越此规则（即事件经理可以干预事件处理并关闭事件单）。其他人无权关闭事件单。
255 1. 事件关闭后，需由值班组组长负责对此事件的记录内容进行核实。
256 1. 事件单的用户可以要求关闭此事件单，例如：误报、错报事件。但具体关闭动作应由对应的一线支持人员负责。
257
258 ==== ====
259
260 ==== **3.1.3.11 流程关联机制** ====
261
262 (% style="text-align:center" %)
263 [[image:1730191078944-131.png]]
264
265
266 **和问题管理的关联**
267
268 * 一线支持在解决事件的过程中，可以通过问题记录查找相应的解决方案
269 * 通过分析事件记录，形成问题，并使该问题与相关事件建立关联
270 * 通过事件单和问题单的关联，服务台人员对问题的解决状况进行跟踪并和用户保持沟通
271 * 对重大事件或者“成功但有问题”关闭的事件，由问题管理流程生成问题进行进一步分析，直到确定根本原因，得到根本解决。事件单和问题应建立关联。
272
273 **和变更发布管理的关联**
274
275 * 事件处理过程中，如果需要变更，必须按照变更管理的定义，提交变更请求（变更单必须和事件单建立关联），变更完成后，继续事件的处理。
276
277 **和配置管理的关联**
278
279 * 事件处理过程中，可以通过配置管理查询相关的配置项信息（尤其是关系信息）以及该配置项历史上发生的事件、问题或变更，来帮助故障的定位
280 * 事件处理过程中，如果可以将故障定位到某个配置项，则必须将事件单与该配置项关联
281
282 **和服务级别管理的关联**
283
284 * 事件处理过程中，依照用户签订的SLA及相应服务级别对事件进行诊断和恢复。
285 * 事件记录为服务级别管理中各项服务是否违背SLA中相关定义提供数据支持。
286
287 === ===
288
289 === **3.1.4 事件单代码设计** ===
290
291 ==== **3.1.4.1  事件单信息项** ====
292
293 事件单必须包含如下信息项，可以在此基础上扩充：
294
295 |序号|(% style="width:156px" %)信息项|(% style="width:1147px" %)说明
296 |1|(% style="width:156px" %)事件ID|(% style="width:1147px" %)系统为此事件生成的唯一 ID。
297 |2|(% style="width:156px" %)状态|(% style="width:1147px" %)(((
298 显示突发事件的状态。
299
300 建议以下预置状态：
301
302 • 打开 — 此突发事件已经打开，但目前没有得到处理。
303
304 • 关闭 — 此突发事件已得到解决，并且得到了客户的同意。
305
306 • 已解决 — 有一个解决方案，但未经客户验证。
307
308 • 正在处理 — 正在处理此突发事件。
309
310 • 待定变更 — 已打开一个相关紧急变更，正在等待关闭该变更。
311
312 • 暂停 — 客户同意将此突发事件暂停一段时间；记录单将不会在该时段出现在待办队列中。
313 )))
314 |3|(% style="width:156px" %)联系人|(% style="width:1147px" %)联系人不一定是服务接收人。此字段可以确保合适的人员将会得到有关交互更新的通知。
315 |4|(% style="width:156px" %)代理人|(% style="width:1147px" %)指定处理此突发事件的人员的姓名。此人是所分配的支持组的成员。代理人可以属于一个或多个分配组。
316 |5|(% style="width:156px" %)分配组|(% style="width:1147px" %)指定处理此突发事件的支持组
317 |6|(% style="width:156px" %)受影响的服务|(% style="width:1147px" %)该服务受此突发事件影响。此字段由交互记录中的数据填充。
318 |7|(% style="width:156px" %)受影响的配置项|(% style="width:1147px" %)对服务产生负面影响的配置项 (CI)。此字段由交互记录中的数据填充。
319 |8|(% style="width:156px" %)配置项可操作（服务不会中断）|(% style="width:1147px" %)如果已选择（设置为 true） ，则表示配置项当前正在操作中，而且服务不会中断。默认情况下，打开一个针对配置项的突发事件时，该配置项标记为出现故障。如果该配置项仍然正常工作，则应该标记此字段。
320 |9|(% style="width:156px" %)事件来源|(% style="width:1147px" %)参见“事件来源”定义
321 |10|(% style="width:156px" %)服务中断开始时间|(% style="width:1147px" %)(((
322 服务中断开始的日期和时间。服务中断的开始和结束时间用于衡量“服务级别协议” (SLA) 的可用性。如果配置项标记为出现故障，则可用性 SLA 将不再支持该配置项。可用性值默认为打开和关闭突发事件的时间，但打开或关闭突发事件之前可能会经历几分钟或几小时，因此，需要变更该值，以报告实际的服务中断开始和结束的时间。例如，设备可能在夜间出现了故障，而且必有人报告该问题
323
324 之后，突发事件才会打开。在此情况下，默认的打开时间不能准确反映服务中断时间。
325 )))
326 |11|(% style="width:156px" %)服务中断结束时间|(% style="width:1147px" %)服务中断结束的日期和时间。服务中断的开始和结束时间用于衡量 SLA 的可用性。如果配置项标记为出现故障，则可用性 SLA 将不再支持该配置项。可用性值默认为打开和关闭突发事件的时间，但需要变更该值以报告实际的服务中断结束时间。例如，重新启动配置项之后，可以对其进行操作，但可能要花数分钟或数小时，才能更新记录，以报告突发事件已关闭。在此情况下，默认的关闭时间不能准确反映实际的服务中断时间。
327 |12|(% style="width:156px" %)位置|(% style="width:1147px" %)报告突发事件的位置。此字段由已升级交互中的数据预先填充。此字段仅供参考。
328 |13|(% style="width:156px" %)标题|(% style="width:1147px" %)(((
329 概述突发事件的简短描述。此字段由已升级交互中的数据预先填充。
330
331 此为必填字段。
332 )))
333 |14|(% style="width:156px" %)描述|(% style="width:1147px" %)(((
334 突发事件的详细描述。此字段由已升级交互中的数据预先填充。
335
336 此为必填字段。
337 )))
338 |15|(% style="width:156px" %)类别|(% style="width:1147px" %)描述突发事件类型，由已升级交互中的数据预先填充。
339 |16|(% style="width:156px" %)区域|(% style="width:1147px" %)此字段由已升级交互中的数据预先填充。对此区域的选择取决于类别。
340 |17|(% style="width:156px" %)子区域|(% style="width:1147px" %)第三级交互分类，主要用于进行报告。此字段由已升级交互中的数据预先填充。
341 |18|(% style="width:156px" %)影响度|(% style="width:1147px" %)(((
342 此字段由已升级交互中的数据预先填充。它指明了突发事件对业务产生的影响。
343
344 影响和紧急程度用于计算优先级。
345 )))
346 |19|(% style="width:156px" %)紧急度|(% style="width:1147px" %)(((
347 此字段由已升级交互中的数据预先填充。紧急程度表示此突发事件对于组织的紧
348
349 迫程度。紧急程度和影响用于计算优先级。
350 )))
351 |20|(% style="width:156px" %)优先级|(% style="width:1147px" %)此突发事件相对其他突发事件的排列顺序。优先级值是根据初始影响和紧急程度来计算的。只有从交互更新或升级突发事件时，此字段才显示。
352 |21|(% style="width:156px" %)SLA目标日期|(% style="width:1147px" %)下一个“服务级别目标”(SLO) 到期的日期和时间。此字段基于与突发事件信息相匹配的 SLO 进行填充，所用日期是违反协议之前即将到期的 SLO。
353 |22|(% style="width:156px" %)解决代码|(% style="width:1147px" %)(((
354 指定一个预定义的解决代码，用于说明如何解决突发事件。此字段的预置选项基于客户的参考数据。
355
356 建议以下预置解决代码：
357
358 • 不可重现
359
360 • 超出范围
361
362 • 请求被拒
363
364 • 通过变更/ 服务请求解决
365
366 • 通过用户说明解决
367
368 • 通过应对措施解决
369
370 • 无法解决
371
372 • 被用户撤销
373 )))
374 |23|(% style="width:156px" %)关闭代码|(% style="width:1147px" %)此项是在服务台质控员在回访时，同用户确定的最终结果
375 |24|(% style="width:156px" %)解决方案|(% style="width:1147px" %)提供对突发事件解决方案的说明。
376
377
378 ==== **3.1.4.2事件分级** ====
379
380 给事件分级是事件管理的一个关键要素，事件的分级决定处理这个事件的顺序及所提供的资源。
381
382 |编号|事件级别|描述|响应时间|解决时限
383 |1|VIP服务| |<10分钟|<8小时
384 |2|重大事件|重大事件指的是严重影响到业务连续性并且涉及多个用户（用户>100）。 例如：病毒爆发、核心网络中断。|<10分钟|<24小时
385 |3|一般故障|一般故障指的是影响到业务连续性并且造成中断的故障且故障仅涉及少数用户（用户<100）， 例如： 蓝屏、死机、病毒感染、关键业务软件无法启动等等。|<30分钟|<48小时
386 |4|微小故障|微小故障指的是不会影响业务连续性的故障，例如键盘鼠标损坏，无法连接INTERNET等故障。|<40分钟|<72小时
387
388
389 ==== **3.1.4.3 事件影响度** ====
390
391 |影响度编码|影响范围|描述
392 |1-非常重要|领导|对领导造成影响
393 |2-严重|多数用户|对公司多数用户造成影响
394 |3-一般|多个用户|对多个用户造成影响
395 |4-轻微|少数用户|对单个或几个用户造成影响
396
397
398 ==== **3.1.4.4 事件紧急度** ====
399
400 |紧急度编码|紧急时间标准|描述
401 |1-非常紧急|8小时|服务需8小时内提供（恢复）
402 |2-紧急|24小时|服务需24小时内提供（恢复）
403 |3-一般|48小时|服务需48小时内提供（恢复）
404 |4-略微紧急|72小时|服务需72小时内提供（恢复）
405
406
407 ==== **3.1.4.5 事件优先级** ====
408
409 |(% colspan="2" rowspan="2" %)优先级|(% colspan="4" %)影响度
410 |1-非常重要|2-严重|3-一般|4-轻微
411 |(% rowspan="4" %)紧急度|1-非常紧急|1-最高|2|2|3
412 |2-紧急|2|2-高|3|3
413 |3-一般|2|3|3-中|4
414 |4-略微紧急|3|3|4|4-低
415
416
417 ==== **3.1.4.6 事件来源** ====
418
419 给事件分级是事件管理的一个关键要素，事件的分级决定处理这个事件的顺序及所提供的资源。
420
421 |编号|来源|描述
422 |1|用户报告|用户通过电话或WEB报告的事件，帮助台人员手工创建事件单
423 |2|监控告警|监控工具发现的告警事件
424 |3|日常运维发现|信息部日常运维检查产生事件
425
426 ==== ====
427
428 ==== **3.1.4.7 事件性质** ====
429
430 |类别|信息项|说明
431 |突发事件|访问|授权错误
432 |突发事件|访问|登录失败
433 |突发事件|数据|数据或文件损坏
434 |突发事件|数据|数据或文件不正确
435 |突发事件|数据|数据或文件丢失
436 |突发事件|数据|超过存储限制
437 |突发事件|失败|错误消息
438 |突发事件|失败|不正常工作
439 |突发事件|失败|作业失败
440 |突发事件|失败|系统故障
441 |突发事件|硬件|硬件故障
442 |突发事件|硬件|丢失或被盗
443 |突发事件|性能|性能降低
444 |突发事件|性能|系统或应用程序挂起
445 |突发事件|安全|违反安全性
446 |突发事件|安全|安全事件/ 消息
447 |突发事件|安全|病毒警报
448
449
450 ==== **3.1.4.8 事件分类** ====
451
452 |类别|子类|一级模块
453 |(% rowspan="72" %)应用系统|(% rowspan="6" %)外部网站（含子公司网站）|招贤纳才
454 |招标投标
455 |乘客服务
456 |企业概况
457 |企业商务
458 |新闻中心
459 |(% rowspan="2" %)企业内部门户|UUV用户管理
460 |SSO应用系统管理
461 |(% rowspan="6" %)财务管理系统|总帐管理
462 |应付管理
463 |应收管理
464 |固定资产管理
465 |项目会计管理
466 |预转资管理
467 |资金管理系统|
468 |(% rowspan="7" %)合同管理系统|范本管理
469 |合同计划
470 |合同招标
471 |合同台账
472 |合同管理
473 |合同支付
474 |系统管理
475 |运营设备维修系统|
476 |运营施工调度管理系统|
477 |运营物流管理系统|需求管理
478 | |计划管理
479 | |采购寻源管理
480 | |采购订单管理
481 | |物资库存管理
482 |票务管理系统|
483 |GIS系统|
484 |(% rowspan="7" %)数字认证平台|部门管理
485 |用户管理
486 |系统日志查询
487 |验证选项
488 |证书管理
489 |印章制作
490 |证书审计查询
491 |SPS平台|
492 |IT运维系统|
493 |办公自动化系统（新）|
494 |办公自动化系统（旧）|
495 |合同管理系统（新）|
496 |档案管理系统（新）|
497 |P3E|
498 |档案管理系统（旧）|
499 |统一通讯平台|
500 |视频会议系统|
501 |基建物流管理系统|
502 |人力资源管理系统|
503 |财务管理系统|
504 |原OA系统|
505 |立项管理系统（原OA）|
506 |企业内部门户|
507 |工程设计管理系统|
508 |内部专家评标系统|
509 |内部网站（含信息专区）|
510 |交流园地|
511 |WCM|
512 |内部网站后台|
513 |外部网站后台|
514 |外部网站招聘管理|
515 |外部网站招投标管理|
516 |资产标识码系统|
517 |企业统计报表系统|
518 |运营日报|
519 |MAXIMO系统|
520 |施工调度管理系统|
521 |工作证管理系统|
522 |车站收益系统|
523 |系统开发服务|
524 |系统培训服务|
525 |桌面终端| |
526 |服务器| |
527 |存储和备份系统| |
528 |网络| |
529 |其他| |
530
531
532 ==== **3.1.4.9 事件关闭代码** ====
533
534 |编号|代码|描述
535 |1|已完成|设备、业务系统等故障已得到修复；
536 |2|未完成|(((
537 故障没有被修复，需要再次进行处理；
538
539 对于该类事件，需要重新开单，并分配给原来处理该事件的人员进行处理。
540 )))
541
542
543 ==== **3.1.4.1 角色及职责** ====
544
545 === **3.1.5 角色介绍** ===
546
547 |**事件管理流程角色**|**主要职责**|**IT运维服务部对应的流程角色人员**
548 |事件管理流程负责人|(((
549 事件管理解决方案的责任人
550
551 对整个事件管理解决方案的结果承担责任，并有相应的权限
552 )))|廖清
553 |事件经理|(((
554 协调事件管理步骤的日常操作
555
556 确保事件受理员（1/2/3/n线）在其各自领域中正常工作；
557 )))|廖清
558 |(((
559 事件记录员
560
561 （1线）
562 )))|(((
563 服务台与客服/用户之间的主要接口
564
565 作为“首问负责人”，全程跟踪确保事件得到解决
566
567 负责事件的初步支持
568
569 重分派事件
570
571 与用户确认关闭事件
572 )))|服务台
573 |(((
574 事件受理员
575
576 （2/3线）
577 )))|(((
578 是其所负责处理的服务领域的专业人员，通常，他们被认为是二线支持专家
579
580 负责分析事件，尽快恢复服务
581 )))|(((
582 支持工程师
583
584
585 )))
586 |用户|(((
587 事件管理流程的服务对象
588
589 提交事件，查询提交的事件，协助Case处理，回复满意度调查
590 )))|广州地铁所有用户
591
592
593 === **3.1.6 事件流程负责人** ===
594
595 事件管理流程负责人从宏观上监控流程，确保事件流程在IT运维服务部的IT运维团队范围内被正确的执行。随着业务需求和IT环境的改变，流程负责人必须定期或不定期进行流程分析、找出缺陷、进行改进，从而实现服务能力的可持续提升。
596
597 **职责定义:**
598
599 1. 确定管理流程的衡量指标
600 1. 确保事件流程能够取得管理层的参与和支持
601 1. 确保事件流程符合业务实际状况和业务发展战略
602 1. 总体上管理和监控流程，建立事件流程运行机制
603 1. 确保事件流程实用、有效、正确地执行
604 1. 保持与其他流程负责人的定期沟通
605
606 **专业技能：**
607
608 1. 理解内部和外部业务环境
609 1. 理解业务规划及发展战略
610 1. 理解用户需求
611 1. 充分理解业务相关IT政策、操作过程和标准
612 1. 流程的评估和设计能力
613 1. 良好的分析和规划能力
614 1. 理解事件管理流程
615 1. 理解服务水平承诺
616
617 **处事技能：**
618
619 1. 良好的矛盾管理技巧
620 1. 确定问题以及趋势发现的能力
621 1. 良好的口头和书面表达能力
622 1. 工作主动性和领导能力
623 1. 决策能力
624
625 === ===
626
627 === **3.1.7 事件经理** ===
628
629 事件经理负责具体事件解决过程中的协调和监控，对事件升级进行判断，以及在升级过程中的具体执行或协调。
630
631 **职责定义：**
632
633 1. 监控事件流程的运行状况
634 1. 负责对事件解决过程中的资源进行协调，保证故障的最终排除
635 1. 当事件超时升级时或重大事件升级时，负责或参与资源协调，解决事件
636 1. 确保和问题管理流程之间的有效合作
637 1. 基于事件处理状况，发现IT或业务的相关问题
638 1. 专业技能
639 1. 充分理解业务相关IT政策、操作过程和标准
640 1. 基本了解业务系统环境
641 1. 具有流程的知识
642 1. 了解用户需求
643 1. 有分析能力
644 1. 理解服务水平承诺
645 1. 用户关系技能
646
647 **处事技能：**
648
649 1. 良好的口头和书面表达能力
650 1. 矛盾管理技巧
651 1. 监控和管理流程的能力
652 1. 谈判技巧
653 1. 确定问题和趋势发现的能力
654 1. 管理经验
655 1. 良好的团队工作能力
656
657 === ===
658
659 === **3.1.8 事件记录员** ===
660
661 事件记录员是同用户间的主要联系人，通常由一线工程师担任，即日勤和值班工程师。他们是用户组织和服务团队之间的纽带。作为事件的整体负责人，他们的职责是负责创建事件单，充当一线支持角色。并跟踪、协调事件的解决过程，以及最终关闭事件单。
662
663 **职责定义：**
664
665 1. 按监控流程和规范进行主动监控工作，并对告警信息进行筛选和识别
666 1. 响应所有用户事件，包括通过电话、邮件等渠道
667 1. 完整记录所有接收的事件信息，包括：IT用户信息、事件描述、发生时间和地点等
668 1. 负责处理事先确定的服务请求
669 1. 对事件进行适当的分类、为事件分配优先级等属性
670 1. 使用知识库等手段对事件进行初步诊断和分析，尝试解决问题
671 1. 必要时联系供应商和现场服务人员，参与事件处理
672 1. 如果不能解决事件，应当将事件分配给合适的二线支持
673 1. 检查事件记录的处理进度，保持与用户的联系，适时通知事件处理状况
674 1. 与用户确认事件解决方案，关闭事件
675
676 **专业技能：**
677
678 1. 了解用户和供应商信息
679 1. 基本理解业务相关IT政策、操作过程和标准
680 1. 用户关系技巧
681 1. 优秀的服务意识
682 1. 服务的基本知识和技能
683 1. 沟通技巧
684 1. 分析诊断能力
685 1. 电话响应技能
686
687 **处事技能：**
688
689 1. 出色的口头和书面沟通能力（必要时多语种支持）
690 1. 客户至上的理念
691 1. 责任心
692 1. 承受压力的能力
693
694
695 === **3.1.9 事件受理员（2/3/n线）** ===
696
697 事件受理员（2/3/n线）具有某个领域的技术技能，负责对服务台无法解决的事件进行进一步快速有效的分析，提出解决方案以尽快恢复服务。
698
699 **职责定义：**
700
701 1. 验证事件的描述和处理状况，进一步收集相关信息
702 1. 根据专业技能和知识库等，确定并实施有效解决方案或临时变通方法
703 1. 必要时联系供应商和现场服务人员参与事件处理
704 1. 更新事件记录和解决方案，确保事件状态代码真实反映事件状态
705 1. 必要时与其他事件受理员（2/3/n线）合作，确定解决方案或临时变通方法
706 1. 将已解决的事件转回事件记录员，由其进行用户确认并关闭事件
707
708 **专业技能：**
709
710 1. 基本理解同业务相关的IT政策、操作过程和标准
711 1. 理解相关的操作过程和工作指导
712 1. IT基础架构和操作环境中某一方面的较高的技术知识
713 1. 用户关系技能
714 1. 分析技能
715
716 **处事技能：**
717
718 1. 良好的口头和书面沟通能力
719 1. 基本的决策能力
720 1. 客户至上的理念
721 1. 承受压力的能力
722
723 == ==
724
725 == **3.2 流程输入及输出** ==
726
727 === **3.2.1 流程触发条件** ===
728
729 1. 客户上报的事件
730 1. 巡检发现事件
731 1. 监控系统上报告警事件
732
733 === ===
734
735 === **3.2.2 输入** ===
736
737 1. 来自于客服的事件请求
738 1. 通过巡检发现的事件
739 1. 监控系统上报的告警事件
740 1. 配置项（CI）的信息
741 1. 来自于知识库的解决方案/变通方法
742
743 === ===
744
745 === **3.2.3 输出** ===
746
747 1. 已关闭的事件单
748 1. 知识库的候选解决方案
749
750 === ===
751
752 === **3.2.4 流程关闭条件** ===
753
754 * 所有事件均通过解决方案或变通方法恢复
755
756 == ==
757
758 == **3.3 流程描述** ==
759
760 === **3.3.1 流程综述** ===
761
762 事件管理流程在执行过程中需要遵循以下要求：
763
764 1. 所有接收的事件要保证完整、准确、详细的记录
765 1. 事件需进行优先级划分和分类
766 1. 应有一线解决方案和事件转交说明
767 1. 事件需进行追踪和生命周期管理
768 1. 事件需验证和关闭
769 1. 事件需存在升级机制
770 1. 所有的事件均应可以追溯和分析相关信息
771 1. 应同事件影响对象及时沟通事件解决的过程，要在事件记录中记录所采取的全部措施
772 1. 应为处理人员提供更新的知识库
773 1. 只有事件确认已经解决并且服务得到恢复的情况下，事件才能被认为可以关闭
774
775
776 === **3.3.2 作业流程图** ===
777
778 (% style="text-align:center" %)
779 [[image:图片6.jpg]]
780
781
782
783 === **3.3.3 流程活动说明** ===
784
785 1）主要活动说明
786
787 (% style="text-align:center" %)
788 [[image:1730191350962-215.png]]
789
790
791 2）分活动说明
792
793 |**编 码**|**活 动**|(% style="width:173px" %)**责任人**|(% style="width:998px" %)**说 明**
794 |IM 1.1|识别和验证客户基本信息|(% style="width:173px" %)事件记录员（1线）|(% style="width:998px" %)(((
795
796
797 * 接受来自客服与系统监控上报的事件请求（包括故障与服务请求）
798 * 根据唯一的客户识别号识别客户
799 * 检查该客户是否属于服务对象的范围
800 )))
801 |IM 1.2|事件记录|(% style="width:173px" %)事件记录员（1线）|(% style="width:998px" %)(((
802
803
804 * (% id="cke_bm_3212S" style="display:none" %) (% id="cke_bm_3110S" style="display:none" %) (%%)如果是用户通过电话报告的事件，事件记录员需要了解用户信息是否准确并与客户沟通事件信息，了解必要的故障请求情况并作初步的受理和支持。
805 * 如果是用户通过邮件或其他方式提交事件单，一线支持人员首先需要检查用户提交的事件请求单是否完整、正确；如果不正确，与用户进行沟通，对用户信息不一致的情况进行调查，并修改相应记录；并关联相关CI、对用户提交的事件单中的类别、紧急度和影响度进行设置。(% id="cke_bm_3212E" style="display:none" %) (% id="cke_bm_3110E" style="display:none" %)
806 )))
807 |IM 2.1|初步支持|(% style="width:173px" %)事件记录员（1线）|(% style="width:998px" %)(((
808
809
810 * (% id="cke_bm_3211S" style="display:none" %) (% id="cke_bm_3109S" style="display:none" %) (%%)事件记录员调用知识库对用户的事件进行初步的支持与解决
811 * 如知识库无法匹配解决办法，事件记录员（1线）负责查找其他资源，包括根据资深知识经验和自己查找信息，或咨询资深人员看能否找到其他解决办法。
812 * 如果找到相应的解决办法，则进行相应的处理和实施工作；
813 * 如果找不到，则转入下一步(% id="cke_bm_3211E" style="display:none" %) (% id="cke_bm_3109E" style="display:none" %)
814 )))
815 |IM 2.2|判断是否能解决|(% style="width:173px" %)(((
816 事件记录员（1线）
817
818
819
820 )))|(% style="width:998px" %)(((
821
822
823 * (% id="cke_bm_3210S" style="display:none" %) (% id="cke_bm_3108S" style="display:none" %) (%%)事件记录员作为一线支持人员，判断该事件是否被解决。
824 * 如果解决，转入任务IM4.3“接受关闭请求？”，与用户进行沟通，是否可以关闭事件。
825 * 如果没有解决，转入任务IM2.3“派单”。(% id="cke_bm_3210E" style="display:none" %) (% id="cke_bm_3108E" style="display:none" %)
826 )))
827 |IM 2.3|派单|(% style="width:173px" %)事件记录员（1线）|(% style="width:998px" %)(((
828
829
830 * (% id="cke_bm_3209S" style="display:none" %) (% id="cke_bm_3107S" style="display:none" %) (%%)将事件单首先分派给2线接口人（项目经理），再由项目经理将事件分派给合适的事件受理员（2/3/n线），具体按分派机制或事件处理流程操作规定来执行；
831 * 如果派单两次仍未成功，则升级给事件经理派单(% id="cke_bm_3209E" style="display:none" %) (% id="cke_bm_3107E" style="display:none" %)
832 )))
833 |IM 2.4|确定是否接受派单|(% style="width:173px" %)事件受理员（2/3/n线）|(% style="width:998px" %)(((
834
835
836 * (% id="cke_bm_3208S" style="display:none" %) (% id="cke_bm_3106S" style="display:none" %) (%%)事件受理员（2/3/n线）查看事件记录描述，决定是否接受派单。如果接受，转入任务IM3.1 “调查和诊断”。否则，转入任务IM2.5 “注明拒绝原因” (% id="cke_bm_3208E" style="display:none" %) (% id="cke_bm_3106E" style="display:none" %)
837 )))
838 |IM 2.5|注明拒绝原因|(% style="width:173px" %)事件受理员（2/3/n线）|(% style="width:998px" %)(((
839
840
841 * (% id="cke_bm_3207S" style="display:none" %) (% id="cke_bm_3105S" style="display:none" %) (%%)事件受理员（2/3/n线）如不接受事件单，应在事件单上注明原因（比如事件分类不正确或自身任务排的很满），并提供下次分派的建议，将事件记录退回一线支持人员进行重新分派，进入任务2.3“重派单”(% id="cke_bm_3207E" style="display:none" %) (% id="cke_bm_3105E" style="display:none" %)
842 )))
843 |IM 3.1|调查和诊断|(% style="width:173px" %)事件受理员（2/3/n线）|(% style="width:998px" %)(((
844
845
846 * (% id="cke_bm_3206S" style="display:none" %) (% id="cke_bm_3104S" style="display:none" %) (%%)事件受理员（2/3/n线）对事件进行分析诊断，可借助知识管理信息进行辅助
847 * 事件受理员（2/3/n线）在必要时对事件信息作进一步的收集，比如向用户询问或者现场了解事件信息。
848 * 事件受理员（2/3/n线）诊断事件，并寻求解决方案或变通方法(% id="cke_bm_3206E" style="display:none" %) (% id="cke_bm_3104E" style="display:none" %)
849 )))
850 |IM3.2|找到解决方案/变通方法？|(% style="width:173px" %)事件受理员（2/3/n线）|(% style="width:998px" %)(((
851
852
853 * (% id="cke_bm_3205S" style="display:none" %) (% id="cke_bm_3103S" style="display:none" %) (%%)事件受理员（2/3/n线）判断是否找到了解决方案或者变通方法
854 * 如果找到，则转入IM3.5“记录解决方案/变通方法”，在事件单上记录解决方案或变通方法
855 * 如果未找到，事件受理员（2/3/n线）判断是否需要寻求进一步的支持，则转入IM3.4“升级到更高层”(% id="cke_bm_3205E" style="display:none" %) (% id="cke_bm_3103E" style="display:none" %)
856 )))
857 |IM3.3|需要更多支持？|(% style="width:173px" %)事件受理员（2/3/n线）|(% style="width:998px" %)(((
858
859
860 * (% id="cke_bm_3204S" style="display:none" %) (% id="cke_bm_3102S" style="display:none" %) (%%)当事件受理员无法解决事件时，转向IM3.4“升级到更高层”,将事件升级.(% id="cke_bm_3204E" style="display:none" %) (% id="cke_bm_3102E" style="display:none" %)
861 )))
862 |IM3.4|升级到更高层|(% style="width:173px" %)事件受理员（2/3/n线）|(% style="width:998px" %)(((
863
864
865 * (% id="cke_bm_3203S" style="display:none" %) (% id="cke_bm_3101S" style="display:none" %) (%%)如果事件受理员（2/3/n线）在规定时限内仍找不到解决方案，应将事件的处理提交给更高层专家来处理。(% id="cke_bm_3203E" style="display:none" %) (% id="cke_bm_3101E" style="display:none" %)
866 )))
867 |IM3.5|记录解决方案和/变通方法|(% style="width:173px" %)事件受理员（2/3/n线）|(% style="width:998px" %)(((
868
869
870 * (% id="cke_bm_3202S" style="display:none" %) (% id="cke_bm_3100S" style="display:none" %) (%%)事件受理员（2/3/n线）找到解决方案或变通方法后，在事件单上应详细记录解决方案或变通方法信息。(% id="cke_bm_3202E" style="display:none" %) (% id="cke_bm_3100E" style="display:none" %)
871 )))
872 |IM4.1|是否需要变更|(% style="width:173px" %)事件受理员（2/3/n线）|(% style="width:998px" %)(((
873
874
875 * (% id="cke_bm_3201S" style="display:none" %) (% id="cke_bm_3099S" style="display:none" %) (%%)事件受理员（2/3/n线）对解决方案进行判断，如果需要变更，则提交变更请求，进入变更管理流程。变更管理流程进行实施后评审并通过之后，将实施结果返回到事件管理流程，进入IM4.3 “记录处理结果”
876 * 如果不需要变更，则直接实施，转入IM4.2 “实施解决方案/变通方法”(% id="cke_bm_3201E" style="display:none" %) (% id="cke_bm_3099E" style="display:none" %)
877 )))
878 |IM4.2|实施解决方案/变通方法|(% style="width:173px" %)事件受理员（2/3/n线）|(% style="width:998px" %)(((
879
880
881 * (% id="cke_bm_3200S" style="display:none" %) (% id="cke_bm_3098S" style="display:none" %) (%%)事件受理员（2/3/n线）根据事件的解决方案或变通方法进行实施，并确保实施成功和解决故障、满足客户请求或达到客户期望。
882 * 必要时可授权事件记录员（1线）来实施解决方案/变通方法(% id="cke_bm_3200E" style="display:none" %) (% id="cke_bm_3098E" style="display:none" %)
883 )))
884 |IM4.3|记录处理结果|(% style="width:173px" %)事件受理员（2/3/n线）|(% style="width:998px" %)(((
885
886
887 * (% id="cke_bm_3199S" style="display:none" %) (% id="cke_bm_3097S" style="display:none" %) (%%)事件受理员（2/3/n线）在实施解决方案或变通方法后，在事件单上应详细记录解决方案或变通方法实施结果信息。
888 * 实施和记录实施结果之后，联系用户以请求关闭事件。(% id="cke_bm_3199E" style="display:none" %) (% id="cke_bm_3097E" style="display:none" %)
889 )))
890 |IM5.1|与用户确认是否可以关闭|(% style="width:173px" %)事件记录员（1线）|(% style="width:998px" %)(((
891
892
893 * (% id="cke_bm_3198S" style="display:none" %) (% id="cke_bm_3096S" style="display:none" %) (%%)一线或事件受理员解决事件后，需要通过事件记录员与用户进行联系，确认相关处理方案是否成功，是否达到用户需求，然后将事件单关闭。(% id="cke_bm_3198E" style="display:none" %) (% id="cke_bm_3096E" style="display:none" %)
894 )))
895 |IM5.2|是否接受关闭请求|(% style="width:173px" %)(((
896 用户
897
898
899 )))|(% style="width:998px" %)(((
900
901
902 * (% id="cke_bm_3197S" style="display:none" %) (% id="cke_bm_3095S" style="display:none" %) (%%)用户检查自己提出的请求或者报障是否得到完全解决，根据实施结果和满足程度判断是否接受关闭请求
903 * 如果接受关闭请求，则通知服务台可以关闭事件单，转入任务IM5.3 “是否需要更新到知识库”
904 * 如果不接受，则需要重新调查和诊断，转入任务(% id="cke_bm_3197E" style="display:none" %) (% id="cke_bm_3095E" style="display:none" %)
905 )))
906 |IM5.3|是否需要更新到知识库|(% style="width:173px" %)事件记录员或事件受理员|(% style="width:998px" %)(((
907
908
909 * (% id="cke_bm_3196S" style="display:none" %) (% id="cke_bm_3094S" style="display:none" %) (%%)事件受理工程师判断该解决方案或变通方法是否需要更新到知识库中，对于一些有价值的方案信息可以提交候选知识库解决方案，进入知识管理流程；
910 * 不需要的话，则直接进入IM5.5“关闭事件”
911 * 转入IM5.4“创建候选知识条目”，将该事件的解决信息更新到知识库(% id="cke_bm_3196E" style="display:none" %) (% id="cke_bm_3094E" style="display:none" %)
912 )))
913 |IM5.4|创建候选知识条目|(% style="width:173px" %)事件受理员（1/2/3/n）|(% style="width:998px" %)(((
914
915
916 * (% id="cke_bm_3195S" style="display:none" %) (% id="cke_bm_3093S" style="display:none" %) (%%)事件受理员在事件关闭后，将事件的根本原因和解决方案写入知识条目，转入IM5.5“关闭事件”。(% id="cke_bm_3195E" style="display:none" %) (% id="cke_bm_3093E" style="display:none" %)
917 )))
918 |IM5.5|关闭事件|(% style="width:173px" %)事件记录员或事件受理员|(% style="width:998px" %)(((
919
920
921 * (% id="cke_bm_3194S" style="display:none" %) (% id="cke_bm_3092S" style="display:none" %) (%%)一线支持人员（一线值班经理）负责填写结束代码后关闭事件(% id="cke_bm_3194E" style="display:none" %) (% id="cke_bm_3092E" style="display:none" %)
922 )))
923
924
925 == **3.4 流程衡量指标及报表** ==
926
927 为了控制流程的质量，提高用户服务体验，建议为事件流程设置衡量指标。通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。基于对IT运维服务部的IT服务认识和了解，事件管理流程KPI指标设置如下：
928
929 |**序号**|**衡量指标**|**指标计算说明**
930 |1|事件总数|(((
931 数量：在事件单中根据以下条件过滤
932
933 1. 【重复事件标记】为空
934 1. 【事件发生时间】在统计周期内
935 )))
936 |2|事件关闭的数量/比率|(((
937 数量：在事件总数中过滤【事件状态】＝‘关闭’
938
939 比率：数量 / 事件总数 × 100 %
940 )))
941 |3|事件成功关闭的数量/比率|(((
942 数量：在事件总数中过滤【事件结束代码】＝‘成功’
943
944 比率：数量 / 事件总数 × 100 %
945 )))
946 |4|升级到问题的数量/比例|(((
947 数量：在事件总数中过滤【事件结束代码】＝‘成功但有问题’
948
949 比率：数量 / 事件总数 × 100 %
950 )))
951 |5|规定时间内解决的事件数量/比率|(((
952 数量：在事件总数中过滤【事件解决是否超时】＝‘未超时’and 【事件结束代码】＝‘成功’
953
954 比率：数量/事件总数 × 100 %
955 )))
956 |6|规定时间内响应的事件数量/比率|(((
957 数量：在事件总数中过滤【事件响应是否超时】＝‘未超时’
958
959 比率：数量/事件总数 × 100 %
960 )))
961 |7|平均响应时间|平均响应时间：累计响应事件的时间（【事件登记时间】 - 【事件发生时间】）/ 事件总数
962 |8|平均解决时间|(((
963 完成的事件数量：在事件总数中过滤所有【事件状态】＝‘已解决’or ‘关闭’，同时【事件解决人角色】=‘一线’or‘二线’的事件
964
965 平均解决时间：累加完成事件的（【事件解决时间】－【事件登记时间】）/ 完成的事件数量
966 )))
967 |9|第三方平均解决时间|(((
968 完成的事件：在事件总数中过滤所有【事件状态】＝‘已解决’or ‘关闭’，同时【事件解决人角色】=‘3/n’的事件
969
970 平均解决时间：累加完成事件的（【事件解决时间】－【转至第三方时间】）/ 完成的事件数量
971 )))
972 |10|一线解决率|(((
973 数量：在事件总数中过滤所有【事件解决人】＝‘一线’
974
975 比率：数量 / 事件总数 × 100 %
976 )))
977 |11|二线解决率|(((
978 数量：在事件总数中过滤所有【事件解决人】＝‘二线’
979
980 比率：数量 / 事件总数 × 100 %
981 )))
982 |12|重大事件数量/比率|(((
983 数量 ：在事件总数中过滤【事件优先级】＝‘1’或‘2’
984
985 比率：数量 / 事件总数 × 100 %
986 )))
987 |13|员工月度发起事件数量|数量：每月事件总数按【事件登记人】=%员工名称% 进行分类统计
988 |14|员工月度处理事件数量|数量：每月事件总数按【事件工作日志】包含%员工名称% 进行分类统计
989 | 15|知识库利用率|(((
990 数量：解决问题，获取知识库的数量；
991
992 比率：数量/时间总数×100%
993 )))
994 |16|员工月度发起事件比率|(((
995 数量：每月事件总数按【事件登记人】=%员工名称% 进行分类统计
996
997 比率：数量/服务组事件总量×100%
998 )))
999 |17|员工月度解决事件比率|(((
1000 数量：在事件总数中过滤所有【事件解决人角色】＝%员工名称%
1001
1002 比率：数量/服务组事件总量×100%
1003 )))
1004
1005
1006 事件流程管理相关报表建议如下，IT运维服务部运维服务团队可在此基础上自行补充：
1007
1008 |**序号**|**报表名称**|**报表类型**|**包含指标**
1009 |1|事件数量按用户及优先级统计|月报/季报|事件总数
1010 |2|事件数量按用户及设备统计|月报/季报|事件总数
1011 |3|事件数量按用户及事件分类统计|月报/季报|事件总数
1012 |4|超时响应事件数量按用户及优先级统计|月报/季报|超时响应数量
1013 |5|超时解决事件数量按用户及优先级统计|月报/季报|超时解决数量
1014 |6|平均响应/解决时间按优先级统计|月报/季报|(((
1015 平均响应时间
1016
1017 平均解决时间
1018 )))
1019 |7|一线/二线解决率按事件分类统计|月报/季报|(((
1020 一线解决率
1021
1022 二线解决率
1023 )))
1024 |8|事件登记/解决数量按服务支持人员统计|月报/季报|事件总数
1025
1026
1027 = **4. 参考** =
1028
1029 == **4.1 相关流程** ==
1030
1031 1. 问题管理
1032 1. 变更与发布管理
1033 1. 服务级别管理
1034 1. 业务关系管理
1035 1. 供应商管理
1036
1037 == ==
1038
1039 == **4.2 相关表单** ==
1040
1041 1. 事件单/事件记录
1042 1. 运维事件月报/周报
1043 1. 经验手册/FAQ
深圳市艾拓先锋企业管理咨询有限公司