企业服务总线ESB方案书

企业服务总线ESB方案书

第1页，共38页 1 需求综述 ......................................................................................... 4

1.1 主数据平台接口 .................................................................................... 4 1.2 业务数据接口 ....................................................................................... 4 1.3 OA系统接口： .................................................................................... 5 1.4 国家法定信息发布媒体： ...................................................................... 5

2 系统解决方案 ................................................................................. 5

2.1 系统技术架构 ....................................................................................... 5

2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7 2.3.1 2.3.2 2.3.3 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.4.6 2.4.7 2.5.1 2.5.2 2.5.3

运行平台 ................................................................................................................6 开发平台 ................................................................................................................6 监控平台 ................................................................................................................7 公共服务 ................................................................................................................7 适配器 ....................................................................................................................7 管理监控部分部署方案 ........................................................................................9 硬件选型建议 ..................................................................................................... 10 逻辑分区部署方案 ............................................................................................. 11 硬件配置建议 ..................................................................................................... 11 服务接口规范 ..................................................................................................... 12 高性能、高可用性及扩展能力设计 ................................................................. 12 完善的安全机制 ................................................................................................. 13 接入控制 ............................................................................................................. 16 通信接入模块 ..................................................................................................... 17 请求系统适配 ..................................................................................................... 18 服务治理 ............................................................................................................. 19 提供对出错服务的及时检测和隔离功能 ......................................................... 20 协议转换 ............................................................................................................. 20 消息格式转换 ..................................................................................................... 21 服务路由 ............................................................................................................. 22 监控和运维 ......................................................................................................... 22 服务等级 ............................................................................................................. 23 可用性 ................................................................................................................. 24 可扩展性 ............................................................................................................. 24 可维护性 ............................................................................................................. 25

2.2 部署方案 ............................................................................................... 9

2.3 整体解决方案 ..................................................................................... 15

2.4 集成服务功能 ..................................................................................... 19

2.5 系统非功能需求 .................................................................................. 24

第2页，共38页 2.5.4 2.5.5 2.6.1 2.6.2 2.6.3 2.6.4 2.7.1 2.7.2 2.7.3 2.7.4 2.7.5

安全性 ................................................................................................................. 25 性能需求 ............................................................................................................. 25 流量控制 ............................................................................................................. 26 故障隔离 ............................................................................................................. 26 统一流水号 ......................................................................................................... 27 日志记录 ............................................................................................................. 27 系统平台级监控 ................................................................................................. 27 应用级监控 ......................................................................................................... 27 统计分析 ............................................................................................................. 27 异常报警 ............................................................................................................. 28 统一的运维管理 ................................................................................................. 28

2.6 公用服务 ............................................................................................. 26

2.7 管理监控 ............................................................................................. 27

3 技术支持与服务方案 .................................................................... 28

3.1 技术支持与售后服务体系 .................................................................... 29 3.2 服务管理模式 ..................................................................................... 29 3.3 服务响应 ............................................................................................. 30

3.3.1 3.3.2 3.3.3 3.3.4 3.4.1 3.4.2 3.4.3 3.4.4

问题优先级（或问题严重程度）级定义 ......................................................... 30 服务响应时间 ..................................................................................................... 31 问题解决时间 ..................................................................................................... 33 服务文档 ............................................................................................................. 34 服务消息创建流程 ............................................................................................. 35 问题处理流程 ..................................................................................................... 35 服务确认流程 ..................................................................................................... 36 投诉及问题升级流程 ......................................................................................... 37

3.4 维护支持服务流程 .............................................................................. 35

第3页，共38页 1 需求综述

1.1 主数据平台接口

系统建立与SAP相同的基础数据管理库，通过数据总线接口同步能源集团MDM中传输过来的编码或数据，以满足电子采购平台基础数据管理的需求。基础数据信息包括：物料编码、计量单位、供应商、客户等。

1.2 业务数据接口

系统业务数据通过数据总线接口同SAP、OA、EC等系统进行数据交互。 系统必须确保通过数据总线接口访问SAP、OA、EC等系统数据与电子采购平台数据传输及时准确、数据完整统一；

