综合网管3期方案建议书

1、附件 1-方案建议书文档属性属性内容客户名称联通项目名称联通 2008 年 GSM 网增值业务综合系统文档 附件 1-方案建议书文档副标题文档版本1.1文档日期文档状态提交稿作者文档变更版本修订日期修订人描述V1.02008-9-22神州 V1.12008-12-30神州 文档送呈目的联通本文档仅限神州和被呈送方，扩散到第。第 352 页 共 342 页目 录1 项目概述62 总体方案设计102.1 增值业务综合系统的定位102.2 增值业务综合建设的关键点分析152.2.1 架构搭建162.2.2功能 . 242.2.3 数据消费292.2.4 系统推广342.3 总体设计思路说明352.3

2、.1技术路线及第的选型思路说明352.3.2硬件选型及网络搭建思路362.3.3架构设计思路383 软硬件部署方案443.1 硬件处理能力配算443.2 局域网/广域网设计方案443.2.1 广域网组网方案443.2.2 各省局域网组网连接方案463.2.3 总部局域网组网方案483.2.4 系统安全考虑493.3 硬件部署方案503.3.1 总部硬件部署方案503.3.2 省分硬件部署方案(SUN/ )错误!未定义书签。3.3.3 省分硬件部署方案(HP)523.4 模块及功能说明533.4.1 总部 模块及功能说明533.4.2 省分 模块功能说明573.5 软硬件部署说明603.5.1

3、总部软硬件部署说明603.5.2 省分软硬件部署说明（SUN/）613.5.3 省分软硬件部署说明（HP）634 功能实现方案654.1 综合 平台654.1.1架构说明654.1.2管理平台674.1.3. 1144.1.4主机数据库. 1344.1.5业务应用 . 1464.1.6横向接口1594.2 综合维护平台1634.2.1架构说明1634.2.2 全网运维子系统1654.2.3 总部 日常维护子系统2364.2.4 通用日常维护子系统2474.2.5 横向接口2854.3 综合分析平台2854.3.1架构设计2864.3.2 分析 设计2984.3.3 周边接口3084.4 省部接

4、口设计方案3084.4.1 实时消息接口3084.4.2 消息/文件接口3094.5 自管理方案3124.5.1 用户管理/权限管理3124.5.2 SSO 实现方案3134.5.3自. 3144.6 防 体系建设3164.6.1选型3164.6.2功能说明3184.6.3部署方案3225 系统平滑过渡方案设计3255.1 数据迁移的要点和需求3255.2 需要重点保障的迁移数据分析3255.3 系统数据迁移步骤3276 图表目录3311 项目概述近年来， 联通增值业务经历了从无到有、从弱到强、阶梯式、 式的发展历程，增值业务种类齐全，已经从附属业务、增值业务发展成为市场规模巨大的基本业务，

5、2007 全年增值业务总收入已经超过 100 亿。与传统的语音业务相比，增值业务具 有巨大的发展前景，在电信重组的格局下，是联通拓展市场份额，发展有效用户。增加 有效收入的关键 之一，随着 3G 的即将来临，增值业务必将得到更大的发展机 遇，在联通总体收入中所占比重会越来越大。在这样的形势下，利用有限的资源，面对增值业务的复杂多样性和不断扩充的业务需求， 如何提高维护工作效率，保障增值业务系统的正常运行，从而确保并逐步提升联通的服务质量，是摆在联通增值业务部面前的紧迫问题。联通增值业务部从 2005 年开始筹划面向整个增值专业的综合系统，我方非常荣幸的获得承建全国 31 各省和总部的增值业务综

6、合项目的机会，从 2006 年 4 月到 2007 年，12 月，神州公司投入了近 150 人的实施和研发团队，与联通总部及各省项目配合紧密协作，克服了很多的 的完成了增值业务综合 项目的建设，该项目分为两个阶段建设，第一个阶段从 2006 年 4 月到 2006 年 9 月，主要完成了总部、山东、江苏、 、上海、浙江 7 个节点的试点工程建设，2006 年 10 月到 2007 年 3 月，完成了其它 25 个省公司的综合系统建设，2007 年 4 月到 5 月，我们用了将近两 的时间完成全国所有业务系统的数据质量核查，系统于 2007 年 6 月正式投产使用，2007 年 12 月完成整个

7、系统的终验工作，从 2007 年 6 月到 2008 年 6 月，我方一直保持着 50 人的现场运维团队，保障综合系统的 运行和数据质量，从系统正式上线投产以来，综合系统已经逐步成为联通增值业务不可或缺的运行支撑系统，其提供的资源资产、容量、性能、告警数据已经成为增值业务专业的日常维护、容量规划、系统建设、管理考核、经营分析最重要的依据，目前增值业务部每 的生产经营分析会材料中的数据均通过综合系统提供， 所有现 的扩容可研报告均以综合系统的容量规划专题提供的数据为依据，提高了项目建设投入的有效性和 性，节约了大量的建设投资。对各省分的运维考核数据也通过综合 系统自动生成并上传总部，极大地促进了

