客户对服务支持不满的诉讼请求，包括：支持质量，支持效率，支持态度等；

客户对服务支持过程中提出的意见和建议。

事件管理

流程负责人

事件管理流程负责人从宏观上监控流程，确保事件管理流程在网管中心被正确的执行。当流程不能适应网管中心的实际情况时，事件管理流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。

1. 确定事件管理流程的衡量指标。
2. 确保事件管理流程能够取得管理层的参与和支持。
3. 确保事件管理流程符合网管中心IT发展战略和实际状况。
4. 总体上管理和监控事件管理流程，建立事件管理流程的实施、评估和持续优化机制。
5. 确保事件管理流程实用、有效、正确地执行，当流程不能够适应网管中心的情况时，必须及时进行分析，找出缺陷，进行改进(例如增加或合并流程的角色)，从而实现可持续提高。
6. 保持与其他流程负责人的定期沟通。

1. 深刻理解事件管理流程
2. 充分理解IT服务管理的其他流程，能够进行流程接口设计
3. 能够很好地理解业务对于事件管理的需求
4. 对质量控制与保障有很深入的了解
5. 有决策权，能够确保事件管理流程设计要求在实施项目中得到贯彻和执行
6. 具有很好的沟通技能，能够取得公司高层的支持，获得所需资源

事件经理负责事件解决过程中的协调和监控，对事件总负责。

1. 总体上负责事件的解决，协调资源，确保故障的最终排除。
2. 出现重大事件时，负责协调资源，启动紧急预案，并及时通知/上报有关机构与人员。
3. 事件处理即将超过规定的解决时限时，负责按照升级原则对事件进行处理，确保有效协调资源，督促支持人员快速恢复正常服务
4. 负责审批二线支持无法及时解决、需协调第三方/供应商支持的升级事件。
5. 负责接受重大事件的处理，判断重大事件的影响度与紧急度，组织或发起应急预案，及时通报相关机构与领导，协助做好善后处理工作。
6. 跟踪及监督超过规定解决时限的事件和客户满意度较低的事件的状况。
7. 确保和事件管理流程负责人的有效合作，改善事件管理流程。
8. 确保正确和广泛地收集和分析事件数据，形成事件管理报告，为问题管理、可用性管理、能力管理和服务级别管理提供依据。
9. 已解决的事件要转告服务台或一线支持，由服务台或一线支持关闭事件。

1. 了解技术架构和技术环境
2. 较强的口头表达能力和与用户沟通技巧
3. 处理纠纷的能力
4. 深刻了解事件管理流程
5. 较强的领导能力

负责受理来自电话、自助平台的服务请求事件和故障申告事件，并有效记录事件信息。根据事件分类分级负责事件的分派，并负责处理部分服务请求事件。

1. 作为与用户进行事件沟通的联系入口。
2. 根据服务级别协议要求，受理来自电话、自助平台的事件申告。
3. 准确、完整地记录所有事件，包括服务请求、故障申告、客户需求、投诉与建议等事件。

1. 对事件进行正确分类分级，并分派到正确的角色（包括服务台、一线支持、现场工程师、二线支持、事件经理等）进行事件处理。
2. 负责部分服务请求类事件的处理，包括咨询服务、知识申请等。（需根据事件分类进行调整，明确服务台所处理的服务请求类事件）
3. 根据知识库负责对服务请求事件的及时处理。

1. 及时与用户直接沟通，向用户通报事件的处理状况。
2. 作为事件的受理者，要及时跟踪、监控事件的处理过程，确保在SLA规定的时间内解决事件，把事件的影响降到最低，确保尽快恢复正常。
3. 事件解决后，在关闭该事件之前要与用户确认事件处理效果及收集用户的满意度。
4. 事件解决后，在关闭该事件之前要更新相关信息，将事件的解决步骤、已知错误、解决方案/变通方法进行文档化，确保信息的完整性、准确性。
5. 事件解决后，在关闭该事件之前，将解决方案/变通方法申请纳入知识库中

