綜合網(wǎng)管3期方案建議書

1、附件 1-方案建議書文檔屬性屬性內(nèi)容客戶名稱聯(lián)通項目名稱聯(lián)通 2008 年 GSM 網(wǎng)增值業(yè)務(wù)綜合系統(tǒng)文檔 附件 1-方案建議書文檔副標題文檔版本1.1文檔日期文檔狀態(tài)提交稿作者文檔變更版本修訂日期修訂人描述V1.02008-9-22神州 V1.12008-12-30神州 文檔送呈目的聯(lián)通本文檔僅限神州和被呈送方，擴散到第。第 352 頁 共 342 頁目 錄1 項目概述62 總體方案設(shè)計102.1 增值業(yè)務(wù)綜合系統(tǒng)的定位102.2 增值業(yè)務(wù)綜合建設(shè)的關(guān)鍵點分析152.2.1 架構(gòu)搭建162.2.2功能 . 242.2.3 數(shù)據(jù)消費292.2.4 系統(tǒng)推廣342.3 總體設(shè)計思路說明352.3

2、.1技術(shù)路線及第的選型思路說明352.3.2硬件選型及網(wǎng)絡(luò)搭建思路362.3.3架構(gòu)設(shè)計思路383 軟硬件部署方案443.1 硬件處理能力配算443.2 局域網(wǎng)/廣域網(wǎng)設(shè)計方案443.2.1 廣域網(wǎng)組網(wǎng)方案443.2.2 各省局域網(wǎng)組網(wǎng)連接方案463.2.3 總部局域網(wǎng)組網(wǎng)方案483.2.4 系統(tǒng)安全考慮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 功能實現(xiàn)方案654.1 綜合 平臺654.1.1架構(gòu)說明654.1.2管理平臺674.1.3. 1144.1.4主機數(shù)據(jù)庫. 1344.1.5業(yè)務(wù)應(yīng)用 . 1464.1.6橫向接口1594.2 綜合維護平臺1634.2.1架構(gòu)說明1634.2.2 全網(wǎng)運維子系統(tǒng)1654.2.3 總部 日常維護子系統(tǒng)2364.2.4 通用日常維護子系統(tǒng)2474.2.5 橫向接口2854.3 綜合分析平臺2854.3.1架構(gòu)設(shè)計2864.3.2 分析 設(shè)計2984.3.3 周邊接口3084.4 省部接

4、口設(shè)計方案3084.4.1 實時消息接口3084.4.2 消息/文件接口3094.5 自管理方案3124.5.1 用戶管理/權(quán)限管理3124.5.2 SSO 實現(xiàn)方案3134.5.3自. 3144.6 防 體系建設(shè)3164.6.1選型3164.6.2功能說明3184.6.3部署方案3225 系統(tǒng)平滑過渡方案設(shè)計3255.1 數(shù)據(jù)遷移的要點和需求3255.2 需要重點保障的遷移數(shù)據(jù)分析3255.3 系統(tǒng)數(shù)據(jù)遷移步驟3276 圖表目錄3311 項目概述近年來， 聯(lián)通增值業(yè)務(wù)經(jīng)歷了從無到有、從弱到強、階梯式、 式的發(fā)展歷程，增值業(yè)務(wù)種類齊全，已經(jīng)從附屬業(yè)務(wù)、增值業(yè)務(wù)發(fā)展成為市場規(guī)模巨大的基本業(yè)務(wù)，

5、2007 全年增值業(yè)務(wù)總收入已經(jīng)超過 100 億。與傳統(tǒng)的語音業(yè)務(wù)相比，增值業(yè)務(wù)具 有巨大的發(fā)展前景，在電信重組的格局下，是聯(lián)通拓展市場份額，發(fā)展有效用戶。增加 有效收入的關(guān)鍵 之一，隨著 3G 的即將來臨，增值業(yè)務(wù)必將得到更大的發(fā)展機 遇，在聯(lián)通總體收入中所占比重會越來越大。在這樣的形勢下，利用有限的資源，面對增值業(yè)務(wù)的復(fù)雜多樣性和不斷擴充的業(yè)務(wù)需求， 如何提高維護工作效率，保障增值業(yè)務(wù)系統(tǒng)的正常運行，從而確保并逐步提升聯(lián)通的服務(wù)質(zhì)量，是擺在聯(lián)通增值業(yè)務(wù)部面前的緊迫問題。聯(lián)通增值業(yè)務(wù)部從 2005 年開始籌劃面向整個增值專業(yè)的綜合系統(tǒng)，我方非常榮幸的獲得承建全國 31 各省和總部的增值業(yè)務(wù)綜

6、合項目的機會，從 2006 年 4 月到 2007 年，12 月，神州公司投入了近 150 人的實施和研發(fā)團隊，與聯(lián)通總部及各省項目配合緊密協(xié)作，克服了很多的 的完成了增值業(yè)務(wù)綜合 項目的建設(shè)，該項目分為兩個階段建設(shè)，第一個階段從 2006 年 4 月到 2006 年 9 月，主要完成了總部、山東、江蘇、 、上海、浙江 7 個節(jié)點的試點工程建設(shè)，2006 年 10 月到 2007 年 3 月，完成了其它 25 個省公司的綜合系統(tǒng)建設(shè)，2007 年 4 月到 5 月，我們用了將近兩 的時間完成全國所有業(yè)務(wù)系統(tǒng)的數(shù)據(jù)質(zhì)量核查，系統(tǒng)于 2007 年 6 月正式投產(chǎn)使用，2007 年 12 月完成整個

7、系統(tǒng)的終驗工作，從 2007 年 6 月到 2008 年 6 月，我方一直保持著 50 人的現(xiàn)場運維團隊，保障綜合系統(tǒng)的 運行和數(shù)據(jù)質(zhì)量，從系統(tǒng)正式上線投產(chǎn)以來，綜合系統(tǒng)已經(jīng)逐步成為聯(lián)通增值業(yè)務(wù)不可或缺的運行支撐系統(tǒng)，其提供的資源資產(chǎn)、容量、性能、告警數(shù)據(jù)已經(jīng)成為增值業(yè)務(wù)專業(yè)的日常維護、容量規(guī)劃、系統(tǒng)建設(shè)、管理考核、經(jīng)營分析最重要的依據(jù)，目前增值業(yè)務(wù)部每 的生產(chǎn)經(jīng)營分析會材料中的數(shù)據(jù)均通過綜合系統(tǒng)提供， 所有現(xiàn) 的擴容可研報告均以綜合系統(tǒng)的容量規(guī)劃專題提供的數(shù)據(jù)為依據(jù)，提高了項目建設(shè)投入的有效性和 性，節(jié)約了大量的建設(shè)投資。對各省分的運維考核數(shù)據(jù)也通過綜合 系統(tǒng)自動生成并上傳總部，極大地促進了

8、各省公司下大力氣提高網(wǎng)絡(luò)質(zhì)量，據(jù)全統(tǒng)計，僅接通率一項指標，2008 年 6 月比 07 年 環(huán)比提高了近 8 個百分點，從而大幅度的提高的增值業(yè)務(wù)的有效收入。通過綜合 系統(tǒng)從開源和節(jié)流兩個方面帶來的投資回報價值是顯而易見的。與此同時，增值業(yè)務(wù)綜合在今年年初的雪災(zāi)和 5 月份以來的抗震救災(zāi)等 活動或中都發(fā)揮了巨大的作用。神州 公司在增值業(yè)務(wù)綜合 項目實施和上線后的維護工作中投入了巨大的人力物力資源，尤其是在 Agent 部署、業(yè)務(wù)系統(tǒng)接口聯(lián)調(diào)和數(shù)據(jù)質(zhì)量保障三項最艱巨的任務(wù)方面， 項目組投入了很多的勞動、心血和精力，同時也取得了總部和各省分公司的高度評價和認可， 積累了大量的寶貴經(jīng)驗， 、有能力為