SAP OA办公系统 MDM EC 中矿微星系统 数据总线系统 电商平台 第4页，共38页 数据中心

1.3 OA系统接口：

支持将电子采购平台中的待办事项发送到OA办公系统进行审批，并读取审批流。

1.4 国家法定信息发布媒体：

按照国家相关要求，选择相关媒体建立统一接口，支持招标公告、变更公告、结果公示等的自动发布。如国家无强行规定，可以不做接口。

2 系统解决方案

2.1 系统技术架构

第5页，共38页

2.1.1 运行平台

运行平台内部按照集成应用的特点分为多个集成“通路”，目前考虑分为四类通路： 1、关键服务通路

关键业务、实时性要求高。 2、非关键通路 非关键业务，查询等。 3、服务代理通路

从目标架构过渡过程中，与集成目标无关的可以采取“穿透”的方式，减少实施工作量和实施成本。

另外，复用价值较低的服务请求也适合采用“代理模式”。 4、低成本通路

对于实时性要求不高，且信息量大的服务，可采取批量处理模式，降低集成实施成本。 实际部署环境中，每一类通路都可以有多个物理部署，用来保证系统的可靠性，同时也支持横向的扩展和减少不同系统之间的相互影响。

2.1.2 开发平台

基于ESB系统标准的服务接口定义、内部统一的元数据管理、数据结构和服务接口定义、路由规则等，实现多个技术通路的统一配置开发。

开发平台的是对各个技术通路实际实现方法的抽象封装。提供服务逻辑的开发框架和组件库，用于转换适配逻辑、公共服务逻辑等的标准化开发、组件重用和统一管理。

第6页，共38页

2.1.3 监控平台

ESB应用系统要建立统一的日志规范、流水记录规范、错误码规范、系统运行状态检测规范、系统运行状态控制标准，实现对ESB系统整体统一的监视和控制。是 ESB系统的集成“控制面板”。

主要功能包括：异常监视、通知提醒、运行控制、实时查询、统计分析、服务的配置和发布、服务管理、统一维护和版本部署等。

由于ESB系统是整个企业的服务访问枢纽，ESB可以集中监控企业内所有的服务访问，能够提供各个系统的服务质量和状态的统计数据，例如：成功率、服务响应时间、服务访问量、服务状态异常等。 2.1.4 公共服务

提供统一的流量控制服务、日志记录、接入参数控制等公共服务。从而实现多技术平台、多物理部署运行环境的公共服务支持。 2.1.5 适配器

适配器是ESB系统解决与外部系统之间各类差异的总称。 ESB将外部系统分为请求系统和服务系统两类。 2.1.5.1

服务系统适配器

第7页，共38页 对于服务系统，尤其是遗留服务系统，基本集成策略是由ESB项目组开发适配器进行集成。但是服务系统适配器，并不能解决所有的服务适配问题，例如：ESB服务接口规范与服务系统规范的复杂对应和匹配工作，尤其是涉及到多个服务系统接口的复杂流程调用部分，如果由ESB组合这类服务流程组合，解决相关的交易完整性、一致性问题，代价太大而且无法保证。

因此，实际集成实施过程中，不可避免的要涉及到对服务系统的改造工作。 2.1.5.2

请求系统适配器

对于请求系统，ESB的基本原则是要求请求系统符合ESB的技术规范和服务接口规范。目的是减少不必要的转换适配层次，提高系统的集成服务效率，降低资源消耗。 ESB系统可为请求系统提供API，对请求系统屏蔽通讯适配、报文组包等技术细节。请求系统只需要理解业务层面的接口规范，从而大大简化请求系统的集成工作，同时还可以加强对请求系统的监控管理，同时为接口技术实现的升级改造提供辅助支持。 ESB也可以开发适配器，实现请求系统的集成。主要针对那些无法改造或改造成本过高的请求系统。

第8页，共38页 2.2 部署方案

2.2.1

管理监控部分部署方案

ESB系统的部署方案必须符合企业基础架构的要求。

1）WebServer和Application Server必须分离，分别部署在Web2区和APP区。 或者Web2区的应用通过生产区域的APP，访问DB。 2）用户管理要符合集团的规范。用户权限控制统一通过UM。 UM决定用户是否有权限操作ESB的管理监控平台。

