渠 凱 ,李 洪 ,彭志婷 ,申文俊
(1.中國電信股份有限公司網絡運行維護事業部 北京 100032;2.中通服軟件科技有限公司 上海 200127)
電信運營商都經歷了網絡的快速發展期,在這個過程中為了滿足快速發展的需要,運營商引入了很多不同的廠商以加快網絡的部署建設,同時網絡的不斷發展也帶來了網絡設備、技術的不斷革新和變化,導致電信網絡普遍存在設備多、廠商多、技術多、專業多、網絡多的現狀。
網管系統是伴隨著網絡發展起來的,而運營商在建設網絡時又往往要求廠商為一套設備提供一套網元管理系統,于是可以看到,在整個網管領域中網元管理系統(element management system,EMS)繁多,有的甚至一兩個設備也建有一套EMS,這不僅帶來了巨大的維護工作量,同時也給跨廠商、跨網絡端到端的網絡管理帶來了難題。運營商很早就意識到了這個問題,因此,在過去一段時間里,從專業網管到綜合網管也一直是其關注的重心。
隨著電信的發展,集約化運營的訴求日益強烈,體現在網管領域,就是對網管的綜合化和集中化的要求,這也是未來建設智能網管的基礎。過去一直困擾于多專業、多廠商、多設備信息難以統一的問題,隨著智能網管的到來,又增加了更多的難度和要求。因此必須要尋找更合理的方式,既能夠刻畫目前存在的多元網絡,同時又能夠適應未來不斷變化的需求,即本文探討的問題。
網管信息首先是設備和網元信息,在IT系統中為描述這些信息,通常會通過數據建模的方法在數據庫中保存,這種數據模型被稱為實體(entity)-關系(relation)(ER)模型,即將所有的數據都歸為兩個大類:實體和關系。其中實體是物體存在的客觀描述,關系是實體與實體之間的聯系。
過去的網管建設中,由于EMS是分廠商建設,專業網管又歸口相應的分專業管理部門建設,因此這些系統大多只關注本專業、本網絡甚至本廠商的設備,在數據上也只考慮本系統內的數據,多采用簡而化之、分而治之的建模思想,將每種設備都獨立地映射為一類實體,分類和映射都由網管系統自行確定,有的分類甚至細分到型號。
通過傳統的按專業分類的方式,可以得到如表1所示的示例。

表1 傳統按專業分類示例
從示例可以看到,很多網管按專業—分類—類型將設備類型映射為一種獨立的實體來進行管理,這種方式被稱之為“硬建模”。“硬建模”的方式就是簡單地將在自然世界中看到的事物分類直接映射為IT系統的一類實體,一一對應。這種建模方式更像一個對象枚舉的過程,需要把現實世界中的事物窮舉出來,否則很難保證分類的完整性。而且一旦有新的事物出現,無法歸入現有的類別,就勢必要增加一種實體才能描述。比如有轎車、貨車、客車3類實體,當出現跑車的時候,發現它不能歸到現有的實體里,必須得增加一類新的實體叫“跑車”,而如果在這一粒度上建立物理模型,就會發現每類實體都會建立一張實體表,多一類實體就會多一張表。
另一個方面從ER模型觀察,由于關系是建立在實體與實體間的,對于N類實體來說,關系的種類理論上可以達到C2n+1=n(n+1)/2種,因此隨著實體種類的增加,關系種類將呈二次冪級數增長,其直接后果就是數據表眾多,模型極不穩定:只要增加一種新的實體,就要增加一張表,只要增加一張表,就要增加多種實體間關系;而按照對象關系映射(object relational mapping,ORM)原理,應用方面也必須同時增加對新實體、新關系的處理。
隨著網絡和業務的發展,這種建模方式將必然導致模型的不斷膨脹,應用也會隨著不斷修改而增加。開發人員會覺得需求在不斷變化,而客戶則會覺得需求響應太慢。這樣不斷地修改、打補丁,不斷增加實體和關系,在網絡快速發展的今天,最終會引發實體和關系的爆炸,系統再也無法承擔負荷,只能再建設新系統。如果不改變方法論,這樣的場景會周而復始,不斷出現。
在過去的幾年中,筆者一直在探索一種更為靈活的物理建模方式,一方面能夠適應不斷變化的網絡和應用的需求,另一方面又不至于產生實體和關系的爆炸,使得模型相對比較穩定。
從方法論上看,一般數據建模的過程分為4個步驟,如圖1所示。
(1)識別目標場景的數據需求。
(2)以數據需求建立實體的概念模型,理清概念實體間的關系,形成ER圖。