9、聯(lián)通提供持續(xù)、高效的服務(wù)。神州 公司于 2007 年中標移動 14 個省的數(shù)據(jù)二期工程，承建 、吉林、重慶、湖南、河南、海南、甘肅、福建、陜西、云南、的數(shù)據(jù)系統(tǒng)建設(shè)工作，從而成為在增值業(yè)務(wù)/數(shù)據(jù) 域國內(nèi)市場份額最大，實施經(jīng)驗最豐富、化程度最高、綜合實力最強的公司。作為電信重組的一部分，增值業(yè)務(wù)綜合系統(tǒng)即將移交給電信，因此，聯(lián)通新一代的增值業(yè)務(wù)綜合系統(tǒng)建設(shè)工作正式提上日程，通過認真分析技術(shù)規(guī)范書，我方認為本項目 以下幾個難點：² 工程實施周期短，技術(shù)規(guī)范書中要求本項目的建設(shè)周期分為兩個階段，其中第一個階段的實施周期為 4 ，完成對近 5000 臺服務(wù)器、1000 多臺網(wǎng)絡(luò)，數(shù)百個數(shù)據(jù)庫

10、、500 多個業(yè)務(wù)系統(tǒng)、32 個節(jié)點這樣規(guī)模巨大的項目實施工作，這對于任何一個廠家來說，都是對其項目管理與組織能力、實施隊伍的規(guī)模和能力的巨大² 項目建設(shè)內(nèi)容多，本期項目中將完成綜合 平臺、綜合維護平臺、綜合分析平臺三大平臺及防 系統(tǒng)的建設(shè)，而且綜合與各業(yè)務(wù)系統(tǒng)間、各平臺間、平臺內(nèi)部 間、省公司與總部之間均著錯綜復(fù)雜的接口 ，大致數(shù)了一下， 本項目涉及到 320 多個子系統(tǒng)、數(shù)百個接口、數(shù)百種報表的開發(fā)、集成、實施、聯(lián)調(diào)工作，這對任何一個廠家來說都是對其研發(fā)能力和系統(tǒng)集成能力的考驗，而在如此之短的工期要求之內(nèi)，如果沒有對 域的深刻理解與積累、對增值業(yè)務(wù)的充分了解、對現(xiàn)網(wǎng)環(huán)境的足夠熟悉

11、，沒有成熟的和類似項目的實施經(jīng)驗，幾乎可以斷定，不可能承擔項目的建設(shè)工作。² 數(shù)據(jù)遷移工作量大， 項目的建設(shè)目的無外乎提供實用有效的運維工具和及時準確、完整的數(shù)據(jù)和，而增值業(yè)務(wù)綜合一階段上線已經(jīng)超過兩年，全國正式上線也已經(jīng)一年多了，目前系統(tǒng)中的數(shù)據(jù)，涵蓋了 C/G 兩網(wǎng)的有效用戶，每種業(yè)務(wù)的業(yè)務(wù)量、用戶數(shù)、用戶使用頻率和業(yè)務(wù)滲透率， 了每個業(yè)務(wù)系統(tǒng)的數(shù)據(jù)，提供了 每個 SP 的業(yè)務(wù)發(fā)展情況，提供了哪些種增值業(yè)務(wù)的業(yè)務(wù)量較好， 提供了每個業(yè)務(wù)系統(tǒng)負荷情系統(tǒng)容量，這些數(shù)據(jù)對于聯(lián)通來說是非常重要和寶貴的，不夸張的說，這些數(shù)據(jù)的價值已經(jīng)遠遠超過了系統(tǒng)建設(shè)的投資，因此，新建的系統(tǒng)必須實現(xiàn)對現(xiàn)

12、的數(shù)據(jù)遷移工作，而如何實現(xiàn)舊系統(tǒng)移交電信的同時完成新系統(tǒng)的數(shù)據(jù)遷移工作，相當于一邊開車飛馳，一邊換輪胎，難度很大² 用戶使用感受與培訓成本問題，在二期項目實施過程中，花了大量的精力用戶使用感受，提高界面的人性化，豐富數(shù)據(jù)展現(xiàn)方式，目前各省和總部的用戶已經(jīng)習慣了增值業(yè)務(wù)綜合系統(tǒng)的數(shù)據(jù)組織 界面風格，新建系統(tǒng)如何在增加新功能，提高系統(tǒng)性能的同時，保證用戶使用習慣的一致性，從而盡量減少培訓成本和用戶的抱怨，同樣是必須面對和解決的問題神州 公司在 2001 年就完成了全球網(wǎng)的項目，2002 年完成了海洋石油公司全管項目，2003-04 年完成聯(lián)通全國WAP 項目，06 年完成移動5 省BOS

13、S項目，06-07 年完成局全國 44 個節(jié)點的項目， 06-07 年完成聯(lián)通全國增值業(yè)務(wù)項目，07 年完成壽全國 36 個節(jié)點的項目，07-08 年完成移動 14 個省的數(shù)據(jù)項目，擁有業(yè)界最豐富的全國性項目項目實施管理經(jīng)驗和充沛的儲備，完全有能力實現(xiàn)增值業(yè)務(wù)并發(fā) 32 個節(jié)點的實施工作。神州 公司在業(yè)務(wù)方向上分 網(wǎng)絡(luò)管理、服務(wù)流程管理、數(shù)據(jù)應(yīng)用管理和安全管理四大部分，每個業(yè)務(wù)方向上均有成熟的 和解決方案，在方面具有充分的準備， 在本項目中推薦使用的各 和功能模塊均有 案例，同時，神州 從 2003 年起就參與聯(lián)通增值業(yè)務(wù)部的項目，先后的實施了一期、WAP 3 期、WAP 網(wǎng)管 4 期、增值業(yè)

14、務(wù)、EMP 等多個項目，對于總部和各省的增值業(yè)務(wù)系統(tǒng)的組網(wǎng)情業(yè)務(wù)情況非常熟悉，對于各省公司和總部的日常運維工作開展方式、工作流程、考核指標算法、運維規(guī)程和維護作業(yè)計劃等管理方面的規(guī)章制度同樣很了解，同時，我方通過 06-08年的增值業(yè)務(wù)綜合項目的實施和維護工作，已經(jīng)完成了與現(xiàn)網(wǎng)各業(yè)務(wù)系統(tǒng)的接口聯(lián)調(diào)工作，接口的性和數(shù)據(jù)質(zhì)量夠充分的保障，從而能夠按時、保質(zhì)的完成增值綜合業(yè)務(wù)系統(tǒng)的集成、應(yīng)用開發(fā)、部署等紛繁復(fù)雜的工作。由于 31 個省公司和總部的增值業(yè)務(wù)綜合系統(tǒng)均由神州公司承建，因此，對我們來說數(shù)據(jù)遷移和用戶使用感受這兩個問題也就不是問題了，能夠充分的統(tǒng)和數(shù)據(jù)的延續(xù)性。通過以上分析，我方認為，神州公

15、司是唯一一家有能力承擔聯(lián)通新一代增值業(yè)務(wù)綜合系統(tǒng)的廠家，我們也非常愿意投入最 資源為聯(lián)通增值業(yè)務(wù)綜合系統(tǒng)的建設(shè)貢獻我們的經(jīng)驗、智慧和力量。下面，我方將對增值業(yè)務(wù)綜合系統(tǒng)的總體方案設(shè)計進行詳細的說明，并從軟硬件部署、功能實現(xiàn)、數(shù)據(jù)遷移幾個方面進行具體的說明。2 總體方案設(shè)計2.1 增值業(yè)務(wù)綜合 系統(tǒng)的定位在考慮增值業(yè)務(wù)綜合系統(tǒng)的整體建設(shè)思路時，首先必須考慮并且回答兩個問題：u 如何理解并明確什么是綜合系統(tǒng)u 如何理解并明確增值業(yè)務(wù)的特點以及增值業(yè)務(wù)的特點r 如何理解并明確什么是綜合 ，我們認為，綜合，就是要考慮清楚這套系統(tǒng)與其他運營商或聯(lián)通其他部門建設(shè)的所謂的專業(yè)之間的差異。而這個差異從定位上來