1. 熟悉事件管理流程和服务台的职责
2. 熟悉技术平台和技术环境
3. 快速诊断事件和解决事件的能力
4. 较强的沟通能力
5. 较强的倾听能力

负责受理来自自助平台、邮件、短信和告警系统的服务请求事件和故障申告事件，并有效记录事件信息。根据事件分类分级负责事件的分派，并负责处理部分服务请求事件和故障申告事件。

1. 作为与用户进行事件沟通的联络入口。
2. 根据服务级别协议要求，受理来自自助平台、邮件、短信和告警系统的事件申告。
3. 准确、完整地记录所申告的事件信息，包括服务请求、故障申告等。

1. 对事件进行正确分类分级，并分派到正确的角色（包括一线支持、现场工程师、二线支持、事件经理等）进行事件处理。
2. 负责部分服务请求事件和故障申告事件的处理，包括桌面故障、系统应用故障等。（需根据事件分类进行调整，明确一线支持所处理的事件类型）
3. 根据知识库负责对事件的及时处理。

1. 如果故障无法及时解决，需将故障升级二线支持。
2. 及时与用户直接的沟通，向用户通报事件的处理状况。
3. 作为事件的受理者，要及时跟踪、监控故障的处理过程，以确保在SLA规定的时间内处理事件，必要时进行事件升级，把事件的影响降到最低，确保尽快恢复正常。
4. 事件解决后，在关闭该事件之前要与用户确认事件处理效果及收集用户的满意度。
5. 事件解决后，在关闭该事件之前要更新相关信息，将事件的解决步骤、已知错误、解决方案/变通方法进行文档化，确保信息的完整性、准确性。
6. 事件解决后，在关闭该事件之前，需将解决方案/变通方法申请纳入知识库中。
7. 向现场工程师提供必要的支持和协助。

1. 熟悉事件管理流程和一线支持的职责
2. 熟悉技术平台和技术环境
3. 快速诊断故障和解决故障的能力
4. 较强的沟通能力
5. 较强的倾听能力

负责处理现场技术服务与支持，以及现场故障诊断与解决。

1. 负责现场技术服务与支持，包括系统软件安装、桌面工具安装等。（需根据事件分类进行调整，明确现场工程师所处理的事件类型）
2. 负责现场故障的处理，包括桌面系统故障、网络故障等。（需根据事件分类进行调整，明确现场工程师处理的事件类型）
3. 根据知识库及时对现场技术服务与故障进行处理。

1. 如果现场故障无法及时解决，可反馈一线支持升级二线支持。
2. 故障解决后，要更新相关信息，将故障的解决步骤、已知错误、解决方案/变通方法进行文档化，确保信息的完整性、准确性。
3. 事件解决后，要及时反馈结果给服务台/一线支持。

1. 熟悉事件管理流程和现场工程师的职责
2. 熟悉现场技术平台和技术环境
3. 具备现场技术服务与支持的能力
4. 具备快速诊断现场故障和解决现场故障的能力
5. 较强的沟通能力

负责处理服务台或一线支持直接分派的事件，以及一线支持升级的故障类事件。

1. 接受与处理服务台或一线支持分派的事件申告。
2. 接受一线支持升级的故障类事件，并验证事件描述的准确性与完整性，进一步收集故障信息。
3. 在SLA规定的时间内解决故障申告。
4. 在故障无法及时解决时，应及时提出第三方/供应商支持，或利用其它资源参与，确保故障解决。

1. 根据知识库及时解决故障。