8、各省公司下大力气提高网络质量，据全统计，仅接通率一项指标，2008 年 6 月比 07 年 环比提高了近 8 个百分点，从而大幅度的提高的增值业务的有效收入。通过综合 系统从开源和节流两个方面带来的投资回报价值是显而易见的。与此同时，增值业务综合在今年年初的雪灾和 5 月份以来的抗震救灾等 活动或中都发挥了巨大的作用。神州 公司在增值业务综合 项目实施和上线后的维护工作中投入了巨大的人力物力资源，尤其是在 Agent 部署、业务系统接口联调和数据质量保障三项最艰巨的任务方面， 项目组投入了很多的劳动、心血和精力，同时也取得了总部和各省分公司的高度评价和认可， 积累了大量的宝贵经验， 、有能力为

9、联通提供持续、高效的服务。神州 公司于 2007 年中标移动 14 个省的数据二期工程，承建 、吉林、重庆、湖南、河南、海南、甘肃、福建、陕西、云南、的数据系统建设工作，从而成为在增值业务/数据 域国内市场份额最大，实施经验最丰富、化程度最高、综合实力最强的公司。作为电信重组的一部分，增值业务综合系统即将移交给电信，因此，联通新一代的增值业务综合系统建设工作正式提上日程，通过认真分析技术规范书，我方认为本项目 以下几个难点：² 工程实施周期短，技术规范书中要求本项目的建设周期分为两个阶段，其中第一个阶段的实施周期为 4 ，完成对近 5000 台服务器、1000 多台网络，数百个数据库

10、、500 多个业务系统、32 个节点这样规模巨大的项目实施工作，这对于任何一个厂家来说，都是对其项目管理与组织能力、实施队伍的规模和能力的巨大² 项目建设内容多，本期项目中将完成综合 平台、综合维护平台、综合分析平台三大平台及防 系统的建设，而且综合与各业务系统间、各平台间、平台内部 间、省公司与总部之间均着错综复杂的接口 ，大致数了一下， 本项目涉及到 320 多个子系统、数百个接口、数百种报表的开发、集成、实施、联调工作，这对任何一个厂家来说都是对其研发能力和系统集成能力的考验，而在如此之短的工期要求之内，如果没有对 域的深刻理解与积累、对增值业务的充分了解、对现网环境的足够熟悉

11、，没有成熟的和类似项目的实施经验，几乎可以断定，不可能承担项目的建设工作。² 数据迁移工作量大， 项目的建设目的无外乎提供实用有效的运维工具和及时准确、完整的数据和，而增值业务综合一阶段上线已经超过两年，全国正式上线也已经一年多了，目前系统中的数据，涵盖了 C/G 两网的有效用户，每种业务的业务量、用户数、用户使用频率和业务渗透率， 了每个业务系统的数据，提供了 每个 SP 的业务发展情况，提供了哪些种增值业务的业务量较好， 提供了每个业务系统负荷情系统容量，这些数据对于联通来说是非常重要和宝贵的，不夸张的说，这些数据的价值已经远远超过了系统建设的投资，因此，新建的系统必须实现对现

12、的数据迁移工作，而如何实现旧系统移交电信的同时完成新系统的数据迁移工作，相当于一边开车飞驰，一边换轮胎，难度很大² 用户使用感受与培训成本问题，在二期项目实施过程中，花了大量的精力用户使用感受，提高界面的人性化，丰富数据展现方式，目前各省和总部的用户已经习惯了增值业务综合系统的数据组织 界面风格，新建系统如何在增加新功能，提高系统性能的同时，保证用户使用习惯的一致性，从而尽量减少培训成本和用户的抱怨，同样是必须面对和解决的问题神州 公司在 2001 年就完成了全球网的项目，2002 年完成了海洋石油公司全管项目，2003-04 年完成联通全国WAP 项目，06 年完成移动5 省BOS

13、S项目，06-07 年完成局全国 44 个节点的项目， 06-07 年完成联通全国增值业务项目，07 年完成寿全国 36 个节点的项目，07-08 年完成移动 14 个省的数据项目，拥有业界最丰富的全国性项目项目实施管理经验和充沛的储备，完全有能力实现增值业务并发 32 个节点的实施工作。神州 公司在业务方向上分 网络管理、服务流程管理、数据应用管理和安全管理四大部分，每个业务方向上均有成熟的 和解决方案，在方面具有充分的准备， 在本项目中推荐使用的各 和功能模块均有 案例，同时，神州 从 2003 年起就参与联通增值业务部的项目，先后的实施了一期、WAP 3 期、WAP 网管 4 期、增值业

14、务、EMP 等多个项目，对于总部和各省的增值业务系统的组网情业务情况非常熟悉，对于各省公司和总部的日常运维工作开展方式、工作流程、考核指标算法、运维规程和维护作业计划等管理方面的规章制度同样很了解，同时，我方通过 06-08年的增值业务综合项目的实施和维护工作，已经完成了与现网各业务系统的接口联调工作，接口的性和数据质量够充分的保障，从而能够按时、保质的完成增值综合业务系统的集成、应用开发、部署等纷繁复杂的工作。由于 31 个省公司和总部的增值业务综合系统均由神州公司承建，因此，对我们来说数据迁移和用户使用感受这两个问题也就不是问题了，能够充分的统和数据的延续性。通过以上分析，我方认为，神州公