UM权限通控制通过以后，由ESB管理监控应用来进行详细的角色权限管理。 3）考虑到费用问题，可以采用Apache和Tomcat。

第9页，共38页 2.2.2 硬件选型建议

ESB系统目标架构硬件选型主要考虑从以下因素： 1）成本因素

ESB系统基于Java技术实现，具有跨平台的技术优势，因此可将成本是考虑硬件选型的首要指标，未来随着ESB应用规模的不断增长，硬件成本在项目投入所占比重将会增加，因此选择性价比高的硬件平台是提高效费比的有效途径。 2）硬件扩容周期

ESB作为企业内部信息化最为关键的服务枢纽，必须能够快速响应应用规模的增长，其中包括硬件的采购周期、系统扩容部署速度。 3）资源调配的简便性、灵活性

ESB系统应能够针对业务量的周期性变化，灵活的增减系统资源配置，资源的调整不应对集成服务持续性造成影响。

基于上述考虑，ESB系统的硬件推荐采用刀片服务器。 刀片服务器还具有以下优点：

1) 硬件成本相对低廉，配套的系统软件和中间件价格也相对较低。 2) 虚拟化的集中资源管理，可有效提高资源的利用率。 3) 在集群中插入新的刀片，就可以提高整体性能。

4) 支持热插拔，硬件资源可以轻松地进行替换，并且将维护时间减少到最小。 5) 节约空间、便于集中管理、易于扩展和提供不间断的服务。

第10页，共38页

2.2.3 逻辑分区部署方案

2.2.4 硬件配置建议

其对应分配如下：

名称 适配器/公共服务 集成核心 功能分布 适配器公共服务 配置 2cpu(8核) 32GB memory WebMethods Message Broker 数据库服务器 Oracle 2cpu(8核) 32GB memory 2cpu(8核) 32GB memory 归档数据库服务器 Oracle 2cpu(8核) 32GB memory 备份资源池 作为公共备份 2cpu(8核)32GB memory 总计 第11页，共38页 计算单元数量 1*2 1*2 1 1 1 7 2.2.5 服务接口规范

ESB系统负责解决实施服务接口规范与服务系统接口的差异，可将主要的实施工作控制在ESB项目范围内，大大降低周边系统的改造工作量，配合一些系统的瘦身计划的分阶段顺利实施。

2.2.6 高性能、高可用性及扩展能力设计

高处理能力保证措施

控制信息+XML应用报文，中间层次不必解析XML应用报文，使系统不仅具备完善的管理控制能力，同时还减少了报文解析开销，提高了效率。 非阻塞的异步模式、流水线式的作业处理，提高吞吐能力。

异步记录流水日志，保证信息的完整记录，同时不影响系统的处理性能。 系统处理能力可随硬件资源的扩展线性的增长。

系统所有配置规则均加载到Cache中，运行过程中不存在对数据库配置信息的读写操作，保证系统高效运行。 持续稳定运行保障措施

所有应用模块均为群集部署，系统不存在单点故障隐患，某个模块的故障不影响正常运行。

系统应用版本的升级可按模块分别进行，不影响业务的正常运行。

采用数据库分区技术，实现海量数据记录的清理和分区切换过程15秒钟内完成，无需采用与应用相关的数据库分表方式，实现批量数据处理对总线应用透明。

第12页，共38页 系统提供完备的动态安全刷新手段，配置信息可运行时在线刷新。 可扩展性

系统可以在CPU、内存等资源增加及扩容的情况下自我线性扩展处理能力；每个逻辑模块可以采用横向扩展的多物理模块部署。中间用队列进行通讯。 可维护性

系统具有较为完善的用户管理界面，提供对系统所有功能的维护与参数配置管理的功能；系统采用统一的服务模式和开发框架，从开发商增加可维护性，系统部署上采用多逻辑单元分离部署，减少系统内部的耦合度，增加整个系统的可维护性。

2.2.7 完善的安全机制