1. 对利用变通方法解决的事件，或无法解决的事件，应将事件升级为问题，提交问题管理流程查找事件的根本原因。
2. 向现场服务人员提供必要的技术支持。
3. 在事件处理过程中，解决方案涉及变更时，需向变更管理流程发起变更申请单（RFC），监督并确认变更结果。
4. 已解决的事件要反馈服务台/一线支持，由服务台/一线支持关闭事件。
5. 故障解决后，在反馈服务台/一线支持之前要更新相关信息，将事件的解决步骤、已知错误、解决方案/变通方法进行文档化，确保信息的完整性、准确性，并提交服务台/一线支持，申请将解决方案纳入知识库中。
6. 负责给用户和服务台/一线支持人员提供技术培训。

1. 熟悉技术平台和技术环境.
2. 很强的技术能力
3. 较强的解决事件的能力
4. 较强的分析能力

负责重大事件的处理与善后工作。

1. 接受和处理重大事件，并将已解决的重大事件反馈服务台/一线支持，由服务台/一线支持关闭事件。
2. 根据事件类型，实施相关的应急预案。
3. 在重大事件处理过程中，根据事态启动服务持续性计划。
4. 对重大事件进行深入的研究与讨论，分析事件根本原因，并提出解决方案或紧急处理方案。
5. 在重大事件处理过程中，方案涉及变更时，需向变更管理流程发起紧急变更申请，监督并确认变更结果。
6. 在确保尽快提供解决方案的前提下，有权根据相关流程缩减工作步骤。
7. 完成重大事件的善后处理工作，向有关各方通报事件处理状况，收集整理事件解决方案，并将事件、问题解决步骤文档化，提交知识管理流程将其加入知识库中。

1. 具备应急处理意识与经验
2. 熟悉相关技术平台和技术环境.
3. 很强的应急处理能力
4. 较强的分析判断能力
5. 较强的沟通协调能力

故障申告

服务请求

1. 客户IT系统故障详细信息，包括：客户信息、故障描述，故障类型，影响及紧急程度等
2. 客户对IT环境及业务系统的应用服务需求

用户

可用性管理

能力管理

1. 与事件关联的配置项信息

已知错误

解决方案

1. 与事件关联的已知错误信息及相关的解决方案

1. 供应商提供的与事件相关的产品信息，包括产品的缺陷、功能、应用范围等

服务目录

服务级别协议

1. 网管中心级的服务级别协议及服务目录

服务目录

服务级别协议

故障解决方案

服务请求处理信息

• 根据用户提出的故障申告及服务请求申告，及时提供有关的解决方案及处理措施

•   事件处理中涉及的变更申请，包括变更目标、内容、策略、联系人等  

•   事件处理中涉及配置信息的更新时，提出的配置更新，包括配置内容、时间等  

•   故障没有得到根本解决，需升级为问题时，向问题管理流程提供问题申请  

•   通过诊断分析，确定了处理事件的解决方案/变更方法，则可通告知识管理流程将解决方案/变更方法保存到知识库中。  

知识提交单

解决方案/

变通方法

•   定期对事件管理进行回顾，总结服务的质量，效率等信息  

能力管理

可用性管理

服务级别管理

INC-01

事件记录与分类分级（服务台）

• 服务台受理来自电话、自助平台的事件申告（包括服务请求、故障申告）。
• 服务台既承担着受理事件申告的职责，也承担着处理服务请求类事件的职责。
• 服务台根据用户的申告，创建事件记录，收集所需信息，确保记录信息的准确和完整。
• 服务台根据事件的分类与优先级，将事件直接分派给一线支持、现场工程师、二线支持和事件经理等不同的角色进行处理。

INC-02

事件记录与分类分级（一线支持）

• 一线支持受理来自自助平台、邮件、短信和告警系统的事件申告（包括服务请求、故障申告）。
• 一线支持既承担着受理事件申告的职责，也承担着处理服务请求类事件和故障类事件的职责。
• 一线支持根据用户的申告，创建事件记录，收集所需信息，确保记录信息的准确和完整。
• 一线支持根据事件的分类与优先级，将事件直接分派给、现场工程师、二线支持和事件经理等不同的角色进行处理。