15、司是唯一一家有能力承担联通新一代增值业务综合系统的厂家，我们也非常愿意投入最 资源为联通增值业务综合系统的建设贡献我们的经验、智慧和力量。下面，我方将对增值业务综合系统的总体方案设计进行详细的说明，并从软硬件部署、功能实现、数据迁移几个方面进行具体的说明。2 总体方案设计2.1 增值业务综合 系统的定位在考虑增值业务综合系统的整体建设思路时，首先必须考虑并且回答两个问题：u 如何理解并明确什么是综合系统u 如何理解并明确增值业务的特点以及增值业务的特点r 如何理解并明确什么是综合 ，我们认为，综合，就是要考虑清楚这套系统与其他运营商或联通其他部门建设的所谓的专业之间的差异。而这个差异从定位上来

16、说，就是需要明确 联通增值业务综合 就是增值专业的综合性的运行支持系统。以移动为例，其系统建设分拆为话务 、传输、数据、信令监测、动换 五个专业系统，再通过运维系统实现工单流转，由以上六大系统基本的运行支撑系统框架。其中，与联通增值业务综合对应的系统是数据系统，但是移动的数据实际上就是一套数据业务的 系统，不包含运维、不包含业务拨测、不包含局数据管理、不包含统计分析、不包含中心以及语音增值类业务应用的 管理，应该说移动数据系统的内涵和外延与联通增值业务综合系统之间着巨大的差异。那么，什么 增值专业的综合性的运行支撑系统呢？我们认为只有该系统的内涵和外延能够覆盖增值专业日常运行、维护、生产、管理

17、的各个层面，才能够称得上是综合性的运行支撑系统，因此，我方认为增值业务综合系统的最终架构应该由以下 7 大体系：u 综合 体系：用于实现对 IT 基础架构和业务应用的全方位管理，消除死角，及时发现系统异常情况， 统的可见性和可用性u 综合维护体系：为一线维护提供全面的维护 和工具，打通与被元之间的透明通道，提供各种与维护工作相关的翔实准确的数据和 ，一方面减轻维护的工作量，另一方面提升系统的运行质量和整体维护水平，实现运维工作的标准化和规范化u 安全管控/防护体系：对系统的安全运行提供各种管理和，对所有的系统操作进行有效的 和审计，检测并安全风险，提供各种安全防护和策略，封堵各种可能的安全漏洞

18、或安全隐患，、安全运行提供保障 。u 管理考核体系：为省公司和总部提供各种数据分析的 ，提供各种实用有效的主题分析和专题分析，使总部制定的各种管理办法和规章制度真正可以执行和落实， 可以做到真正意义上的量化考核，通过各种横向/纵向比对，鼓励先进，督促后进， 进一步提升全国运维生产工作的标准化。u 指挥调度体系：联通增值业务的特点之一是垂直管理力度大，如何保证总部的各项工作安排能够落到实处，保证总部与省分公司之间上传下达的通道的顺畅，提升整体执行力，提升总部从全网的角度发现问题、分析问题、指挥调度、质量检查、主动管理的能力，就需要有完善的指挥调度体系的支撑u 支撑体系：如何通过运维支撑体系实现“

19、发展有效用户，增加有效收入”的目标，其中很重要的一点就是提高增值专业对 的处理能力，而这一方面需要建立健全增值专业的 的跟踪处理能力，另一方面需要建设有效的，帮助 部门提升投诉拦截率和解决问题的能力，从而大幅度提升用户的满意度u 合作伙伴考核体系：大部分增值业务实际上是类的系统，即联通提供高效的业务 ，由合作伙伴（CP/SP）基于业务 开展丰富的业务应用，而如何引加强对合作伙伴的管理力度，尽量减少或及早发现 CP/SP 的行为，是保证增值业务能够健康、持续发展的基础我们认为，由这“七种”的综合系统，才能够担负起为增值专业提供综合运行支撑系统的任务，当然，运行支撑系统的建设也不是一蹴而就的，其建

20、设规模、建设效果、推广情况与投资额度、整体规划、员工素质、组织机构、工作流程、管理考核机制、领导重视程度都是关的，因此，我方认过本期项目建设，搭建综合、综合维护和综合分析三大平台，同时建设全网防体系，是符合联通目前的发展现状和生产中的急迫需要的。与此同时，也有必要通盘考虑、科学规划整体运行支撑体系的建设并逐步完善。r 如何理解并明确联通增值业务的特点以及增值业务 的特点我方从 2003 年开始就参与增值专业的系统建设，通过一期工程、WAP 三期、四期工程中的及安全系统以及增值业务综合二期工程的建设，我联通增值专业非常熟悉，再加上我方承建了移动数据二期工程中 14 个省的项目建设工作， 使我 增

21、值业务以及增值业务 的特点有了深刻的认识和体会。我方认为联通增值业务的特点主要有：u 增值业务种类多，新技术、新业务、新应用层出不穷，代表着电信运营商最重要的业务发展方向u 增值业务涉及的协议、标准、规范多，与传统的语音业务相比，增值业务要复杂得多，传统的语音业务涉及到的业务流程无外乎建立连接、鉴权、漫游、切换、寻呼、拆除连接等固定的流程，涉及的网元无外乎 MSC、HLR、BSC、BTS、Cell、STP 等，其业务流程、业务模型固定且标准，同时由于 GSM 和 CDMA 等技术已经非常成熟，互联互通体系 语音业务相比，每种增值业务的协议、标准、业务流程和业务模型，而且各种增值业务的业务模型和

