李 洪，渠 凱，周文紅，伍思源，申文俊

（1.中國電信集團公司網(wǎng)絡運行維護事業(yè)部 北京100032；2.中通服軟件科技有限公司 上海200127）

1 網(wǎng)管的發(fā)展

電信網(wǎng)絡在過去很長一段時間一直處于持續(xù)發(fā)展的階段。在這個階段中，由于市場競爭，電信運營商一直重點關注市場的拓展和用戶的增長。因此在IT支撐系統(tǒng)的建設中，一直關注的是與業(yè)務發(fā)展有關的BSS域系統(tǒng)以及與業(yè)務開通有關的OSS域系統(tǒng)，在與服務保障有關的系統(tǒng)建設方面相對落后。特別是在網(wǎng)管領域，長期以來一直是以廠商網(wǎng)管建設為主，缺乏在專業(yè)和綜合網(wǎng)管方面的投入，比如中國電信集團公司（以下簡稱中國電信）在2005-2006年完成綜合告警系統(tǒng)建設后，就再也沒有相關的舉動，導致在網(wǎng)絡運營方面前后端能力嚴重脫節(jié)，不得不為支撐業(yè)務運營增加臨時的工具類系統(tǒng)，故而如激活系統(tǒng)、服務能力前置系統(tǒng)等應運而生。

電信運營商在經(jīng)歷了網(wǎng)絡和客戶的大規(guī)模發(fā)展之后，意識到競爭格局已從單純的客戶競爭轉向了全方位的服務競爭，而體現(xiàn)電信運營商的服務能力和服務差異化之處在于后端網(wǎng)絡的運營能力。因此自動化、智能化將成為電信運營商在后端不斷追求的目標。

2 網(wǎng)管集約化——綜合網(wǎng)管

實現(xiàn)網(wǎng)管自動化、智能化，首先要實現(xiàn)基于網(wǎng)管信息的完整和準確。但正如前文所述，長久以來在網(wǎng)管領域的投入偏廢，導致各級網(wǎng)管系統(tǒng)的建設參差不齊，系統(tǒng)極其零散。在系統(tǒng)內的數(shù)據(jù)質量都難以保證的情況下，系統(tǒng)間數(shù)據(jù)的一致性就更難保證，更不要說是端到端的全程數(shù)據(jù)了。而在現(xiàn)行計算模式下，自動化和智能化嚴重依賴于數(shù)據(jù)的完備，這一點在綜合告警系統(tǒng)的實施過程中體現(xiàn)得非常突出，所有的故障關聯(lián)分析、故障定位都離不開資源數(shù)據(jù)的支持，而數(shù)據(jù)的準確性也決定了自動化、智能化的程度和效果。

歸根結底，目前掣肘網(wǎng)管自動化、智能化發(fā)展的最大因素是在網(wǎng)管領域沒有一個能夠完整覆蓋所有電信智能網(wǎng)絡、實現(xiàn)端到端的全網(wǎng)統(tǒng)一管理的集中管理系統(tǒng)。

因此，實現(xiàn)智能網(wǎng)管的第一步是實現(xiàn)網(wǎng)管的集約化，即綜合網(wǎng)管系統(tǒng)。

3 集約化綜合網(wǎng)管的建設模式

全網(wǎng)集約化模式下的綜合網(wǎng)管將面臨眾多現(xiàn)實的問題。傳統(tǒng)意義上，網(wǎng)管分為網(wǎng)元（NE）、廠商網(wǎng)管（EMS）、專業(yè)網(wǎng)管（NMS）和綜合網(wǎng)管（INMS）4個層次。隨著網(wǎng)絡與網(wǎng)絡技術的發(fā)展，網(wǎng)元數(shù)量增長迅速，隨之增長的是廠商網(wǎng)管的數(shù)量，且存在接口眾多、技術復雜、規(guī)范不統(tǒng)一、在建設期沒有規(guī)范要求的問題，有些廠商網(wǎng)管甚至不提供或要有償提供北向接口；而在專業(yè)網(wǎng)管層面，由于長期的投入不足，專業(yè)網(wǎng)管的建設大多落后，沒有專業(yè)網(wǎng)管，完全依賴廠商網(wǎng)管的情況普遍存在。