16、說，就是需要明確 聯(lián)通增值業(yè)務(wù)綜合 就是增值專業(yè)的綜合性的運行支持系統(tǒng)。以移動為例，其系統(tǒng)建設(shè)分拆為話務(wù) 、傳輸、數(shù)據(jù)、信令監(jiān)測、動換 五個專業(yè)系統(tǒng)，再通過運維系統(tǒng)實現(xiàn)工單流轉(zhuǎn)，由以上六大系統(tǒng)基本的運行支撐系統(tǒng)框架。其中，與聯(lián)通增值業(yè)務(wù)綜合對應(yīng)的系統(tǒng)是數(shù)據(jù)系統(tǒng)，但是移動的數(shù)據(jù)實際上就是一套數(shù)據(jù)業(yè)務(wù)的 系統(tǒng)，不包含運維、不包含業(yè)務(wù)撥測、不包含局數(shù)據(jù)管理、不包含統(tǒng)計分析、不包含中心以及語音增值類業(yè)務(wù)應(yīng)用的 管理，應(yīng)該說移動數(shù)據(jù)系統(tǒng)的內(nèi)涵和外延與聯(lián)通增值業(yè)務(wù)綜合系統(tǒng)之間著巨大的差異。那么，什么 增值專業(yè)的綜合性的運行支撐系統(tǒng)呢？我們認為只有該系統(tǒng)的內(nèi)涵和外延能夠覆蓋增值專業(yè)日常運行、維護、生產(chǎn)、管理

17、的各個層面，才能夠稱得上是綜合性的運行支撐系統(tǒng)，因此，我方認為增值業(yè)務(wù)綜合系統(tǒng)的最終架構(gòu)應(yīng)該由以下 7 大體系：u 綜合 體系：用于實現(xiàn)對 IT 基礎(chǔ)架構(gòu)和業(yè)務(wù)應(yīng)用的全方位管理，消除死角，及時發(fā)現(xiàn)系統(tǒng)異常情況， 統(tǒng)的可見性和可用性u 綜合維護體系：為一線維護提供全面的維護 和工具，打通與被元之間的透明通道，提供各種與維護工作相關(guān)的翔實準確的數(shù)據(jù)和 ，一方面減輕維護的工作量，另一方面提升系統(tǒng)的運行質(zhì)量和整體維護水平，實現(xiàn)運維工作的標準化和規(guī)范化u 安全管控/防護體系：對系統(tǒng)的安全運行提供各種管理和，對所有的系統(tǒng)操作進行有效的 和審計，檢測并安全風險，提供各種安全防護和策略，封堵各種可能的安全漏洞

18、或安全隱患，、安全運行提供保障 。u 管理考核體系：為省公司和總部提供各種數(shù)據(jù)分析的 ，提供各種實用有效的主題分析和專題分析，使總部制定的各種管理辦法和規(guī)章制度真正可以執(zhí)行和落實， 可以做到真正意義上的量化考核，通過各種橫向/縱向比對，鼓勵先進，督促后進， 進一步提升全國運維生產(chǎn)工作的標準化。u 指揮調(diào)度體系：聯(lián)通增值業(yè)務(wù)的特點之一是垂直管理力度大，如何保證總部的各項工作安排能夠落到實處，保證總部與省分公司之間上傳下達的通道的順暢，提升整體執(zhí)行力，提升總部從全網(wǎng)的角度發(fā)現(xiàn)問題、分析問題、指揮調(diào)度、質(zhì)量檢查、主動管理的能力，就需要有完善的指揮調(diào)度體系的支撐u 支撐體系：如何通過運維支撐體系實現(xiàn)“

19、發(fā)展有效用戶，增加有效收入”的目標，其中很重要的一點就是提高增值專業(yè)對 的處理能力，而這一方面需要建立健全增值專業(yè)的 的跟蹤處理能力，另一方面需要建設(shè)有效的，幫助 部門提升投訴攔截率和解決問題的能力，從而大幅度提升用戶的滿意度u 合作伙伴考核體系：大部分增值業(yè)務(wù)實際上是類的系統(tǒng)，即聯(lián)通提供高效的業(yè)務(wù) ，由合作伙伴（CP/SP）基于業(yè)務(wù) 開展豐富的業(yè)務(wù)應(yīng)用，而如何引加強對合作伙伴的管理力度，盡量減少或及早發(fā)現(xiàn) CP/SP 的行為，是保證增值業(yè)務(wù)能夠健康、持續(xù)發(fā)展的基礎(chǔ)我們認為，由這“七種”的綜合系統(tǒng)，才能夠擔負起為增值專業(yè)提供綜合運行支撐系統(tǒng)的任務(wù)，當然，運行支撐系統(tǒng)的建設(shè)也不是一蹴而就的，其建

20、設(shè)規(guī)模、建設(shè)效果、推廣情況與投資額度、整體規(guī)劃、員工素質(zhì)、組織機構(gòu)、工作流程、管理考核機制、領(lǐng)導(dǎo)重視程度都是關(guān)的，因此，我方認過本期項目建設(shè)，搭建綜合、綜合維護和綜合分析三大平臺，同時建設(shè)全網(wǎng)防體系，是符合聯(lián)通目前的發(fā)展現(xiàn)狀和生產(chǎn)中的急迫需要的。與此同時，也有必要通盤考慮、科學規(guī)劃整體運行支撐體系的建設(shè)并逐步完善。r 如何理解并明確聯(lián)通增值業(yè)務(wù)的特點以及增值業(yè)務(wù) 的特點我方從 2003 年開始就參與增值專業(yè)的系統(tǒng)建設(shè)，通過一期工程、WAP 三期、四期工程中的及安全系統(tǒng)以及增值業(yè)務(wù)綜合二期工程的建設(shè)，我聯(lián)通增值專業(yè)非常熟悉，再加上我方承建了移動數(shù)據(jù)二期工程中 14 個省的項目建設(shè)工作， 使我 增

21、值業(yè)務(wù)以及增值業(yè)務(wù) 的特點有了深刻的認識和體會。我方認為聯(lián)通增值業(yè)務(wù)的特點主要有：u 增值業(yè)務(wù)種類多，新技術(shù)、新業(yè)務(wù)、新應(yīng)用層出不窮，代表著電信運營商最重要的業(yè)務(wù)發(fā)展方向u 增值業(yè)務(wù)涉及的協(xié)議、標準、規(guī)范多，與傳統(tǒng)的語音業(yè)務(wù)相比，增值業(yè)務(wù)要復(fù)雜得多，傳統(tǒng)的語音業(yè)務(wù)涉及到的業(yè)務(wù)流程無外乎建立連接、鑒權(quán)、漫游、切換、尋呼、拆除連接等固定的流程，涉及的網(wǎng)元無外乎 MSC、HLR、BSC、BTS、Cell、STP 等，其業(yè)務(wù)流程、業(yè)務(wù)模型固定且標準，同時由于 GSM 和 CDMA 等技術(shù)已經(jīng)非常成熟，互聯(lián)互通體系 語音業(yè)務(wù)相比，每種增值業(yè)務(wù)的協(xié)議、標準、業(yè)務(wù)流程和業(yè)務(wù)模型，而且各種增值業(yè)務(wù)的業(yè)務(wù)模型和