22、业务流程之间的差异非常大u 增值业务系统的 性不足，由于大部分增值业务是基于 IT 技术实现，其实从基础技术的角度说，就达不到电信级的高可用性，同时，由于增值业务系统的业务处理环节多，各增值业务间接口繁多，以炫为例，其与 GSM 网、信令网、MMS、WAP、IVR 等系统均接口，且涉及到运营商 无法的 SP 的，因此，增值业务的 性 先天不足，与传统的语音业务相比，更容易出问题u 增值业务的维护力量和维护经验不足，由于联通增值业务在运维方面的人手不够， 而且由于新建项目多，涉及到的厂家多，很多系统的维护工作由厂家承担，且运维经验没有得到充分的梳理、总结和沉淀，也缺乏必要的来固化这些运维经验，

23、这些问题造成了联通增值专业的总体维护水平不高u 增值专业在业务开展方面与合作伙伴之间 密切，传统的语音业务实际上只涉及到运营商自身以及与其他运营商之间的互联互通，而增值业务不仅涉及到联通内部各专业和其他运营商，同时还涉及到数量众多，良莠不齐的 SP，这就造成业务质量保障和用户投诉处理的，与此同时，信产部关于增值业务的监督管理机制也比语音业务复杂，这也造成了增值专业必须着重考虑如何加强对合作伙伴的管理由于增值专业在业务种类、业务流程、业务流程度、维护力量、与合作伙伴等几个方面都着上述特点，这就决定了增值业务 系统的特点：u 增值业务 系统的承建厂商必须深入了解业务特点和业务具体流程，增值 系统必

24、须具备强大的业务建模、业务流程建模能力：增值业务 必须具备准确刻画各种增值业务的能力，全面梳理每种增值业务的关键业务点和 KPI 指标，并且清晰的表现各业务关键点之间的关联 ，才能够准确的发现系统的异常以及这些故障对整体业务的影响程度，以中心为例，如果不把 中心与防系统之间的接口纳入 体系，当该接口出现问题时，不仅会影响 中心的 MO、MT 接通率指标，同时还会造成互通网关接通率的下降，如果不把 中心与 PDSCP 间的接口纳入 体系，就有可能无法定位预付费用户的投诉，如果不把中心与 BSS 系统间的接口纳入体系，就有可能造成收入方面的损失。同时，由于增值业务的复杂多变，必须提供灵活的模型调整

25、和 能力。u 增值业务 系统必须有全面的接口支持能力和健壮的数据质量保障机制： 数据来源复杂且不规范，为了保证综合系统数据的全面性，就需要通过对多种协议的支持从多个数据源获取数据，如为了获取网络 的数据，需要支持 SNMP、Syslog、Trap 等协议，为了获取服务器、数据库的数据，需要部署 Agent 并进行数据级的集成，为了获取业务系统提供的 KPI 指标，需要支持 Corba、DB、FTP、 、CLI、MML 等多种接口方式，为了对业务量、有效用户等数据进行统计，就需要 并 每个业务系统各种各样的话单文件，并进行复杂的剔重处理，为了获取网络质量并提供运营商网络质量对比数据，就需要支持

26、SMS、MMS、WAP、IVR、Java、流媒体、定位等多种对各种业务及 SP 提供的各种应用进行业务拨测，这一方面造成了的复杂和，同时由于业务系统的频繁升级（影响与系统间接口或话单格式改变），造成数据完整性和数据质量很难保证。u 增值业务 系统需要充分考虑数据之间关联 ：在进行数据分析的 设计和算法设计要充分考虑数据模型的复杂程度，以 MMS 业务量分析为例，一方面需要搞清楚 MO/MT，AO/AT、/FO/FT、/EO/ET 八个方向，28 种组合，另一方面需要考虑每种业务应用（如像册、 报等）都需要单独作为统计维度，而为了支持分地市的业务量分析，就需要将局数据管理中的 MMSC 中的号段

27、局数据作为分析维度纳入统计算法，同时还需要考虑品牌维度（世界风、新、如意通），从上例可知，为了有效的提供各种分析专题，需要通盘考虑数据来源和数据模型的组合u 需要仔细设计系统部署方案：由于增值业务种类繁多，且由于大部分省分公司并没 的网络规划，每建设一个新的增值业务系统，就新建一个局域网，造成了目前的“片状互连”的现状，因此，在设计综合系统部署方案时，必须充分考虑的分布式部署能力，同要综合考虑各业务系统之间的 ，在统安全策略的前提下，简化网络接入方案，例如，文本类的业务系统（中心、在信网关、互通网关、EMP 和SPMS）基本上是可以部署一台机进行数据的，但是语音增值类的业务系统，如炫铃和 IV

28、R 之间网络是完全的，就只能通过分别部署 机的方式 数据u 充分考虑运维经验和运维知识的积累与固化能力：由于目前联通增值专业的运维力 量、运维经验不足，因此，在设计实现增值业务综合时，不仅需要考虑提供多少个功能点、多少张报表、多少种数据，还必须提供运维经验和运维支持的固化能力，通过灵活的技术 ，将这些经验和知识不断地总结出来，再固化在综合系统中，以切实有效的提升联通 维护 的业务水平和解决问题的能力u 重点考虑并提高对 SP 的管理和考核能力：在增值业务中，除了点对点和 MMS 之外，大部分业务的开展都是与 SP 相关的，因此，需要从多个维度分析 SP 的业务发展情况，一方面扶植、帮助 SP