INC-03

服务请求事件处理

• 服务台/一线支持处理服务请求类事件。
• 服务台根据服务请求的类型，将事件分派给一线支持、现场工程师、二线支持等不同角色处理。
• 一线支持根据服务请求的类型，将事件分派给现场工程师、二线支持等不同角色处理。
• 如果一线支持受理的服务请求类的事件是服务台所负责的服务请求类事件，则由一线支持直接转派给服务台处理。
• 如果服务请求事件是关于客户需求、客户服务建议等信息，则由服务台记录基本信息后，关闭事件，并将信息转给相关流程。

事件申请单

投诉建议

客户需求

服务台/

现场工程师

INC-04

重大事件处理

• 接受对服务台/一线支持分派的重大故障处理。
• 事件经理组织启动相关的紧急预案，并上报相关机构与领导。
• 事件经理组织协调各方资源，支持应急小组分析诊断与解决重大故障。
• 应急小组尽快解决重大故障，并负责善后处理工作。
• 在解决重大故障的过程中，如果需要变更，需提出紧急变更请求，走变更管理流程。

事件经理

应急小组

INC-05

故障一线支持与处理

• 处理服务台分派或一线支持受理的故障类事件。
• 根据知识库处理常规故障。
• 通过故障分析与诊断，提出故障解决方案/变通方法。
• 在解决故障的过程中，如果需要发生变更，则需提出变更请求，走变更管理流程。
• 如果在时限内无法解决故障，则需将故障升级二线支持处理。
• 故障解决后，需对故障的解决方案或变通方法进行文档化。
• 故障处理后，需反馈故障处理结果给分派方（服务台）。

事件申请单

已知错误

解决方案

INC-06

故障二线支持与处理

• 处理服务台分派的故障类事件。
• 接受与处理一线支持升级的故障类事件。
• 通过故障分析与诊断，提出故障解决方案/变通方法。
• 在解决故障的过程中，如果需要发生变更，则需提出变更请求，走变更管理流程。
• 在规定时限内无法解决的故障，需升级协调第三方支持。
• 故障处理后，对故障的解决方案或变通方法进行文档化。
• 故障处理后，需反馈故障处理结果给分派方（服务台或一线支持）。

事件申请单

已知错误

解决方案

事件申请单

变更申请单

INC-07

协调第三方支持

• 二线支持无法在规定时限内解决的故障，升级第三方/供应商处理。
• 根据需要对故障处理的相关信息进行整理和归类。
• 将整理后的信息提供给第三方/供应商。
• 定期与第三方/供应商进行沟通，确保故障及时解决。
• 二线支持申请第三方/供应商提供支持时，必须通过事件经理审批。事件经理将从故障处理成本、服务级别协议指标等因素综合考虑。

事件申请单

第三方申请单

INC-08

事件关闭

• 事件关闭之前，需要受理方（服务台或一线支持）及时通知用户，并沟通事件处理效果，得到认可后关闭事件。
• 回顾事件处理，如果故障是采用变通方法解决的，同时需要进一步找出故障的根本原因，则需要提起问题申请单，交问题管理流程。
• 根据故障处理结果，受理方（服务台或一线支持）需完善故障处理过程的相关文档
• 如果需要将已确定的解决方案/变通方法存入知识库中，则需提交知识申请单，走知识管理流程。
• 事件关闭遵循首问责任制，谁受理谁负责谁关闭的原则。

事件申请单

问题申请单

知识申请单

服务台/

一线支持

L1.1

是否来自自助平台

• 判断用户申告的事件是来自自助平台，还是电话。
• 如果来自自助平台，事件信息自动导入。
• 如果来自电话，需要服务台进行事件记录。
• 自助平台发起的事件已有事件的信息记录；电话发起的事件需要服务台帮助记录。

L1.2

事件记录