22、業(yè)務(wù)流程之間的差異非常大u 增值業(yè)務(wù)系統(tǒng)的 性不足，由于大部分增值業(yè)務(wù)是基于 IT 技術(shù)實現(xiàn)，其實從基礎(chǔ)技術(shù)的角度說，就達不到電信級的高可用性，同時，由于增值業(yè)務(wù)系統(tǒng)的業(yè)務(wù)處理環(huán)節(jié)多，各增值業(yè)務(wù)間接口繁多，以炫為例，其與 GSM 網(wǎng)、信令網(wǎng)、MMS、WAP、IVR 等系統(tǒng)均接口，且涉及到運營商 無法的 SP 的，因此，增值業(yè)務(wù)的 性 先天不足，與傳統(tǒng)的語音業(yè)務(wù)相比，更容易出問題u 增值業(yè)務(wù)的維護力量和維護經(jīng)驗不足，由于聯(lián)通增值業(yè)務(wù)在運維方面的人手不夠， 而且由于新建項目多，涉及到的廠家多，很多系統(tǒng)的維護工作由廠家承擔，且運維經(jīng)驗沒有得到充分的梳理、總結(jié)和沉淀，也缺乏必要的來固化這些運維經(jīng)驗，

23、這些問題造成了聯(lián)通增值專業(yè)的總體維護水平不高u 增值專業(yè)在業(yè)務(wù)開展方面與合作伙伴之間 密切，傳統(tǒng)的語音業(yè)務(wù)實際上只涉及到運營商自身以及與其他運營商之間的互聯(lián)互通，而增值業(yè)務(wù)不僅涉及到聯(lián)通內(nèi)部各專業(yè)和其他運營商，同時還涉及到數(shù)量眾多，良莠不齊的 SP，這就造成業(yè)務(wù)質(zhì)量保障和用戶投訴處理的，與此同時，信產(chǎn)部關(guān)于增值業(yè)務(wù)的監(jiān)督管理機制也比語音業(yè)務(wù)復(fù)雜，這也造成了增值專業(yè)必須著重考慮如何加強對合作伙伴的管理由于增值專業(yè)在業(yè)務(wù)種類、業(yè)務(wù)流程、業(yè)務(wù)流程度、維護力量、與合作伙伴等幾個方面都著上述特點，這就決定了增值業(yè)務(wù) 系統(tǒng)的特點：u 增值業(yè)務(wù) 系統(tǒng)的承建廠商必須深入了解業(yè)務(wù)特點和業(yè)務(wù)具體流程，增值 系統(tǒng)必

24、須具備強大的業(yè)務(wù)建模、業(yè)務(wù)流程建模能力：增值業(yè)務(wù) 必須具備準確刻畫各種增值業(yè)務(wù)的能力，全面梳理每種增值業(yè)務(wù)的關(guān)鍵業(yè)務(wù)點和 KPI 指標，并且清晰的表現(xiàn)各業(yè)務(wù)關(guān)鍵點之間的關(guān)聯(lián) ，才能夠準確的發(fā)現(xiàn)系統(tǒng)的異常以及這些故障對整體業(yè)務(wù)的影響程度，以中心為例，如果不把 中心與防系統(tǒng)之間的接口納入 體系，當該接口出現(xiàn)問題時，不僅會影響 中心的 MO、MT 接通率指標，同時還會造成互通網(wǎng)關(guān)接通率的下降，如果不把 中心與 PDSCP 間的接口納入 體系，就有可能無法定位預(yù)付費用戶的投訴，如果不把中心與 BSS 系統(tǒng)間的接口納入體系，就有可能造成收入方面的損失。同時，由于增值業(yè)務(wù)的復(fù)雜多變，必須提供靈活的模型調(diào)整

25、和 能力。u 增值業(yè)務(wù) 系統(tǒng)必須有全面的接口支持能力和健壯的數(shù)據(jù)質(zhì)量保障機制： 數(shù)據(jù)來源復(fù)雜且不規(guī)范，為了保證綜合系統(tǒng)數(shù)據(jù)的全面性，就需要通過對多種協(xié)議的支持從多個數(shù)據(jù)源獲取數(shù)據(jù)，如為了獲取網(wǎng)絡(luò) 的數(shù)據(jù)，需要支持 SNMP、Syslog、Trap 等協(xié)議，為了獲取服務(wù)器、數(shù)據(jù)庫的數(shù)據(jù)，需要部署 Agent 并進行數(shù)據(jù)級的集成，為了獲取業(yè)務(wù)系統(tǒng)提供的 KPI 指標，需要支持 Corba、DB、FTP、 、CLI、MML 等多種接口方式，為了對業(yè)務(wù)量、有效用戶等數(shù)據(jù)進行統(tǒng)計，就需要 并 每個業(yè)務(wù)系統(tǒng)各種各樣的話單文件，并進行復(fù)雜的剔重處理，為了獲取網(wǎng)絡(luò)質(zhì)量并提供運營商網(wǎng)絡(luò)質(zhì)量對比數(shù)據(jù)，就需要支持

26、SMS、MMS、WAP、IVR、Java、流媒體、定位等多種對各種業(yè)務(wù)及 SP 提供的各種應(yīng)用進行業(yè)務(wù)撥測，這一方面造成了的復(fù)雜和，同時由于業(yè)務(wù)系統(tǒng)的頻繁升級（影響與系統(tǒng)間接口或話單格式改變），造成數(shù)據(jù)完整性和數(shù)據(jù)質(zhì)量很難保證。u 增值業(yè)務(wù) 系統(tǒng)需要充分考慮數(shù)據(jù)之間關(guān)聯(lián) ：在進行數(shù)據(jù)分析的 設(shè)計和算法設(shè)計要充分考慮數(shù)據(jù)模型的復(fù)雜程度，以 MMS 業(yè)務(wù)量分析為例，一方面需要搞清楚 MO/MT，AO/AT、/FO/FT、/EO/ET 八個方向，28 種組合，另一方面需要考慮每種業(yè)務(wù)應(yīng)用（如像冊、 報等）都需要單獨作為統(tǒng)計維度，而為了支持分地市的業(yè)務(wù)量分析，就需要將局數(shù)據(jù)管理中的 MMSC 中的號段

27、局數(shù)據(jù)作為分析維度納入統(tǒng)計算法，同時還需要考慮品牌維度（世界風、新、如意通），從上例可知，為了有效的提供各種分析專題，需要通盤考慮數(shù)據(jù)來源和數(shù)據(jù)模型的組合u 需要仔細設(shè)計系統(tǒng)部署方案：由于增值業(yè)務(wù)種類繁多，且由于大部分省分公司并沒 的網(wǎng)絡(luò)規(guī)劃，每建設(shè)一個新的增值業(yè)務(wù)系統(tǒng)，就新建一個局域網(wǎng)，造成了目前的“片狀互連”的現(xiàn)狀，因此，在設(shè)計綜合系統(tǒng)部署方案時，必須充分考慮的分布式部署能力，同要綜合考慮各業(yè)務(wù)系統(tǒng)之間的 ，在統(tǒng)安全策略的前提下，簡化網(wǎng)絡(luò)接入方案，例如，文本類的業(yè)務(wù)系統(tǒng)（中心、在信網(wǎng)關(guān)、互通網(wǎng)關(guān)、EMP 和SPMS）基本上是可以部署一臺機進行數(shù)據(jù)的，但是語音增值類的業(yè)務(wù)系統(tǒng)，如炫鈴和 IV