29、快速发展有效业务，另一方面及时发现并坚决纠正 SP 的行为，以保证增值业务的健康、持续发展u 保证总部与省分公司之间上传下达通道的顺畅：在省部接口设计和工单流程设计时，要充分考虑联通增值专业垂直管理的特点，在设计省部接口方案时要保证省部接口数据上传的实时性和准确性，特别是 告警和考核指标；在工单流程设计时要重点考虑总部各处室之间工单流转的特点，和总部/省分公司之间工单流转的不同特点，例如，对于总部下发省分公司的工单，需要考虑多级审批的情况，即有可能需要总部相关处室领导、总部增值业务部领导、省分公司主管领导等多个审批环节， 同要必须实现工单字段级的 和处理环节的 等功能的实现，例如，总部业务运行

30、室受理了某省分公司创建的一个投诉工单，其工单的内部处理环节要求省分公司不可见，而业务运行室内部相关 是可以全程跟踪该工单的处理情况的。总部下发的通用工单 都是同时发给多个省分公司的，这就要求系统能够支持多个子工单的生成以及对每个子工单的状态分别和变更功能，同应提供对工单流转全生命周期的跟踪功能，以保证总部对工单处理情况的全面了解r 小结通过上述分析可知，联通增值业务综合 系统的定位是增值专业的综合运行支撑系统，同时，由于增值业务的自身特点，在设计和实现增值业务系统时必须充分考虑增值专业在业务模型、业务关联程度、运维现状等方面的特点，在系统部署、资源建模/数据建模、SP 考核、省部接口等方面重点

31、考虑。同要指出的是，由于本项目中必须充分考虑现中的数据迁移问题，因此， 数据迁移方案的设计也是需要重点关注的内容之一。2.2 增值业务综合 建设的关键点分析上文中我们分析并论述了增值业务综合系统的定位，下面，我们就本期项目建设的关键点进行深入的分析和探讨。根据我方多年来在建设领域中的经验总结，我方认为增值业务综合建设的关键点可以归纳为以下四个：u 架构搭建u 功能 u 数据消费u 系统推广下面，我们就分别对这个四个关键点进行详细的分析。2.2.1 架构搭建增值业务综合系统主要由综合平台、综合维护平台和综合分析平台三大平台， 十几种 ，数十个功能模块，因此，如何设计、搭建、高效且扩展能力强的系统

32、架构，是必须放在首要位置考虑并解决的问题。系统架构的重要性是众所周知的，从某种意义上，系统架构的生命周期就是整个系统的生命周期，可以把系统架构比喻为生产，而用户的需求和基于用户需求的各种功能实现都是生产力，如果系统架构不能够继续支持新的需求和新的功能或者现有功能改造的要求， 就类似于生产已经妨碍了生产力的发展，因此，选择正确的系统架构能够统自身的生命力以及这个系统的可持续发展能力，对于联通来说，需要考虑在系统架构上的投资回报问题，是选择一个价格便宜而生命周期短的架构？还是选一个架构合理、价格适中的系统架构呢？我们认为一个 、高效、扩展能力强的系统架构设计需要从以下几个方面入手：r 组合的选择：

33、需要充分考虑到各种 在整体架构中的位置和特点，并进行深入细致的研究，保证产品选型的科学合理，在本项目中，我方考虑到主机需要部署在生产服务器上，对软件的 性和安全性要求很高；而工作流引擎需要适应联通组织机构、部门职责、工作流程的不断变化；在总部的全网综合分析系统中，由于需要提供非常提供的数据组织和处理能力， 通常的统计报表系统不可能满足总部对数据处理和展现要求，需要部署专业的 OLAP 工具， 因此我方认为在这三个 方面，很有必要考虑选择国外主流的成熟 。而在其他方面， 我方 开发的 不论在功能、整体框架设计、人性化等方面经非常成熟，而且经经过了多个项目的验证，因此除了主机、工作流引擎以及 OL

34、AP 前端工具三个，其余均选择了我方 开发的相关 。我方在选择主机时，重点考察了五个关键点：u 主机对现网操作系统和数据库种类及版本的支持全面性，如果这点不能满足现网要求，则会出现 的空白点；u 考察其 的 性，由于主机需要部署在各业务系统每台生产服务器上， 其 性和安全性是必须考察的，在这方面，国际主流的显然具有国内自主开发的不可比拟的优势；u 考察其 的实现机制，有些 与操作系统底层结合的过于紧密，如上期项目中使用的 HP OVO ，不仅需要调整系统的参数，同时对操作系统的补丁有着严格的要求，这就造成了实施方面的很多；u 考察其 的数据和通讯机制，在上期项目中，由于 HP OVO 采用从

