电子运维知识库管理系统建设方案0107.docx

电子运维知识库管理系统建设方案0107.docx

《电子运维知识库管理系统建设方案0107.docx》由会员分享，可在线阅读，更多相关《电子运维知识库管理系统建设方案0107.docx（15页珍藏版）》请在冰豆网上搜索。

电子运维知识库管理系统建设方案0107

文件编号：

受控状态：

■受控□非受控

级别：

□公司级□部门级■项目级□普通级

采纳标准：

GB/T19001-2000idtISO9001：

2000标准

质量记录编号：

分发编号：

电子运维知识库管理系统

建设方案

Version1。

0

2007。

12

WrittenByCreator

科创信息技术股份

AllRightsReserved

1.概述

1.1.建设背景

现E-OMS系统已初步形成了面向日常运维事务、对日常运维工作进行监督和管理的具有移动自身特色的电子化运维的平台性系统，成为移动网络部日常工作、网络维护不可或缺的系统。

随着E-OMS系统的完善，电子化运维的使用人员对资源的优化，使用的方便程度提出了越来越高的要求，迫切需要建设一套电子运维知识库系统，来提高运维工作效率，以便于日常工作管理。

1.2.建设原则

按照集团公司的规划，知识库系统采用独立部署，统设的原则，达到应用统一和信息共享的目的。

由于客服目前已经依据集团规划，建设了一套知识库系统，因此不允许再进行重复性的建设。

1.3.建设容

根据前面所述的系统的建设背景及原则，我们提出：

依托客服现有的知识库系统，建设电子运维知识库管理系统。

通过对现有客服知识库系统的改造来满足电子运维对知识库的需求，同时也大大降低了成本，加快了建设的速度。

总体建设方式如下：

1、在现有知识库中新增电子运维专用数据节点，同时分配给电子运维专用的账号及权限，以便进行管理。

2、通过对现有知识库系统知识搜索功能的改造，增强现有知识库的搜索引擎功能。

3、在现有知识库系统上，增加新的业务接口，满足电子运维对知识库的需求。

2.系统体系结构

知识是人们在实践中获得的认识和经验，是客户服务所需的服务知识与营销知识，包括业务技术知识、业务代表和客户经理的日常工作总结、案例分析、移动终端的使用方法等。

知识库是按一定的层次结构，以文本、图片等方式保存所有知识容，并提供知识采编、审核、发布和维护等功能的应用。

知识库管理系统提供知识库中各项业务功能的逻辑实现，主要包括知识生成逻辑、知识应用逻辑以及公告应用逻辑，实现知识库数据在各系统的共享与应用。

知识库管理系统架构

系统采用面向对象技术来分析设计系统，采用分布式组件技术来实现系统的总体设计思想，采用模块化的结构设计。

整个系统分为数据层、业务逻辑层、服务界面层。

其中，数据层存储系统运行时的各项业务数据；业务逻辑层实现各个业务需要的各项逻辑功能；服务界面层则将各个业务逻辑最终展现给用户。

整个系统构建在移动业务规以及系统的安全管理机制之上，保证了系统的安全性、稳定性、可靠性。

3.系统功能

3.1.现有知识库功能

现有知识库系统具有知识维护、知识审核、知识发布、模板维护、知识检索、公告管理等功能。

3.1.1.知识维护

【功能描述】

知识维护是通过录入、采集、提取等方法获取资料，并对资料的各种属性进行编辑的各种功能的集合。

知识编辑包括资料及资料属性的新增、修改和删除等。

1、提供知识信息的新增、删除、修改等功能；

2、提供对各知识信息改动的日志信息，并能实时查询；

3、提供对问题解答汇编集的建立、划分层次结构、录入资料的功能；

4、提供对问题解答的有效日期设置功能；

5、提供通过层次结构建立目录的功能；

6、提供各种标准格式信息的采集，如HTML页面、文本信息、图片等；

7、提供人工录入，通过统一的录入界面录入到容库；

8、提供人工导入各种文件到容库，包括TXT、DOC、PDF、JPEG、GIF等；

9、提供自定义采集主题，通过定义关键词，能对容中与主题相关的部分进行采集；

10、提供对信息容和图片分类保存，支持自定义的信息分类；

11、提供选择模板进行知识维护及预览功能；

3.1.2.知识审核

【功能描述】

在发布特定的文件版本前，用户可以制作多份草稿，而使用者只能在信息门户上查找或是检阅已发布的文件。

1、提供过滤功能，审核人员可对审核的容进行过滤，以迅速定位到要审核的信息；

2、提供最终效果的预览功能；

3、提供批注功能。

审核人员在审批时可以对页面做批注，为编辑人员提供修改意见；

4、提供回退功能。