28、R 之間網(wǎng)絡(luò)是完全的，就只能通過分別部署 機的方式 數(shù)據(jù)u 充分考慮運維經(jīng)驗和運維知識的積累與固化能力：由于目前聯(lián)通增值專業(yè)的運維力 量、運維經(jīng)驗不足，因此，在設(shè)計實現(xiàn)增值業(yè)務(wù)綜合時，不僅需要考慮提供多少個功能點、多少張報表、多少種數(shù)據(jù)，還必須提供運維經(jīng)驗和運維支持的固化能力，通過靈活的技術(shù) ，將這些經(jīng)驗和知識不斷地總結(jié)出來，再固化在綜合系統(tǒng)中，以切實有效的提升聯(lián)通 維護 的業(yè)務(wù)水平和解決問題的能力u 重點考慮并提高對 SP 的管理和考核能力：在增值業(yè)務(wù)中，除了點對點和 MMS 之外，大部分業(yè)務(wù)的開展都是與 SP 相關(guān)的，因此，需要從多個維度分析 SP 的業(yè)務(wù)發(fā)展情況，一方面扶植、幫助 SP

29、快速發(fā)展有效業(yè)務(wù)，另一方面及時發(fā)現(xiàn)并堅決糾正 SP 的行為，以保證增值業(yè)務(wù)的健康、持續(xù)發(fā)展u 保證總部與省分公司之間上傳下達通道的順暢：在省部接口設(shè)計和工單流程設(shè)計時，要充分考慮聯(lián)通增值專業(yè)垂直管理的特點，在設(shè)計省部接口方案時要保證省部接口數(shù)據(jù)上傳的實時性和準確性，特別是 告警和考核指標；在工單流程設(shè)計時要重點考慮總部各處室之間工單流轉(zhuǎn)的特點，和總部/省分公司之間工單流轉(zhuǎn)的不同特點，例如，對于總部下發(fā)省分公司的工單，需要考慮多級審批的情況，即有可能需要總部相關(guān)處室領(lǐng)導(dǎo)、總部增值業(yè)務(wù)部領(lǐng)導(dǎo)、省分公司主管領(lǐng)導(dǎo)等多個審批環(huán)節(jié)， 同要必須實現(xiàn)工單字段級的 和處理環(huán)節(jié)的 等功能的實現(xiàn)，例如，總部業(yè)務(wù)運行

30、室受理了某省分公司創(chuàng)建的一個投訴工單，其工單的內(nèi)部處理環(huán)節(jié)要求省分公司不可見，而業(yè)務(wù)運行室內(nèi)部相關(guān) 是可以全程跟蹤該工單的處理情況的?？偛肯掳l(fā)的通用工單 都是同時發(fā)給多個省分公司的，這就要求系統(tǒng)能夠支持多個子工單的生成以及對每個子工單的狀態(tài)分別和變更功能，同應(yīng)提供對工單流轉(zhuǎn)全生命周期的跟蹤功能，以保證總部對工單處理情況的全面了解r 小結(jié)通過上述分析可知，聯(lián)通增值業(yè)務(wù)綜合 系統(tǒng)的定位是增值專業(yè)的綜合運行支撐系統(tǒng)，同時，由于增值業(yè)務(wù)的自身特點，在設(shè)計和實現(xiàn)增值業(yè)務(wù)系統(tǒng)時必須充分考慮增值專業(yè)在業(yè)務(wù)模型、業(yè)務(wù)關(guān)聯(lián)程度、運維現(xiàn)狀等方面的特點，在系統(tǒng)部署、資源建模/數(shù)據(jù)建模、SP 考核、省部接口等方面重點

31、考慮。同要指出的是，由于本項目中必須充分考慮現(xiàn)中的數(shù)據(jù)遷移問題，因此， 數(shù)據(jù)遷移方案的設(shè)計也是需要重點關(guān)注的內(nèi)容之一。2.2 增值業(yè)務(wù)綜合 建設(shè)的關(guān)鍵點分析上文中我們分析并論述了增值業(yè)務(wù)綜合系統(tǒng)的定位，下面，我們就本期項目建設(shè)的關(guān)鍵點進行深入的分析和探討。根據(jù)我方多年來在建設(shè)領(lǐng)域中的經(jīng)驗總結(jié)，我方認為增值業(yè)務(wù)綜合建設(shè)的關(guān)鍵點可以歸納為以下四個：u 架構(gòu)搭建u 功能 u 數(shù)據(jù)消費u 系統(tǒng)推廣下面，我們就分別對這個四個關(guān)鍵點進行詳細的分析。2.2.1 架構(gòu)搭建增值業(yè)務(wù)綜合系統(tǒng)主要由綜合平臺、綜合維護平臺和綜合分析平臺三大平臺， 十幾種 ，數(shù)十個功能模塊，因此，如何設(shè)計、搭建、高效且擴展能力強的系統(tǒng)

32、架構(gòu)，是必須放在首要位置考慮并解決的問題。系統(tǒng)架構(gòu)的重要性是眾所周知的，從某種意義上，系統(tǒng)架構(gòu)的生命周期就是整個系統(tǒng)的生命周期，可以把系統(tǒng)架構(gòu)比喻為生產(chǎn)，而用戶的需求和基于用戶需求的各種功能實現(xiàn)都是生產(chǎn)力，如果系統(tǒng)架構(gòu)不能夠繼續(xù)支持新的需求和新的功能或者現(xiàn)有功能改造的要求， 就類似于生產(chǎn)已經(jīng)妨礙了生產(chǎn)力的發(fā)展，因此，選擇正確的系統(tǒng)架構(gòu)能夠統(tǒng)自身的生命力以及這個系統(tǒng)的可持續(xù)發(fā)展能力，對于聯(lián)通來說，需要考慮在系統(tǒng)架構(gòu)上的投資回報問題，是選擇一個價格便宜而生命周期短的架構(gòu)？還是選一個架構(gòu)合理、價格適中的系統(tǒng)架構(gòu)呢？我們認為一個 、高效、擴展能力強的系統(tǒng)架構(gòu)設(shè)計需要從以下幾個方面入手：r 組合的選擇：

33、需要充分考慮到各種 在整體架構(gòu)中的位置和特點，并進行深入細致的研究，保證產(chǎn)品選型的科學合理，在本項目中，我方考慮到主機需要部署在生產(chǎn)服務(wù)器上，對軟件的 性和安全性要求很高；而工作流引擎需要適應(yīng)聯(lián)通組織機構(gòu)、部門職責、工作流程的不斷變化；在總部的全網(wǎng)綜合分析系統(tǒng)中，由于需要提供非常提供的數(shù)據(jù)組織和處理能力， 通常的統(tǒng)計報表系統(tǒng)不可能滿足總部對數(shù)據(jù)處理和展現(xiàn)要求，需要部署專業(yè)的 OLAP 工具， 因此我方認為在這三個 方面，很有必要考慮選擇國外主流的成熟 。而在其他方面， 我方 開發(fā)的 不論在功能、整體框架設(shè)計、人性化等方面經(jīng)非常成熟，而且經(jīng)經(jīng)過了多個項目的驗證，因此除了主機、工作流引擎以及 OL

34、AP 前端工具三個，其余均選擇了我方 開發(fā)的相關(guān) 。我方在選擇主機時，重點考察了五個關(guān)鍵點：u 主機對現(xiàn)網(wǎng)操作系統(tǒng)和數(shù)據(jù)庫種類及版本的支持全面性，如果這點不能滿足現(xiàn)網(wǎng)要求，則會出現(xiàn) 的空白點；u 考察其 的 性，由于主機需要部署在各業(yè)務(wù)系統(tǒng)每臺生產(chǎn)服務(wù)器上， 其 性和安全性是必須考察的，在這方面，國際主流的顯然具有國內(nèi)自主開發(fā)的不可比擬的優(yōu)勢；u 考察其 的實現(xiàn)機制，有些 與操作系統(tǒng)底層結(jié)合的過于緊密，如上期項目中使用的 HP OVO ，不僅需要調(diào)整系統(tǒng)的參數(shù)，同時對操作系統(tǒng)的補丁有著嚴格的要求，這就造成了實施方面的很多；u 考察其 的數(shù)據(jù)和通訊機制，在上期項目中，由于 HP OVO 采用從