35、上层应用侧定时串行 Agent 缓被管服务器侧数据的机成了数据及时性和完整性难以得到保证的问题，同时，其 不支持分布式的部署方式，造成在不少省分公司只能将 系统的 机与所有被管服务器之间打通通信端口，而这种方式是一定的安全隐患的；u 考察其 的可扩展能力，由于 的需求是不断变化的，个性化的 需求是层出不穷的，因此，不可能有哪种 提供的默认指标能够满足本项目中的所有要求， 这就需要考察 是否具备可扩展能力，是否提供了灵活的二次开发 ，与此同时还需要不断在项目中梳理总结共性化的 需求，逐步积累和推广这些二次开发形成的新的经过充分的考察和比对分析，我方认为 BMC 公司的 Performance M

36、anager 在以上五个方面都是最优的选择。我方在选择工作流引擎 时，主要考察以下四个关键点u 是否符合 ITIL 规范要求，是否融合和内置了大量 ITIL 最佳经验；u 是否足够灵活，进行深入定制和二次开发，以适应本地化需求；u 定制和二次开发是否足够简单、方便，以适应服务流程不断变化的业务要求；u 系统本身的 性、可靠性、性能、安全性、接口灵活性等技术因素。我方认为 BMC 公司的 Remedy 是工作流引擎领域中最，主要的选型依据如下：u 业界第一家 ITIL 认证的服务管理u 市场占有份额最高的服务管理平台 ，现有超过 12,000 企业客户使用 Remedy 的 管理服务，其中超过

37、7,000 家是世界级跨国公司，Remedy 的终端用户已经超过了 10,000,000 人。 100 80%使用了 Remedy ，全球 500 也有超过60使用了Remedy 的解决方案。u 上期项目中已经采用了 Remedy 作为底层工作流引擎，现有的运维功能均基于Remedy 开发实现，能够达到快速部署、快速上线的要求u Remedy 提供了强大的表单设计器工具，通过该工具能够通过前台界面以拖拽的方式快速开发工单的前端样式，同时可以随时扩展数据库的表和字段，而不是通过“预留字段”的 现的。既保证了充分的灵活性和可扩展性，扩展时又无需停止服务或重启系统。u Remedy 的体系架构 成熟

38、，其体系架构为CSS 三层架构，同时可以支持Web、 和 PDA 等各种用户界面，可以支持双机容错、多机负载均衡等各种特性，可以充分 统的可用性、可靠性、可扩展性和性能；在安全性方面，它支持 SSL 链路加密、支持多种认证方式、支持显示界面、字段、操作等多级 ，具备完善的审计功能；在可靠性方面，支持多台服务器、Web 服务器自动负载均衡；在性能方面，在客户机、应用服务器 缓存机制，实践证明对硬件要求较低；在可扩展方面，支持多台服务器共同工作，提供丰富的 API 接口， 平滑扩容。由于以上几项明显的优势，我们选择继续使用 Remedy 作为运维系统的底层工作流引擎。在 OLAP 选型方面，我方主

39、要考虑到一期、WAP 统计分析和增值业务综合项目中均使用了 Cognos Powerplay 分析 ，考虑到使用习惯的延续性和原有开发成果的保留，在本期项目中选择了 Cognos 最新的 Powerplay 8.0 ，用于实现总部综合分析平台的 OLAP 前端工具。Cognos 8.0 是具有强大的专业化的虚拟 OLAP 数据引擎（OLAP 服务器），它能产生多维数据分析的立方体（Cubes） 数据立方体是一系列面向应用 的数据集市，能处理大数据量，它为用户快速实现大数据量的统计分析报表提供了中间数据文件， 数据库（Cubes）。基于 Upfront 的用户权限更加方便,基于时间分区的虚拟 C

40、ube 技术，支持增量更新，支持超大数据量。Cognos Powerplay Enterprise Server 支持多机负载均衡 统的处理能力的可扩展性，为大数据量、大用户数提供了坚实的承载基础。Cognos Transformation Server 具备强大的模型制作能力，如灵活的时间序列处理、全面的汇总类型定义、任意组合的计算类别定义等等，可以快速适配用户的业务逻辑和分析要求， 制作出结构良好、效率极高的分析模型，以满足用户对数据分析的各种需求。计算型指标、指标文件夹的功能可以在立方体的建模中令指标的 更加人性化用户可以通过鼠标任意拖拽组合 分析条件，或在图形、报表中进行切片、旋转、上

41、下钻取等操作，分析结果随时可以导出为 PDF、CSV 等多种格式的文件。Cognos 提供了饼图、线图、柱图、图等多种图形展现方式，并提供了各种计算、累计和 分析功能，同时还支持用户自定义的例外项显示，可以迅速定位异常的数据。附图1.Cognos Powerplayr 模块间横向和纵向接口设计由于本系统的和功能模块众多，如何保证在系统建成后，不是交付给用户一堆，而是一套有机结合，各和功能模块分工协作的运行支撑系统，这就要在方案设计阶段着重考虑各，各功能模块间的横向和纵向接口的问题。同时，除了在技术方面的考虑，还需要考虑本系统的建设模式，明确哪些事情是可为的，哪些是不可为的，并尽力把可为的事情做