未通过审核的容返回给资料提供者重新编辑；

5、支持签发功能；

6、支持不同的审批机制（单级审批、多级审批）。

审核后的容才能进行发布操作。

3.1.3.知识发布

【功能描述】

知识发布管理是对通过审核的知识信息在各个渠道进行信息更新。

1、提供容的实时、定时发布；

2、提供容的单发、群发；

3、支持容的全量发布、增量发布；

4、提供发布模块的多线程处理能力；

5、支持发布时自动进行文件的打包、压缩，以提高网络传输效率。

3.1.4.模板维护

【功能描述】

模版是决定容展示的页面模型。

模版管理主要负责对模版的创建、模版的编辑、模版的解析三部分容进行管理。

1、提供各种类型模板的创建，包括框架模版、栏目模版、新闻页模版、数据模版；

2、提供对模版进行可视化编辑；

3、支持对一个网页文件进行解析，直接保存为模板文件到容库；

4、支持模版与模版的嵌套；

5、模版管理需要支持多种类型模版，以支撑门户的栏目和专区的设置。

3.1.5.知识检索

【功能描述】

知识检索是一种信息检索方式，通过知识检索可迅速定位所需知识，以有效的提高工作效率。

1、支持按检索容并可选择目录围进行全文检索，根据匹配程度对检索结果进行排序；

2、支持按时间、关键字等条件单项或组合设置查询围后进行检索；

3、支持在搜索结果中进行再次查询；

4、支持按标题或容分类查询。

3.1.6.公告管理

【功能描述】

公告管理指对维护好的公告容进行监控，实现在指定围、群体、渠道中进行公告发布。

1、提供公告的增、删、改并进行相应日志记录；

2、提供公告的实时、定时发布；

3、提供公告的单发、群发。

3.2.新增数据节点说明

现有的知识库的功能基本能够满足电子运维知识库的需求，对于电子运维特有的知识可采取新增数据据点并分配权限来进行分类管理。

3.2.1.项目管理知识库

项目管理知识库是移动公司工程人员分享项目管理的经验的知识库。

工程师可以在知识库中找寻过往类似项目成功及失败的经验，对立项有重要的参考价值，提高项目投票的成功机会。

除此之外，知识库存放着各种立项文件的本，移动员工可参照文本编写，减少文书处理所需的时间。

【数据围】

移动公司相关系统的技术、故障处理方法、经验等。

【目标用户】

技术人员、设计人员、故障处理人员

3.2.2.专家服务知识库

提供顾问服务所需要之文件本，有不同项目的要点资料，有系统地制成目录，方便搜寻，减少花费在翻查资料的时间。

围：

专家服务知识库，主要是对移动公司人员的专业技能、以及有专业特长的人员进行专家档案信息的管理和维护，在移动公司人员需要进行有关专家帮助时，系统能提供有关专家人员的信息。

目标：

专家的产生主要有以下两种途径和方式：

移动公司级别专家：

由移动公司和部门根据员工的个人岗位、职务、业务或技术特长等特点进行综合判断和评定；

知识系统专家：

主要是根据用户在移动知识库系统方面的经验分、以及价值分进行综合判断，符合条件的人员，通过一定的评估审核后确定；

经评定的专家的个人信息，以及其专业特长，可通过用户信息维护的方式，由各级管理人员进行维护设置。

对于移动公司人员自身的专业技能，则可通过设置自己个人的信息来描述自己的专业技能和特长。

【数据围】

移动公司相关系统的技术、故障处理方法、经验等。

【目标用户】

技术人员、设计人员、故障处理人员

3.2.3.技术资料知识库

项目管理知识库是移动公司工程人员分享项目管理的经验的知识库。

工程师可以在知识库中找寻过往类似项目成功及失败的经验，对立项有重要的参考价值，提高项目投票的成功机会。

除此之外，知识库存放着各种立项文件的本，同事们可参照文本编写，减少文书处理所需的时间。

【数据围】

移动公司各部门、各中心、各项目的相关技术文档资料。

【目标用户】

移动公司所有人员按权限使用

3.2.4.故障案例知识库

鉴于运维工作面对的是多区域、多层次的网络综合维护管理，维护管理知识库的建设，将维护人员的先进经验“沉淀”在本系统中，将操作维护人员的维护经验集中，并得到共享，使得在故障处理时少走弯路；同时，还可以提供简便、有效的查询手段，使维护人员可以快速检索到所需的维护处理建议，以供参考，从而提高故障处理速度、有效降低平均故障历时。

故障案例库是将网络运维工作中的“经典”故障案例抽取出来，“沉淀”在知识库中，提供给运维人员学习和借鉴，以提高人员故障处理技能、缩短故障处理时间。

【数据围】