•  服务台根据用户的申告，记录事件信息。
• 可通过工具对事件信息进行详细记录，包括事件症状，影响，申告人、联系方式等信息。
• 工具既可以是IT服务支持的平台工具，也可采用Excel，Word等工具。 

L1.3

判断服务范围

•  服务台根据网管中心IT运维服务的服务目录和服务级别协议对受理的事件信息，判断是否在网管中心IT运维服务范围。
• 如果不在服务范围，则直接回复用户。
• 如果在服务范围，则受理服务请求，验证事件信息的完整性。 

L1.4

回复/配合

•  直接回复用户，解释其服务请求不在网管中心IT运维服务范围内。
• 如果是VIP客户，可适当配合，提供一定的协助咨询服务。
• 如果用户提供的信息是需求信息，可记录之后，转给相关部门或需求管理流程。 

L1.5

事件信息完整性

确认

• 服务台根据事件信息，生成事件申请单，正式受理用户事件申告。
• 如果发现事件信息不准确、不完整，需与用户进行沟通，完善事件申请单的信息。

L1.6

判断事件类别

• 根据事件分类规则，判断事件类型，可具体到事件分类三级。
• 如果是服务请求类事件，标注服务请求类。
• 如果是故障类事件，需进行故障等级判断。

L1.7

转INC-03:服务请求处理流程

• 将事件申请单直接转服务请求处理流程，对事件进行处理。

L1.8

判断故障优先级

• 根据故障的影响度和紧急度，判断故障的优先级。
• 事件的优先级可参考《事件分级》相关文件的定义。

L1.9

转INC-06:重大事件处理流程

• 服务台根据事件优先级的规则，判断事件等级是极高，则标记事件为重大事件，并提交重大事件处理流程。
• 一般事件的影响度和紧急度会有初始设定，服务台根据与用户的交流，可更新其影响度和紧急度，改变故障优先级。

L1.10

判断重复故障

• 判断是否是重复性故障申告，如果是，则进行重复性故障处理。

L1.11

重复故障处理

• 若用户提报的事件为重复故障，则服务台需要关联相对应的主事件，并按照主事件的解决方案进行处理。

L1.12

故障派单

• 如果申告的故障等级非极高，则根据故障类型进行任务分配。
• 服务台“分派”的故障事件，最终事件处理完成后，需要反馈事件处理结果由服务台关闭此事件。

L1.13

分派现场服务

• 如果需要现场故障处理，则派单现场工程师实施现场服务

现场工单

事件申请单

L2.1

现场服务

• 现场工程师到用户现场进行故障处理。

现场工单

事件申请单

现场

工程师

L2.2

反馈服务结果

• 现场服务完成后，需反馈现场故障处理情况，包括故障现象、解决方案、是否解决等

现场

工程师

L1.14

分派一线支持

• 如果需要一线支持提供服务，则直接分派一线支持，并转一线支持与处理流程。

L1.15

分派二线支持

• 如果需要二线支持提供服务，则直接分派二线支持，并转二线支持与处理流程。

L1.1

是否来自告警系统

• 判断用户申告的事件是来自告警系统，还是自助平台、邮件、短信。
• 如果是告警系统发起的事件，则直接确认事件信息的完整性。
• 如果事件来自自助平台、邮件、短信等渠道，需要一线支持进行服务范围的判断。
• 告警系统发起的事件都是故障类事件；自助平台、邮件、短信等渠道发起的事件包括服务请求类和故障类事件。

L1.2

判断服务范围

• 一线支持根据网管中心IT运维服务的服务目录和服务级别协议对受理的事件信息，判断是否在网管中心IT运维服务范围。
• 如果不在服务范围，则直接回复用户。
• 如果在服务范围，则受理服务请求，验证事件信息的完整性。

L1.3

回复/配合

• 直接回复用户，解释其服务请求不在网管中心IT运维服务范围内。
• 如果是VIP客户，可适当配合，提供一定的配合性服务。
• 如果用户提供的信息是需求信息，可记录之后，转给相关部门或需求管理流程。