35、上層應(yīng)用側(cè)定時串行 Agent 緩被管服務(wù)器側(cè)數(shù)據(jù)的機成了數(shù)據(jù)及時性和完整性難以得到保證的問題，同時，其 不支持分布式的部署方式，造成在不少省分公司只能將 系統(tǒng)的 機與所有被管服務(wù)器之間打通通信端口，而這種方式是一定的安全隱患的；u 考察其 的可擴展能力，由于 的需求是不斷變化的，個性化的 需求是層出不窮的，因此，不可能有哪種 提供的默認指標能夠滿足本項目中的所有要求， 這就需要考察 是否具備可擴展能力，是否提供了靈活的二次開發(fā) ，與此同時還需要不斷在項目中梳理總結(jié)共性化的 需求，逐步積累和推廣這些二次開發(fā)形成的新的經(jīng)過充分的考察和比對分析，我方認為 BMC 公司的 Performance M

36、anager 在以上五個方面都是最優(yōu)的選擇。我方在選擇工作流引擎 時，主要考察以下四個關(guān)鍵點u 是否符合 ITIL 規(guī)范要求，是否融合和內(nèi)置了大量 ITIL 最佳經(jīng)驗；u 是否足夠靈活，進行深入定制和二次開發(fā)，以適應(yīng)本地化需求；u 定制和二次開發(fā)是否足夠簡單、方便，以適應(yīng)服務(wù)流程不斷變化的業(yè)務(wù)要求；u 系統(tǒng)本身的 性、可靠性、性能、安全性、接口靈活性等技術(shù)因素。我方認為 BMC 公司的 Remedy 是工作流引擎領(lǐng)域中最，主要的選型依據(jù)如下：u 業(yè)界第一家 ITIL 認證的服務(wù)管理u 市場占有份額最高的服務(wù)管理平臺 ，現(xiàn)有超過 12,000 企業(yè)客戶使用 Remedy 的 管理服務(wù)，其中超過

37、7,000 家是世界級跨國公司，Remedy 的終端用戶已經(jīng)超過了 10,000,000 人。 100 80%使用了 Remedy ，全球 500 也有超過60使用了Remedy 的解決方案。u 上期項目中已經(jīng)采用了 Remedy 作為底層工作流引擎，現(xiàn)有的運維功能均基于Remedy 開發(fā)實現(xiàn)，能夠達到快速部署、快速上線的要求u Remedy 提供了強大的表單設(shè)計器工具，通過該工具能夠通過前臺界面以拖拽的方式快速開發(fā)工單的前端樣式，同時可以隨時擴展數(shù)據(jù)庫的表和字段，而不是通過“預(yù)留字段”的 現(xiàn)的。既保證了充分的靈活性和可擴展性，擴展時又無需停止服務(wù)或重啟系統(tǒng)。u Remedy 的體系架構(gòu) 成熟

38、，其體系架構(gòu)為CSS 三層架構(gòu)，同時可以支持Web、 和 PDA 等各種用戶界面，可以支持雙機容錯、多機負載均衡等各種特性，可以充分 統(tǒng)的可用性、可靠性、可擴展性和性能；在安全性方面，它支持 SSL 鏈路加密、支持多種認證方式、支持顯示界面、字段、操作等多級 ，具備完善的審計功能；在可靠性方面，支持多臺服務(wù)器、Web 服務(wù)器自動負載均衡；在性能方面，在客戶機、應(yīng)用服務(wù)器 緩存機制，實踐證明對硬件要求較低；在可擴展方面，支持多臺服務(wù)器共同工作，提供豐富的 API 接口， 平滑擴容。由于以上幾項明顯的優(yōu)勢，我們選擇繼續(xù)使用 Remedy 作為運維系統(tǒng)的底層工作流引擎。在 OLAP 選型方面，我方主

39、要考慮到一期、WAP 統(tǒng)計分析和增值業(yè)務(wù)綜合項目中均使用了 Cognos Powerplay 分析 ，考慮到使用習慣的延續(xù)性和原有開發(fā)成果的保留，在本期項目中選擇了 Cognos 最新的 Powerplay 8.0 ，用于實現(xiàn)總部綜合分析平臺的 OLAP 前端工具。Cognos 8.0 是具有強大的專業(yè)化的虛擬 OLAP 數(shù)據(jù)引擎（OLAP 服務(wù)器），它能產(chǎn)生多維數(shù)據(jù)分析的立方體（Cubes） 數(shù)據(jù)立方體是一系列面向應(yīng)用 的數(shù)據(jù)集市，能處理大數(shù)據(jù)量，它為用戶快速實現(xiàn)大數(shù)據(jù)量的統(tǒng)計分析報表提供了中間數(shù)據(jù)文件， 數(shù)據(jù)庫（Cubes）?；?Upfront 的用戶權(quán)限更加方便,基于時間分區(qū)的虛擬 C

40、ube 技術(shù)，支持增量更新，支持超大數(shù)據(jù)量。Cognos Powerplay Enterprise Server 支持多機負載均衡 統(tǒng)的處理能力的可擴展性，為大數(shù)據(jù)量、大用戶數(shù)提供了堅實的承載基礎(chǔ)。Cognos Transformation Server 具備強大的模型制作能力，如靈活的時間序列處理、全面的匯總類型定義、任意組合的計算類別定義等等，可以快速適配用戶的業(yè)務(wù)邏輯和分析要求， 制作出結(jié)構(gòu)良好、效率極高的分析模型，以滿足用戶對數(shù)據(jù)分析的各種需求。計算型指標、指標文件夾的功能可以在立方體的建模中令指標的 更加人性化用戶可以通過鼠標任意拖拽組合 分析條件，或在圖形、報表中進行切片、旋轉(zhuǎn)、上

41、下鉆取等操作，分析結(jié)果隨時可以導(dǎo)出為 PDF、CSV 等多種格式的文件。Cognos 提供了餅圖、線圖、柱圖、圖等多種圖形展現(xiàn)方式，并提供了各種計算、累計和 分析功能，同時還支持用戶自定義的例外項顯示，可以迅速定位異常的數(shù)據(jù)。附圖1.Cognos Powerplayr 模塊間橫向和縱向接口設(shè)計由于本系統(tǒng)的和功能模塊眾多，如何保證在系統(tǒng)建成后，不是交付給用戶一堆，而是一套有機結(jié)合，各和功能模塊分工協(xié)作的運行支撐系統(tǒng)，這就要在方案設(shè)計階段著重考慮各，各功能模塊間的橫向和縱向接口的問題。同時，除了在技術(shù)方面的考慮，還需要考慮本系統(tǒng)的建設(shè)模式，明確哪些事情是可為的，哪些是不可為的，并盡力把可為的事情做

42、到位，盡量做到最好。所謂縱向接口主要指本系統(tǒng)中的省部接口。聯(lián)通增值業(yè)務(wù)綜合系統(tǒng)首先是一個兩級三層的架構(gòu)，因此，總部與省分公司間的省部接口設(shè)計非常關(guān)鍵的。我方在上期工程中，由于總部及全國 31 個省的系統(tǒng)我公司承建，因此，在省部接口方面已經(jīng)做得非常成熟，能夠?qū)崿F(xiàn)省分公司的告警和拓撲改變的實時上傳；提供了省部接口數(shù)據(jù)防篡改機制，以保證各種考核數(shù)據(jù)在側(cè)的真實準確；提供了實時的省部接口機制，在發(fā)現(xiàn)有數(shù)據(jù)積壓或丟失的情況，可以采用相應(yīng)的技術(shù)由總部系統(tǒng)自動發(fā)起直接在省公司系統(tǒng)中重采、補采數(shù)據(jù)，對于話單、處理流程，我們采用了通過在總部部署一套調(diào)度 ，調(diào)度全國相應(yīng)服務(wù)器系統(tǒng)工作的方式。通過采用以上多種技術(shù) ，