42、到位，尽量做到最好。所谓纵向接口主要指本系统中的省部接口。联通增值业务综合系统首先是一个两级三层的架构，因此，总部与省分公司间的省部接口设计非常关键的。我方在上期工程中，由于总部及全国 31 个省的系统我公司承建，因此，在省部接口方面已经做得非常成熟，能够实现省分公司的告警和拓扑改变的实时上传；提供了省部接口数据防篡改机制，以保证各种考核数据在侧的真实准确；提供了实时的省部接口机制，在发现有数据积压或丢失的情况，可以采用相应的技术由总部系统自动发起直接在省公司系统中重采、补采数据，对于话单、处理流程，我们采用了通过在总部部署一套调度 ，调度全国相应服务器系统工作的方式。通过采用以上多种技术 ，

43、我们基本上保证了省部接口的通畅运转，保证了总部和省分公司之间的上传下达。但是由于本期项目，非常有可能采取多厂家共同承担本项目建设的方式，由于各厂家的应用 设计思路不一致，数据结构不一致、处理流程不一致、展现风格不一致、命名规则不一致等因素，省部接口的功能必然会有所下降，如全网拓扑功能基本不可能实现，数据防篡改机制也不可能继续生效，数据补采和重采只能采用手工方式进行，话单处理的统一调度更加不可能实现，因此，我方将在本方案中重新设计省部接口的实现方案，以保证基本的告警、性能统计数据通过省部接口的上 能的实现。所谓横向接口，是指总部或省分公司综合 系统内部各 和功能模块之间的接口以及综合 系统与周

44、之间的接口，这些接口包含了技术方面的接口设计和业 务方面的接口设计。我们大致梳理了一下，本项目中需要实现的横向接口主要有：u 管理平台与运维子系统之间的 六类故障工单接口，包含自动故障工单生成接口、手工派单接口，告警升级触发工单级别变更接口，告警自动恢复触发相应工单关闭的接口，工单受理动作触发告警状态变更为“已确认”状态接口，工单关闭触发当前告警清除并转为历史告警接口u 管理平台告警通知接口，本接口为 SGIP 协议接口，即联通总部及各省分公司分别为综合系统分配一个接入号，通过 SGIP 协议接入在信网关，实现告警通知功能u 管理平台备用告警通知接口，当在信网关不可用时，所有告警通知将无法正常

45、发送，因此，需要实现 管理平台与业务拨测之间的接口，即由 管理平台调用业务拨测系统，利用业务拨测系统的 GPRS Modem 实现告警通知规则u 管理平台与自动巡检子系统之间的 资源接口，自动巡检系统需要从管理平台中定期获取资源数据，主要有 名称、IP 地址、操作系统类型/版本、所属业务系统等u 自动巡检子系统与管理平台之间告警生成接口，自动巡检系统在发现巡检结果异常时，调用本接口，在 管理平台中生成相应的告警u 自动巡检子系统与业务拨测子系统间任务调度接口，即自动巡检子系统在配置任务调度要获取在业务拨测子系统中定义的各种拨测任务列表，并根据定义任务类型，将相应的拨测任务归入某个巡检任务中调度

46、执行，并在实际执行时在业务拨测子系统中创建有特殊标记的拨测任务，通过业务拨测子系统执行相应的拨测规则u 业务拨测系统与自动巡检子系统间的拨测结果数据接口，即业务拨测系统在完成自动巡检子系统生成的拨测任务之后，把拨测结果传递给自动巡检子系统，以形成相应的巡检报告u 业务拨测子系统与管理平台之间的接口，即业务拨测出现某种拨测任务率低于设定门限、拨测时延高于设定门限，出现 SP 等情况时，调用本接口在监控管理平台中生成告警u 业务拨测子系统与局数据管理子系统之间的接口，业务拨测子系统需要从局数据管理子系统中获取各种局数据，如每个 SP 的每个业务的资费标准，订购/退订命令字，号码等u 局数据管理子系

47、统与 管理平台之间的告警生成接口， 数据管理子系统对采集到的现网局数据与标准局数据进行比对稽核或者与前一 批次的局数据进行比对稽核时，发现异常时，调用本接口，在 管理平台中生成告警u 局数据管理子系统与 管理平台间的自动 规则生成接口，对于 SMPP 接口、SGIP 接口、PDSCP 接口等配置类局数据来说，在局数据到此类局数据时，自动在 管理平台中生成相应的 规则，定时 相应的 IP 地址以及TCP 端口的活动情况，在发现异常情况时由管理平台自动生成告警u 局数据管理子系统与综合分析平台之间的接口，由于号段、SP （企业代码、接入号等）、SP 业务都是在进行综合分析时的重要的维度数据，因此，

48、需要定期将局数据传送给综合分析平台u 管理平台与 IP 地址管理子系统之间的 IP 资源数据接口，IP 地址管理子系统需要从 管理平台自动发现出的网段、子网和 IP 地址中选择哪些是需要纳入到IP 地址管理范围内的，因此，需要通过调用本接口获取相应u IP 地址管理子系统与管理平台之间的告警接口，IP 地址管理子系统一方面会根据 IP 地址的规划情况与现网的 IP 地址占用情况进行比对，在发现有时，调用本接口生成告警；另一方面，IP 地址管理子系统在发现篡改 IP 地址、MAC 地址 ，未知 接入网络等情况时，调用本接口生成告警u 管理平台与 维护管理子系统之间的数据接口，利用 管理平台的数据