L1.4

事件信息完整性

确认

• 一线支持根据事件信息，生成事件申请单，正式受理用户事件申告。
• 如果发现事件信息不准确、不完整，需与用户进行沟通，完善事件申请单的信息。

L1.5

判断事件类别

• 根据事件分类规则，判断事件类型，可具体到事件分类三级。
• 如果是服务请求类事件，标注服务请求类。
• 如果是故障类事件，需进行故障等级判断。

L1.6

转INC-03:服务请求处理流程

• 将事件申请单直接转服务请求处理流程，对事件进行处理。

L1.7

判断故障优先级

• 根据故障的影响度和紧急度，判断故障的优先级。
• 事件的优先级可参考《事件分级》相关文件的定义。

L1.8

转INC-06:重大事件处理流程

• 根据事件优先级的规则，判断事件等级是极高，则标记事件为重大事件，并提交重大事件处理流程。
• 一般事件的影响度和紧急度会有初始设定，一线支持根据与用户的交流，可更新其影响度和紧急度，改变故障优先级。

L1.9

判断重复故障

• 判断是否是重复性故障申告，如果是，则进行重复性故障处理。

L1.10

重复故障处理

• 若用户提报的事件为重复故障，则服务台需要关联相对应的主事件，并按照主事件的解决方案进行处理。

L1.11

故障派单

• 如果申告的故障等级非极高，则根据故障类型进行任务分配。
• 一线支持“分派”的故障事件，最终事件处理完成后，需要反馈事件处理结果由一线支持关闭此事件。

L1.12

分派现场服务

• 如果需要现场故障处理，则派现场工单给现场工程师实施现场服务

现场工单

事件申请单

L2.1

现场服务

• 现场工程师到用户现场进行故障处理。

现场工单

事件申请单

现场

工程师

L2.2

反馈服务结果

• 现场服务完成后，需向一线支持反馈现场故障处理情况，包括故障现象、解决方案、是否解决等。

现场

工程师

L1.13

分派二线支持

• 如果需要二线支持提供服务，则直接分派二线支持，并转二线支持与处理流程。

L1.1

明确服务请求需求

• 服务台/一线支持与用户进一步沟通，明确用户的服务需求。  

L1.2

选择与分(转)派

服务支持

• 根据服务请求事件的分类，分派不同角色。
• 如果是服务台“分派”的事件，需要由服务台关闭此事件；如果是一线支持“分派”的事件需要由一线支持关闭此事件。
• 如果一线支持受理的服务请求事件需要服务台处理，则直接“转派”给服务台受理与处理，不再执行任务“分派”。也就是将事件直接转给服务台，由服务台对该事件负责。

L1.3

服务台解决

• 服务台对所负责的服务请求事件进行处理。
• 事件处理完，由服务台关闭此事件。

L2.1

一线支持与服务

• 一线支持对所负责的服务请求事件进行处理。
• 事件处理完，如果事件是服务台“分派”的事件，返回服务台服务结果，由服务台关闭此事件。
• 事件处理完，如果事件是一线支持受理的事件，由一线支持关闭此事件。

L3.1

现场服务

• 现场工程师实现现场服务，并返回服务结果给“分派”方（服务台或一线支持）。
• 事件处理完，如果事件是服务台“分派”的事件，返回服务台服务结果，由服务台关闭此事件。
• 事件处理完，如果事件是一线支持“分派”的事件，返回一线支持服务结果，由一线支持关闭此事件。。

L4.1

二线支持与服务

• 二线支持实现服务请求服务，并返回服务结果给“分派”方（服务台或一线支持）。
• 事件处理完，如果事件是服务台“分派”的事件，返回服务台服务结果，由服务台关闭此事件。
• 事件处理完，如果事件是一线支持“分派”的事件，返回一线支持服务结果，由一线支持关闭此事件。

L1.1