43、我們基本上保證了省部接口的通暢運轉(zhuǎn)，保證了總部和省分公司之間的上傳下達。但是由于本期項目，非常有可能采取多廠家共同承擔本項目建設(shè)的方式，由于各廠家的應(yīng)用 設(shè)計思路不一致，數(shù)據(jù)結(jié)構(gòu)不一致、處理流程不一致、展現(xiàn)風格不一致、命名規(guī)則不一致等因素，省部接口的功能必然會有所下降，如全網(wǎng)拓撲功能基本不可能實現(xiàn)，數(shù)據(jù)防篡改機制也不可能繼續(xù)生效，數(shù)據(jù)補采和重采只能采用手工方式進行，話單處理的統(tǒng)一調(diào)度更加不可能實現(xiàn)，因此，我方將在本方案中重新設(shè)計省部接口的實現(xiàn)方案，以保證基本的告警、性能統(tǒng)計數(shù)據(jù)通過省部接口的上 能的實現(xiàn)。所謂橫向接口，是指總部或省分公司綜合 系統(tǒng)內(nèi)部各 和功能模塊之間的接口以及綜合 系統(tǒng)與周

44、之間的接口，這些接口包含了技術(shù)方面的接口設(shè)計和業(yè) 務(wù)方面的接口設(shè)計。我們大致梳理了一下，本項目中需要實現(xiàn)的橫向接口主要有：u 管理平臺與運維子系統(tǒng)之間的 六類故障工單接口，包含自動故障工單生成接口、手工派單接口，告警升級觸發(fā)工單級別變更接口，告警自動恢復(fù)觸發(fā)相應(yīng)工單關(guān)閉的接口，工單受理動作觸發(fā)告警狀態(tài)變更為“已確認”狀態(tài)接口，工單關(guān)閉觸發(fā)當前告警清除并轉(zhuǎn)為歷史告警接口u 管理平臺告警通知接口，本接口為 SGIP 協(xié)議接口，即聯(lián)通總部及各省分公司分別為綜合系統(tǒng)分配一個接入號，通過 SGIP 協(xié)議接入在信網(wǎng)關(guān)，實現(xiàn)告警通知功能u 管理平臺備用告警通知接口，當在信網(wǎng)關(guān)不可用時，所有告警通知將無法正常

45、發(fā)送，因此，需要實現(xiàn) 管理平臺與業(yè)務(wù)撥測之間的接口，即由 管理平臺調(diào)用業(yè)務(wù)撥測系統(tǒng)，利用業(yè)務(wù)撥測系統(tǒng)的 GPRS Modem 實現(xiàn)告警通知規(guī)則u 管理平臺與自動巡檢子系統(tǒng)之間的 資源接口，自動巡檢系統(tǒng)需要從管理平臺中定期獲取資源數(shù)據(jù)，主要有 名稱、IP 地址、操作系統(tǒng)類型/版本、所屬業(yè)務(wù)系統(tǒng)等u 自動巡檢子系統(tǒng)與管理平臺之間告警生成接口，自動巡檢系統(tǒng)在發(fā)現(xiàn)巡檢結(jié)果異常時，調(diào)用本接口，在 管理平臺中生成相應(yīng)的告警u 自動巡檢子系統(tǒng)與業(yè)務(wù)撥測子系統(tǒng)間任務(wù)調(diào)度接口，即自動巡檢子系統(tǒng)在配置任務(wù)調(diào)度要獲取在業(yè)務(wù)撥測子系統(tǒng)中定義的各種撥測任務(wù)列表，并根據(jù)定義任務(wù)類型，將相應(yīng)的撥測任務(wù)歸入某個巡檢任務(wù)中調(diào)度

46、執(zhí)行，并在實際執(zhí)行時在業(yè)務(wù)撥測子系統(tǒng)中創(chuàng)建有特殊標記的撥測任務(wù)，通過業(yè)務(wù)撥測子系統(tǒng)執(zhí)行相應(yīng)的撥測規(guī)則u 業(yè)務(wù)撥測系統(tǒng)與自動巡檢子系統(tǒng)間的撥測結(jié)果數(shù)據(jù)接口，即業(yè)務(wù)撥測系統(tǒng)在完成自動巡檢子系統(tǒng)生成的撥測任務(wù)之后，把撥測結(jié)果傳遞給自動巡檢子系統(tǒng)，以形成相應(yīng)的巡檢報告u 業(yè)務(wù)撥測子系統(tǒng)與管理平臺之間的接口，即業(yè)務(wù)撥測出現(xiàn)某種撥測任務(wù)率低于設(shè)定門限、撥測時延高于設(shè)定門限，出現(xiàn) SP 等情況時，調(diào)用本接口在監(jiān)控管理平臺中生成告警u 業(yè)務(wù)撥測子系統(tǒng)與局數(shù)據(jù)管理子系統(tǒng)之間的接口，業(yè)務(wù)撥測子系統(tǒng)需要從局數(shù)據(jù)管理子系統(tǒng)中獲取各種局數(shù)據(jù)，如每個 SP 的每個業(yè)務(wù)的資費標準，訂購/退訂命令字，號碼等u 局數(shù)據(jù)管理子系

47、統(tǒng)與 管理平臺之間的告警生成接口， 數(shù)據(jù)管理子系統(tǒng)對采集到的現(xiàn)網(wǎng)局數(shù)據(jù)與標準局數(shù)據(jù)進行比對稽核或者與前一 批次的局數(shù)據(jù)進行比對稽核時，發(fā)現(xiàn)異常時，調(diào)用本接口，在 管理平臺中生成告警u 局數(shù)據(jù)管理子系統(tǒng)與 管理平臺間的自動 規(guī)則生成接口，對于 SMPP 接口、SGIP 接口、PDSCP 接口等配置類局數(shù)據(jù)來說，在局數(shù)據(jù)到此類局數(shù)據(jù)時，自動在 管理平臺中生成相應(yīng)的 規(guī)則，定時 相應(yīng)的 IP 地址以及TCP 端口的活動情況，在發(fā)現(xiàn)異常情況時由管理平臺自動生成告警u 局數(shù)據(jù)管理子系統(tǒng)與綜合分析平臺之間的接口，由于號段、SP （企業(yè)代碼、接入號等）、SP 業(yè)務(wù)都是在進行綜合分析時的重要的維度數(shù)據(jù)，因此，

48、需要定期將局數(shù)據(jù)傳送給綜合分析平臺u 管理平臺與 IP 地址管理子系統(tǒng)之間的 IP 資源數(shù)據(jù)接口，IP 地址管理子系統(tǒng)需要從 管理平臺自動發(fā)現(xiàn)出的網(wǎng)段、子網(wǎng)和 IP 地址中選擇哪些是需要納入到IP 地址管理范圍內(nèi)的，因此，需要通過調(diào)用本接口獲取相應(yīng)u IP 地址管理子系統(tǒng)與管理平臺之間的告警接口，IP 地址管理子系統(tǒng)一方面會根據(jù) IP 地址的規(guī)劃情況與現(xiàn)網(wǎng)的 IP 地址占用情況進行比對，在發(fā)現(xiàn)有時，調(diào)用本接口生成告警；另一方面，IP 地址管理子系統(tǒng)在發(fā)現(xiàn)篡改 IP 地址、MAC 地址 ，未知 接入網(wǎng)絡(luò)等情況時，調(diào)用本接口生成告警u 管理平臺與 維護管理子系統(tǒng)之間的數(shù)據(jù)接口，利用 管理平臺的數(shù)據(jù)

