Last modified by superadmin on 2024/10/29, 18:58
From version < 2.1 >
edited by superadmin
on 2024/10/29, 17:18
To version < 4.1 >
edited by superadmin
on 2024/10/29, 17:23
< >
Change comment: 上传新附件图片11.jpg

Summary

Details

Icon Page properties
Title
... ... @@ -1,0 +1,1 @@
1 +18 某通信集团网络管理中心IT服务管理体系文件ITIL事件管理流程
Parent
... ... @@ -1,0 +1,1 @@
1 +G 参考资料.ITIL实施项目资料.ITIL实施项目流程设计方案集.事件管理.WebHome
Content
... ... @@ -1,0 +1,660 @@
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]]
Icon 图片10.jpg
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +109.3 KB
Content Icon
Icon 图片11.jpg
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +101.3 KB
Content Icon
深圳市艾拓先锋企业管理咨询有限公司