49、采集机制，细粒度的 配置 ，如序列号、部件号、规格型号等 ，通过调用本接口传递给维护管理子系统u 维护管理子系统与 管理平台之间的告警接口，维护管理子系统需要实现 维保预警和出保告警功能，在发现有 处在维保预警或出保告警状态时， 调用本接口在 管理平台侧生成相应的告警u 与自管理模块之间的用户管理与登录认证接口，由于所有的用户、组织机构、帐号口令 均 在自中，因此， 均需要调用本接口实现用户登录认证功能u 与自管理模块之间的 接口，由于 的 模型在自管理模块中维护，因此，无论功能点还是管理内容的自管理模块实现，因此，都需要通过调用本接口获取已登录的用户所拥有的权限 u 与自管理模块之间的操作接

50、口， 的用户操作 均由自管理模块，因此， 均需要调用本接口生成操作日志，u 与自管理模块之间的自接口的工作状态、数据处理量、输入输出情况均需要通过调用本接口上报给自管理模块u 综合 平台、综合维护平台与综合分析平台之间的接口，需要根据综合分析平台各分析 、分析专题和统计报表的需要，综合 平台和综合维护平台将相关的数据定期传送给综合分析平台，由综合分析平进行各种数据的后处理、再处理、二次分析以及数据组织和数据呈现等工作r 系统统一的框架设计与实现我们讨论了 选型和各种纵向接口和横向接口的设计，同时，为了提升用户的使用感知和系统的整体性，还需要考虑整体的框架设计与实现。整体框架设计的考虑主要体现在

51、以下个方面：u 各模块间通讯机制的统一u 各模块 B/S 界面统一框架实现u 用户/登录/认证/权限的统一管理u 统一的规则引擎u 统一的操作日志管理u 统一的自体系搭建为了实现以上的整体框架搭建，我方在总体设计时，采用了 SUN 公司提倡的 JEF（Java Enterprise Framework）。附图2.JEF 框架通过在线规划时严格遵循 JEF 框架要求，我方提供的解决方案分别采用了以下机制，共同实现框架的整体性：u 通过部署 JBOSS 中间件，利用 JMS 和 RMI 等通用的标准协议，实现、各模块之的实时消息和调用等通讯机制u 通过设计、开发和维护基于 Struts/Sprin

52、g/Hibernate 技术搭建所有 B/S 的前端框架， 约束 B/S 展现层的布局、配色、字体等，保证前端界面展现风格的一致性u 通过统一使用 Log4j 技术，所有及功能模块的操作日志均通过 Log4j 生成， 并统一 ，同时又在系统中内置了 lucence 的搜索引擎，按照相应的规则，对系统日志、操作日志建立索引，支持按照关键字如用户名、ip 等进行、展现。u 通过统一采用采用 antlr (ANother Tool for Language Recognition)技术来作的策略服务工具。基于 antlr 技术，我方实现了统一和 各种匹配规则，这些匹配规则是在用户的使用过程中可以根据

53、需要随意配置的，而不是嵌死在 。这样，在我方的系统中，不重新编译也不重新部署系统就可以改变规则匹配行为，从而提高了系统的客户化定制的能力u 通过统一使用基于 XML 的 JDNC（JDesktop Network Components）组件，实现功能点 和管理内容，功能权限的组织最终被抽象为诸如菜单和按钮等界面元素， 对这些元素的 我们基于 JDNC 进行统一，这样使得界面的是基于 XML 文件，而不是由程序员写死在代码中，而 XML 文件的内容又可以通过系统所赋予的功能权限来动态。内容权限的是基于内容权限 节点来进行的，首先将多个对象归属到一个 节点下，通过 节点的复选来 内容权限，再将这些

54、内容权限授予某一个角色，属于该角色的用户将会得到这些内容的 ，从而实现统一的权限管理与 u 通过统一采用 JMX 技术，实现全方面的自功能，通过 JMX 提供的自身管理接口就是将可被管理的到内部的 MBean 服务器，这些软硬件运行情况、通讯环境、内部线程、处理队列等各种运行指标通过以上各种技术 ，我方为联通设计的增值业务综合系统的所有和功能模块，都采用了统一的 框架，从而切实有效的 的整体性。2.2.2 功能 综合系统提供了 N 多项功能，但是，需要指出的是，如果没有深入细致的需求调研，没有联通广大维护的日常使用，没有最佳实践的积累，就形成真正有效的 策略和维护条目，那么大部分的功能就不可能

55、充分发挥作用，因此，在搭建的 、高效、可扩展能力强、生命周期长的系统架构之后，必须想方设法，解决功能的问题，为了有效的说明功能 的必要性，我们总结了二期工程中的三个典型案例进行剖析：u 一根网线的故事u 一个灯泡的故事u 一个号段的故事r 一根网线的故事，在二期工程上线之后 在帮助每个省分公司检查数据的变化情况，在发现问题时，主动 相关省分公司，对异常情况进行及时的处理。去年的某天，我们负责检查某省分公司的同事发现该省的 点对点接通率指标和互通 接通率指标连续两天大幅度下降，比正常指标下降了 40%左右，由于这两个指标都是总部考核各省分公司的关键指标，于是立即通知相关省分公司维护一起调查。通过调查，发现了以下现象：u 点对点接通率指标确实明显下降u 互通接通率指标确实明显下降u 互通网关和 中心的相应关键业务进程工作正常u 检查该省近两天的业务量和互通业务量，