企业应用集成技术使复杂的业务流程、大量的信息和数据在各IT应用系统和业务部门之间高效的流转和共享，实现业务流程标准化和自动化，促进业务流程优化，提高建行运营效率。任何不安全因素都会造成不可估量的损失，故所有数据的传输、处理、交换都必须在良好的安全环境下进行，因此，必须建立一套完整的安全机制，以确保整个通信系统的安全运行。方案主要为ESB系统提供如下几个方面的安全服务： 1. 密钥管理

提供安全有效的密钥管理方案，实现应用系统和ESB系统的密钥产生、密钥分发、密钥更新、密钥注销等。提供密钥的自动更新机制，保证密钥的安全性，提供高效的对称密码算法，确保应用系统具有可用性和易用性。 2. 身份认证

第13页，共38页 保证接入ESB系统的合法性，提供应用系统和ESB系统之间的双向身份认证，采用基于证书的认证模式，系统使用的数字证书由第三方CA或者采用自运行维护的CA提供。CA证书采用离线下发的方式，以PKCS#12文件的格式安装到ESB系统和应用接入系统。

身份认证完成后，双方得到一个64个字节的随机数，通讯双方使用的对称密钥都是基于这一组随机数产生，对称密钥的选取规则双方使用相同的策略。对称密钥和对方的公钥信息存放在系统主机的共享内存，方便应用系统加密使用 3. 通讯加密

ESB系统的安全性是保障IT应用系统安全可靠运行的重要环节，使用PKI技术实现系统的密钥管理和通讯加密是目前解决此类问题的最有效途径，应用系统和ESB系统之间通讯的报文使用对称算法加密保护其机密性。为了提高密码运算的处理速度，这里推荐使用AES算法，密钥的长度为128bit。

通讯双方在身份认证完成后，在共享内存中保存对称密钥。客户端和服务器端的加密流程如下：

客户端加/解密流程：

1) 查询共享内存中的对称密钥和算法ID，根据加密要求选取对称密钥，如果共享内存中没有对称密钥，加/解密失败。

2) 使用查询得到的对称加密密钥，对报文进行加/解密处理。 服务器端加/解密流程：

第14页，共38页 1) 根据客户端的系统代码，查询共享内存的加密密钥和算法ID，如果共享内存中没有 对称密钥，加/解密失败。

2) 使用查询得到的对称密钥，对报文进行加/解密处理。 4. 关键字段MAC

2.3 整体解决方案

ESB集成技术架构方案划分为四个层面：渠道通迅接入、数据交换层、平台服务调度层、服务适配层。系统的每个层次都可进行横向扩展，实际应用中系统处理能力可以线性增长。

? 对于渠道服务请求的接入，ESB提供标准的通迅协议（支持TCP/IP、HTTP、

SNA、 FTP、MQSeries、JMS等协议和中间件）和ＭＢＳＤ标准接口规范，同时还为请求系统提供服务请求的API，屏蔽通讯协议和报文格式的技术细节，能够提高请求系统的集成开发效率、减少转换适配环节，同时还大大加强了总线系统对接入的控制和管理，促进了集成应用的快速推广和可靠运行。

? 对于改造成本过高的存量系统，

通过集成开发在数据交换层实现分类路由、同步异步转换、消息格式转换、代码转换等功能。

? 平台服务调度支持四种模式：

（一）、ＭＢ通道，用于高时效性、高一致性、高吞吐 能力的服务；

第15页，共38页

但是应注意，ESB更多的情况下是为了适应服务系统的技术差异，才进行通讯的适配，从系统的规范化和易维护性角度考虑，不推荐被动的对请求系统进行通讯协议适配。 接入框架提供了对各种通讯协议的转换适配器，可以满足上述协议转换要求。MQ自身作为消息中间件为JMS通讯协议提供底层的通讯服务。但ESB作为企业服务总线需要有大吞吐量，而同步服务并发有限，容易造成资源的阻塞，以异步的方式进行访问，而MQ作为消息中间件，是最好的异步通讯方式。

2.4.4 消息格式转换

支持通过元数据管理消息格式定义；支持任意类型报文之间的转换。

消息格式转换是集成类系统应具备的基本功能，ESB系统对于消息格式的转换是基于配置实现的，因此消息报文的的数据域需要在配置中进行定义。