在這樣的情況下建設集約化網(wǎng)管，一直以來在其建設模式上存在爭議，尤其在技術日趨成熟的今天，條件已經(jīng)具備，系統(tǒng)如何落地成為一個現(xiàn)實問題。

3.1 集中系統(tǒng)

傳統(tǒng)上，按照我國電信運營商多級管理的模式，可以分級建立集中的綜合網(wǎng)管，從網(wǎng)元→廠商網(wǎng)管→專業(yè)網(wǎng)管→省級綜合網(wǎng)管→集團綜合網(wǎng)管，將網(wǎng)管的能力進行逐級匯集，建立物理集中的綜合網(wǎng)管，如圖1所示。

圖1 集中系統(tǒng)模式的綜合網(wǎng)管

分級集中適合于垂直管理的體系。在這種體系下，上級網(wǎng)管通過下級網(wǎng)管行使網(wǎng)管職能，上級網(wǎng)管的能力嚴重依賴下級網(wǎng)管的能力：任何一個層級的網(wǎng)管能力都是不可缺失的，因為任何一個層級的網(wǎng)管能力不足或缺失，都將影響上級網(wǎng)管對下級網(wǎng)管的管理；同時，同級網(wǎng)管間沒有互聯(lián)的通道，相互之間的溝通都依賴于上級網(wǎng)管，所以一定程度上還存在信息“孤島”，能力沒有形成真正的共享。

集中系統(tǒng)的模式在網(wǎng)管系統(tǒng)建設比較完善、能夠制定相對完整的網(wǎng)管北向接口規(guī)范且系統(tǒng)逐級收斂的情況下才可能實現(xiàn)。否則，集中系統(tǒng)的建設將直接面對繁多的多專業(yè)多廠商接口，對這些接口的適應和接口的功能及可靠性將成為制約集中系統(tǒng)發(fā)展的關鍵，這也是長期以來困擾綜合網(wǎng)管發(fā)展的最大因素。

綜合網(wǎng)管的提出已有很長時間了，但一直以來都停留在集中系統(tǒng)建設的傳統(tǒng)模式上。很多廠商和運營商在這條道路上已經(jīng)走了很多彎路，也碰過很多釘子，特別是目前網(wǎng)管建設相對落后，要按照集中模式逐級建立完備的網(wǎng)管體系，僅補齊中間缺失的環(huán)節(jié)，就需耗費大量的人力、物力，而未來網(wǎng)絡的發(fā)展變化愈加頻繁，新技術、新網(wǎng)絡愈加不斷出現(xiàn)，要網(wǎng)管逐級適應這些新技術、新網(wǎng)絡，很難滿足市場快速變化的需求。

3.2 多系統(tǒng)互聯(lián)

基于ESB（enterprise service bus，企業(yè)服務總線）的SOA（service oriented architecture，面向服務的體系結構）集成架構體系為多系統(tǒng)互聯(lián)提供了基礎。在這種模式下，各級網(wǎng)管以SOA規(guī)范對現(xiàn)有網(wǎng)管進行改造或重新構建，也就是經(jīng)過SOA治理的過程后，各系統(tǒng)向ESB暴露封裝好的、符合規(guī)范的服務，通過ESB將服務進行集成和整合。多系統(tǒng)互聯(lián)的綜合網(wǎng)管架構如圖2所示。

圖2 多系統(tǒng)互聯(lián)的綜合網(wǎng)管架構

采用ESB進行互聯(lián)，首先需要對現(xiàn)有系統(tǒng)進行改造，即SOA治理的過程。SOA要求遵循服務封裝、服務松耦合、服務契約、服務抽象、服務的重用性、服務的可組合性、服務自治、服務無狀態(tài)、服務的可被發(fā)現(xiàn)性等原則進行分層。