明确支持需求

• 一线支持受理或接受分派的事件请求后，如果需要与用户进一步沟通，可根据事件申请单信息联系用户，进行深层次了解事件情况，为评估诊断和提供解决方案奠定基础。

L1.2

故障诊断分析

及解决

• 依据专业知识，借助已有的知识库对事件现象进行诊断分析，查明原因。
• 查询配置数据库中受影响的配置项的属性和配置项间的关联关系，以定位故障。
• 根据对故障的评估诊断，提供合理的解决方案或变通方法。
• 如果是变通方法，在提供解决方案的同时，标注变通方法标记。
• 如果故障处理过程中，涉及变更，需提交变更申请单，交变更管理流程。
• 如果故障仅是通过变通方法解决而没有根本性解决，则需要创建问题申请单，走问题管理流程。

事件申请单

已知错误

解决方案

配置信息

L1.3

解决与恢复

• 判断故障是否解决，如果在规定时限内无法解决，则可升级二线支持；如果已解决，则记录与整理解决方案。

L1.4

记录详细

解决方案

• 如果故障得到解决，可将此故障的解决方案整理归档，存入知识库中，记录内容可包括详细的解决方案，诊断过程，处理人的信息等。
• 如果是变通方法，需要标明。
• 将处理结果反馈受理方（服务台或一线支持），交受理方关闭事件。

解决方案

事件申请单

L1.5

升级二线支持

• 如果故障相对复杂，一线支持无法解决，或者故障影响范围和程度较大，则需提交二线支持进行故障评估与解决。
• 标注事件状态，升级二线支持处理。

L1.1

事件受理及

需求明确

• 二线支持在接到服务台分派或一线支持升级的事件后，如果需要与用户或一线支持人员进一步沟通，可根据事件申请单信息联系用户/一线支持人员进行深层次了解事件情况，为评估诊断和提供解决方案奠定基础。

L1.2

故障诊断分析

及解决

• 二线支持依据专业知识，借助已有的知识库对事件现象进行诊断分析，查明原因。
• 查询配置数据库中受影响的配置项的属性和配置项间的关联关系，以定位故障。
• 根据对故障的评估诊断，提供合理的解决方案或变通方法。
• 如果是变通方法，在提供解决方案的同时，标注变通方法标记。
• 如果故障处理过程中，涉及变更，需提交变更申请单，交变更管理流程。
• 如果故障仅是通过变通方法解决而没有根本性解决，则需要创建问题申请单，走问题管理流程。

事件申请单

已知错误

解决方案

配置信息

事件申请单

变更申请单

L1.3

解决与恢复

• 判断故障是否解决，如果在规定时限内无法解决，则可升级第三方支持；如果已解决，则记录与整理解决方案。

L1.4

记录详细

解决方案

• 如果故障得到解决，可将此故障的解决方案整理归档，存入知识库中，记录内容可包括详细的解决方案，诊断过程，处理人的信息等。
• 如果是变通方法，需要标明。
• 将处理结果反馈受理方（服务台或一线支持），交受理方关闭事件。

解决方案

事件申请单

L1.5

升级第三方支持

• 如果故障相对复杂困难，二线支持能力范围之内无法解决，或者故障影响范围和程度较大，则需提交第三方/供应商的支持进行事件评估与解决。
• 需要事件经理参与协调。

第三方申请单

事件申请单

L1.1

事件评估

• 对重大事件的影响范围、影响程度和紧急程度进行评估，为协调资源提供依据。
• 通知相关机构及部门领导

L1.2

已有应急预案

• 判断是否有对应事件的应急预案。
• 如果有，直接交应急小组启动应急预案。
• 如果没有，协调相关专家资源，启动应急小组参与。

L2.1

实施应急预案

• 事件经理根据判断的紧急预案类型，上报主管领导，同时启动相应的紧急预案。

L1.3

协调资源