ESB的服务接口规范标准中包括规范中使用的数据域。在ESB系统内部数据域分为不同的类型、长度、精度等表示形式，ESB系统引用预先定义的、规范化的元数据对服务接口规范进行描述，使用元数据可以是规范定义工作更加规范化、减少冗余、便于管理和统一维护。

元数据可根据应用范围划分成不同的“域”，可以更加方便的进行方便维护和管理。 ESB系统一般通过配置方式实现标准与非标准的报文转换，包括：格式转换和数据映射，对于复杂的映射规则可以通过增加映射功能函数（服务组件）的形式实现

第21页，共38页 MBSD接入框架提供了可配置的定长、变长报文转换组件，以及可扩展的接口可以适应各种不同格式的报文转换。同时接入框架提供了MBSD元数据管理功能，能够方便的定义报文的元数据，为报文的转换以及应用的开发提供了便利。目前已经支持XML，定长等多种报文格式。

2.4.5 服务路由

基于服务ID、内容、结果等方式路由；交易流程能使用智能路由组合多个子交易。 我们采用两个层次的路由：

? 前端API进行的服务通路路由。前端API根据ESB平台提供的接入参数信息决定采用哪条通路（MB/WEBMETHODS）进行服务访问。

? 核心的交易路由。由MB/WEBMTHODS核心进行路由，根据交易码决定哪个后台服务系统进行服务访问。 路由方式： ? 服务ID路由。也就是交易码进行路由判断。

? 数据依赖路由。动态的根据报文中的数据和配置业务规则进行路由选择。 ? 复杂流程路由。在复杂组合交易中根据每一步的响应结果和配置的复杂交易流程来进行路由选择。此路由在ESB平台的流程配置来实现。

2.4.6 监控和运维

第22页，共38页 提供服务调用的记录、测量和监控数据；提供事件检测、触发和发布功能；支持产品版本升级后对现有组件的兼容性。

ESB系统应记录每一次服务访问的流水信息，用于统计和分析。记录过程应该是高效的，应避免流水的记录影响服务的执行效率。流水记录一般只记录服务过程的摘要信息。需要时，可以通过开关控制打开或关闭详细的报文信息。

系统还应及时捕获服务处理过程中的各种异常信息，通过统一的控制台发出报警，警示信息应划分异常的类别和级别，对于重要的异常还可以通过短信等手段及时通知运维人员及时处理。

监控管理的接口定义应是可扩展的，例如异常种类、异常级别、流水信息数据项等，做到信息的获取与后续的处理动作无关，从而保证接口的兼容性、稳定性。

2.4.7 服务等级

可定义不同的服务等级并实现具体内容。

可以从多种维度来定义服务的属性，包括服务的级别。服务的级别可以关联到不同的处理动作。

服务级别与处理的关联关系可以通过规则进行定义，实现功能的灵活定义与扩展。关联的动作可以是：处理的优先级，异常提醒方式等。

第23页，共38页 2.5 系统非功能需求

2.5.1

可用性

系统能提供功能方面的各种需求的实现，在运行环境下提供7*24小时NONE-STOP服务；ESB是服务访问的枢纽，不允许由于系统的故障和恢复过程中断系统服务，ESB应采用群集模式保证系统的高可用性，群集模式还可以使系统资源得到充分利用。 对于数据库服务器、通讯接入服务起等模块的高可用性需求，为降低实现方案的复杂度和实施成本，可采用设备之间相互热备的方式。例如数据库服务器可以和归档数据库服务器采用热备的方式保证高可用性。

系统自身的批量处理，如：数据归档清理，日志归档等工作，不能影响系统的正常运行，保证系统7*24小时连续运行。

需要定期进行的系统资源累积效应消除动作，如：定期重启Java虚拟机消除长期运行后的堆栈碎片，应保证在其他群集模块正常运行的情况依次进行，保证系统服务不间断。系统的配置更新应采用动态刷新的机制联机进行，避免配置更新对系统的处理能力造成影响。

2.5.2 可扩展性

系统可以在CPU、内存等资源增加及扩容的情况下自我线性扩展处理能力；系统的架构设计要保证系统的各个层次均可按照负载情况，单独进行横向的扩展，以提高处理能力。应保证处理能力随硬件资源的扩展呈线性增长。