圖1 一般數據建模過程
(3)基于ER關系對實體進一步分解和細化,設計數據的邏輯模型,體現實體及關系的分類和繼承。
(4)基于實體分解,建立實體的數據存儲模型,設計數據庫表結構。
分析過去的建模過程,可以發現對于目標場景的識別沒有問題,以中國電信對網絡的經驗,理解場景需求基本沒有偏差,但是從目標場景到概念模型、概念模型到邏輯模型、邏輯模型到物理模型的過程,就會發現以往缺乏合理的抽象,比如前面提到的“硬建模”,就是將目標場景直接映射到模型的結果。
其次,分析在電信業里比較成熟的模型,比如SID模型以及中國電信OSS 2.8規范模型。筆者發現這些模型雖然對網絡的概念進行了抽象,在實體繼承和分類上也給出了方法,但是這些模型都僅僅停留在邏輯模型這一個層次,對于從邏輯模型如何轉換到物理模型既沒有給出方法也沒有給出指導原則,導致在具體實踐中,人們往往依照自己的理解從邏輯模型中直接映射為物理模型,實際上是另一種程度的“硬建模”。
因此,在統一建模方法中,必須強調抽象的價值,將抽象與驗證結合起來,如圖2所示。

圖2 統一建模方法過程
經過一定抽象后的模型將更具有代表性和普適性。但是也需要注意到目標場景的范圍,抽象必須保留在合理的范圍,高度的抽象將帶來處理的復雜性,因此需要在抽象與現實之間選擇一個平衡點,既提高模型的抽象度和穩定度,也考慮相當的易用性,而不至于過度泛化。
網管領域的數據建模是電信網到IT系統的抽象過程。什么是電信網?按照百度百科的解釋,電信網是構成多個用戶相互通信的多個電信系統互連的通信體系,是人類實現遠距離通信的重要基礎設施,利用電纜、無線、光纖或者其他電磁系統,傳送、發射和接收標識、文字、圖像、聲音或其他信號。從這個定義可以看出電信網絡實際是由具備一定電信能力(傳送、發射和接收信號)的設備、設施、系統等實體組成的可相互聯通的網。
因此,基于以上對電信網的認識,筆者認為目前的分立網絡是電信網按照不同的能力劃分出來的,具有不同能力的設備、設施和系統。依照這個假設,可以放棄傳統的“分而治之”的“硬建模”方式,基于一套抽象的模型統一管理各專業網絡,按照能力的不同區分不同類型的實體,采用“從共性→個性”的分專業建模思想,先不分專業刻畫共性,形成電信網的統一模型,再通過刻畫個性,還原專業網絡的現實復雜性,以此保證核心數據模型關系穩定、緊密且關系四通八達。

圖3 實體與關系繼承示意
對于電信網來說,其關鍵的特性是形成網絡,而形成網絡的基本元素是點和線,因此可以從點、線、網為基礎擴展網絡模型,這樣可以將ER模型進行層次擴展,如圖3所示。左邊是實體的繼承圖,右邊是關系的繼承圖,黑色加粗線條表明關系是建立在對等的兩個實體之間。從E抽象實體出發,依據點、線、網擴展,可以得到點→設備→SDH設備這樣的繼承層次,同樣也可以得到點—線→端口—電路→SDH端口—傳輸電路這樣的R抽象關系的繼承層次。這是兩棵實體與關系繼承樹。
下一步,當把這兩個繼承的層次關系再進行表達,就得到另外兩棵繼承樹,如圖4所示。
圖4的ET/RT兩棵樹就是用來描述實體與關系繼承關系的,即元數據。進一步思考,實際上是將模型建立在樹的葉子節點上,也就是“硬建模”的方式,不管是實體還是關系,節點數都非常多,而一旦將模型向上移一層,可以帶來模型的巨大簡化。但問題是模型抽象后,細粒度的差異化信息如何體現?這就需要用到ET/RT這兩棵樹來描述。
因此筆者的策略是在大類基礎上,引入元模型建模,通過元數據的配置定義細粒度數據模型,使得細粒度數據模型靈活、可擴展。模型是對現實世界的抽象,而元模型是對模型的抽象和描述,軟件可針對元數據編程,快速實現新需求。即通過大類+元數據的建模思路,根據網絡共性,抽象出核心領域模型,通過元數據支持個性化特征,支持具體網元、鏈路的創建和配置。帶來的好處顯而易見:
·核心模型穩定,反映網絡本質;
·信息查找全、速度快;
·外圍模型可根據不同新業務、新技術進行配置,快速支持新客戶、新業務。
統一建模方法論是理論基礎,有了這個理論基礎,如何將網管要管理的對象抽象出大類來呢?
正如綜合資源的大類建模經歷了一系列歸納的過程一樣,其現有的模型是值得借鑒的,除此以外,需要描繪綜合網管的主要應用場景,分析在應用場景中綜合網管提供的基礎功能。例如局數據的作用場景,網管配置是一個過程,局數據體現為配置到網元上的所有配置數據。下面以網元為例,簡單描述一下網元的生命周期以及局數據的作用場景,如圖5所示。
·工程:綜合網管里,資源系統作用于工程建設,在工程建設中創建設備,設備上電后,EMS建好,形成網元。出廠的局數據配置在上電的時候配好。上電時,綜合網管采集到的非結構化數據,便是設備的出廠配置。資源和網元的關聯關系可在工程建設結束的時候,把網元回填回資源。
·建設:即內部組網,從資源系統下工單到網管施工。在組網的時候要保證資源和網元已經對應上了。網元的組網在資源系統完成。網元的施工就是在網管里面完成網元的配置過程,再下發給EMS完成網元的開通。工單所帶的局數據,最終的結果體現為結構化數據——在綜合網管中新增的實體和實體關系。