SOA體系架構如圖3所示。按照SOA架構的要求，各級網(wǎng)管將其網(wǎng)管能力封裝成規(guī)范的服務并注冊在ESB上。綜合網(wǎng)管應用通過ESB訪問注冊的網(wǎng)管服務，實現(xiàn)集中管理。

通過ESB進行多網(wǎng)管系統(tǒng)互聯(lián)的方式，很好地解決了系統(tǒng)間信息的傳遞和服務調用問題，實現(xiàn)了上級網(wǎng)管和下級網(wǎng)管之間的互動。通過ESB，網(wǎng)管能力得以共享，使得全網(wǎng)集中管理成為可能。

但是以系統(tǒng)形式互聯(lián)在全網(wǎng)規(guī)模下也同樣存在很多問題，介紹如下。

·該方式主要基于將單個網(wǎng)管作為獨立的系統(tǒng)來看待這一基礎。ESB作為SOA集成架構平臺，主要用于系統(tǒng)間互聯(lián)，以服務方式進行集成。對于體系和功能架構相對一致的網(wǎng)管系統(tǒng)是否需要ESB來集成，值得商榷。

·基層網(wǎng)管數(shù)量眾多，若以其直接接入ESB，則完成SOA治理的成本巨大，而且具有大量老舊系統(tǒng)，實施難度和風險巨大。

·ESB除完成服務注冊、管理、路由、組裝等基本功能外，還在系統(tǒng)間引入了中介處理環(huán)節(jié)，進行審計、對賬、安全等第三方仲裁功能，對于網(wǎng)管這樣以同步操作為主（可以不需要仲裁）、實時性要求非常高、數(shù)據(jù)交換頻繁的系統(tǒng)，ESB很可能成為性能瓶頸。

3.3 云化

隨著互聯(lián)網(wǎng)技術的發(fā)展，特別是海量數(shù)據(jù)應用在互聯(lián)網(wǎng)企業(yè)的實踐，云計算的概念越來越符合IT系統(tǒng)發(fā)展的趨勢。以云化實現(xiàn)運營商IT系統(tǒng)集約化的條件也日漸成熟。

網(wǎng)管域系統(tǒng)主要有以下3個特點。

圖3 SOA體系架構

·不管是廠商網(wǎng)管、專業(yè)網(wǎng)管還是綜合網(wǎng)管，在功能域上都是完成TMF定義的FCAPS五大功能，因此一定意義上，各級網(wǎng)管系統(tǒng)的功能是近似的，也可以是對等的。

·網(wǎng)管的數(shù)量依賴于網(wǎng)絡的復雜度和規(guī)模，具備不確定性，可任意擴展；對于全網(wǎng)來說，網(wǎng)管系統(tǒng)的數(shù)量是海量的。

·網(wǎng)管是自管理的。對于自己管理的范圍，網(wǎng)管可以不依賴于其他系統(tǒng)而獨立進行管理。

以上都具備云計算的基本特征，說明網(wǎng)管系統(tǒng)云化具備一定的基礎。

在討論網(wǎng)管系統(tǒng)云化前，先介紹下比較流行的云計算平臺Hadoop的基本架構，如圖4所示。

圖4 云計算平臺Hadoop的基本架構

Hadoop的分布式文件系統(tǒng)由命名節(jié)點（name node）和數(shù)據(jù)節(jié)點（data node）構成，數(shù)據(jù)節(jié)點負責提供數(shù)據(jù)存取服務。命名節(jié)點負責數(shù)據(jù)節(jié)點的管理，不參與數(shù)據(jù)存取。數(shù)據(jù)節(jié)點是對等的，各自負責一部分數(shù)據(jù)的存??；也是可以任意擴展，所以整個體系具備很好的可伸縮性。

對照Hadoop的結構，可以將全網(wǎng)網(wǎng)管作為一個分布式系統(tǒng)來考慮，而不是把每個網(wǎng)管都作為單獨的系統(tǒng)看待。每個對等的網(wǎng)管都可以作為一個網(wǎng)管能力節(jié)點，負責提供一部分網(wǎng)元的網(wǎng)管能力。于是只要建立全網(wǎng)的網(wǎng)管能力管理節(jié)點，就可以將全網(wǎng)的網(wǎng)管統(tǒng)一管理起來，進而具備全網(wǎng)網(wǎng)元的管理能力。