第24页，共38页 2.5.3 可维护性

统具有较为完善的用户管理界面，提供对系统所有功能的维护与参数配置管理的功能； 系统涉及到多种平台产品和技术、采用多物理分区的部署方式，单独对每个分区进行监控和维护是不现实的，必须提供统一的管理监控界面，实现系统的集中统一管理、监控和维护。

2.5.4 安全性

提供认证和授权、不可否认和机密性、安全标准的支持等。

ESB系统作为服务访问的中间层，除了发布标准的安全规范以外，还要满足各类集成应用的安全需求，要实现与存量服务系统的安全协议支配，因此ESB需要支持通讯层面，应用层面的安全技术标准。例如：对标准安全协议的支持，通讯过程加解密，MAC校验，PKI，特定场景的数字签名等。

2.5.5 性能需求

统能通过招标人的压力测试。

性能指标：日均1000万笔数据，ESB对于关键数据的处理时间<1秒，对于非关键数据ESB的处理时间<2秒。

第25页，共38页

达到系统性能指标峰值要求时，系统处理能力应留有足够的余量，CPU，内存等系统资源的使用率应低于80%，达到平均值要求时，系统资源使用率应低于50%。保证系统在设计指标压力情况下的长期稳定运行。

2.6 公用服务

2.6.1

流量控制

当服务访问量超过预设的流量值时，总线系统快速挡回对该服务的访问请求，根据服务系统的服务响应时间和返回状态，判断服务状态是否异常，当服务系统发生异常达到设定的条件时，自动降低对该服务系统的访问流量限制，避免服务系统的故障影响范围扩大。

通过交易阀值的统计来完成实时的后台系统服务质量统计。从而达到对前端系统访问的指示。在后台服务质量不好的情况下，把针对此后台的数据在接入层直接挡回，避免交易在ESB中占用过多处理资源。

由于系统超时时间一般设置的比较长，防止公用通路被单一后台服务通道堵塞，需要知道后台系统的运行状况，当出现问题后，及时隔离，不影响主通路运行。

2.6.2 故障隔离

服务系统发生异常达到设定的条件时，自动降低对该服务系统的访问流量限制，避免服务系统的故障影响范围扩大。保留少量的探测服务对故障系统进行探测，服务系统故障排除恢复正常后，总线系统可自动恢复其正常的流量。

第26页，共38页 2.6.3 统一流水号

实现ESB平台内统一标准平台流水号的分配功能，唯一标识请求系统的发往ESB平台单次服务调用。

2.6.4 日志记录

应用日志作为服务系统的又一I/O点，也可以采用异步模式。将一个服务线程在完成一次报文处理过程中的所有日志集中一次性异步输入到指定文件是必要的。一方面减少业务处理线程的I/O操作，另一方面讲一次业务处理的日志集中输出相比传统的多线程分离输出方便问题查找，大大增加了日志的可读性。

2.7 管理监控

由于实际部署的系统随着需求的增加，部署会经常发生变化，对于随着出现的多监控源，我们需要建立统一集中的管理和操作平台。需要做到以下几方面：

2.7.1 系统平台级监控

包括cpu，内存，文件系统，各队列深度，应用日志，应用core文件等。

2.7.2 应用级监控

包括各部署模块的内部运行状态。

2.7.3 统计分析

第27页，共38页 既定的汇报机制、汇报内容和汇报格式。有些汇报的内容是通过手工统计汇总的，能尽量将这些汇报物交由报表系统自动生成。ESB作为全行的运行基础平台，需要能向IT部分提供全面的IT资源运行情况，为全行的IT资源分配提供依据。

2.7.4 异常报警

对平台运行的问题进行报警，需要有统一的报警规范来支持未来报警类型的扩展，需要提供多种报警模式，例如声音，短信，微信等。

2.7.5 统一的运维管理

提供应用日志，流水日志的统一处理，防止多点，多平台部署情况下维护混乱的情况。

3 技术支持与服务方案