圖4 類型繼承示意

圖5 網元—場景流程示例
·配置:即外部組網,其過程和內部組網類似。
·割接:老的設備斷電后,將新的設備上電,局數據沒有在新的設備配置,這時要恢復局數據,需從綜合網管獲取原來的局數據,下發數據到EMS執行。
以此類推,可分析出電路、系統等的應用場景。
在考慮模型之前,首先需要分析需要建模的數據有哪些,除網管本身管理的業務對象外,在統一建模方法論的基礎上,業務對象對應到業務模型中已經過高度的抽象,業務對象和物理存儲并不是“硬建模”方式的一一對應,物理模型只能反映出實體抽象后的結果,因而還需要元數據刻畫實體的定義以及實體的存儲,即通過元數據的刻畫,反映出在物理模型高度抽象和穩定后,各類實體及規格的差異,對于代碼來說,只要通過訪問元數據就能夠知道不同規格的定義以及存儲,可以屏蔽業務對象的各種差異提供標準的元數據服務。另外,對于業務數據,有些是可以規范定義的,例如可以枚舉的屬性值,這些約束需要通過主數據來定義。除此以外,要建設一個應用系統,有其必不可少的系統數據和應用數據來支撐系統的完整功能應用。
因此,網管所要管理的數據范疇有以下幾種。
·元數據:與實體定義、存儲有關的類型數據。
·主數據:與規格有關的可規范定義的枚舉、約束數據。
·網管數據:存量數據、增量數據。
·系統數據:系統用戶、權限、審計、功能相關數據。
·應用數據:表現層數據,與界面、操作相關的對象。由于篇幅有限,本文針對網管數據的建模來探討。
3.2.1 大類繼承關系
建模的頂層即為上文描述過的網管的管理對象:實體和關系。實體和關系都可以繼承。樹上的一個節點決定了一類對象,具備特定的存儲位置。從數據的幾何結構往下分,實體可以有點、線、集合,關系可以分為點—點關系、線—線關系、點—線關系以及集合和點、線、子集合的關系。在此思路之下,從實體的功能本質以及大類間關系的收斂出發,定義出第3層的大類。數據建模在第3層上,因此需保證第3層的大類的抽象合理、收斂、穩定,并和實踐論證切合。
另外,根據前述現實依據的梳理,需知哪些數據的生命周期是在網管域中管理的、其主數據是在網管維護的,哪些數據的生命周期是在其他域中管理的、其主數據是在其他域中維護的,而網管只是因為一些應用需要,將數據同步過來供上層應用使用。例如機架、機框這類硬件數據,又或是站點、子區域這類區域數據以及機房這樣的設施數據。
抽象出的網管對象如圖6所示。
3.2.2 大類之間關系
如上述方法論所提到的,關系的建模是從第3層開始,在繼承圖(圖6)的第3層之間建立穩定的關系模型。圖7中的網元核心、事件、配置這三大塊為網管著重關注的模型,資源關聯域和產品服務域屬于關聯域。關聯域表現為從各域視角觀察網管存量所得到的投影,通過此投影可以關聯存量實體在不同域的視圖。
上文對數據模型進行了抽象,在方法論中提到抽象的結果需要進行驗證,下面對抽象的結果進行簡單的驗證。這里只做合理性驗證,復雜的、完備性的驗證需要全面的網絡數據,本文就不再深入。
首先,以交換網管為例,交換網元、交換板卡、交換端口可分別對應到模型中的網元、模塊、端口大類中,而交換網管中的平臺屬于系統的范疇,可對應到模型中的網這個大類。兩臺交換網元中的信令、中繼鏈路都是線形實體,可統統歸到鏈路這個大類當中。中繼群、信令鏈路組作為鏈路集合仍然呈線性,依然可以放在鏈路實體中。而中繼群和中繼鏈路的管理則體現為鏈路和鏈路大類中的并聯關系。交換網管中,網元上配置的碼號數據是局數據中的一種,可放到碼號大類中統一管理。
然后分析數據網管,數據網元、數據板卡、數據端口依然可以對應到模型中的網元、模塊、端口大類中,而數據網中的ATM電路、DDN電路、FR電路等也都是線形實體,可統統歸到鏈路這個大類當中。而數據網管中的各種ATM網絡、DDN等屬于管理網絡,另外VPN屬于虛擬網范疇,仍然是點—線集合,都可放在網這個實體中統一管理。還有一類用于實現用戶和業務的隔離、標識、管理和控制的數據,像VLAN,實際標識了一條鏈路或一個網絡劃分出來的數據通道標識,若管理上要求細化,可作為網實體管理,若管理上只需要管到VLAN號,可作為像碼號一樣的局數據放在碼號這個大類中管理。
在此基礎上,如果有交換和數據合一的網元,需要融合建模,建模方法也是一樣。例如,一個既有寬帶板又有語音板的ONU設備,當網管融合后,依然可以作為一個融合的網元放在網元大類中建模,而其中的寬帶和語音板只是作為網元所具有的兩個模塊建模,而無需像傳統的網管分專業,在交換網管和數據網管中分別建立各自的網元實體。
以此類推,傳輸網管、EPON網管抑或是基于IP技術的傳輸網管都可以用類似的方法建模,因為這是高度抽象了網絡的幾何本質的大類,不因為網絡技術發生改變而改變,只要分析實體在網絡中的存在本質就可以找到模型中對應的大類,非常穩定可靠。
在OSS領域中,對于網絡數據方面,不管是數據的規模還是數據的重要性,資源域和網元域都是最關鍵的部分。從數據的整個生命周期來看,這兩者是密不可分的,但也各有側重點。
資源域管理資源數據的整個生命周期,用于支撐整個電信網絡從設計、施工到開通、運行和退網完整的過程,希望在IT系統里再現真實網絡的生命過程,并支持它的變化,因此資源域重在描述網絡組成。