實際上，可以運用SOA的觀點，將網(wǎng)管按照“平臺+應用”的模式進行建設，全網(wǎng)集約化的網(wǎng)管可以形成如圖5所示的兩朵“云”，提供基礎網(wǎng)管服務的網(wǎng)管平臺形成網(wǎng)管云，各級網(wǎng)管應用可以基于網(wǎng)管云形成應用云。

不管是廠商網(wǎng)管還是專業(yè)網(wǎng)管或各級的綜合網(wǎng)管，都是網(wǎng)管云中的一個服務節(jié)點，不同的只是各自提供的能力和管理范圍不同。

圖5 全網(wǎng)集約化的網(wǎng)管

這樣，引入一個新的網(wǎng)管就如同增加一個云數(shù)據(jù)節(jié)點一樣簡單。云架構具備的良好的可伸縮性可以很好地支持海量網(wǎng)管服務節(jié)點的引入，使得網(wǎng)管云的服務能力可以無限地擴展。而應用云相比網(wǎng)管云來說，可以更不拘于既定的管理范圍和形式，任何一個應用都可以使用網(wǎng)管云提供的全網(wǎng)網(wǎng)管服務能力，而不管它在什么位置。

采用云化實施網(wǎng)管集約化有以下3個明顯的好處。

·相比ESB，對網(wǎng)管系統(tǒng)的SOA改造是必須的，完成基本服務的封裝，但采用“平臺+應用”方式實施的云架構體系對網(wǎng)管平臺的改造要求更簡單，由于在基礎架構上支持高度的可伸縮性，因此集成更加簡便、靈活，易于實施。

·網(wǎng)管云趨向于扁平化結構，應用直接訪問服務的提供者而不需要有第三方參與，這樣在服務訪問過程中減少了中間環(huán)節(jié)和不必要的處理，避免產(chǎn)生更多的性能瓶頸。

·體系架構的簡便也帶來了對應用要求門檻的降低，使得應用可以關注不同的維度，依不同的維度構建創(chuàng)新應用，如更關注端到端管理的綜合應用、更傾向于技術深度的專業(yè)應用等，這樣從體系上更有利于應用層面的微創(chuàng)新。

4 網(wǎng)管云技術

從技術上看，網(wǎng)管系統(tǒng)具有與其他系統(tǒng)不同的特點。（1）網(wǎng)管功能可分為如圖6所示的三大域。

圖6 網(wǎng)管功能三大域

·網(wǎng)管Ⅰ:網(wǎng)管的數(shù)據(jù)來自于網(wǎng)絡設備，形成數(shù)據(jù)采集域或網(wǎng)元同步域。

·網(wǎng)管Ⅱ：對采集數(shù)據(jù)進行管理，形成數(shù)據(jù)管理域。

·網(wǎng)管Ⅲ：對網(wǎng)元設備進行操作，形成網(wǎng)元配置域。

其中，網(wǎng)元同步域和網(wǎng)元配置域涉及網(wǎng)元的接口，這是網(wǎng)管系統(tǒng)與其他系統(tǒng)最大的不同之處。

（2）網(wǎng)元同步具有海量的事件信息上傳，需要應對數(shù)據(jù)風暴這樣的極端情況。

（3）網(wǎng)元配置以同步調用為主，需要保證高可靠性和實時性。

因此，在采用云技術上，要針對網(wǎng)管系統(tǒng)的特點進行適當?shù)倪x擇。

4.1 Hadoop+HBase

Hadoop是目前比較常見的開源分布式系統(tǒng)基礎框架，用戶可以在不了解分布式底層細節(jié)的情況下開發(fā)分布式程序，充分利用集群的威力高速運算和存儲。Hadoop具有高可靠性、高擴展性、高效性和高容錯性，可以在低成本平臺上實現(xiàn)可伸縮的分布式計算能力。Hadoop由分布式文件系統(tǒng)（HDFS）和分布式計算框架（MapReduce）組成。