公司在大力开拓市场的同时，高度重视售后服务及技术支持工作，始终恪守“客户满意第一”的原则，以全力满足用户的一切需要为己任，向用户提供“及时、专业、真诚”的技术服务。公司不仅为用户提供一流的产品，而且为用户提供一流的服务，在第一时间对用户的服务要求做出响应。

公司将尽心尽力与用户紧密合作，为用户单位提供及时、全面的技术支持和服务，保障系统的正常运行。

第28页，共38页 3.1 技术支持与售后服务体系

为满足客户系统7X24小时不间断、高可靠地运行，公司按照国际质量标准，形成了一套完备严谨的质量管理体系，实现了从产品、服务到公司运营全过程、全方位的质量管理

3.2 服务管理模式

公司将按如下模式进行技术支持与服务管理：

1) 公司服务代表是对客户服务需求的接口，并定位服务内容，指定服务技术人员,咨询顾问。

2) 公司服务团队负责提供维护支持服务。

3) 公司全体技术人员,咨询顾问都可以作为后台资源，为服务技术人员,咨询顾问提供支持，满足客户的服务需求。在必要时还可以要求合作伙伴提供技术支持，为客户提供满意的服务。

4) 客户的服务需求将按级别优先级响应，并提供相应的服务。

第29页，共38页

3.3 服务响应

3.3.1

问题优先级（或问题严重程度）级定义

优先级定义：

优先级 判定标准 系统崩溃，无法启动或拒绝连接等原因导致客户无法获得任何系1 统服务，并对客户业务的正常运行造成重大影响。 系统主要功能不能正常工作，并对客户业务的正常运行造成较大2 影响；生产系统不稳定，并有周期性的中断。 系统有故障，但仍可全面运行，对客户业务系统的正常运行有一3 定的或轻微的影响 4 优先级1、2和3之外的问题和需求，例如产品性能增强请求；第30页，共38页

产品功能、安装或配置方面需要信息或支持，对客户的业务运作几乎无影响；非生产系统故障。 严重程度定义：

严重程度1：问题导致客户的业务系统完全丧失服务功能，对业务至关重要的工作无法继续进行，情况紧急。具有如下特点：

数据丢失、关键功能丧失、系统不正常刮起、系统崩溃，并在启动后重复崩溃。

严重程度2：问题导致客户的业务系统丧失部分重要的服务功能，没有可以接受的替代解决方案，但业务系统可以有限的继续运行。

严重程度3：问题导致客户的业务系统丧失较少的服务功能。对业务系统影响较小，需要提供解决方案以恢复功能。

严重程度4：问题导致客户的业务系统没有丧失服务功能。一般是较小的错误信息、不正确的结果或文档错误，对业务系统运行没有影响。

3.3.2 服务响应时间

在接到客户方通过电话、信函、传真、电子邮件等方式提出的服务请求后，我方将在规定的响应时间内尽快做出响应，并根据问题的优先级采取相应的措施。

服务响应时间：

第31页，共38页 优先级 响应时间 1 < 1小时 2 < 1工作日 3 < 2工作日 4 < 5工作日 对优先级为1的问题：公司将不分昼夜和节假日，立即安排相关人员与客户沟通，查找、分析问题原因，提供解决方案及处理意见，并采用远程和现场服务的方式，务求在最短的时间内解决客户的问题。

对优先级为2的问题：公司将不分节假日，在接到客户服务请求的当天内，安排相关人员与客户沟通，查找、分析问题原因，提供解决方案及处理意见。在远程登录无法解决问题时，最迟在48小时之内安排相关人员到达现场提供服务。

对优先级为3的问题：公司将在法定工作时间内安排相关人员与客户联系，尽可能通过远程服务方式为客户处理问题。

对优先级为4的问题：公司将在法定工作时间内安排相关人员与客户联系，客户应与公司协商，确定采用远程或现场服务方式及提供服务的时间

注： 工作时间：周一至周五9：00－18：00

第32页，共38页 3.3.3 问题解决时间

此项仅作为内部考核参考用，不作为对客户的承诺。

服务技术人员,咨询顾问在接到服务请求后，应该在规定的时间内给出解决方案，并根据问题的优先级采取相应的措施。

解决时间：

