文档更改11 某省移动业务支撑网挑战365ITIL事件管理实施细则

由 superadmin 于 2024/10/28, 11:01 最后修改

从版本< 23.1 >

由superadmin编辑
在2024/10/28, 11:00上

到版本

由superadmin编辑
在2024/10/28, 10:55上

< >

修改评论上传新附件图片3.jpg

Raw
已渲染

Summary

Page properties (3 modified, 0 added, 0 removed)
Attachments (0 modified, 0 added, 1 removed)
- 1730084151498-853.png

Details

Page properties

标题

...	...	@@ -1,1 +1,0 @@
1		-11 某省移动业务支撑网挑战365ITIL事件管理实施细则

父

...	...	@@ -1,1 +1,0 @@
1		-G 参考资料.ITIL实施项目资料.ITIL实施项目流程设计方案集.事件管理.WebHome

Content

@@ -1,1107
          +1,0 @@
--= 1.1.流程目的 =
--
--本文档是针对挑战365活动（以下简称C365）范围内的相关事件进行处理的细则，基于集团对BOMC系统规范2.0。
--
--事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括：
--
--* 在成本允许的范围内尽快恢复IT服务
--** 快速响应服务请求（电话/Web/邮件等）
--** 用户在线获得帮助
--** 沟通事件解决的状态
--** 和客户确认事件的解决
--** 启动应急预案
--* 进行事件控制
--** 按规范记录事件
--** 就事件的优先级，影响度进行分类
--** 分析，诊断，必要时进行升级
--** 监视并结束事件
--** 进行定期服务流程回顾
--* 提供IT管理信息
--** 人力资源利用情况
--** 故障处理情况
--** 支持效率
--
--
--= 1.2.流程主要内容 =
--
--事件管理流程始于事件的接收和报告，结束于事件的解决。该流程包含下述主要内容：
--
--* 事件检测和记录
--
-- 这个环节是事件管理流程的起点。所有用户或系统报告的IT 事件必须由此步骤开始。此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。在此步骤中将会收集创建事件记录所需的信息。
--
--该环节的关键是信息的准确性和完整性。
--
--* 分类和初步支持
--
--对于每个事件，需要确立优先级和分类。若没有现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。
--
--* 调查和诊断
--
--若支持人员无法解决事件，可运用自身技能、知识库、诊断工具等进行更加深入的分析以找到恢复服务的临时措施，必要时可调用多名支持人员以寻求解决措施。
--
--* 解决和恢复
--
--支持人员实施事件的解决方案，并将解决完毕的事件转回开单人.
--
--* 优先级为紧急的事件（紧急事件）和事件升级
--
--对于紧急事件，服务台应立即提交给一线人员，由一线人员判断，上报给事件经理和相关的管理层，由事件经理决定紧急事件的处理方式，确保其得到最快速的解决。
--
--当事件处理超过预期时限，将自动通知处理人员和相应管理层，以引起相关人员和管理人员的重视和参与。
--
--* 结束事件
--
--服务台通知用户解决的结果，并得到用户的确认。当用户确认事件解决后，此时可结束该事件。
--
--
--= 1.3.与其他流程的关系 =
--
--* 和问题管理流程的关系
--
--事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为紧急的事件解决并恢复服务后做为问题进行进一步的分析和处理。
--
--* 和配置管理流程的关系
--
--需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。
--
--* 和变更管理流程的关系
--
--服务台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。在事件的解决过程中，必要时需要发起变更请求来解决事件。
--
--* 和知识库的关系
--
--事件得到解决后，解决的过程中所获得的经验以及相关解决方案可以进入知识库，作为知识保存，为后续的工作提供指导。
--
--
--= 1.4.流程范围 =
--
--在此次C365项目中事件管理流程的范围包括涉及到BOSS系统和CRM系统中所有IT生产环境所产生的申告、故障、告警、咨询和客户投诉。
--
--不包括：
--
--1. 尚处于开发或测试环境的系统和应用引发的事件
--1. 容灾系统和BOMC系统相关的事件
--
--
--
--= 1.5.流程执行原则 =
--
--== 1.5.1.常规原则 ==
--
--* 所有业务支撑部门事件管理范围内发生的事件，都应该记录在服务管理平台中，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相应的附件
--* 所有IT支持人员对优先级为紧急和高的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有优先处理级别
--* 应该每月产生事件管理报表，包含对考核指标的统计，以及相应的报表。并对重复发生的事件和变通方法解决的事件，应该举行定期的事件管理会议对这些事件进行评估
--* 应该半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进事件管理流程
--
--
--== 1.5.2.所有权原则 ==
--
--所有权原则用来确保每个事件在任何时段都有适当的人员负责，服务台是事件的负责人。下表是事件管理中各角色在各环节中承担不同责任的RACI模型。
--
--
--
--表2-1 事件管理RACI模型
--
--(% style="text-align:center" %)
--[[image:1730083193004-304.png]]
--
--
--
--= 1.5.3.再分派原则 =
--
--事件的再分派原则是确保事件在服务目标时段内处理和解决的重要因素。因此，应当尽量减少事件单再分派的几率。事件单可以分派给服务台组，但分配给一、二线时，只能够分派到个人。
--
--* 事件单的重分派次数不应该超过5次（从服务台派单开始计算）。
--* 超出分派次数，短信通知事件经理。
--* 地市支撑人员提交工单给服务台组；
--* 服务台可以将事件单分配给其他服务台人员、一线支持
--* 一线支持人员可以将事件单重新再分配给服务台（驳回）、其他一、二线支持人员
--* 二线支持人员可以将事件单重新再分配给其他一线（驳回）、二线支持人员和厂商人员
--
--
--== 1.5.4.重复事件原则 ==
--
--重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控平台上报的同一个配置项上现象相同的告警，或者一人/多人申告的同一来源（系统、应用）现象相同的事件。
--
--当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。
--
--* 监控平台应该自动过滤重复告警，避免将重复的告警发送到服务管理平台
--* 重复的事件信息必须被标识，并且不计入事件流程的关键衡量指标
--* 如果服务台可以判断到重复事件，则由服务台对重复事件标识，否则由一、二线支持人员负责重复事件的处理
--* 重复事件与原事件单关联
--* 在原有事件单获得解决时，所有的重复事件单获得解决。
--
--
--== 1.5.5.关闭原则 ==
--
--事件工单关闭环节的基本原则：谁开单，谁负责关闭。
--
--* 各地市支撑人员提交的工单，最后由提交人关闭；
--* 服务台通过电话、邮件、飞信、BQQ等方式受理的事件工单，由服务台和IT用户确认解决后进行关闭；
--* 二线人员自行创建的事件单，由创建人关闭；
--* 监控平台产生的告警，由服务台人员（机房值班人员）根据监控平台的反馈确认后关闭；
--* 优先级为紧急的事件工单由事件经理进行关闭
--* 事件处理人员在解决完成事件时，根据实际解决情况填写事件的结束代码，采用临时措施恢复服务时，结束代码为“变通方法解决”。服务台负责和IT用户再次确认事件的解决
--** 由IT用户认可获得关闭的事件单的结束代码为“成功解决”关闭
--** 采用临时措施恢复服务时，结束代码为“变通方法解决”；
--** 已解决的事件单如果没有得到IT用户的认可，则首先关闭该事件单，结束代码修改为“不成功”，同时创建一个新的事件单重新分配到原处理人员继续处理。同时短信通知事件经理，服务台通过线下的方式让用户了解不成功的工单后续处理情
--* 已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单，并与已关闭的重复工单进行关联。
--
--
--== 1.5.6.升级原则 ==
--
--制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。
--
--* 优先级为紧急的事件，由一线再次确认，如果确认了优先级为紧急，则通过线下短信通知的方式升级升级到事件经理，启动紧急事件处理流程，并用短信方式通知相应的管理层—室经理
--* 优先级为高的事件，一线人员处理15分钟（解决时限的50%）内未解决，则要求立即升级到二线人员进行处理
--* 优先级为中、低的事件，处理时间超过解决时限的80%时，由服务台对处理人进行督促，要求将规定时间内不能解决的事件升级。（一线升级到二线，二线升级到三线）
--* 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定解决时限，服务台系统应自动将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理
--* 服务台人员主动监督优先级为中和低的事件处理情况，应及时将不能解决的事件升级；事件经理并对未及时升级的事件及时介入，负责协调升级处理。事件经理通过对事件的抽查和对超时解决的事件统计情况对服务台人员的主动性进行监督。
--
--
--
--= 1.6.流程相关定义 =
--
--== 1.6.1.事件信息项 ==
--
--事件单必须包含如下事件信息项，各省可以在此基础上扩充：
--
--表5-2 事件信息项
--
--
--(% style="text-align:center" %)
--[[image:1730083361927-973.png]]
--
--(% style="text-align:center" %)
--[[image:1730083376704-870.png]]
--
--
--
--== 1.6.2.事件性质 ==
--
--事件性质定义为如下五类事件：
--
--(% style="text-align:center" %)
--[[image:1730083402816-226.png]]
--
--
--
--== 1.6.3.事件来源 ==
--
--事件来源代码用来标明事件的提出方式，事件来源可以包括以下几种：
--
--
--(% style="text-align:center" %)
--[[image:1730083427108-403.png]]
--
--
--
--== 1.6.4.所属系统类型 ==
--
--定义业务系统。当事件发生时，应该由服务台初步定位是哪个系统及子类出现问题，由一、二线进行进一步的明确。
--
--注：各省在细化设计时不能修改此表中现有定义，第一层业务系统和第二层子类不能修改和扩充(注：第一层为”其它系统”的话，对应的子类可以扩充)，但可以有选择的基于第二层子类定义扩充进行第三层条目的细化。对没有覆盖到的业务系统用”其它系统”表示。
--
--
--(% style="text-align:center" %)
--[[image:1730083456792-590.png]]
--
--
--
--== 1.6.5.事件分类 ==
--
--事件分类代码用于标识故障或申告的具体原因，由支持人员在处理过程中填写。在制作统计报表时，可以通过和所属系统类型代码的结合来统计分析故障或申告。
--
--事件的分类层次设计不超过三层，第一级分类，称之为“类别”，第二级分类，称之为”子类”，第三级分类，称之为”条目”。
--
--注：各省可以在此表的基础上扩展子类和自定义条目，针对一个子类，可以定义多个条目。
--
--表5-3事件分类
--
--
--(% style="text-align:center" %)
--[[image:1730083485996-949.png]]
--
--
--
--== 1.6.6.事件优先级 ==
--
--优先级是事件管理的一个关键要素，优先级决定处理事件的顺序及所需的资源，事件优先级可分为四级（紧急、高、中、低）。
--
--
--(% style="text-align:center" %)
--[[image:1730083508896-434.png]]
--
--
--
--当故障发生时，为了在判断优先级时增强实际可操作性，可以根据故障的影响范围和业务系统的关键程度在优先级映射表中定位优先级,登记人员和支持人员不能直接修改优先级。故障的影响范围可以根据配置项中定义的‘影响范围’和用户报障描述来确定。
--
--(% style="text-align:center" %)
--[[image:1730083549859-560.png]]
--
--
--注：
--
--1. 如果某些业务模块没有反映在优先级映射表中，各省可以根据实际需要添加
--1. 优先级映射表中空的字段，各省在细化流程中自行定义
--1. 在事件处理解决后，可以由负责关闭的服务台人员对事件的优先级做最终的修正。
--
--
--== 1.6.7.事件响应时限和解决时限 ==
--
--在事件处理过程中，对于一个事件有解决时间的限制和响应时间的限制。一方面，需要各工程师协同合作，在解决事件的时候应该有时间的概念；也要求事件经理必须实时地督促事件的解决，对于影响度为高或者紧急的事件，需要及时通告事件经理；如果该事件的响应或解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。
--
--响应时限指的是事件状态从“已登记”到“一线处理中”经过的时间，如果服务台直接分配到二线支持，响应时限指的是事件状态从“已登记”到“二线处理中”经过的时间；
--
--解决时限指的是事件状态从“已登记”到“已解决”经过的时间；
--
--事件优先级对应的事件响应时限和解决时限参考下表（以下时间是24×7工作时间）：
--
--(% style="text-align:center" %)
--[[image:1730083582307-827.png]]
--
--
--
--**超出和即将超出解决时限的通告定义**
--
--通知人员列表的用途：当服务管理平台判断到解决时限已经或即将超出，则自动按照表中的人员列表发出邮件或短信通知。
--
--
--== 1.6.8.通知与提醒 ==
--
--在事件流程开始和处理过程中，发送满足以下条件的通知或提醒，推进事件工单的及时执行：
--
--* 当事件工单分（转）派时，发送通知给接收人；
--* 当紧急事件确认并触发按钮后，发送通知给事件经理、室经理；
--* 当超出分派次数时，发送通知给事件经理；
--* 为关闭代码是“不成功”的事件工单创建新工单时，发送通知给事件经理；
--* 对高、中、低优先级的事件，在处理时间过去50%时，发送提醒给事件处理人；
--* 对紧急、高优先级的事件，在处理时间过去80%时，发送提醒给事件经理、事件处理人；
--* 对中、低优先级的事件，在处理时间过去80%时，发送提醒给服务台、事件处理人；
--* 对高、中、低优先级的事件，超过解决时间时，发送提醒给事件经理；
--
--(% style="text-align:center" %)
--[[image:1730083617172-701.png]]
--
--
--
--
--== 1.6.9.事件影响度 ==
--
--事件影响度用于衡量事件所影响业务的严重程度。严重程度通常通过事件所影响的人数、关键系统数以及服务故障所造成的损失来设定。
--
--定义事件影响度等级的因素有：
--
--1. 是否影响了核心业务
--1. 所影响的用户数
--1. 服务失效的影响范围和时长
--
--事件影响度在事件的生命周期中是可以改变的，例如，初始等级为严重的故障会随着服务失效的时间变成重大故障，所以事件的影响度应在事件得到解决（服务恢复）后重新确认。
--
--事件的响应时间、解决时限以及处理事件所需要引入的资源主要由事件的优先级决定。
--
--(% style="text-align:center" %)
--[[image:1730083665510-519.png]]
--
--注：各省根据自己业务情况扩展或修改本表格的描述，对于重大级别的事件，应严格按照集团公司的定义。
--
--
--
--== 1.6.10.事件状态 ==
--
--事件状态代码表明事件所处的处理状态，事件状态如下：
--
--(% style="text-align:center" %)
--[[image:1730083693232-406.png]]
--
--
--
--== 1.6.11.事件结束代码 ==
--
--事件结束代码说明了事件是在何种情况下关闭的，结束代码如下：
--
--(% style="text-align:center" %)
--[[image:1730083718659-526.png]]
--
--
--
--== 1.6.12.事件解决人角色 ==
--
--事件解决人角色用来标明该事件单最终解决的角色是服务台、一线还是二线。
--
--
--(% style="text-align:center" %)
--[[image:1730083742664-943.png]]
--
--
--
--== 1.6.13.处理是否超时 ==
--
--每个优先级别都对应了解决期限，“处理是否超时”用来标明事件的处理是否已超过了解决期限。
--
--
--(% style="text-align:center" %)
--[[image:1730083765757-346.png]]
--
--
--
--== 1.6.14.故障厂商 ==
--
--用来在事件单中记录是哪个厂商的设备/系统，或者哪个集成商的应用软件发生故障(针对事件分类中的”应用软件”故障)。代码定义参见附件C厂商和集成商名称标准（可以根据情况从厂商和集成商两个表中选择一个合适的故障厂商）。
--
--各省可以根据实际情况对厂商名称标准表和集成商名称标准表进行扩充。
--
--
--= 1.7.流程概要设计 =
--
--事件管理概要设计流程图如下：
--
--
--图2.1事件管理流程
--
--(% style="text-align:center" %)
--[[image:图片1.jpg]]
--
--
--
--
--事件管理概要设计流程说明
--
--|(% style="width:80px" %)序号|(% style="width:112px" %)步骤名称|(% style="width:89px" %)责任人|(% style="width:1056px" %)说明
--|(% style="width:80px" %)100.1|(% style="width:112px" %)事件记录和分类|(% style="width:89px" %)服务台|(% style="width:1056px" %)(((
--* 服务台对来自用户和系统自动产生的事件进行详细记录，主要包括来自IT基础架构的C365相关故障告警、来自客服和业务部门的客户投诉，也包括来自其它业务部门的服务请求；
--* 服务台负责在接收到地市的申告、识别C365相关故障告警、及其他资讯与投诉事件后进行分类转发
--* 对事件进行初步的诊断和支持
--* 对于初步判断为紧急的事件马上升级到一线人员进行确认
--* 对于非业务支撑维护职责范围的事件转给其它相关责任部门
--)))
--|(% style="width:80px" %)100.3-1|(% style="width:112px" %)一线尝试解决|(% style="width:89px" %)一线支持|(% style="width:1056px" %)(((
--* 一线支持人员在接受到由服务台派发的事件后，进行调查诊断，尝试解决
--* 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决方案
--* 事件解决后，在事件管理平台记录事件解决方案并更新事件状态
--* 不能解决的事件，转100.3-2二线尝试解决
--* 指定时限内不能解决的事件，通告事件经理，由事件经理负责协调资源
--)))
--|(% style="width:80px" %)100.3-2|(% style="width:112px" %)二线尝试解决|(% style="width:89px" %)二线支持|(% style="width:1056px" %)(((
--* 二线支持人员在接受到由一线升级的事件后，进行调查诊断，尝试解决
--* 在必要时根据服务协议联系厂商帮助解决并负责核查
--* 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决方案
--* 事件解决后，在事件管理平台记录事件解决方案并更新事件状态
--* 不能解决的事件，转100.4三线尝试解决
--* 指定时限内不能解决的事件，通告事件经理，由事件经理负责协调资源
--)))
--|(% style="width:80px" %)100.4|(% style="width:112px" %)三线尝试解决|(% style="width:89px" %)三线支持|(% style="width:1056px" %)(((
--* 三线支持人员接受事件，进行调查诊断，提出解决方案
--* 事件解决后，在事件管理平台记录事件解决方案并更新事件状态
--)))
--|(% style="width:80px" %)100.5|(% style="width:112px" %)紧急事件再确认|(% style="width:89px" %)一线支持|(% style="width:1056px" %)(((
--* 一线支持人员接受到来自服务台的紧急事件后，根据事件优先级别标准再次确认事件是否为紧急事件
--* 如果优先级确实紧急，则通知室管理层和事件经理，转101紧急事件处理子流程，工单转派给应急小组
--* 如不是，转100.3一线尝试解决，开始正常事件解决流程
--)))
--|(% style="width:80px" %)100.6|(% style="width:112px" %)记录解决方案细节|(% style="width:89px" %)(((
--服务台
--
--一线支持
--
--二线支持
--)))|(% style="width:1056px" %)(((
--* 在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案并更新事件信息
--* 针对故障，一线/二线支持必须记录业务恢复时间
--)))
--|(% style="width:80px" %)100.7|(% style="width:112px" %)关闭事件|(% style="width:89px" %)(((
--服务台
--
--一线支持
--
--二线支持
--)))|(% style="width:1056px" %)(((
--* 服务台与申报用户确认事件是否已得到解决，如果解决，事件以成功解决或变通方法解决而关闭；否则，事件以不成功关闭，重新开事件记录，并与原记录做关联，分派到原处理人员继续处理
--* 服务台在关闭事件的同时必须确认事件单记录的业务恢复时间是否准确
--* 其它由一线或二线人员自行创建的事件单，则由开单人负责关闭
--* 处理过程对后续工作有指导或参考的，录入知识库
--)))
--|(% style="width:80px" %)100.8|(% style="width:112px" %)事件处理的监控|(% style="width:89px" %)(((
--服务台
--
--事件经理
--)))|(% style="width:1056px" %)(((
--* 负责监控所有未关闭的事件的处理状况，对接收到的超时告警应及时关注
--* 事件经理负责协调资源，保证事件的最终解决
--)))
--|(% style="width:80px" %)101|(% style="width:112px" %)紧急事件处理流程|(% style="width:89px" %)事件经理|(% style="width:1056px" %)(((
--* 事件经理负责协调紧急事件的处理，具体过程见紧急事件处理子流程
--)))
--
--
--
--
--下表以事件管理概要图中的关键流程活动为主线，与事件管理概要设计中的其它重要内容进行了关联，以帮助各省业务支撑维护部门更好地理解流程设计内容。
--
--|序号|步骤名称|子流程和流程相关定义|执行原则|流程关联
--|100.1|事件记录和分类|(((
--* 参考”事件性质”、”事件来源”、”所属系统类型”、”事件分类” 、”事件优先级”、”事件影响度”、”事件状态”确定以上代码内容
--)))|(((
--* 参考”所有权原则”，服务台是该事件的负责人
--* 参考”再分派原则”，选择合适的支持组或人员进行分派
--)))|(((
--* 配置管理：关联相关配置项
--* (* 参见”流程关联原则”，下同)
--)))
--|100.3|一线/二线尝试解决|(((
--* 参考”事件状态”，并及时修改
--)))|(((
--* 参考”重复事件原则”，对重复事件进行标识
--* 参考”升级原则”，及时对事件进行升级
--* 参考”再分派原则”，转派事件单
--)))|(((
--* 问题管理：参考问题管理记录中的根本原因、变通方法
--* 变更管理：参考近期变更管理记录
--* 变更管理：必要时提出变更请求，走变更管理流程，一般为紧急变更请求；在变更完成后继续事件处理
--* 配置管理：通过配置管理查询配置项的属性和关联信息定位故障原因
--)))
--|100.4|三线尝试解决|(((
--* 参考”事件状态”，并及时修改
--)))|(((
--* 参考”升级原则”，及时对事件进行升级
--* 参考”再分派原则”，转派事件单
--*
--)))|(((
--* 问题管理：参考问题管理记录中的根本原因、变通方法
--* 变更管理：参考近期变更管理记录
--* 变更管理：必要时提出变更请求，走变更管理流程，一般为紧急变更请求；在变更完成后继续事件处理
--* 配置管理：通过配置管理查询配置项的属性和关联信息定位故障原因
--)))
--|100.5|紧急事件再确认|(((
--* 参考并再次确定”事件优先级”
--* 参考”紧急变更子流程”
--)))|(((
--* 参考”升级原则”，及时对紧急事件升级
--)))|(((
--
--)))
--|100.6|记录解决方案细节|(((
--* 在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案并更新事件信息
--* 针对故障，一线/二线支持必须记录业务恢复时间
--* 参考”事件状态”、”事件影响度”，根据影响度的定义重新确认影响度代码，及时更新事件状态代码
--)))|(((
--
--)))|(((
--
--)))
--|100.7|关闭事件|(((
--* 参考”事件结束代码”、”事件解决人角色”
--)))|(((
--* 参考”关闭原则”，和用户确认事件的解决和分配相应的结束代码
--)))|(((
--
--)))
--|100.8|事件处理的监控|(((
--* 参考”事件的响应时限和解决时限”，关注所有处理中的事件单
--)))|(((
--* 参考”升级原则”
--)))|(((
--
--)))
--|101|紧急事件处理子流程|(((
--* 参考”紧急事件处理子流程”
--)))|(((
--
--)))|(((
--* 问题管理：优先级为紧急的事件解决完后，需要创建新的问题单
--)))
--
--
-- 下表以事件管理概要图中的关键流程活动为主线，与事件管理概要设计中的其它重要内容进行了关联，以帮助各省业务支撑维护部门更好地理解流程设计内容。
--
--
--== 1.7.1.紧急事件处理子流程 ==
--
--制定紧急事件处理子流程的目标：
--
--* 当紧急事件发生时，尽可能采取措施减少对于业务带来的影响
--* 确保对紧急情况的有效管理
--** 加快紧急事件的响应和处理速度
--** 对紧急情况中的人员及采取的行动加强管理
--** 加强处理人员与用户之间的沟通和反馈
--** 对紧急情况妥善处理
--
--紧急事件处理的特殊性包括各系统应急处理预案的制定和使用，及时的集团上报等。
--
--应急处理预案是事先制定的针对某种特定故障的处理措施，可以确保系统发生重大故障时，能够尽快恢复业务，并充分调动技术力量，在最短时间内排除故障。预案中的内容至少应涵盖应急预案启动条件、应急处理小组负责人和成员联系名单和联系方式、应急处理步骤、应急信息通报、应急善后处理、应急保障措施（人员、培训、演习、场地）等。
--
--一线人员对紧急事件进行确认后，通过点击按钮的方式，触发紧急事件流程，工单自动流转到应急小组，并发送短信提醒事件经理和室经理，由事件经理通召集应急小组，协调会议的召开，开展事件的处理工作。
--
--一线人员确认此紧急事件为普通事件后，修改优先级，按照常规方式执行。
--
--为切实掌握各省公司业务支撑系统紧急事件情况，要求各省公司在紧急事件发生时立即上报，并在紧急事件处理过程中的关键点将处理情况上报，具体上报内容和方式参见2.10集团、省公司两级交互。
--
--
--图2.2  紧急事件处理流程
--
--(% style="text-align:center" %)
--[[image:1730084151498-853.png]]
--
--
--
--紧急事件处理流程说明如下：
--
--|序号|步骤名称|说明
--|101.1|召集应急小组，协调应急会议|(((
--* 事件经理主持应急会议，并组织讨论、协调各方资源，分析紧急事件处理方案，并将紧急事件情况通报省中心相关领导和集团公司，工单已在一线触发时，自动转派给了应急小组。
--)))
--|101.2|判断是否属于应急预案中的事件？|(((
--* 应急小组和相关厂商根据紧急事件现象和影响程度，判断是否需要启动相应系统的应急预案
--** 如果没有应急预案，则进入101.4组织相关厂商共同分析紧急事件，制定处理方案并处理
--** 如果有应急预案，则进入101.3按照应急预案处理
--)))
--|101.3|按照应急预案处理|根据各系统制定的应急预案中的实施步骤，处理紧急事件
--|101.4|组织相关厂商共同分析，制定处理方案并处理|(((
--* 应急小组负责组织相关厂商共同分析紧急事件，制定相应的处理方案，如果需要集团中心介入处理，则向集团中心申请介入
--* 处理方案在实施前应得到应急小组和相关领导的认可
--* 事件处理过程中如果需要中断业务或对系统的IT组件产生变更，则需要按照紧急变更管理流程的定义和要求，提出紧急变更请求
--)))
--|101.5|紧急事件解除确认？|(((
--* 在紧急事件处理方案实施后，应急小组、相关厂商和相关部门对紧急事件是否解除进行确认
--** 紧急事件如果没有解除，则重新进入101.4组织相关厂商共同分析紧急事件，制定处理方案并处理；
--** 如果解除，则进入101.6紧急事件善后处理和总结分析
--)))
--|101.6|善后处理和通报|(((
--* 紧急事件解除后，应急小组向事件经理、公司相关领导简要报告紧急事件处理过程，解决方法，事件解除时间，业务恢复情况，并将该信息汇报到集团公司
--* 应急小组负责人将事件工单标识为“已解决”；
--)))
--|101.7|关闭事件|(((
--* 事件流转到事件经理，由事件经理将工单关闭；
--* 事件经理需要创建一个新问题，将紧急事件处理过程的详细信息记录到问题单中，提交到问题经理，由问题经理组织相关专家进行问题根源的分析
--)))
--
--
--= 1.8.关键角色、职责定义 =
--
--事件管理流程主要分为以下角色：
--
--
--== 1.8.1.事件管理流程负责人 ==
--
--事件管理流程负责人从宏观上监控流程，确保事件流程在业务支持中心范围内被正确的执行。当流程不能够适应业务支持中心的情况时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。
--
--**职责：**
--
--1. 确定管理流程的衡量指标
--1. 确保事件流程能够取得管理层的参与和支持
--1. 确保事件流程符合公司实际状况和公司 IT发展战略
--1. 总体上管理和监控流程，建立事件流程实施、评估和持续优化机制
--1. 确保事件流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时的对此进行分析、找出缺陷、进行改进(假如增加或合并流程的角色)，从而实现可持续提高
--1. 保持与其他流程负责人的定期沟通
--
--
--== 1.8.2.事件经理 ==
--
--事件经理负责事件解决过程中的协调和监控，以及事件升级的判断以及具体执行。
--
--职责
--
--1. 负责对事件的解决协调资源，保证故障的最终排除
--1. 确保和问题管理流程经理的有效合作
--1. 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题
--1. 监督优先级为紧急、高的事件的处理情况
--1. 监督服务台是否及时将事件工单升级。
--
--
--== 1.8.3.服务台人员 ==
--
--服务台人员负责接收所有的事件，对事件进行初步的处理，并根据实际情况将事件分派到合适的一线支持工程师或者二线支持工程师。
--
--职责：
--
--1. 负责24×7的值班和系统监控
--1. 响应客户投诉工单、热线电话、邮件、告警、飞信、BQQ等事件报告
--1. 完整记录所有接收的事件信息，包括：记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等
--1. 为事件进行适当的分类、为事件分配优先级等属性
--1. 做初步的诊断和处理
--1. 将事件分配给最合适的一线支持小组/人员来处理
--1. 检查事件记录的处理进度，保持与事件报告人的联系，适时通知事件处理进展
--1. 与用户确认事件解决方案，关闭事件
--1. 监督优先级为中、低的事件是否被及时处理，必要时进行升级
--
--
--== 1.8.4.一、二线支持人员 ==
--
--一线支持人员按照系统进行进行划分，对事件进行快速有效的分析，提出解决方案以尽快恢复服务，并在必要时提供现场支持。
--
--职责：
--
--1. 按照系统进行划分，对事件进行快速有效的分析，提出解决方案以尽快恢复服务；
--1. 验证事件的描述和信息，进一步收集相关信息；
--1. 实施事件解决方案；
--1. 更新事件解决信息，已解决的事件转回建单人。
--
--
--二线支持人员按照专业组进行划分，是相关问题领域的专家。负责提供对一线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。
--
--职责:
--
--1. 验证事件的描述和信息，进一步收集相关信息；
--1. 进行深入调查研究或协调三线支持，提供/获取有效的解决方案；
--1. 实施事件解决方案；
--1. 更新事件解决信息，已解决的事件转回建单人。
--
--
--== 1.8.5.三线支持人员 ==
--
--包括现场支持的应用开发厂商和远程支持设备厂商。
--
--职责:
--
--1. 必要时提供现场支持和深入调查研究，提供有效的解决方案
--1. 参与解决方案的实施
--1. 更新事件解决信息，已解决的事件转回建单人。
--
--
--== 1.8.6.流程角色和人员对应表 ==
--
--|(% colspan="2" %)**角色**|**成员**
--|(% colspan="2" %)事件管理流程负责人|
--|(% colspan="2" %)事件经理|孙XX
--|(% rowspan="2" %)服务台|白班人员|(% rowspan="2" %)
--|值班人员
--|(% rowspan="4" %)一线支持|维护室BOSS经分组|(% rowspan="2" %)
--|维护室CRM系统
--|维护室系统组|
--|维护室网络安全组|
--|(% rowspan="3" %)(((
--二线支持
--
--
--)))|规划室|
--|电子渠道室|
--|经分室|
--|三线支撑（厂商）|(((
--xxxxxxx
--)))|
--
--
--= 1.9.关键流程衡量指标 =
--
--为了控制流程的质量，必须为流程设置衡量指标。通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。
--
--表2-4 事件管理KPI指标
--
--|序号|衡量指标|指标计算说明
--|1|事件总数|(((
--数量：在事件单中根据以下条件过滤
--
--【重复事件标记】为空
--
--【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
--
--【事件发生时间】在统计周期内
--)))
--|2|事件成功关闭的数量/比率|(((
--数量：在事件总数中过滤【事件结束代码】＝‘成功解决’or‘变通方法解决’
--
--比率：数量 / 事件总数  × 100 %
--)))
--|3|规定时间内解决的事件数量/百分比|(((
--数量：在事件总数中过滤【处理是否超时】＝‘未超时’and 【事件结束代码】＝‘成功解决’or‘变通方法解决’
--
--比率：数量/事件总数 × 100 %
--)))
--|5|平均解决时间|(((
--完成的事件：在事件总数中过滤所有【事件状态】＝‘已解决’or ‘关闭’的事件
--
--平均解决时间：累加完成事件的（【实际完成时间】－【登记时间】）/ 完成的事件数量
--)))
--|6|一线解决率|(((
--数量：在事件总数中过滤所有【事件解决人角色】＝‘一线’
--
--比率：数量 / 事件总数 × 100 %
--)))
--|7|超时未解决的事件数量|数量：在事件总数中过滤【处理已超时】＝‘超时’and 【事件状态】！＝‘关闭’or ‘已解决’
--|8|事件的一次解决率|(((
--数量1：在事件总数中过滤【事件结束代码】＝‘成功解决’or‘变通方法解决’
--
--数量2：在事件总数中过滤【事件结束代码】＝‘不成功’
--
--比率：（数量1－数量2 ） / 数量1  × 100 %
--)))
--|9|计划外业务中断时长|(((
--完成的事件：在事件总数中过滤所有【事件状态】＝‘已解决’or ‘关闭’的事件
--
--【中断时长】分别对应到融合计费、综合帐务、客户服业务系统的子类，进行分类统计
--)))
--
--
--
--= 1.10.集团、省公司两级交互 =
--
--省公司在紧急事件发生时，必须在第一时间上报集团公司业务支撑系统部，并在事件处理过程中的每个状态变化点将最新事件记录上传到集团公司。
--
--|(% rowspan="2" %)上报方式|(% rowspan="2" %)触发条件|(% colspan="2" %)上报内容
--|事件信息项|附件内容
--|(% rowspan="4" %)服务管理平台|事件经理召集应急小组，协调应急会议后人工触发|所有事件信息项|N/A
--|处理中的事件信息项发生改变|所有事件信息项|N/A
--|事件状态转入已解决|所有事件信息项|N/A
--|(((
--事件状态转入关闭
--
--（如果影响度为重大，必须有重大事件报告做为附件）
--)))|所有事件信息项|(((
--《重大事件报告》内容包含：
--
--包括事件的发生时间、事件现象、影响的主要系统、影响度、处理过程、解决方法、业务恢复时间等
--)))
--
--
--
--= 1.11.事件管理报表 =
--
--== 1.11.1.按业务系统和优先级分类统计报表 ==
--
--|(% rowspan="2" %)业务系统|(% rowspan="2" %)事件性质|(% rowspan="2" %)总数|(% colspan="4" %)优先级
--|紧急|高|中|低
--|(% rowspan="3" %)BOSS系统|故障| | | | |
--|申告| | | | |
--|告警| | | | |
--|(% rowspan="3" %)客服系统|故障| | | | |
--|申告| | | | |
--|告警| | | | |
--
--指标计算方法如下：
--
--|序号|指标名称|指标计算说明
--|1|故障总数|(((
--数量：在事件单中根据以下条件过滤：
--
--* 【重复事件标记】为空
--* 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
--* 【事件发生时间】在统计周期内
--* 【事件性质】＝‘故障’
--)))
--|2|申告总数|(((
--数量：在事件单中根据以下条件过滤：
--
--* 【重复事件标记】为空
--* 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
--* 【事件发生时间】在统计周期内
--* 【事件性质】＝‘申告’
--)))
--|3|告警总数|(((
--数量：在事件单中根据以下条件过滤：
--
--* 【重复事件标记】为空
--* 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
--* 【事件发生时间】在统计周期内
--* 【事件性质】＝‘告警’
--)))
--|4|紧急、高、中、低|在故障、申告、告警中分别过滤【事件优先级】
--|5|业务系统|分别过滤【所属系统类型】的业务系统
--
--
--== 1.11.2.按业务系统细分的故障和优先级分类统计报表 ==
--
--|(% rowspan="2" %)业务系统|(% rowspan="2" %)子类|(% rowspan="2" %)故障数量|(% colspan="4" %)优先级
--|紧急|高|中|低
--|(% rowspan="17" %)BOSS系统|营销管理| | | | |
--|渠道管理| | | | |
--|客户服务| | | | |
--|产品管理| | | | |
--|客户管理| | | | |
--|订单与服务请求管理| | | | |
--|服务开通| | | | |
--|资源管理| | | | |
--|综合采集| | | | |
--|融合计费| | | | |
--|综合帐务| | | | |
--|综合结算| | | | |
--|合作伙伴管理| | | | |
--|基础功能| | | | |
--|统计报表| | | | |
--|一级BOSS| | | | |
--|其它| | | | |
--|客服系统| | | | | |
--
--指标计算方法如下：
--
--|序号|指标名称|指标计算说明
--|1|故障总数|(((
--数量：在事件单中根据以下条件过滤：
--
--1. 【重复事件标记】为空
--1. 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
--1. 【事件发生时间】在统计周期内
--1. 【事件性质】＝‘故障’
--)))
--|2|紧急、高、中、低|在故障、申告、告警中分别过滤【事件优先级】
--|3|业务系统|分别过滤【所属系统类型】的子类
--
--
--== 1.11.3.按业务系统统计故障和申告处理效率指标报表  ==
--
--|(% rowspan="2" %)业务系统|(% rowspan="2" %)事件性质|(% rowspan="2" %)总数|(% rowspan="2" %)服务台解决率|(% rowspan="2" %)一线解决率|(% rowspan="2" %)二线解决率|(% rowspan="2" %)三线解决率|(% rowspan="2" %)及时解决率|(% rowspan="2" %)一次解决率|(% rowspan="2" %)超时未解决数|(% colspan="4" %)平均解决时间
--|紧急|高|中|低
--|(% rowspan="4" %)BOSS系统|故障| | | | | | | | | | | |
--|申告| | | | | | | | | | | |
--|咨询| | | | | | | | | | | |
--|告警| | | | | | | | | | | |
--|(% rowspan="4" %)客服系统|故障| | | | | | | | | | | |
--|申告| | | | | | | | | | | |
--|咨询| | | | | | | | | | | |
--|告警| | | | | | | | | | | |
--|(% rowspan="4" %)经营分析|故障| | | | | | | | | | | |
--|申告| | | | | | | | | | | |
--|咨询| | | | | | | | | | | |
--|告警| | | | | | | | | | | |
--|(% rowspan="2" %)容灾系统|故障| | | | | | | | | | | |
--|告警| | | | | | | | | | | |
--|(% rowspan="2" %)BOMC|故障| | | | | | | | | | | |
--|告警| | | | | | | | | | | |
--|(% rowspan="2" %)其它系统|故障| | | | | | | | | | | |
--|告警| | | | | | | | | | | |
--
--指标计算方法如下：
--
--|序号|指标名称|指标计算说明
--|1|(((
--故障总数
--
--申告总数
--
--咨询总数
--
--告警总数
--)))|(((
--数量：在事件单中根据以下条件过滤
--
--1. 【重复事件标记】为空
--1. 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
--1. 【事件发生时间】在统计周期内
--1.  分别统计【事件性质】＝‘故障’、‘申告’、‘咨询’、‘告警’
--)))
--|2|服务台解决率|(((
--数量：在（故障、申告、咨询、告警）总数中过滤所有【事件解决人角色】＝‘服务台’
--
--比率：数量 / 总数 × 100 %
--)))
--|3|一线解决率|(((
--数量：在（故障、申告、咨询、告警）总数中过滤所有【事件解决人角色】＝‘一线’
--
--比率：数量 / 总数 × 100 %
--)))
--|4|二线解决率|(((
--数量：在（故障、申告、咨询、告警）总数中过滤所有【事件解决人角色】＝‘二线’
--
--比率：数量 / 总数 × 100 %
--)))
--|4|三线解决率|(((
--数量：在（故障、申告、咨询、告警）总数中过滤所有【事件解决人角色】＝‘三线’
--
--比率：数量 / 总数 × 100 %
--)))
--|6|一次解决率|(((
--数量1：在（故障、申告、咨询、告警）总数中过滤【事件结束代码】＝‘成功解决’or‘变通方法解决’
--
--数量2：在（故障、申告、咨询、告警）总数中过滤【事件结束代码】＝‘不成功’
--
--比率：（数量1 － 数量2） / 数量1  × 100 %
--)))
--|7|超时未解决数|数量：在（故障、申告、咨询、告警）总数中过滤【处理已超时】＝‘超时’and 【事件状态】！＝（‘关闭’or ‘已解决’）
--|8|平均解决时间|(((
--完成的事件：在（故障、申告、咨询、告警）总数中过滤所有【事件状态】＝‘已解决’or ‘关闭’的事件
--
--平均解决时间：累加完成事件的（【实际完成时间】－【登记时间】）/ 完成的事件数量
--)))
--
--
--== 1.11.4.按事件分类的故障和优先级统计报表 ==
--
--|(% rowspan="2" %)类别|(% rowspan="2" %)子类|(% rowspan="2" %)(((
--故障
--
--数量
--)))|(% colspan="4" %)优先级
--|紧急|高|中|低
--|(% rowspan="8" %)系统硬件|小型机| | | | |
--|PC服务器| | | | |
--|路由器| | | | |
--|网络交换机| | | | |
--|磁盘阵列| | | | |
--|存储光纤交换机| | | | |
--|磁带库| | | | |
--|安全设备| | | | |
--|(% rowspan="7" %)系统软件|操作系统| | | | |
--|数据库| | | | |
--|中间件| | | | |
--|集群软件| | | | |
--|备份软件| | | | |
--|系统管理软件| | | | |
--|安全软件| | | | |
--|(% rowspan="5" %)应用软件|进程| | | | |
--|数据| | | | |
--|参数| | | | |
--|代码| | | | |
--|接口| | | | |
--|(% rowspan="4" %)客服设备|排队机| | | | |
--|CTI服务器| | | | |
--|CCS| | | | |
--|IVR服务器| | | | |
--|(% rowspan="3" %)配套设施|UPS| | | | |
--|空调| | | | |
--|其它| | | | |
--
--指标计算方法如下：
--
--|序号|指标名称|指标计算说明
--|1|故障总数|(((
--数量：在事件单中根据以下条件过滤：
--
--1. 【重复事件标记】为空
--1. 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
--1. 【事件发生时间】在统计周期内
--1. 【事件性质】＝‘故障’
--)))
--|2|紧急、高、中、低|在故障总数分别过滤【事件优先级】
--|3|事件分类|分别过滤【事件分类】的子类
--
--
--== 1.11.5.按业务中断时长分类的统计报表 ==
--
--|业务系统|子类|故障数量|业务中断时长
--|(% rowspan="17" %)BOSS系统|营销管理| |
--|渠道管理| |
--|客户服务| |
--|产品管理| |
--|客户管理| |
--|订单与服务请求管理| |
--|服务开通| |
--|资源管理| |
--|综合采集| |
--|融合计费| |
--|综合帐务| |
--|综合结算| |
--|合作伙伴管理| |
--|基础功能| |
--|统计报表| |
--|一级BOSS| |
--|其它| |
--|客服系统| | |
--|经营分析| | |
--|容灾系统| | |
--|BOMC| | |
--|其它系统| | |
--
--注： 业务中断时长＝业务恢复时间－事件发生时间， 单位为分钟
--
--指标计算方法如下：
--
--|序号|指标名称|指标计算说明
--|1|故障数量|(((
--数量：在事件单中根据以下条件过滤：
--
--1. 【重复事件标记】为空
--1. 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
--1. 【事件发生时间】在统计周期内
--1. 【事件性质】＝‘故障’
--)))
--|2|业务中断时长|【业务恢复时间】－【事件发生时间】
--|3|业务系统分类|分别过滤【所属系统类型】的子类
--
--
--== 1.11.6.故障厂商统计 ==
--
--|系统分类|厂商名称|故障数量|重大|严重|一般
--|(% rowspan="4" %)小型机|HP| | | |
--|IBM| | | |
--|SUN| | | |
--|NCR| | | |
--|(% rowspan="4" %)路由器|Cisco| | | |
--|中兴| | | |
--|3COM| | | |
--|华为| | | |
--|(% rowspan="4" %)网络交换机|Cisco| | | |
--|中兴| | | |
--|3COM| | | |
--|华为| | | |
--|(% rowspan="7" %)磁盘阵列|HP| | | |
--|EMC| | | |
--|IBM| | | |
--|NCR| | | |
--|HDS| | | |
--|NETAPP| | | |
--|SUN| | | |
--|(% rowspan="5" %)存储光纤交换机|HP| | | |
--|IBM| | | |
--|McDATA| | | |
--|BROCADE| | | |
--|EMC| | | |
--|(% rowspan="5" %)磁带库|HP| | | |
--|SUN| | | |
--|IBM| | | |
--|STK| | | |
--|Quantum ATL| | | |
--|(% rowspan="6" %)数据库|Oracle| | | |
--|DB2| | | |
--|Microsoft| | | |
--|TERADATA| | | |
--|Informix| | | |
--|Sybase| | | |
--|(% rowspan="3" %)操作系统|HP| | | |
--|IBM| | | |
--|SUN| | | |
--|(% rowspan="4" %)系统管理软件|CA| | | |
--|HP| | | |
--|BMC| | | |
--|IBM| | | |
--|(% rowspan="4" %)中间件|BEA| | | |
--|IBM| | | |
--|东方通科技| | | |
--|Borland| | | |
--|(% rowspan="3" %)客服设备|华为| | | |
--|AVAYA| | | |
--|北电| | | |
--
--注：该报表中的厂商按照各省实际情况上报。
--
--指标计算方法如下：
--
--|序号|指标名称|指标计算说明
--|1|故障数量|(((
--数量：在事件单中根据以下条件过滤：
--
--1. 【重复事件标记】为空
--1. 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
--1. 【事件发生时间】在统计周期内
--1. 【事件性质】＝‘故障’
--)))
--|2|重大、严重、一般|在故障数量分别过滤【事件影响度】
--|3|故障厂商|分别过滤【故障厂商】
--
--
--== 1.11.7.各组工程师工作量和工作效率统计报表 ==
--
--|(% rowspan="2" %)**组**|(% rowspan="2" %)**人员**|(% rowspan="2" %)(((
--**处理事件**
--
--**总数**
--)))|(% rowspan="2" %)**未解决事件数**|(% rowspan="2" %)**一次解决率**|(% colspan="4" %)**平均处理时间――按优先级分布**|(% colspan="5" %)**按事件性质分布的处理事件数**
--|**紧急**|**高**|**中**|**低**|**系统故障**|**平台告警**|**服务咨询**|**客户投诉**|**业务可用性告警**
--|(% rowspan="8" %)帮助台| | | | | | | | | | | | |
--| | | | | | | | | | | | |
--| | | | | | | | | | | | |
--| | | | | | | | | | | | |
--| | | | | | | | | | | | |
--| | | | | | | | | | | | |
--| | | | | | | | | | | | |
--| | | | | | | | | | | | |
--|(% rowspan="5" %)一线支持| | | | | | | | | | | | |
--| | | | | | | | | | | | |
--| | | | | | | | | | | | |
--| | | | | | | | | | | | |
--| | | | | | | | | | | | |
--|(% rowspan="4" %)二线支持| | | | | | | | | | | | |
--| | | | | | | | | | | | |
--| | | | | | | | | | | | |
--| | | | | | | | | | | | |
--
--

1730084151498-853.png

Author

...	...	@@ -1,1 +1,0 @@
1		-XWiki.superadmin

Size

...	...	@@ -1,1 +1,0 @@
1		-79.1 KB

Content

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司