HBase是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統(tǒng)，利用HBase技術可在廉價PC服務器上搭建起大規(guī)模結構化存儲集群。

Hadoop+HBase系統(tǒng)架構如圖7所示。

圖7 Hadoop+HBase系統(tǒng)架構

在集約化網(wǎng)管的模式下，集中進行事件處理，將面對海量的事件信息，包括告警、性能和日志信息。以往對于大量的原始信息，通常沒有辦法長期保存，主要是先進行處理加工，對處理加工后的信息進行管理。這在一定程度上丟失了部分網(wǎng)絡的信息，同時無法針對大范圍的數(shù)據(jù)進行趨勢分析和統(tǒng)計，而使用Hadoop+HBase，提供了一條具有可伸縮性、低成本的海量數(shù)據(jù)解決思路。Hadoop+HBase可以廣泛地應用在告警、性能以及日志信息的存儲和處理上。

4.2 分布式網(wǎng)管基礎架構

從上面的討論看，服務總線的引入會在系統(tǒng)性能上帶來瓶頸，因此為適應網(wǎng)管系統(tǒng)的特點，需要采用分布式系統(tǒng)架構，演進過程如圖8所示。

圖8 分布式架構的演進

針對網(wǎng)管云的建設，并吸取過去網(wǎng)管系統(tǒng)統(tǒng)一協(xié)議的經(jīng)驗教訓，集約式網(wǎng)管應該采用一種輕量級的分布式系統(tǒng)架構來進行部署。這樣的輕量級分布式網(wǎng)管基礎構件包括：命名節(jié)點、基礎服務節(jié)點（base node）（其中分為日志服務（審計）、安全服務（鑒權）和事件服務（告警/性能））、服務節(jié)點（service node）、應用節(jié)點（App node）。

所謂輕量級,就是基礎架構不在協(xié)議層保證負載均衡、不在協(xié)議層保證事務一致性、不在協(xié)議層保證數(shù)據(jù)完整性，依賴于各自的應用解決相應的問題。這在一定程度上降低了基礎架構對應用的要求，應用的開發(fā)難度降低。

服務節(jié)點首先讓命名節(jié)點注冊服務信息，應用在調用服務之前向命名節(jié)點查詢服務訪問節(jié)點，之后應用直接向服務節(jié)點發(fā)起服務調用，如圖9所示，服務節(jié)點和命名節(jié)點就構成網(wǎng)管云。

分布式網(wǎng)管的基本過程包括服務注冊、服務查詢、服務調用，如圖10所示。

5 結束語

根據(jù)筆者長期從事OSS建設的經(jīng)驗教訓，按照網(wǎng)管云方式建立的扁平化綜合網(wǎng)管系統(tǒng)是最適合網(wǎng)管特點的系統(tǒng)建設模式，也是最符合OSS未來發(fā)展趨勢的。從“物理統(tǒng)一”的集中建設模式到“邏輯統(tǒng)一”的云化建設模式，關鍵是將所有網(wǎng)管的集合作為一個大系統(tǒng)看待，而不是系統(tǒng)的集成，這一點是觀念上的一大變革，是對傳統(tǒng)模式的挑戰(zhàn)。但電信運營商在“去電信化”和互聯(lián)網(wǎng)企業(yè)化的過程中，在IT系統(tǒng)建設的模式和思路上也需要互聯(lián)網(wǎng)應用化。

當然云計算不是萬能的，現(xiàn)在也還是模式的問題，落實到具體的系統(tǒng)建設，網(wǎng)管云還有很多技術問題需要解決，海量數(shù)據(jù)的處理和性能的提升仍是需要面對的難題。但從互聯(lián)網(wǎng)技術發(fā)展的歷程上看，技術革新是不可逆轉的，只要積極擁抱這樣的變革，未來一定會取得回報。