Version 7.1 by superadmin on 2024/10/29, 18:50
Show last authors
1 = **1. 概述** =
2
3 == **1.1 目的** ==
4
5 编写事件管理程序的目的是为了规范XX移动网管中心IT服务管理体系的事件的管理，尽快解决IT环境中的突发事件、故障和服务请求，尽快恢复被中断或受到影响的IT服务，保持提供稳定的、高效的、高质量的IT服务。
6
7 具体目标体现在：
8
9 1）在成本允许的范围内尽快恢复IT服务
10
11 1. 快速响应服务请求（电话、邮件）
12 1. 快速处理故障申告（电话、邮件、自助平台、告警系统）
13 1. 用户在线获得帮助，提高用户工作效率
14 1. 沟通事件解决状态，提升客户满意度
15
16 2）进行事件的有效控制
17
18 1. 按规范记录事件
19 1. 对事件进行有效分类
20 1. 对事件优先级进行分级
21 1. 事件分析与诊断，必要时进行升级
22 1. 监视并结束事件
23 1. 进行定期服务流程回顾
24
25 3）提供有效的IT服务管理信息
26
27 1. 服务资源利用情况
28 1. 故障处理情况
29 1. 服务支持效率
30 1. 有效配置信息
31 1. 服务质量管理报告
32
33 == ==
34
35 == **1.2 适用范围** ==
36
37 事件管理的范围包括辽宁移动网管中心合同范围内客户的IT生产和运行环境中发生的故障、服务请求。如果用户通过事件管理流程提出新增服务，变更请求和服务投诉等事件，则它们会通过事件管理流程转入其他相应的管理流程进行处理，事件管理只负责故障申告和服务请求的处理。具体如下：
38
39 1）故障申告
40
41 1. 用户报告的故障事件
42 1. 监控系统的告警事件
43 1. IT服务人员监测、检测的故障事件
44 1. 其他人员转告的用户故障事件
45
46 2）服务请求
47
48 1. 业务支持
49 1. 信息咨询
50 1. 辅助配合
51 1. 文档需求
52
53
54 本事件管理范围不包括尚处于开发或测试环境系统引发的事件。
55
56
57
58 == **1.4 前提与假设** ==
59
60 阅读本文的读者应该了解IT服务管理国际最佳实践（ITIL）的基本知识，并具有流程的基本技能，了解XX移动网管中心系统运维的业务。
61
62 同时，假设网管中心的事件发起主要通过电话、邮件、自助平台、告警系统、短信。
63
64
65 == **1.5 文档结构** ==
66
67 本文有以下几个章节组成：
68
69 第一章，“概述”，描述了本文的目的、适用范围、引用文件、前提与假设等内容。
70
71 第二章，“术语”，描述了本文使用到的术语及其定义或说明。这些术语和说明是基于IT服务管理国际最佳实践（ITIL）和IT服务管理国际标准（ISO20000），同时结合网管中心实际进行的定义和说明。
72
73 第三章，“角色与职责”，描述了本管理程序相关的角色与角色应承担的职责。角色为逻辑角色，与网管中心现有人员的职能岗位无关，可以一人对应多个角色或多人对应一个角色。
74
75 第四章，“流程准则”，描述本管理程序应遵循的管理规范和要求。
76
77 第五章，“工作流程”，描述了本管理程序所遵循的管理流程及其流程说明。
78
79 第六章，“关键绩效指标”，描述了度量管理程序有效性的关键绩效指标。
80
81 第七章，“三四级文件”，描述了本管理程序配套的三四级文件名称。
82
83
84
85 = **2. 术语** =
86
87 |**术语**|**说明**
88 |事件|用户在信息系统使用过程中，在合同范围内的任何故障和服务请求。
89 |服务请求|服务请求是指用户希望从服务台/一线支持获得的业务支持、信息咨询、辅助配合或者文档方面的事件请求。
90 |故障申告|故障申告是指来自用户、IT维护人员、告警系统等不同对象关于桌面、系统、数据库、服务器、存储、网络等IT基础环境的事件请求。
91 |投诉建议|(((
92 客户对服务支持不满的诉讼请求，包括：支持质量，支持效率，支持态度等；
93
94 客户对服务支持过程中提出的意见和建议。
95 )))
96 |事件分类|事件分类通常是标明一个事件的类别属性，根据不同的类别属性，由具备不同技能的事件处理人员进行事件受理。
97 |事件优先级|事件优先级是根据事件的影响度和紧急度共同决定的事件处理的优先等级。
98 |主事件|主事件是由于相同原因导致的多个故障中，首先申告上来的故障。
99 |从事件|从事件是由于相同原因导致的多个故障中，在主事件后提出来的故障。
100
101
102
103 = **3. 角色与职责** =
104
105 流程的实现是通过不同的流程角色以及其被赋予的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合。在实际操作中，不同的人员将被赋予不同的角色，既可以一个人被赋予多个角色，也可以多个人被赋予一个角色。
106
107
108 事件管理流程主要有以下几类角色，其职责及技术技能如下。
109
110
111 |(% style="width:114px" %)角色|(% style="width:854px" %)职责|(% style="width:369px" %)技能要求
112 |(% style="width:114px" %)(((
113 事件管理
114
115 流程负责人
116 )))|(% style="width:854px" %)(((
117 事件管理流程负责人从宏观上监控流程，确保事件管理流程在网管中心被正确的执行。当流程不能适应网管中心的实际情况时，事件管理流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。
118
119 1. 确定事件管理流程的衡量指标。
120 1. 确保事件管理流程能够取得管理层的参与和支持。
121 1. 确保事件管理流程符合网管中心IT发展战略和实际状况。
122 1. 总体上管理和监控事件管理流程，建立事件管理流程的实施、评估和持续优化机制。
123 1. 确保事件管理流程实用、有效、正确地执行，当流程不能够适应网管中心的情况时，必须及时进行分析，找出缺陷，进行改进(例如增加或合并流程的角色)，从而实现可持续提高。
124 1. 保持与其他流程负责人的定期沟通。
125 )))|(% style="width:369px" %)(((
126 1. 深刻理解事件管理流程
127 1. 充分理解IT服务管理的其他流程，能够进行流程接口设计
128 1. 能够很好地理解业务对于事件管理的需求
129 1. 对质量控制与保障有很深入的了解
130 1. 有决策权，能够确保事件管理流程设计要求在实施项目中得到贯彻和执行
131 1. 具有很好的沟通技能，能够取得公司高层的支持，获得所需资源
132 )))
133 |(% style="width:114px" %)事件经理|(% style="width:854px" %)(((
134 事件经理负责事件解决过程中的协调和监控，对事件总负责。
135
136 1. 总体上负责事件的解决，协调资源，确保故障的最终排除。
137 1. 出现重大事件时，负责协调资源，启动紧急预案，并及时通知/上报有关机构与人员。
138 1. 事件处理即将超过规定的解决时限时，负责按照升级原则对事件进行处理，确保有效协调资源，督促支持人员快速恢复正常服务
139 1. 负责审批二线支持无法及时解决、需协调第三方/供应商支持的升级事件。
140 1. 负责接受重大事件的处理，判断重大事件的影响度与紧急度，组织或发起应急预案，及时通报相关机构与领导，协助做好善后处理工作。
141 1. 跟踪及监督超过规定解决时限的事件和客户满意度较低的事件的状况。
142 1. 确保和事件管理流程负责人的有效合作，改善事件管理流程。
143 1. 确保正确和广泛地收集和分析事件数据，形成事件管理报告，为问题管理、可用性管理、能力管理和服务级别管理提供依据。
144 1. 已解决的事件要转告服务台或一线支持，由服务台或一线支持关闭事件。
145 )))|(% style="width:369px" %)(((
146 1. 了解技术架构和技术环境
147 1. 较强的口头表达能力和与用户沟通技巧
148 1. 处理纠纷的能力
149 1. 深刻了解事件管理流程
150 1. 较强的领导能力
151 )))
152 |(% style="width:114px" %)服务台|(% style="width:854px" %)(((
153 负责[[受理来自电话、自助平台的服务请求事件和故障申告事件，并有效记录事件信息。根据事件分类分级负责事件的分派>>path:#_Hlk258312191]]，并负责处理部分服务请求事件。
154
155 1. 作为与用户进行事件沟通的联系入口。
156 1. 根据服务级别协议要求，受理来自电话、自助平台的事件申告。
157 1. 准确、完整地记录所有事件，包括服务请求、故障申告、客户需求、投诉与建议等事件。
158
159 1. 对事件进行正确分类分级，并分派到正确的角色（包括服务台、一线支持、现场工程师、二线支持、事件经理等）进行事件处理。
160 1. 负责部分服务请求类事件的处理，包括咨询服务、知识申请等。（需根据事件分类进行调整，明确服务台所处理的服务请求类事件）
161 1. 根据知识库负责对服务请求事件的及时处理。
162
163 1. 及时与用户直接沟通，向用户通报事件的处理状况。
164 1. 作为事件的受理者，要及时跟踪、监控事件的处理过程，确保在SLA规定的时间内解决事件，把事件的影响降到最低，确保尽快恢复正常。
165 1. 事件解决后，在关闭该事件之前要与用户确认事件处理效果及收集用户的满意度。
166 1. 事件解决后，在关闭该事件之前要更新相关信息，将事件的解决步骤、已知错误、解决方案/变通方法进行文档化，确保信息的完整性、准确性。
167 1. 事件解决后，在关闭该事件之前，将解决方案/变通方法申请纳入知识库中
168 )))|(% style="width:369px" %)(((
169 1. 熟悉事件管理流程和服务台的职责
170 1. 熟悉技术平台和技术环境
171 1. 快速诊断事件和解决事件的能力
172 1. 较强的沟通能力
173 1. 较强的倾听能力
174 )))
175 |(% style="width:114px" %)一线支持|(% style="width:854px" %)(((
176 负责受理来自自助平台、邮件、短信和告警系统的服务请求事件和故障申告事件，并有效记录事件信息。根据事件分类分级负责事件的分派，并负责处理部分服务请求事件和故障申告事件。
177
178 1. 作为与用户进行事件沟通的联络入口。
179 1. 根据服务级别协议要求，受理来自自助平台、邮件、短信和告警系统的事件申告。
180 1. 准确、完整地记录所申告的事件信息，包括服务请求、故障申告等。
181
182 1. 对事件进行正确分类分级，并分派到正确的角色（包括一线支持、现场工程师、二线支持、事件经理等）进行事件处理。
183 1. 负责部分服务请求事件和故障申告事件的处理，包括桌面故障、系统应用故障等。（需根据事件分类进行调整，明确一线支持所处理的事件类型）
184 1. 根据知识库负责对事件的及时处理。
185
186 1. 如果故障无法及时解决，需将故障升级二线支持。
187 1. 及时与用户直接的沟通，向用户通报事件的处理状况。
188 1. 作为事件的受理者，要及时跟踪、监控故障的处理过程，以确保在SLA规定的时间内处理事件，必要时进行事件升级，把事件的影响降到最低，确保尽快恢复正常。
189 1. 事件解决后，在关闭该事件之前要与用户确认事件处理效果及收集用户的满意度。
190 1. 事件解决后，在关闭该事件之前要更新相关信息，将事件的解决步骤、已知错误、解决方案/变通方法进行文档化，确保信息的完整性、准确性。
191 1. 事件解决后，在关闭该事件之前，需将解决方案/变通方法申请纳入知识库中。
192 1. 向现场工程师提供必要的支持和协助。
193 )))|(% style="width:369px" %)(((
194 1. 熟悉事件管理流程和一线支持的职责
195 1. 熟悉技术平台和技术环境
196 1. 快速诊断故障和解决故障的能力
197 1. 较强的沟通能力
198 1. 较强的倾听能力
199 )))
200 |(% style="width:114px" %)现场工程师|(% style="width:854px" %)(((
201 负责处理现场技术服务与支持，以及现场故障诊断与解决。
202
203 1. 负责现场技术服务与支持，包括系统软件安装、桌面工具安装等。（需根据事件分类进行调整，明确现场工程师所处理的事件类型）
204 1. 负责现场故障的处理，包括桌面系统故障、网络故障等。（需根据事件分类进行调整，明确现场工程师处理的事件类型）
205 1. 根据知识库及时对现场技术服务与故障进行处理。
206
207 1. 如果现场故障无法及时解决，可反馈一线支持升级二线支持。
208 1. 故障解决后，要更新相关信息，将故障的解决步骤、已知错误、解决方案/变通方法进行文档化，确保信息的完整性、准确性。
209 1. 事件解决后，要及时反馈结果给服务台/一线支持。
210 )))|(% style="width:369px" %)(((
211 1. 熟悉事件管理流程和现场工程师的职责
212 1. 熟悉现场技术平台和技术环境
213 1. 具备现场技术服务与支持的能力
214 1. 具备快速诊断现场故障和解决现场故障的能力
215 1. 较强的沟通能力
216 )))
217 |(% style="width:114px" %)二线支持|(% style="width:854px" %)(((
218 负责处理服务台或一线支持直接分派的事件，以及一线支持升级的故障类事件。
219
220 1. 接受与处理服务台或一线支持分派的事件申告。
221 1. 接受一线支持升级的故障类事件，并验证事件描述的准确性与完整性，进一步收集故障信息。
222 1. 在SLA规定的时间内解决故障申告。
223 1. 在故障无法及时解决时，应及时提出第三方/供应商支持，或利用其它资源参与，确保故障解决。
224
225 1. 根据知识库及时解决故障。
226
227 1. 对利用变通方法解决的事件，或无法解决的事件，应将事件升级为问题，提交问题管理流程查找事件的根本原因。
228 1. 向现场服务人员提供必要的技术支持。
229 1. 在事件处理过程中，解决方案涉及变更时，需向变更管理流程发起变更申请单（RFC），监督并确认变更结果。
230 1. 已解决的事件要反馈服务台/一线支持，由服务台/一线支持关闭事件。
231 1. 故障解决后，在反馈服务台/一线支持之前要更新相关信息，将事件的解决步骤、已知错误、解决方案/变通方法进行文档化，确保信息的完整性、准确性，并提交服务台/一线支持，申请将解决方案纳入知识库中。
232 1. 负责给用户和服务台/一线支持人员提供技术培训。
233 )))|(% style="width:369px" %)(((
234 1. 熟悉技术平台和技术环境.
235 1. 很强的技术能力
236 1. 较强的解决事件的能力
237 1. 较强的分析能力
238 )))
239 |(% style="width:114px" %)应急小组|(% style="width:854px" %)(((
240 负责重大事件的处理与善后工作。
241
242 1. 接受和处理重大事件，并将已解决的重大事件反馈服务台/一线支持，由服务台/一线支持关闭事件。
243 1. 根据事件类型，实施相关的应急预案。
244 1. 在重大事件处理过程中，根据事态启动服务持续性计划。
245 1. 对重大事件进行深入的研究与讨论，分析事件根本原因，并提出解决方案或紧急处理方案。
246 1. 在重大事件处理过程中，方案涉及变更时，需向变更管理流程发起紧急变更申请，监督并确认变更结果。
247 1. 在确保尽快提供解决方案的前提下，有权根据相关流程缩减工作步骤。
248 1. 完成重大事件的善后处理工作，向有关各方通报事件处理状况，收集整理事件解决方案，并将事件、问题解决步骤文档化，提交知识管理流程将其加入知识库中。
249 )))|(% style="width:369px" %)(((
250 1. 具备应急处理意识与经验
251 1. 熟悉相关技术平台和技术环境.
252 1. 很强的应急处理能力
253 1. 较强的分析判断能力
254 1. 较强的沟通协调能力
255 )))
256
257
258
259 = **4. 流程准则** =
260
261 == **4.1 执行准则** ==
262
263 === **4.1.1 常规原则** ===
264
265 1. 服务台/一线支持作为事件的总责任人，应监督事件的处理过程，负责事件的记录与最终关闭。
266 1. 服务台/一线支持应查看并监督用户申告事件相关表单等信息的完整性、准确性。
267 1. 在事件全生命周期管理中，服务台/一线支持从事件记录开始到事件关闭为止， 需要监督事件的影响及处理情况。
268 1. 所有事件都应该被记录，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案等相应的信息。同时，在事件关闭前应确保相关文档完整、全面、准确并归档。
269 1. 在建立知识库过程中，相关支持人员需要对其进行定期更新与维护，同时服务台及支持人员具有受限的访问权限。
270 1. 服务台及支持人员要按照服务级别协议规定的时限对事件进行处理。当事件处理发生冲突时，应优先处理重大紧急事件或优先级高的事件；如果优先级别相同，则优先处理相对简单事件。
271 1. 在事件处理过程中，服务台/一线支持应随时保持与用户的沟通，通知用户事件处理进展状况。若不能按照预期恢复，应提前告知用户，并采取相应措施，取得用户的认可。
272 1. 应定期（每月/半月/周）产生事件管理报告，应定期举行事件管理会议对重复发生的事件和通过变通方法解决的事件进行评估分析，为找出根本问题提供依据。
273 1. 应该定期（半年/季/月/周）对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以持续改进事件管理流程。
274 1. 事件主要来源于用户的电话、邮件、短信和自助平台，以及告警系统对事件的触发等几种情况。其中服务台主要受理来自用户电话、自助平台的事件申告；一线支持主要受理来自助平台、邮件、短信和告警系统的事件申告。
275 1. 用户发起的预授权变更走事件管理的服务请求事件流程；IT支持人员发起的变更都走变更管理流程。
276
277 === ===
278
279 === **4.1.2 分配原则** ===
280
281 事件的分配原则具体描述如下：
282
283 1. 服务台/一线支持不能解决事件，将事件分配给适合的二线支持工作组或二线支持人员。当不确定具体分配人时，可不填写支持人员。二线支持工作组的所有人员都能看到分派到本组的事件申请单，当二线支持人员接管事件的处理时，应将自己填入到分配人中。
284 1. 二线支持人员对不适合自己处理的事件，一定要先退回原分派的服务台/一线支持，由服务台/一线支持重新分配。
285 1. 通常情况，服务台/一线支持重新分配的次数建议不要超过4次。
286
287 === ===
288
289 === **4.1.3 通知原则** ===
290
291 通知原则的目的是提醒与事件相关的事件处理人、事件经理和管理层，以便及时地了解事件发展的状况，做出快速的应对，有效地监控事件流程的整体运行情况。
292
293 1. 如果事件没有在线解决，需要通过邮件、电话、短信等方式告知用户。
294 1. 事件被分配，有具体的分配人则通知到人，如只有分配工作组，则通知所有组内人员
295 1. 事件超过响应时限、即将超过和已经超过解决时限，要通知事件相关人员。（具体参见《事件响应、解决和通告时限规定文档》）
296 1. 出现重大事件时，事件经理要及时通知上级主管部门及人员。
297 1. 事件已经解决，但无法电话联系用户时，需通过邮件、短信等手段通知用户，用户24小时内没有异议则默认事件关闭。
298
299 === ===
300
301 === **4.1.4 升级原则** ===
302
303 制定升级原则的目的是确保事件在服务级别协议（SLA）规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，从而提供合适的资源，以快速找到解决事件的方案。
304
305 1. 服务台/一线支持应对事件的影响程度和影响范围，以及紧急程度进行初步评估，如果事件的影响范围广，影响程度深，时效性要求高的事件可以升级为重大事件，由事件经理直接负责。（可参考事件优先级划分文档及重大事件分类文档）
306 1. 服务台/一线支持对超出能力范围的事件应升级到二线支持处理，同时将事件相关信息转移给二线支持; 如果二线支持仍然无法及时解决，可申请第三方/供应商支持，事件经理根据UC或处理成本等评估进行审批，由二线支持和第三方/供应商共同解决。
307 1. 事件经理应将网管中心现有技术水平无法控制和解决的重大紧急事件升级第三方/供应商支持，以借助外部资源进口解决事件，确保业务尽快恢复正常；同时，根据网管中心要求上报有关领导与机构。
308 1. 对于升级的事件，处理人员应填写相关的申请表单或标注升级标记后，交由他人处理。
309
310
311 === **4.1.5 关闭原则** ===
312
313 用户申报的事件关闭必须由受理事件的服务台/一线支持完成。
314
315 1. 服务台/一线支持在事件关闭前，应与用户进行沟通，了解事件支持与处理的服务效率，服务质量和服务态度。
316 1. 服务台应定期与客户针对已关闭的事件进行回顾，了解客户的反馈。
317 1. 服务台/一线支持在关闭事件前，应将事件生命周期中所产生的所有表单信息进行归档。
318 1. 对于暂时恢复的事件，在事件关闭时，服务台/一线支持应将其升级为问题管理，并填写相应的问题申请单。
319 1. 已关闭的事件不允许重开。如果一个事件重复发生，则应创建一个新的事件申请单。
320 1. 如果事件存在相关联的问题或变更，应等待问题或变更关闭后才能关闭原事件。
321
322
323 == **4.2 流程关联原则** ==
324
325 事件管理与问题管理、变更管理、发布管理、配置管理、可用性管理和能力管理存在以下关联原则：
326
327 * 和问题管理的关联
328 ** 通过临时解决方法解决的事件在恢复客户IT服务后，都应该创建问题单，问题单需和事件申请单要建立关联。
329 ** 相关问题解决以后，需要将解决方案等信息反馈到事件管理流程中，从而避免故障的重复发生。
330 * 和变更管理的关联
331 ** 事件处理过程中，如果需要对系统进行变更，必须按照变更管理流程的规定，提交变更申请单（变更单和事件申请单要建立关联），变更完成后，再继续事件申请单的处理。
332 ** 当发生重大事件时，如果需要对系统进行变更，必须按照变更管理流程的规定，提出紧急变更请求。变更完成后，如果没有填写紧急变更单，必须补录紧急变更单，并要和重大事件申请单建立关联。
333 ** 对于错误或者不成功的变更所引起的事件，需要按照事件管理流程进行解决和改善。
334 * 和配置管理的关联
335 ** 事件处理过程中，可以通过配置管理查询相关的配置项信息以及该配置项历史上发生的事件或变更，来帮助故障的定位。
336 ** 事件处理过程中，如果可以将故障定位到某个配置项，则必须将事件申请单与该配置项关联。
337 ** 对于配置项等信息的修改，需要及时反馈给事件经理，并走变更管理流程，以避免由此引发新的故障。
338 * 和发布管理的关联
339 ** 不成功的发布可能触发新事件的产生，其触发的事件按照事件管理流程进行解决和恢复。
340 ** 发布管理流程应向事件管理流程提供发布的相关信息，包括：年度发布计划，发布信息等，以确保事件管理的有效控制。
341 * 和可用性管理/能力管理的关联
342 ** 在日常系统检测中，当发现的IT基础设施问题或一些潜在故障时，应通过事件管理流程进行解决。
343 ** 当发生的事件需要调整相关的可用性指标和能力指标时，例如安全事件处理，则需要在通过可用性与能力的完善和修改后，反馈事件管理流程。
344 * 和知识管理的关联
345 ** 在事件处理过程中，会调用知识库中与事件相关的知识。
346 ** 事件处理完毕后，如果知识库没有处理相关事件的解决方案或变通方法。则可将该事件处理的解决方案/变通方法通告知识管理存入知识库中。
347
348
349 (% style="text-align:center" %)
350 [[image:1730193362660-174.png]]
351
352
353 == **4.3 入口原则** ==
354
355 合同范围内，事件管理流程运作过程中需要输入的信息包括：
356
357 1. 用户通过电话、邮件、自助平台等方式申告的事件
358 1. IT环境中监控系统的告警事件
359 1. 服务人员巡检过程中发现或其他人员转告的申告事件
360 1. 配置管理数据库(CMDB)提供的相关配置信息（CI）
361 1. 知识库提供的已知错误及解决方案信息
362 1. 供应商提供的其产品信息，包括产品技术细节和产品本身存在的已知错误
363 1. 服务目录和服务级别协议(SLA)
364
365
366 |名称|描述|模板|输入
367 |(((
368 故障申告
369
370 服务请求
371 )))|(((
372 1. 客户IT系统故障详细信息，包括：客户信息、故障描述，故障类型，影响及紧急程度等
373 1. 客户对IT环境及业务系统的应用服务需求
374 )))|事件申请单|(((
375 用户
376
377 可用性管理
378
379 能力管理
380 )))
381 |配置信息|(((
382 1. 与事件关联的配置项信息
383 )))|CMDB|配置管理
384 |(((
385 已知错误
386
387 解决方案
388 )))|(((
389 1. 与事件关联的已知错误信息及相关的解决方案
390 )))|知识库|知识库
391 |产品信息|(((
392 1. 供应商提供的与事件相关的产品信息，包括产品的缺陷、功能、应用范围等
393 )))|产品信息|供应商
394 |(((
395 服务目录
396
397 服务级别协议
398 )))|(((
399 1. 网管中心级的服务级别协议及服务目录
400 )))|(((
401 服务目录
402
403 服务级别协议
404 )))|服务级别管理
405
406
407 |序号|来源方式|说明
408 |1|电话|用户通过电话申告的事件，需要服务台/一线支持人员创建事件申请单。
409 |2|邮件|用户通过电子邮件向服务台/一线支持人员申报事件。
410 |3|自助平台|用户通过自助平台（网上）填写事件申请单申报事件。
411 |4|监控告警|通过后台监控软件/工具自动转发事件。
412
413
414 == **4.4 出口原则** ==
415
416 合同范围内，事件管理流程运作过程中需要输出的信息包括：
417
418 1. 向用户提供事件的处理措施或解决方案
419 1. 事件处理过程中，涉及变更时需向变更管理流程提出变更申请
420 1. 事件没有的得到根本解决，向问题管理流程提出问题解决申请
421 1. 事件处理过程中，涉及配置信息的变更，向配置管理流程提出配置申请
422 1. 根据事件管理情况，定期提供事件管理的相关分析报告
423
424
425 |名称|(% style="width:840px" %)描述|(% style="width:148px" %)模板|(% style="width:192px" %)输出
426 |(((
427 故障解决方案
428
429 服务请求处理信息
430 )))|(% style="width:840px" %)(((
431
432
433 * 根据用户提出的故障申告及服务请求申告，及时提供有关的解决方案及处理措施
434 )))|(% style="width:148px" %)事件申请单|(% style="width:192px" %)用户
435 |变更申请|(% style="width:840px" %)(((
436
437
438 * (% id="cke_bm_1143S" style="display:none" %) (% id="cke_bm_1091S" style="display:none" %) (%%)事件处理中涉及的变更申请，包括变更目标、内容、策略、联系人等(% id="cke_bm_1143E" style="display:none" %) (% id="cke_bm_1091E" style="display:none" %)
439 )))|(% style="width:148px" %)变更申请单|(% style="width:192px" %)变更管理
440 |配置更新|(% style="width:840px" %)(((
441
442
443 * (% id="cke_bm_1142S" style="display:none" %) (% id="cke_bm_1090S" style="display:none" %) (%%)事件处理中涉及配置信息的更新时，提出的配置更新，包括配置内容、时间等(% id="cke_bm_1142E" style="display:none" %) (% id="cke_bm_1090E" style="display:none" %)
444 )))|(% style="width:148px" %)配置申请表|(% style="width:192px" %)配置管理
445 |问题申请|(% style="width:840px" %)(((
446
447
448 * (% id="cke_bm_1141S" style="display:none" %) (% id="cke_bm_1089S" style="display:none" %) (%%)故障没有得到根本解决，需升级为问题时，向问题管理流程提供问题申请(% id="cke_bm_1141E" style="display:none" %) (% id="cke_bm_1089E" style="display:none" %)
449 )))|(% style="width:148px" %)问题申请表|(% style="width:192px" %)问题管理
450 |解决方案|(% style="width:840px" %)(((
451
452
453 * (% id="cke_bm_1140S" style="display:none" %) (% id="cke_bm_1088S" style="display:none" %) (%%)通过诊断分析，确定了处理事件的解决方案/变更方法，则可通告知识管理流程将解决方案/变更方法保存到知识库中。(% id="cke_bm_1140E" style="display:none" %) (% id="cke_bm_1088E" style="display:none" %)
454 )))|(% style="width:148px" %)(((
455 知识提交单
456
457 解决方案/
458
459 变通方法
460 )))|(% style="width:192px" %)知识管理
461 |服务报告|(% style="width:840px" %)(((
462
463
464 * (% id="cke_bm_1139S" style="display:none" %) (% id="cke_bm_1087S" style="display:none" %) (%%)定期对事件管理进行回顾，总结服务的质量，效率等信息(% id="cke_bm_1139E" style="display:none" %) (% id="cke_bm_1087E" style="display:none" %)
465 )))|(% style="width:148px" %)服务报告|(% style="width:192px" %)(((
466 能力管理
467
468 可用性管理
469
470 服务级别管理
471 )))
472
473
474
475 = **5. 工作流程** =
476
477 == **5.1 事件管理主流程** ==
478
479 === **5.1.1 流程描述** ===
480
481 此流程是事件管理的主流程，它涵盖了事件记录与分类分级（帮助台）、事件记录与分类分级（一线支持）、服务请求处理、重大事件处理、故障一线支持与处理、故障二线支持与处理、协调第三方支持和事件关闭等子流程。事件管理流程主要是为了帮助用户迅速解决事件，并确保事件对业务的不利影响最小化。流程始于事件的接收和申告，结束于经过用户确认的事件的解决。
482
483 === ===
484
485 === **5.1.2 流程图** ===
486
487 (% style="text-align:center" %)
488 [[image:图片9.jpg]]
489
490
491
492 === **5.1.3 流程说明** ===
493
494 |序号|活动/子流程|(% style="width:769px" %)描述|(% style="width:102px" %)输入|(% style="width:125px" %)输出|责任人
495 |1|开始|(% style="width:769px" %)流程的起始节点|(% style="width:102px" %) |(% style="width:125px" %) |
496 |2|(((
497 INC-01
498
499 事件记录与分类分级（服务台）
500 )))|(% style="width:769px" %)(((
501
502
503 * 服务台受理来自电话、自助平台的事件申告（包括服务请求、故障申告）。
504 * 服务台既承担着受理事件申告的职责，也承担着处理服务请求类事件的职责。
505 * 服务台根据用户的申告，创建事件记录，收集所需信息，确保记录信息的准确和完整。
506 * 服务台根据事件的分类与优先级，将事件直接分派给一线支持、现场工程师、二线支持和事件经理等不同的角色进行处理。
507 )))|(% style="width:102px" %)事件申请单|(% style="width:125px" %)事件申请单|服务台
508 |3|(((
509 INC-02
510
511 事件记录与分类分级（一线支持）
512 )))|(% style="width:769px" %)(((
513
514
515 * 一线支持受理来自自助平台、邮件、短信和告警系统的事件申告（包括服务请求、故障申告）。
516 * 一线支持既承担着受理事件申告的职责，也承担着处理服务请求类事件和故障类事件的职责。
517 * 一线支持根据用户的申告，创建事件记录，收集所需信息，确保记录信息的准确和完整。
518 * 一线支持根据事件的分类与优先级，将事件直接分派给、现场工程师、二线支持和事件经理等不同的角色进行处理。
519 )))|(% style="width:102px" %)事件申请单|(% style="width:125px" %)事件申请单|一线支持
520 |4|(((
521 INC-03
522
523 服务请求事件处理
524 )))|(% style="width:769px" %)(((
525
526
527 * 服务台/一线支持处理服务请求类事件。
528 * 服务台根据服务请求的类型，将事件分派给一线支持、现场工程师、二线支持等不同角色处理。
529 * 一线支持根据服务请求的类型，将事件分派给现场工程师、二线支持等不同角色处理。
530 * 如果一线支持受理的服务请求类的事件是服务台所负责的服务请求类事件，则由一线支持直接转派给服务台处理。
531 * 如果服务请求事件是关于客户需求、客户服务建议等信息，则由服务台记录基本信息后，关闭事件，并将信息转给相关流程。
532 )))|(% style="width:102px" %)事件申请单|(% style="width:125px" %)(((
533 事件申请单
534
535 投诉建议
536
537 客户需求
538 )))|(((
539 服务台/
540
541 现场工程师
542 )))
543 |5|(((
544 INC-04
545
546 重大事件处理
547 )))|(% style="width:769px" %)(((
548
549
550 * 接受对服务台/一线支持分派的重大故障处理。
551 * 事件经理组织启动相关的紧急预案，并上报相关机构与领导。
552 * 事件经理组织协调各方资源，支持应急小组分析诊断与解决重大故障。
553 * 应急小组尽快解决重大故障，并负责善后处理工作。
554 * 在解决重大故障的过程中，如果需要变更，需提出紧急变更请求，走变更管理流程。
555 )))|(% style="width:102px" %)事件申请单|(% style="width:125px" %)事件申请单|(((
556 事件经理
557
558 应急小组
559 )))
560 |6|(((
561 INC-05
562
563 故障一线支持与处理
564 )))|(% style="width:769px" %)(((
565
566
567 * 处理服务台分派或一线支持受理的故障类事件。
568 * 根据知识库处理常规故障。
569 * 通过故障分析与诊断，提出故障解决方案/变通方法。
570 * 在解决故障的过程中，如果需要发生变更，则需提出变更请求，走变更管理流程。
571 * 如果在时限内无法解决故障，则需将故障升级二线支持处理。
572 * 故障解决后，需对故障的解决方案或变通方法进行文档化。
573 * 故障处理后，需反馈故障处理结果给分派方（服务台）。
574 )))|(% style="width:102px" %)(((
575 事件申请单
576
577 已知错误
578
579 解决方案
580 )))|(% style="width:125px" %)事件申请单|一线支持
581 |7|(((
582 INC-06
583
584 故障二线支持与处理
585 )))|(% style="width:769px" %)(((
586
587
588 * 处理服务台分派的故障类事件。
589 * 接受与处理一线支持升级的故障类事件。
590 * 通过故障分析与诊断，提出故障解决方案/变通方法。
591 * 在解决故障的过程中，如果需要发生变更，则需提出变更请求，走变更管理流程。
592 * 在规定时限内无法解决的故障，需升级协调第三方支持。
593 * 故障处理后，对故障的解决方案或变通方法进行文档化。
594 * 故障处理后，需反馈故障处理结果给分派方（服务台或一线支持）。
595 )))|(% style="width:102px" %)(((
596 事件申请单
597
598 已知错误
599
600 解决方案
601 )))|(% style="width:125px" %)(((
602 事件申请单
603
604 变更申请单
605 )))|二线支持
606 |8|(((
607 INC-07
608
609 协调第三方支持
610 )))|(% style="width:769px" %)(((
611
612
613 * 二线支持无法在规定时限内解决的故障，升级第三方/供应商处理。
614 * 根据需要对故障处理的相关信息进行整理和归类。
615 * 将整理后的信息提供给第三方/供应商。
616 * 定期与第三方/供应商进行沟通，确保故障及时解决。
617 * 二线支持申请第三方/供应商提供支持时，必须通过事件经理审批。事件经理将从故障处理成本、服务级别协议指标等因素综合考虑。
618 )))|(% style="width:102px" %)(((
619 事件申请单
620
621 第三方申请单
622 )))|(% style="width:125px" %)事件申请单|事件经理
623 |9|(((
624 INC-08
625
626 事件关闭
627 )))|(% style="width:769px" %)(((
628
629
630 * 事件关闭之前，需要受理方（服务台或一线支持）及时通知用户，并沟通事件处理效果，得到认可后关闭事件。
631 * 回顾事件处理，如果故障是采用变通方法解决的，同时需要进一步找出故障的根本原因，则需要提起问题申请单，交问题管理流程。
632 * 根据故障处理结果，受理方（服务台或一线支持）需完善故障处理过程的相关文档
633 * 如果需要将已确定的解决方案/变通方法存入知识库中，则需提交知识申请单，走知识管理流程。
634 * 事件关闭遵循首问责任制，谁受理谁负责谁关闭的原则。
635 )))|(% style="width:102px" %)事件申请单|(% style="width:125px" %)(((
636 事件申请单
637
638 问题申请单
639
640 知识申请单
641 )))|(((
642 服务台/
643
644 一线支持
645 )))
646 |10|结束|(% style="width:769px" %)流程结束节点。|(% style="width:102px" %) |(% style="width:125px" %) |
647
648
649 == **5.2 子流程1：事件记录与分类分派（服务台）** ==
650
651 === **5.2.1 子流程描述** ===
652
653 该子流程是事件管理流程的起始点之一，是服务台受理来自电话、自助平台等渠道的服务请求类和故障类事件，并有效记录事件信息，以及根据事件分类分级进行事件分派的管理流程。服务台通过规范的流程不仅可确保事件信息记录的准确性与完整性，同时通过正确的事件分类分级和事件分派，还可达到提高事件处理质量与效率的目的。
654
655 === ===
656
657 === **5.2.2 流程图** ===
658
659 (% style="text-align:center" %)
660 [[image:图片10.jpg]]
661
662
663 === **5.2.3 流程说明** ===
664
665 |序号|活动/子流程|描述|输入|输出|责任人
666 |1|开始|流程的起始节点 。|-|-|
667 |2|(((
668 L1.1
669
670 是否来自自助平台
671 )))|(((
672
673
674 * 判断用户申告的事件是来自自助平台，还是电话。
675 * 如果来自自助平台，事件信息自动导入。
676 * 如果来自电话，需要服务台进行事件记录。
677 * 自助平台发起的事件已有事件的信息记录；电话发起的事件需要服务台帮助记录。
678 )))|-|-|服务台
679 |3|(((
680 L1.2
681
682 事件记录
683 )))|(((
684
685
686 * (% id="cke_bm_11576S" style="display:none" %) (%%)服务台根据用户的申告，记录事件信息。
687 * 可通过工具对事件信息进行详细记录，包括事件症状，影响，申告人、联系方式等信息。
688 * 工具既可以是IT服务支持的平台工具，也可采用Excel，Word等工具。(% id="cke_bm_11576E" style="display:none" %)
689 )))|用户信息|事件信息|服务台
690 |4|(((
691 L1.3
692
693 判断服务范围
694 )))|(((
695
696
697 * (% id="cke_bm_11575S" style="display:none" %) (%%)服务台根据网管中心IT运维服务的服务目录和服务级别协议对受理的事件信息，判断是否在网管中心IT运维服务范围。
698 * 如果不在服务范围，则直接回复用户。
699 * 如果在服务范围，则受理服务请求，验证事件信息的完整性。(% id="cke_bm_11575E" style="display:none" %)
700 )))|-|-|
701 |5|(((
702 L1.4
703
704 回复/配合
705 )))|(((
706
707
708 * (% id="cke_bm_11841S" style="display:none" %) (%%)直接回复用户，解释其服务请求不在网管中心IT运维服务范围内。
709 * 如果是VIP客户，可适当配合，提供一定的协助咨询服务。
710 * 如果用户提供的信息是需求信息，可记录之后，转给相关部门或需求管理流程。(% id="cke_bm_11841E" style="display:none" %)
711 )))|事件信息|回复信息|服务台
712 |6|(((
713 L1.5
714
715 事件信息完整性
716
717 确认
718 )))|(((
719
720
721 * 服务台根据事件信息，生成事件申请单，正式受理用户事件申告。
722 * 如果发现事件信息不准确、不完整，需与用户进行沟通，完善事件申请单的信息。
723 )))|事件信息|事件申请单|服务台
724 |7|(((
725 L1.6
726
727 判断事件类别
728 )))|(((
729
730
731 * 根据事件分类规则，判断事件类型，可具体到事件分类三级。
732 * 如果是服务请求类事件，标注服务请求类。
733 * 如果是故障类事件，需进行故障等级判断。
734 )))|事件申请单|事件申请单|服务台
735 |8|(((
736 L1.7
737
738 转INC-03:服务请求处理流程
739 )))|(((
740
741
742 * 将事件申请单直接转服务请求处理流程，对事件进行处理。
743 )))|事件申请单|事件申请单|服务台
744 |9|(((
745 L1.8
746
747 判断故障优先级
748 )))|(((
749
750
751 * 根据故障的影响度和紧急度，判断故障的优先级。
752 * 事件的优先级可参考《事件分级》相关文件的定义。
753 )))|-|-|
754 |10|(((
755 L1.9
756
757 转INC-06:重大事件处理流程
758 )))|(((
759
760
761 * 服务台根据事件优先级的规则，判断事件等级是极高，则标记事件为重大事件，并提交重大事件处理流程。
762 * 一般事件的影响度和紧急度会有初始设定，服务台根据与用户的交流，可更新其影响度和紧急度，改变故障优先级。
763 )))|事件申请单|事件申请单|服务台
764 |11|(((
765 L1.10
766
767 判断重复故障
768 )))|(((
769
770
771 * 判断是否是重复性故障申告，如果是，则进行重复性故障处理。
772 )))|-|-|服务台
773 |12|(((
774 L1.11
775
776 重复故障处理
777 )))|(((
778
779
780 * 若用户提报的事件为重复故障，则服务台需要关联相对应的主事件，并按照主事件的解决方案进行处理。
781 )))|事件申请单|事件申请单|服务台
782 |13|(((
783 L1.12
784
785 故障派单
786 )))|(((
787
788
789 * 如果申告的故障等级非极高，则根据故障类型进行任务分配。
790 * 服务台“分派”的故障事件，最终事件处理完成后，需要反馈事件处理结果由服务台关闭此事件。
791 )))|-|-|服务台
792 |14|(((
793 L1.13
794
795 分派现场服务
796 )))|(((
797
798
799 * 如果需要现场故障处理，则派单现场工程师实施现场服务
800 )))|事件申请单|(((
801 现场工单
802
803 事件申请单
804 )))|服务台
805 |15|(((
806 L2.1
807
808 现场服务
809 )))|(((
810
811
812 * 现场工程师到用户现场进行故障处理。
813 )))|(((
814 现场工单
815
816 事件申请单
817 )))|事件申请单|(((
818 现场
819
820 工程师
821 )))
822 |16|(((
823 L2.2
824
825 反馈服务结果
826 )))|(((
827
828
829 * 现场服务完成后，需反馈现场故障处理情况，包括故障现象、解决方案、是否解决等
830 )))|事件申请单|事件申请单|(((
831 现场
832
833 工程师
834 )))
835 |17|(((
836 L1.14
837
838 分派一线支持
839 )))|(((
840
841
842 * 如果需要一线支持提供服务，则直接分派一线支持，并转一线支持与处理流程。
843 )))|事件申请单|事件申请单|服务台
844 |18|(((
845 L1.15
846
847 分派二线支持
848 )))|(((
849
850
851 * 如果需要二线支持提供服务，则直接分派二线支持，并转二线支持与处理流程。
852 )))|事件申请单|事件申请单|服务台
853 |19|结束|流程结束节点。| | |
854
855
856 == **5.3 子流程2：事件记录与分类分派（一线支持）** ==
857
858 === **5.3.1 子流程描述** ===
859
860 该子流程是事件管理流程的起始点之一，是一线支持受理来自自助平台、邮件、短信和告警系统等渠道的服务请求类和故障类事件，并有效记录事件信息，以及根据事件分类分级进行事件分派的管理流程。一线支持通过规范的流程不仅可确保事件信息记录的准确性与完整性，同时通过正确的事件分类分级和事件分派，可达到提高事件处理质量与效率的目的。
861
862 === ===
863
864 === **5.3.2 流程图** ===
865
866 (% style="text-align:center" %)
867 [[image:图片11.jpg]]
868
869
870 === **5.3.3 流程说明** ===
871
872 |序号|活动/子流程|描述|输入|输出|责任人
873 |1|开始|流程的起始节点 。|-|-|
874 |2|(((
875 L1.1
876
877 是否来自告警系统
878 )))|(((
879
880
881 * 判断用户申告的事件是来自告警系统，还是自助平台、邮件、短信。
882 * 如果是告警系统发起的事件，则直接确认事件信息的完整性。
883 * 如果事件来自自助平台、邮件、短信等渠道，需要一线支持进行服务范围的判断。
884 * 告警系统发起的事件都是故障类事件；自助平台、邮件、短信等渠道发起的事件包括服务请求类和故障类事件。
885 )))|-|-|一线支持
886 |3|(((
887 L1.2
888
889 判断服务范围
890 )))|(((
891
892
893 * 一线支持根据网管中心IT运维服务的服务目录和服务级别协议对受理的事件信息，判断是否在网管中心IT运维服务范围。
894 * 如果不在服务范围，则直接回复用户。
895 * 如果在服务范围，则受理服务请求，验证事件信息的完整性。
896 )))|-|-|
897 |4|(((
898 L1.3
899
900 回复/配合
901 )))|(((
902
903
904 * 直接回复用户，解释其服务请求不在网管中心IT运维服务范围内。
905 * 如果是VIP客户，可适当配合，提供一定的配合性服务。
906 * 如果用户提供的信息是需求信息，可记录之后，转给相关部门或需求管理流程。
907 )))|事件信息|回复信息|一线支持
908 |5|(((
909 L1.4
910
911 事件信息完整性
912
913 确认
914 )))|(((
915
916
917 * 一线支持根据事件信息，生成事件申请单，正式受理用户事件申告。
918 * 如果发现事件信息不准确、不完整，需与用户进行沟通，完善事件申请单的信息。
919 )))|事件信息|事件申请单|一线支持
920 |6|(((
921 L1.5
922
923 判断事件类别
924 )))|(((
925
926
927 * 根据事件分类规则，判断事件类型，可具体到事件分类三级。
928 * 如果是服务请求类事件，标注服务请求类。
929 * 如果是故障类事件，需进行故障等级判断。
930 )))|事件申请单|事件申请单|一线支持
931 |7|(((
932 L1.6
933
934 转INC-03:服务请求处理流程
935 )))|(((
936
937
938 * 将事件申请单直接转服务请求处理流程，对事件进行处理。
939 )))|事件申请单|事件申请单|一线支持
940 |8|(((
941 L1.7
942
943 判断故障优先级
944 )))|(((
945
946
947 * 根据故障的影响度和紧急度，判断故障的优先级。
948 * 事件的优先级可参考《事件分级》相关文件的定义。
949 )))|-|-|
950 |9|(((
951 L1.8
952
953 转INC-06:重大事件处理流程
954
955
956 )))|(((
957
958
959 * 根据事件优先级的规则，判断事件等级是极高，则标记事件为重大事件，并提交重大事件处理流程。
960 * 一般事件的影响度和紧急度会有初始设定，一线支持根据与用户的交流，可更新其影响度和紧急度，改变故障优先级。
961 )))|事件申请单|事件申请单|一线支持
962 |10|(((
963 L1.9
964
965 判断重复故障
966 )))|(((
967
968
969 * 判断是否是重复性故障申告，如果是，则进行重复性故障处理。
970 )))|-|-|服务台
971 |11|(((
972 L1.10
973
974 重复故障处理
975 )))|(((
976
977
978 * 若用户提报的事件为重复故障，则服务台需要关联相对应的主事件，并按照主事件的解决方案进行处理。
979 )))|事件申请单|事件申请单|服务台
980 |12|(((
981 L1.11
982
983 故障派单
984 )))|(((
985
986
987 * 如果申告的故障等级非极高，则根据故障类型进行任务分配。
988 * 一线支持“分派”的故障事件，最终事件处理完成后，需要反馈事件处理结果由一线支持关闭此事件。
989 )))|-|-|一线支持
990 |13|(((
991 L1.12
992
993 分派现场服务
994 )))|(((
995
996
997 * 如果需要现场故障处理，则派现场工单给现场工程师实施现场服务
998 )))|事件申请单|(((
999 现场工单
1000
1001 事件申请单
1002 )))|一线支持
1003 |14|(((
1004 L2.1
1005
1006 现场服务
1007 )))|(((
1008
1009
1010 * 现场工程师到用户现场进行故障处理。
1011 )))|(((
1012 现场工单
1013
1014 事件申请单
1015 )))|事件申请单|(((
1016 现场
1017
1018 工程师
1019 )))
1020 |15|(((
1021 L2.2
1022
1023 反馈服务结果
1024 )))|(((
1025
1026
1027 * 现场服务完成后，需向一线支持反馈现场故障处理情况，包括故障现象、解决方案、是否解决等。
1028 )))|事件申请单|事件申请单|(((
1029 现场
1030
1031 工程师
1032 )))
1033 |16|(((
1034 L1.13
1035
1036 分派二线支持
1037 )))|(((
1038
1039
1040 * 如果需要二线支持提供服务，则直接分派二线支持，并转二线支持与处理流程。
1041 )))|事件申请单|事件申请单|一线支持
1042 |17|结束|流程结束节点。| | |
1043
1044
深圳市艾拓先锋企业管理咨询有限公司