移动公司相关系统的技术、故障处理方法、经验等。

【目标用户】

技术人员、设计人员、故障处理人员

3.2.5.技术经验知识库

技术经验库的容包括：

故障处理经验、投诉处理经验、厂家提供的经验、市公司的维护经验、网络优化类经验、集团公司及其他省公司维护经验等等。

技术经验库的入库要求：

故障类及投诉类经验由故障工单最终回复人员负责入库；集团公司及其他省公司维护经验、厂家提供的经验、市公司的维护经验、网络优化类的经验由经验库管理人员审核后入库。

技术经验库的维护：

定期对经验库容进行整理和修订，对具有共性的维护经验组织推广。

【数据围】

移动公司相关系统的技术、故障处理方法、经验等。

【目标用户】

技术人员、设计人员、故障处理人员

3.3.搜索引擎改造说明

知识表现方法可以使用户方便地找到所需要的知识。

系统提供了分类查询、聚类查询、多种元数据查询和全文检索多种方式，全面反映了知识的各种特性，使用户可以通过不同侧面发现知识。

支持全系统所有工单、资料、案例以及它们所带附件的全文检索，可以支持普通和高级查询，支持组合查询，方便用户在大量的信息中快速查找信息。

搜索服务是实现知识共享的重要方式之一，增强后的功能如下：

1、支持对网页、知识文档、附件的搜索，文件格式包括但不限于：

文本、Rft、Word、Excel、PPT、PDF等

2、搜索围限制在使用者有权限阅读的围进行；对于无权阅读的信息和文档，应该不显示这些搜索结果；

3、支持关键字的搜索；

a.支持单个及多个关键字的搜索，关键字之间使用空格字符分发；同时关键字的先后位置能具有一定的含义；

b.多关键字之间通过一定的表示方式，支持并行搜索，即多个关键字只要出现一个即可；

c.对于英文，不区分大小写；

d.允许排除含有某些词语/关键字的搜索，有利于缩小查询围；

e.支持联想式的关键字输入：

即关键字包含文字中只要输入第一个字符，系统根据“关键字库”马上可提示符合此词组合的相关联的词组供选择，如：

Ø如输入I：

就会马上出现一连串以“I”为开头的固化关键字如：

IP、IP充值卡、IP直通车、IP收费、ICP、ICP端口号等；

Ø如输入每二个字符IP：

就会出现IP充值卡、IP直通车、IP收费等；

Ø如输入第三个字符IP充：

就会出现IP充值卡等，只要输入越多字符可供选择的围就会越小。

其中，关键字库的容维护，可由各级管理员维护。

4、允许指定搜索围

a.允许指定搜索围定义为标题或全文搜索，及是否包含对附件的搜索；

b.允许指定在已定义的知识类别中搜索，如：

在指定的所属业务、业务类别中搜索；系统应提供简单快捷的方式用于指定所属业务及业务类别；其中所属业务、业务类别相当于知识分类的一级和二级目录，由各级管理员进行统一维护；

c.允许根据文献的著者、文档更新时间围等限定其搜索围；

5、支持对图像/声音等资料的检索，该类搜索通过预先设置的关键词来进行；

6、支持搜索关键字提示：

即输入一个简单关键字进行搜索时，搜索引擎会为用户提供"其它用户搜索过的相关搜索词"作参考。

点击任何一个相关搜索词，都能得到那个相关搜索词的搜索结果。

7、支持在搜索结果中继续搜索的功能。

8、记忆搜索功能，自动显示最近打开的十个文档。

9、支持搜索智能化：

在缺省情况下，搜索引擎根据使用者的部门、岗位情况等信息，自动缩小搜索围。

3.4.新增接口

3.4.1.总部EOMS故障工单转入接口

通过该接口把总部EOMS故障工单相关容转入到知识库系统中。

3.4.2.省EOMS系统故障案例库导入接口

通过该接口把省EOMS系统故障案例库的资料导入到知识库系统中。

3.4.3.知识库查询接口

通过该接口为电子运维系统提供知识库查询的功能。

3.4.4.专业类型自动检索接口

知识库允许以故障工单的纪录作为知识基础，形成相关的知识库，经管理人员提交至知识库。

通过该接口，电子运维系统中的每工单的下方可以连接到“知识库”，并可以根据工单的专业类型自动检索知识库中的对应知识信息。

4.系统软硬件平台方案

现有电子运维用户达到了2200，都有访问知识库系统的需求。

目前的客服知识库所在的服务器承担了知识库、投诉工单、考试系统等多种客服应用，系统的设计容量基本上只能满足客服的需求，因此在总体设计上要按照满足现有知识库用户访问及电子运维用户访问进行估算。