圖7 網管對象關系
網管域是網絡能力的體現,更關注網絡的現態。網管的操作直接即時反映到現實網絡,同時現實網絡的變化也即時反饋到網管,引發網管數據的變化,因此網管域重在描述網絡能力。
過去更傾向于關注資源域和網管域的差異,因此這兩個部分的建設和管理都是分離的,一定程度上導致了這兩部分數據的不一致,包括數據模型不一致。
在智能網管發展的今天,網管需要從綜合化到自動化再到最終實現智能化,OSS數據綜合化已成為智能化建設的基礎,而融合建模使這一目標成為可能,這里的融合不僅包括專業融合,而且站在OSS的高度看跨域也需要進一步融合。
從核心模型的穩定性為主出發,筆者建議建模時應從網絡結構出發考慮網管的管理對象在網絡組成中的本質差異,避免將業務因素混淆到建模的本質要求中去,區分哪些是組網的基礎,哪些是應用的需要。
在對網管融合的模型建議中,筆者著重描述了網管數據的模型建議。對于元數據、主數據、系統數據、應用數據的建模沒有關注。特別是元數據的建模,是支撐網管融合后的統一建模的基礎。
網管融合后的統一建模,模型中的大類和大類關系趨于穩定,不穩定的部分如大類細分后的細粒度類型的屬性及細粒度實體間關系約束等可通過元數據的靈活配置來體現。元數據模型是對實體模型的建模,考慮元數據模型的建模時,需明確實體構成,例如類型、規格、組件、擴展等。元數據的本質是關于數據的數據,元數據的內容包含了數據范圍、數據部署和數據結構。
總的來說,建模思路是指導模型建立的方向,網管融合建模更需要從以往紛繁復雜的多個凌亂的管理對象中跳脫出來,從網絡構成本質出發,抽象出穩定的數據模型。
1 TMF.The Information Framework(SID)V13,2013
2 中國電信集團公司.CTG-MBOSS OSS網絡資源管理系統規范 V2.8,2009
3 周三保.淺談數據倉庫建設中的數據建模方法.http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0803zhousb/,2008