优先级 解决时间 1 < 0.5工作日 2 < 1工作日 3 < 2工作日 4 < 5工作日 对优先级为1的问题：维护技术人员,咨询顾问应该在半个工作日内确认问题原因，给出解决方案，或者至少给出解决问题的方向（例如：硬件问题：找硬件厂商等）。

对优先级为2的问题：维护技术人员,咨询顾问应该在一个工作日内确认问题原因，给出解决方案，或者给出解决问题的方向（例如：数据问题，给出切换方案），并和客户确认实施的时间点。

第33页，共38页 对优先级为3的问题：维护技术人员,咨询顾问应该在两个工作日内确认问题原因，给出解决方案，或者给出解决问题的方向，并确认后续实施的方式（例如：流程问题，重新设计流程、配置及测试）。

对优先级为4的问题：维护技术人员,咨询顾问应该在两个工作日内确认问题原因，给出解决方案，或者给出解决问题的方向（例如：开发问题，给出开发需求分析，指导客户自行开发，或者帮助客户开发，确认完成及测试时间点等）。

注 ：工作时间：周一至周五9：00－18：00

3.3.4 服务文档

服务文档格式详见附件。

(1)服务请求单：用于客户提出服务请求。需要简要描述服务需求，由客户联系人传递给公司服务代表。

(2) 服务确认单：用于技术人员,咨询顾问纪录解决方案，并由客户联系人确认服务效果，最后由公司服务代表存档。

(3) 需求定义报告：对于比较复杂的应用服务需求，由技术人员,咨询顾问完成需求定义报告，确认服务类型（应用配置、开发等），给出针对性分析，提交用户决策。

(4)服务评估表：由客户对现场服务人员进行评估，交公司服务代表存档。

第34页，共38页 3.4 维护支持服务流程

3.4.1

服务消息创建流程

流程描述

1) 客户最终用户发现问题，提交关键用户确认。

2) 关键用户判断是否需要提交服务申请，如果不需要，流程结束。

3) 确认需要提交服务申请，通过Email或者传真发送给公司help desk manager，由公司help desk manager创建相关记录。 4) 公司help desk manager开始支持服务。

3.4.2 问题处理流程

流程描述

1) Help desk manager收到服务申请（包括电话申请，Email申请），进行初步诊断，判定服务申请级别和内容，指派技术人员,咨询顾问进行支持，并通知技术人员,咨询顾问开始服务。

2) Help desk通知客户服务技术人员,咨询顾问姓名，联系方式。

3) 服务技术人员,咨询顾问收集服务需求信息，判断是否需要客户方的配合。 4) 如果需要客户的配合，服务技术人员,咨询顾问联系客户，取得响应的信息。 5) 服务技术人员,咨询顾问分析定位问题，提供解决方案。

第35页，共38页

6) 如果能解决问题，更新服务消息，并通知help desk manager。同时通知客户，确认解决方案实施。

7) 如果不能解决问题，提请问题升级处理流程。

流程图：

3.4.3 服务确认流程

流程描述

1) Help Desk manager收到通知，通过电话回访客户，确认问题已经解决。 2) 如果客户不满意或者问题没有解决，Help Desk manager通知技术人员,咨询顾问继续服务。

第36页，共38页 3) 如果客户确认问题已经解决，Help Desk manager则检查服务记录是否更新，解决方案记录是否完整有效。

4) 如果记录不完整，Help Desk manager通知技术人员,咨询顾问更新维护记录。 5) 记录完整有效，Help Desk manager close该记录，并将服务确认单Email发给客户。

流程图：

3.4.4 投诉及问题升级流程

流程描述

1) 客户对顾问的服务不满意，可以通过电话、邮件、传真等方式进行投诉。 2) Help Desk manager收到投诉，或者查到超期的服务记录，和服务工程师确认该问题的处理进度。

第37页，共38页 3) 根据工程师的反馈判断是否需要更换服务工程师。如果可以顺利继续，则由原工程师继续处理流程。

4) 如果原来工程师不能继续进行服务，或者有顾问提出升级申请，则调派高级工程师进行支持。

5) 高级工程师对问题进行诊断，继续服务流程，help desk manager通知客户相关变化。

第38页，共38页

本文来源：https://www.bwwdw.com/article/lm5g.html