由于知识库系统是部使用系统，系统开销由并发数控制，增加的访问并发数按电子运维30%的用户量计算。

4.1.系统现状

4.1.1.服务器部署及网络拓扑

4.1.2.设备部署

知识库所在的2台8420是按如下原则进行分区：

分区1，给集中客服做数据库服务器（6颗CPU、48G存）

分区2，给知识库、电子工单、考试系统做中间件和数据库服务器（3颗CPU、24G存）

数据库采用Oracle9i双机RAC方式，并分成两个物理分区，分别用作集中客服平台和应用的数据库服务器。

阵列，10220GB（48*146G），做RAID0+1后，可用空间5000G，和门户数据库服务器共享该阵列空间：

给数据库服务器3500G（目前数据库服务器有2400G）、知识库和电子工单1500G（目前8*73G裸盘，可用空间300G到400G左右）

知识库、电子工单、考试系统的中间件服务器及其数据库服务器都部署在8420的分区2，其中RAC数据库本身占用了4G存。

8420分区2的tpmC值为：

20万左右。

4.1.3.应用现状

一台8420的分区2作为应用服务器，该服务器上部署的应用程序有知识库的应用程序，电子工单流系统应用程序，考试系统应用程序，以及中间件Weblogic。

另一台8420的分区2作为数据库服务器，该服务器上部署的有知识库的数据库应用程序，电子工单流系统数据库应用程序，考试系统数据库应用程序以及Oracle数据库。

服务器的现状：

分区2部署

IP地址

现有配置

资源利用率

时间段：

09-10

资源利用率

时间段：

19-20

知识库应用及中间件服务器

10.154.81.38

3颗CPU

24G存

CPU占用率60%

存可用率30%

CPU占用率70%

存可用率25%

知识库数据库服务器

10.154.81.39

3颗CPU

24G存

CPU占用率60%

存可用率9.6%

CPU占用率60%

存可用率8.3%

注：

上表资源利用率的参数采样值是在上午9－10点和下午19－20点的值，是服务器的负荷相对较大时的参数值。

4.1.4.存在的问题

客服知识库系统随着业务的发展，用户量的不断增长，已经不能有效满足用户的访问要求。

4.2.需求分析

4.2.1.电子运维知识库应用服务器

―每次业务对应用服务器的处理能力需求等价于3个标准事务

－每次受理业务在2秒钟响应（查询类）

－并发数为2200×30%=660

－考虑30%的冗余

则TPCC＝并发数×事务数（3）×60/并发时间长度×冗余率

=660×3×60/2×1.3==77220tpmC

4.2.2.电子运维知识库数据库服务器

―每次业务对数据库服务器的处理能力需求等价于2个标准事务

－每次受理业务在2秒钟响应（查询类）

－并发数为2200×30%=660

－考虑30%的冗余

则TPCC＝并发数×事务数

（2）×60/并发时间长度×冗余率

=660×2×60/2×1.3=51480tpmC

4.2.3.电子运维知识库存储

―预计容量大约在200G左右

4.3.建议方案

通过上面的分析可以看出，由于目前8420的分区2上存为24G，而数据库又占用了4G，tpmC值为20万左右，刚刚满足现有知识库、电子工单、考试系统等性能的要求，而加入了电子运维知识库后，电子运维知识库需要的tpmC值为77220+51480=128700，必须通过扩容或购置新的服务器才能满足要求。

4.3.1.方案1

在电子渠道整合项目中，已经对部署有客服知识库的这两台8420提出了扩容需求，每台8420增加一块Cell板，板载16G存。

由于知识库应用，大量的请数据库查询操作，而非计算类型操作。

数据库查询操作是非常占用存的操作，因此在考虑在tpmC满足要求的情况下，采用大存应用的配置方式。

依照HP公司对该机型的最优配置建议（CPU颗数与存容量的比例是1：

8，1颗CPU配8G存最能发挥这种大存应用的性能），在每台8420所扩容的Cell板上增加2颗CPU，达到性能均衡的要求。

本次扩容后的单台8420分区2的配置如下：

机器

Cell板

现有配置

扩容后配置

可扩容余量

8420

分区2

3

3颗CPU

24G存

3颗CPU

24G存

1颗CPU

8G存

4

空

2颗CPU

16G存

2颗CPU

16G存

扩容后tpmC值超过27万，可以满足性能需求。

4.3.2.方案2

新购两台主机（或分区），两台主机（或分区）构成双机群集系统。

单台TPCC性能要求：

tpmC值大于128700。

建议配置单台tpmC值为15万。

依照集团公司独立部署的规划，将电子运维知识库的相关应用部署到新的服务器上，既可以满足应用性能的要求，又不与客服知识库产生冲突，提高系统的稳定性。