49、采集機制，細粒度的 配置 ，如序列號、部件號、規(guī)格型號等 ，通過調(diào)用本接口傳遞給維護管理子系統(tǒng)u 維護管理子系統(tǒng)與 管理平臺之間的告警接口，維護管理子系統(tǒng)需要實現(xiàn) 維保預(yù)警和出保告警功能，在發(fā)現(xiàn)有 處在維保預(yù)警或出保告警狀態(tài)時， 調(diào)用本接口在 管理平臺側(cè)生成相應(yīng)的告警u 與自管理模塊之間的用戶管理與登錄認證接口，由于所有的用戶、組織機構(gòu)、帳號口令 均 在自中，因此， 均需要調(diào)用本接口實現(xiàn)用戶登錄認證功能u 與自管理模塊之間的 接口，由于 的 模型在自管理模塊中維護，因此，無論功能點還是管理內(nèi)容的自管理模塊實現(xiàn)，因此，都需要通過調(diào)用本接口獲取已登錄的用戶所擁有的權(quán)限 u 與自管理模塊之間的操作接

50、口， 的用戶操作 均由自管理模塊，因此， 均需要調(diào)用本接口生成操作日志，u 與自管理模塊之間的自接口的工作狀態(tài)、數(shù)據(jù)處理量、輸入輸出情況均需要通過調(diào)用本接口上報給自管理模塊u 綜合 平臺、綜合維護平臺與綜合分析平臺之間的接口，需要根據(jù)綜合分析平臺各分析 、分析專題和統(tǒng)計報表的需要，綜合 平臺和綜合維護平臺將相關(guān)的數(shù)據(jù)定期傳送給綜合分析平臺，由綜合分析平進行各種數(shù)據(jù)的后處理、再處理、二次分析以及數(shù)據(jù)組織和數(shù)據(jù)呈現(xiàn)等工作r 系統(tǒng)統(tǒng)一的框架設(shè)計與實現(xiàn)我們討論了 選型和各種縱向接口和橫向接口的設(shè)計，同時，為了提升用戶的使用感知和系統(tǒng)的整體性，還需要考慮整體的框架設(shè)計與實現(xiàn)。整體框架設(shè)計的考慮主要體現(xiàn)在

51、以下個方面：u 各模塊間通訊機制的統(tǒng)一u 各模塊 B/S 界面統(tǒng)一框架實現(xiàn)u 用戶/登錄/認證/權(quán)限的統(tǒng)一管理u 統(tǒng)一的規(guī)則引擎u 統(tǒng)一的操作日志管理u 統(tǒng)一的自體系搭建為了實現(xiàn)以上的整體框架搭建，我方在總體設(shè)計時，采用了 SUN 公司提倡的 JEF（Java Enterprise Framework）。附圖2.JEF 框架通過在線規(guī)劃時嚴格遵循 JEF 框架要求，我方提供的解決方案分別采用了以下機制，共同實現(xiàn)框架的整體性：u 通過部署 JBOSS 中間件，利用 JMS 和 RMI 等通用的標準協(xié)議，實現(xiàn)、各模塊之的實時消息和調(diào)用等通訊機制u 通過設(shè)計、開發(fā)和維護基于 Struts/Sprin

52、g/Hibernate 技術(shù)搭建所有 B/S 的前端框架， 約束 B/S 展現(xiàn)層的布局、配色、字體等，保證前端界面展現(xiàn)風格的一致性u 通過統(tǒng)一使用 Log4j 技術(shù)，所有及功能模塊的操作日志均通過 Log4j 生成， 并統(tǒng)一 ，同時又在系統(tǒng)中內(nèi)置了 lucence 的搜索引擎，按照相應(yīng)的規(guī)則，對系統(tǒng)日志、操作日志建立索引，支持按照關(guān)鍵字如用戶名、ip 等進行、展現(xiàn)。u 通過統(tǒng)一采用采用 antlr (ANother Tool for Language Recognition)技術(shù)來作的策略服務(wù)工具。基于 antlr 技術(shù)，我方實現(xiàn)了統(tǒng)一和 各種匹配規(guī)則，這些匹配規(guī)則是在用戶的使用過程中可以根據(jù)

53、需要隨意配置的，而不是嵌死在 。這樣，在我方的系統(tǒng)中，不重新編譯也不重新部署系統(tǒng)就可以改變規(guī)則匹配行為，從而提高了系統(tǒng)的客戶化定制的能力u 通過統(tǒng)一使用基于 XML 的 JDNC（JDesktop Network Components）組件，實現(xiàn)功能點 和管理內(nèi)容，功能權(quán)限的組織最終被抽象為諸如菜單和按鈕等界面元素， 對這些元素的 我們基于 JDNC 進行統(tǒng)一，這樣使得界面的是基于 XML 文件，而不是由程序員寫死在代碼中，而 XML 文件的內(nèi)容又可以通過系統(tǒng)所賦予的功能權(quán)限來動態(tài)。內(nèi)容權(quán)限的是基于內(nèi)容權(quán)限 節(jié)點來進行的，首先將多個對象歸屬到一個 節(jié)點下，通過 節(jié)點的復(fù)選來 內(nèi)容權(quán)限，再將這些

54、內(nèi)容權(quán)限授予某一個角色，屬于該角色的用戶將會得到這些內(nèi)容的 ，從而實現(xiàn)統(tǒng)一的權(quán)限管理與 u 通過統(tǒng)一采用 JMX 技術(shù)，實現(xiàn)全方面的自功能，通過 JMX 提供的自身管理接口就是將可被管理的到內(nèi)部的 MBean 服務(wù)器，這些軟硬件運行情況、通訊環(huán)境、內(nèi)部線程、處理隊列等各種運行指標通過以上各種技術(shù) ，我方為聯(lián)通設(shè)計的增值業(yè)務(wù)綜合系統(tǒng)的所有和功能模塊，都采用了統(tǒng)一的 框架，從而切實有效的 的整體性。2.2.2 功能 綜合系統(tǒng)提供了 N 多項功能，但是，需要指出的是，如果沒有深入細致的需求調(diào)研，沒有聯(lián)通廣大維護的日常使用，沒有最佳實踐的積累，就形成真正有效的 策略和維護條目，那么大部分的功能就不可能

55、充分發(fā)揮作用，因此，在搭建的 、高效、可擴展能力強、生命周期長的系統(tǒng)架構(gòu)之后，必須想方設(shè)法，解決功能的問題，為了有效的說明功能 的必要性，我們總結(jié)了二期工程中的三個典型案例進行剖析：u 一根網(wǎng)線的故事u 一個燈泡的故事u 一個號段的故事r 一根網(wǎng)線的故事，在二期工程上線之后 在幫助每個省分公司檢查數(shù)據(jù)的變化情況，在發(fā)現(xiàn)問題時，主動 相關(guān)省分公司，對異常情況進行及時的處理。去年的某天，我們負責檢查某省分公司的同事發(fā)現(xiàn)該省的 點對點接通率指標和互通 接通率指標連續(xù)兩天大幅度下降，比正常指標下降了 40%左右，由于這兩個指標都是總部考核各省分公司的關(guān)鍵指標，于是立即通知相關(guān)省分公司維護一起調(diào)查。通過調(diào)查，發(fā)現(xiàn)了以下現(xiàn)象：u 點對點接通率指標確實明顯下降u 互通接通率指標確實明顯下降u 互通網(wǎng)關(guān)和 中心的相應(yīng)關(guān)鍵業(yè)務(wù)進程工作正常u 檢查該省近兩天的業(yè)務(wù)量和互通業(yè)務(wù)量，