Wiki源代码事件管理程序

Version 3.1 by superadmin on 2024/05/28, 16:46
Show last authors
1
2
3 = **事件管理程序** =
4
5
6
7 ===
8 **1  简介** ===
9
10
11 ===== **1.1 目的** =====
12
13 事件管理过程提供日程支持服务的接口，以降低因IT事件带来的影响。该过程关注尽可能快的恢复服务以满足预定服务等级协议（SLA）的要求。
14
15
16
17 ===== **1.2 适用范围** =====
18
19 事件管理过程适用于记录、处理、关闭事件并监督整个过程的管理活动，事件管理过程包括服务台和相应的支持组。
20
21
22 ===== =====
23
24 ===== **1.3术语表** =====
25
26 **◆ 事件：**
27
28 指服务的任何异常，并将导致或可能导致服务的中断或服务质量下降的事态。
29
30 **◆服务请求：**
31
32 来自客户对IT服务的信息、建议、标准变更或访问请求。例如要求增加内存、安装某个软件、账号申请、变更请求等。变更通常不认为是一个事件，而是一个变更请求（RFC） 。但两者的处理方式相近，因此在事件处理过程中也包括对服务请求的处理，即事件包含服务请求。
33
34 **◆事件关闭：**
35
36 接到事件请求后，服务台不能当时解决问题，则将需要把事件分配给相应的支持组。为尽可能快地恢复业务，可利用解决方案（永久性的）或临时措施。当事件得到了解决，并且服务也恢复到正常状态后，事件关闭。另外事件还包括系统自动产生或例行巡检所发现的某些事态，如硬盘空间超出设定值、机房UPS告警等。虽然这些事态不会对服务的交付产生直接影响，但对这些事态的处理也包括在事件管理过程中。
37
38 **◆事件处理过程：**
39
40 事件发生后，通常服务台接受和尝试处理，当服务台未能快速解决时，派单给一线工程师作为一线支持处理；当一线工程师未能快速解决时，事件从一线返回服务台重新分配到二线；二线未能解决时，调用三线厂商支持，后续的二线或三线支持应具有更高的技能和资源来解决事件。事件从一线支持转到二线或后续支持线，通常称为“职能升级”。为表述方便，在《事件管理程序》中，把“职能升级”过程称为“事件处理过程”。
41
42 **◆事件升级过程：**
43
44 如果事件未能及时按照预定的时间得以解决或未能满足用户要求，需要管理层参与，以提供更多资源，则进行“垂直升级”。按照问题的解决时间进度设置自动升级的时间段，如果在预定时间段，问题没有解决，则自动进行“垂直升级”。在设定预定时间段时，应考虑留有足够的时间以进行管理升级采取必要措施（如引入第三方支持）。因为技能或经验的缺乏，可以通过服务台或支持工程师进行人工要求进行“垂直升级”。 为表述方便，在《事件管理程序》中，把“垂直升级”过程称为“事件升级过程”。
45
46 **◆事件分类**
47
48 由于用户提供信息的不完整或不正确，可能导致开始的分类与最终的分类有很大的差别。首先对事件按照事件类型进行分类，各类可以对应到相应的支持组，以便准确分配任务。
49
50 |编号|一级分类|二级分类|描述
51 |(% rowspan="8" %)1|(% rowspan="8" %)合同服务|视讯系统|包括视频会议、视频监控系统线路及外围设备
52 |网络|
53 |PC终端|
54 |PC服务器|
55 |小型机|
56 |存储系统|
57 |应用软件|公司自主开发软件或由公司提供服务的第三方软件
58 |基础设施|电源、空调、门禁、KVM
59 |(% rowspan="9" %)2|(% rowspan="9" %)工程售后|视讯系统|
60 |全球眼|
61 |网络|
62 |PC终端|
63 |PC服务器|
64 |小型机|
65 |存储系统|
66 |应用软件|
67 |基础设施|
68 |(% rowspan="4" %)3|(% rowspan="4" %)公司资产维护|硬件送修|
69 |PC机|
70 |网络|
71 |前端应用系统|公司协同办公、MIS系统服务
72 |4|业务咨询| |
73 |5|单次收费服务| |
74
75 **◆事件分级**
76
77 给事件分配优先级，以保证支持组对事件必要的重视。分级应基于是事件的紧急程度和影响面。事件严重程度定义如下。
78
79 |(% rowspan="2" %)事件级别 |(% colspan="3" %)级别定义
80 |影响业务范围 |影响业务程度 |业务修复紧急程度
81 |一级事件 |客户业务中断，无法工作 |80%以上客户业务受影响 |非常紧急
82 |二级事件 |客户业务性能严重下降 |50%以上客户业务受影响 |紧急
83 |三级事件|客户业务性能下降 |20%以上客户业务受影响 |普通
84 |四级事件 |问题请求，业务性能无下降 |客户业务可能有潜在影响 |与客户协商确定
85
86 **◆事件状态**
87
88 为方便事件状态的跟踪和查询，对事件状态定义如下。
89
90 |编号|状态|描述
91 |1|待处理|已在系统中记录，未派单给工程师
92 |2|已派单|已分配至工程师，工程师未处理
93 |3|处理中|工程师正在处理过程中，事件未关闭
94 |4|挂起|工程师正在处理，调用三线厂商支持或送外修，尚未完毕
95 |5|暂停|工程师正在处理，因客户原因暂时无法处理
96 |6|待审核|事件已关闭，等待项目经理审核
97 |7|已归档|服务台已审核归档，服务台回访客户结束。
98
99
100
101 ===== **1.4  引用文件** =====
102
103 1. 《ISO/IEC 20000-1 2005》
104 1. 《IT服务管理手册》
105
106
107
108 === **2  职责** ===
109
110
111
112 ===== **2.1  服务台** =====
113
114 受理事件请求，自行解决事件或调度相关支持组解决事件。
115
116 服务等级协议（SLA）约定的服务范围内的事件报告和服务请求，服务台都应纳入事件处理范围。
117
118 负责对相关数据进行统计分析。
119
120
121 ===== =====
122
123 ===== **2.2  一线（现场工程师）/二线（专项工程师）** =====
124
125 接收服务台的事件处理请求，解决系统运维相关事件。
126
127 负责提供一线/二线支持，按照标准要求填写处理过程。
128
129 负责联络和管理外部三线支持。
130
131
132
133 ===== **2.3  外部资源** =====
134
135 接收一线/二线的事件处理请求，配合解决系统运维相关事件。
136
137
138 ===== =====
139
140 ===== **2.4  项目经理** =====
141
142 负责协调资源调度，保障业务尽快恢复。
143
144 负责和客户确认事件解决并最终关闭事件。
145
146 监控事件处理流程的效率和效果。
147
148 管理一线/二线支持组的工作。
149
150 为改进工作提供建议。
151
152
153 === **3  流程图** ===
154
155
156 [[image:微信图片_20240528160757.png]]
157
158 ===== [[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml8452\wps1.png]] =====
159
160 === **4  具体内容** ===
161
162
163
164 ===== **4.1  接受/记录事件** =====
165
166
167 **4.1.1 **用户、IT维护人员、公司合作伙伴可以通过电话、传真或电子邮件等方式向服务台报告事件，IT维护人员的日常检查等获得事件信息。
168
169 **4.1.2 **IT维护人员应按《服务合同》的要求进行例行检查，并应在检查结束后，填写相应的检查记录，对所发现的事件应告知服务台登记。
170
171 **4.1.3** 所有工程师（含服务组、技术组）接受的客户直接报修或工程师自身主动发现的事件，告知服务台登记。
172
173 **4.1.4 **服务台接到事件报告和服务请求后，及时在事件管理系统内作好记录。事件记录应包括以下要素：
174
175 4.1.4.1 事件编号
176
177 4.1.4.2 事件报告的日期、时间
178
179 4.1.4.3 记录人
180
181 4.1.4.4 事件报告人员、用户及其联系方式
182
183 4.1.4.5 事件发生的日期和时间，受影响的配置项(CI)信息
184
185 4.1.4.6 症状描述和任何错误代码（如果是服务请求，则该项为所请求的服务的详细信息）
186
187 4.1.4.7 已经产生的影响或可能导致的影响等级；
188
189 4.1.4.8 事件处理状态
190
191 **4.1.5 **服务台记录事件后，要分析事件是否在受理责任范围内。如果不在受理范围内，则由服务台告知事件报告人。如客户仍需提供超出受理范围的支持服务，则由服务台告知客户及销售部门，由销售部门决定是否进行服务。
192
193
194
195 ===== **4.2  分级/分类和初步支持** =====
196
197
198
199
200 **4.2.1** 在接受和记录事件之后，服务台首先根据1.3的事件分级、分类准则对受理的事件进行分级和分类以方便后续的监视和报告。
201
202 **4.2.2** 服务台要根据事件分类及性质确定应由哪个小组处理该事件，转到对应的一线或二线支持组。
203
204 **4.2.3 **如果发现人员安排紧张时，应优先安排紧急程度高的事件。必要时，可以召回低紧急度事件的工程师，应对紧急程度较高的事件。
205
206 **4.2.4** 对于重大事件，在按上述步骤进行处理的同时，还应按照第5节 “事件升级过程”进行升级汇报。
207
208
209
210 ===== **4.3  调查和分析** =====
211
212
213
214 **4.3.1 **接到事件处理请求的小组应立即着手对事件进行调查诊断，提供事件、问题解决方案。判断事件的分级分类是否合理。
215
216 4.3.1.1 如果事件派单错误（如网络故障事件被派单到应用组），则立即返回服务台重新派单。
217
218 4.3.1.2 如果事件分级错误，则进行相应的调整，并告知服务台。但原则上，原有分级不得降低。
219
220 **4.3.2 **接到事件处理请求的小组收到转发过来的事件后，查看知识库，看以前是否有类似事件发生。
221
222 **4.3.3** 如果类似事件发生过，查看知识库里是否已经有事件或类似事件的解决方案或是应急措施等，如果有就参照这些方案组织实施以解决事件。如没有发生过类似事件，尝试解决。
223
224 **4.3.4** 如果接到事件处理请求的小组不能快速解决事件，或者事件处理要求已经超过他们直接解决范围，则转入后续支持，如由一线通过服务台转到二线，或直接调用第三方厂家支持，并告知服务台。
225
226 **4.3.5 **接到事件处理请求的小组不能快速解决事件时，应按事件的紧急程度，按照第5节 “事件升级过程”进行升级汇报。
227
228 **4.3.6 **如果事件无法得到解决，或事件虽然得到暂时解决，但没有找到事件发生的根本原因，则由IT服务工程师汇报项目经理及部门经理，视其需要创建问题，进入问题管理过程。
229
230
231
232 ===== **4.4 解决和恢复** =====
233
234
235
236 4.4.1 接到事件处理请求的小组应着手解决事件和恢复服务。
237
238 4.4.2 如果事件的处理需要在中心机房、或其他重要区域及系统进行操作，应遵照客户的规定执行。
239
240 4.4.3 如事件的解决方案涉及IT基础设施、配置变更的，由负责事件处理的小组按《变更管理程序》的要求向项目经理提交变更请求，项目经理制订相应的变更计划并监控实施。
241
242
243
244 ===== **4.5  事件关闭** =====
245
246
247
248 4.5.1 工程师获得用户对事件解决的认可后，将事件转为“待审核”状态,关闭事件。
249
250 4.5.2 项目经理每天确认所对应的“待审核状态”的事件是否解决。如果确认事件解决，则终止该事件，将事件状态改为“已归档”；否则事件管理活动需要在未解决的地方重新开始处理。
251
252 4.5.3 项目经理应对所发生事件进行分析，对于需要进行问题管理的事件，按照《问题管理程序》的要求进行管理。
253
254 4.5.4 项目经理负责事件记录以及最终分类和分级的准确性。
255
256
257
258 ===== **4.6  过程的跟踪监控** =====
259
260
261
262 **4.6.1 **事件处理人员在实施过程中应按照1.3中的状态定义，随时更新事件状态或向服务台报告事件状态。当天未能解决的事件, 服务台应在每个工作日下班前1小时告知项目经理事件的处理状态，以及预期的行动。
263
264 **4.6.2 **项目经理负责对事件进展进行跟踪和监控，根据服务等级协议（SLA）来监控事件处理流程的效果和效率，在事件处理过程中要和客户保持良好沟通，及时通报事件处理的进展情况，提高客户满意度。当天未能解决的事件，应在当天下班前半小时告知客户当前事件的处理状态，以及预期的行动。
265
266 **4.6.3** 服务台应每周对所有事件进行回访，并向项目经理通报回访结果。
267
268
269 === **5  事件升级过程** ===
270
271
272
273 ===== **5.1** **事件严重程度定义** =====
274
275
276 **5.1.1 **如果事件未能及时按照一定的时间得以解决或未能满足用户要求，需要管理层参与，以提供更多资源，则负责处理事件的工程师和项目经理应按照事件的严重程度逐步升级汇报。事件严重程度定义按照1.3中的定义执行。
277
278
279 ===== **5.2  事件升级步骤** =====
280
281
282
283 **5.2.1** 当事件未能或预计未能按照服务等级协议（SLA）的要求，得以修复时，将按照预定的时间表自动（或由服务台）发起事件升级。另当，用户或支持队伍认为有必要时，可以要求发起事件升级。
284
285 **5.2.2** 事件升级时间表
286
287 |汇报人|工程师|项目经理|事业部总监
288 |一级事件 |立即|立即|立即
289 |二级事件 |4小时内|6小时内|8小时内
290 |三级事件|6小时内|8小时内|12小时内
291 |四级事件 |12小时内|24小时内|48小时内
292 |升级至|项目经理|事业部总监|公司管理层
293
294 （时间表按照客户合同重新调整）
295
296
297 === **6  事件管理过程与其他流程的关系** ===
298
299
300
301 ===== **6.1 事件管理过程与其他关系** =====
302
303
304
305 **6.1.1** 图2为事件管理过程与其他过程的之间关联关系。在事件管理过程中，可能需要直接触发其他管理过程， 或直接向某些过程获取必要数据。对于在事件管理过程没有直接影响的其他管理过程，则不在本过程中进行描述。
306
307
308 [[image:微信图片_20240528164313.png]]
309
310 [[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml8452\wps2.png]]
311
312
313
314 **6.1.2** 配置管理指服务台/一线/二线/三线支持在处理问题过程中，可能需要从配置数据库中获取必要的配置项相关的信息，并在处理过程中对配置项的变更及时更新。
315
316 **6.1.3** 问题管理指事件没有得到解决，需要升级为问题进行进一步分析处理时，应创建问题；事件虽然得到解决，但可能存在未知错误时，应创建问题；重大事件，无论是否得到解决，为防止再次出现，应创建问题；在事件分析报告中提出的存在趋势或潜在隐患的可能问题，例如事件类型或数量的趋势分析存在问题。创建问题后，启动问题管理过程。
317
318 **6.1.4 **变更管理过程指服务台/一线/二线/三线支持在处理问题过程中，可能需要提交变更请求，以解决问题。
319
320 **6.1.5 **服务等级管理指为服务台在接受/跟踪时，提供必要的服务等级协议（SLA）信息。
321
322
323 === **7  事件管理过程的KPI** ===
324
325
326
327 ===== **7.1 KPI定义 ** =====
328
329
330
331 **7.1.1 **为保证事件管理过程的快速有效，发现潜在的问题，被加以改善是非常必要的。为此，定义以下关键指标：
332
333 7.1.1.1 事件的总数
334
335 7.1.1.2 对业务的影响
336
337 7.1.1.3 未能满足服务等级协议（SLA）要求的比例
338
339 7.1.1.4 平均花费的时间（按事件分类进行统计）
340
341 7.1.1.5 一线解决问题的比例
342
343 7.1.1.6 事件趋势分析
344
345 7.1.1.7 重大事件分析。
346
347
348
349 === **8  输出的文件和记录** ===
350
351 |**文件和记录**|**文件属性**|**拟制部门**
352 |《事件记录表》|D|服务部
353 |《服务月报》|D|服务部
354 |《客户服务工作单》|D|服务部
355
356
深圳市艾拓先锋企业管理咨询有限公司