• 根据事件评估结果组织有关的专家成员，并启动应急小组。
• 协调相关设备资源，以应对重大事件。

L2.2

诊断分析及解决

• 应急小组与相关技术专家对重大事件进行分析诊断，查找根本原因。
• 如果需要，须与用户进一步沟通，为决策提供依据。
• 根据分析诊断的结果，形成并提供适合的解决方案，包括临时紧急处理方案。
• 如果在事件处理过程中，需要变更，则需提交紧急变更申请，走紧急变更流程。
• 相关技术专家成员须参与。

事件申请单

评估结果

解决方案

临时处理方案

紧急变更申请单

L2.3

解决恢复

• 判断重大事件是否得到解决。
• 如果已解决，则走善后处理过程。
• 如果未解决，则需调研外部资源，继续分析诊断与解决。

L2.4

协调外部

资源支持

• 若故障相对复杂困难，应急小组及内部专家组成员无法解决，或者故障影响范围和影响程度很大，则应邀请相关的第三方或供应商参与解决。

L2.5

善后处理及通报

• 重大事件解除后，应通知重大事件各方（申报方、受影响部门、主管机构及相关领导），并向主管机构及相关领导简要报告重大事件处理过程，解决方法，事件解除时间，业务恢复情况等。
• 如果是临时处理方案，应创建一个新问题，将重大事件处理过程的详细信息记录到问题申请单中，提交问题管理流程。
• 应对重大事件的处理过程进行详细记录，形成重大事件处理报告，包括事件、分析、诊断、解决等过程。
• 将重大事件的解决方案或临时处理方案提交到知识管理流程，存入知识库中。

重大事件处理报告

事件申请单

问题申请单

L1.1

信息收集

• 根据故障处理的实际情况，收集故障关联的所有相关信息。
• 确保故障及故障处理描述要准确全面。

L1.2

整理分类

• 对收集到的故障等进行整理，并按照其类别进行划分，以方便有效的识别和诊断。
• 根据故障处理情况，提交第三方申请单，交事件经理审批。

事件申请单

第三方申请单

L1.3

审批

• 事件经理根据故障的影响程度、紧急程度、投入成本、UC，以及提供信息的安全性等进行综合评估。
• 如果未通过，则反馈二线支持和受理方，关闭事件。

第三方申请单

事件申请单

L1.4

提供信息

• 二线支持将审批通过后的、故障相关信息提供给已协调的第三方/供应商。
• 提供的方式可以多种，包括邮件、书面等方式或当面提供等。

L1.5

沟通解决

• 二线支持负责跟踪第三方/供应商的故障处理状态，并不定期的保持沟通，以保证解决的效率和效果。
• 如果在UC范围内，则按照协议规定，监督供应商的服务支持。
• 记录第三方/供应商的解决方案，并反馈事件受理方（帮助台/一线支持）。

事件申请单

解决方案

L1.1

通知客户

• 告知用户关闭事件。
• 调查用户对故障处理的反馈，包括服务支持的质量，支持的效率和支持的态度等。

服务台/

一线支持

L1.2

记录反馈信息

• 将用户的反馈信息记录到相应的单据中。
• 用户的反馈信息可采用短信平台收集。

服务台/

一线支持

L1.3

查看过程文档

是否全面

• 服务台/一线支持（事件受理者）应查看事件生命周期中所产生的文档是否完整全面。
• 如果全面，标明事件状态为结束。

文档清单

事件申请单

服务台/

一线支持

• 若在整个过程中文档不全面，则要求相关责任人完善。
• 将产生的所有信息归档。
• 如果解决事件时，采用了新的解决方案/变通方法，则申请将解决方案/变通方法加入到知识库中。
• 标明事件状态为结束。

事件申请单

知识申请单

服务台/

一线支持

事件超限率

（超过SLA）

∑（超限事件数量）/∑（事件数）×100%

超限事件数量=用户事件未能在指定时间内解决