鵝廠網事：網際網路時代需要怎樣的網管？

本文轉載自微信公眾號“ 鵝廠網事”(ID：tencent_network)，作者：王福。

近十年通訊和網際網路行業飛速發展，人們可以體驗越來越豐富的網際網路應用，從文字、圖片到語音、影片，但萬變不離其宗，Internet服務從根本上由兩部分組成：管道+內容。最初，管道由運營商包辦，內容提供商將自己的伺服器接入運營商機房，甚至直接將業務部署在運營商伺服器上，但是隨著業務發展，這種方式逐漸無法滿足需求，內容提供商內部的互聯互通需求，使得初具規模的內容提供商開始自建/整租機房(IDC：Internet Data Center)和機房間的內部互d聯管道(DCI：Data Center Interconnection)，這便是網際網路公司的運營網路，脫胎於電信運營商網路，但又有不同，同樣，網際網路絡網管系統也是類似。
一、運營商網管簡介

運營商網管基本基於TMN(Telecommunications Management Network)模型構建，TMN相關介紹的文章很多，本文不展開詳述，其總體思路為：將網路管理系統的功能分為如下四層：

網元管理層(Element Management Layer)：提供單個網元管理，包括網元的Fault(故障)、Configuration(配置)、Performance(效能)、Security(安全)等特性，在運營商網管體系中，網元層管理系統主要由網路裝置廠家提供，從而遮蔽不同廠商之間的私有MIB以及命令列的差異，當然，從實際情況看，這種差異遮蔽做的並不好，導致上層系統整合很困難，EMS(Element Management System)面向使用者主要為運營商網路運維人員及廠商代維人員。

網路管理層(Network Management Layer)：提供對網路層面的管理，同樣也包括網路的健康狀態監控、網元間的故障相關性分析、故障處理工具、網路保護及路由排程控制等，由於網路管理層和網元管理層乃至網元裝置間耦合度較高，以及運營商軟體開發能力欠缺，所以NMS(Network Management System)也通常由網路裝置廠家提供，面向使用者也主要為運營商網路運維人員及廠商代維人員。

業務管理層(Service Management Layer)：又叫運營支撐層(Operation Support Layer)，主要支撐運營商將網路作為一種服務提供給使用者，主要包括：網路資源及資產閉環管理、使用者業務實際開通及運營(計費、流統、行為分析等)、網路及業務健康狀況監控、以及異常/故障處理和跟進。另外，由於EMS和NMS對廠商的差異性遮蔽不好，以及運營商基於成本考慮，引入多廠商混合組網，導致跨廠商的告警收斂以及多廠商的底層差異遮蔽，也作為OSS的重要特性。由於其複雜性以及多廠商混合組網的存在，使得單一裝置廠家很難提供整套OSS，所以這個細分市場主要由傳統軟體服務提供商提供，海外主要是IBM、HP這些傳統巨頭，國內如合力金橋、中盈優創、神州泰嶽等。面向的使用者為運營商的網路及業務運維人員。

事務管理層(Business Management Layer)：主要是針對運營資料的分析和沉澱，找出規律，供高層決策或驅動ERP/CRM系統進行最佳化。其系統被稱為BSS(Business Support System)，主要構建模式為使用者定製，面向使用者主要是運營商資料分析或決策人員。

網際網路絡管理系統的架構，其實也類似，都是基於TMN的模型演變而來，具備FCAPS的大部分功能，但是和傳統運營商網管相比，又有些區別，其差異的根本原因，是由於現代網際網路公司與傳統運營商的差異造成，下面從如下幾個維度來簡單聊聊二者異同。

二、網際網路時代網路特點

(一)海量網路高效運營

從行業發展看，網際網路行業處於高速發展的時代，業務對於網路頻寬的需求，導致網路規模快速擴大，動輒數萬臺裝置，數百G流量;同時，基於成本考慮，對網路運營人員規模和生產效率也有更高期望，能夠重複的事情繫統做，複雜的事情簡單做，提升效率，用更少的人做更多的事，滿足海量網路高效、穩定運營的需求。

(二)差異化和精細化

從網路架構看，網際網路絡主要包含幾部分：分佈於各處的IDC、將IDC互聯的DCI、和運營商互聯的出口、以及和其它企業互聯的ECN網路等。一方面，不同層次的網路，具備不同特質，使用不同技術，例如：DCI在跨城間互聯的主要挑戰是多業務承載以及差異化流量服務，所以這部分使用MPLS承載，而城域內則使用IP承載即可;另一方面，由於業務的不同要求，使得網路使用不同技術應對，例如：有的IDC使用大二層，有的IDC則是三層網路。不同的網路結構，在提供通用監控和管理的同時，也需要提供差異化和精細化管理能力。

(三)業務靈活排程

從業務需求和成本看，一方面，業務希望網路提供儘可能多的冗餘和備份，一旦發生問題，可以快速排程，保障使用者體驗，另一方面，流量不均衡導致不同鏈路利用率參差不齊，期望可以透過靈活排程，提升利用率，降低成本。所以，需要提供靈活排程能力。

(四)雲服務

從發展趨勢看，由於雲服務的推廣和普及，雲服務提供商也需要將使用者相關的網路管控能力向使用者開放，所以，網管還需要提供服務封裝能力。

三、網際網路時代需要怎樣的網管

具備如下特質

● 針對海量網路管理需求，提供高效、穩定的運營能力

● 針對不同網路架構和技術，提供差異化和精細化管理能力

● 基於使用者體驗提升和成本考慮，提供靈活排程能力

● 隨著雲時代到來，提供管控服務對外封裝能力

(一)海量網路監管控

海量網路主要具備以下特點和挑戰：

1.海量監控

挑戰一：海量資料採集

◆ 從監控維度看，想要對網路進行全方位管理，需要從點線面三個維度進行全方位監控，細化到監控指標，則有數十個之多(例如：CPU/記憶體/流量/包量/丟包/錯包等)。

◆ 從監控物件看，需要在固定週期內(例如：5分鐘)對全網數萬臺裝置都檢測一遍。

◆ 從實現方式看，SNMP採集、telnet採集、主動探測等多種技術方式都需要用到。

◆ 如此海量情況下，單臺伺服器基本不可能完成全網監控任務。

應對：分而治之

採用分而治之的思路，首先需要按功能拆分成子系統，例如：SNMP採集子系統、telnet採集子系統、質量探測子系統等，對於每個子系統，都需要提供分散式架構，底層採集器/探測器按需分佈，靈活擴充，採集/探測到的資料，初步處理和壓縮後，提交給中央二次處理，這樣可以提升採集、處理能力，也可以平滑支援網路擴充套件。

挑戰二：海量告警處理

採集到的監控項，經中央處理後，除了直接展示(例如：流量圖、質量曲線等)，更重要的是對其進行判定，匹配到異常則轉換為告警，通知NOC處理。

運營商的架構一般分為集團公司、省分和地市，所以網路也通常是按這個模式來運維，即：一張網由多個組織分層維護，由於運營商人力較多，所以對告警最重要的需求是告警要全，不要漏告，對收斂需求較少。

但大型網際網路企業則不一樣，裝置數量不亞於國內主流運營商，但是網路比較扁平，統一由NOC集中運維，人員數量相對於運營商不在一個量級，面對每天數萬乃至十萬量級原始告警，如果沒有工具系統對其進行強有力的收斂，全手工很難運維。

應對：告警收斂，關注根因

針對每種故障場景，告警收斂的邏輯各不相同，但是萬變不離其宗，一個核心的原則是：將告警進行分層，基於配置資訊，不同層次之間實現縱向收斂，同層次內實現橫向收斂。例如：傳輸告警縱向收斂鏈路狀態告警、本端鏈路狀態告警橫向收斂對端鏈路狀態告警。

要實現這樣的收斂能力，有兩個關鍵點需要關注：

◆ 配置準確性(如何保證參考配置管理章節)。

◆ 提供通用收斂框架，基於通用框架，快速開發、不斷累積收斂規則。

目前鵝廠已經累計數十種收斂規則，可以將每天上萬條告警收斂為數百條，並且還在持續精耕細作。

另外，從長遠看，這種模式終歸需要人工干預，後續也在考慮引入人工智慧，由系統根據現網運營情況，自動學習規則，然後基於規則收斂。

2.自動化

網路不僅有監控，還有排障和最佳化，海量網路中，每天數十次trace測試，數百次VLAN切換，數千次策略開通司空見慣。一千個人眼裡有一千個哈姆雷特，但是如果讓你重複開一千次安全策略，估計你會瘋掉。所以海量網路，沒有自動化將寸步難行。

挑戰一：配置準確性

自動化的基礎其實是標準化，一方面是操作流程要標準，另一方面，基礎配置資料要準確，否則會做多錯多，所以第一個挑戰是配置準確性(如何解決參考配置管理章節)。

挑戰二：人機介面及廠商差異

由於SNMP對於裝置的控制能力很弱，自動化通常基於telnet/SSH協議，使用命令列和裝置互動，命令列天生是一種人機介面，現在強行用於被程式呼叫，在傳參、呼叫結束判別、回顯提取等方面存在很多挑戰。另外，考慮到成本問題，網際網路絡通常是多廠商裝置混合組網，由於眾所周知的原因，各廠商之間，甚至同一廠商的不同型號、不同OS版本之間，也存在差異。如何使人機介面為程式所用，並適配各廠家差異，是第二個挑戰。

應對：通用框架+差異封裝

要解決這個問題，首先需要有一個框架，將任務封裝、命令列組裝、執行、結果解析、異常處理等公共部分抽象出來，各自動化任務都使用這套公共框架執行，對於各廠商命令列的差異，則採用模板的形式來遮蔽，同一個任務，不同廠商對應不同的同名模板，上層應用只關注使用哪個名稱的模板，具體執行時，框架根據對應的裝置型號或廠家來選擇某個具體模板執行。這種外掛式的模板是可配置的，新裝置引入時，針對該裝置型號配置對應的新模板即可，無需修改應用和框架。

目前這種通用框架+模板的方式，已經在鵝廠自動化工具中廣泛應用，按網路生命週期劃分，主要包含以下幾類：

◆ 建設類：IDC建設流程自動化，主要包括自動生成裝置拓撲和配置、自動轉運營驗收等。

◆ 運營類：伺服器部署自動化、安全策略開通自動化、鏈路除錯自動化、OS升級自動化等。

◆ 排障工具類：主要針對常用故障場景，如：多路徑丟包排查、traceroute分析、靜態路由分析等。

據不完全統計，鵝廠網管年執行超過150萬次自動化任務，修改裝置配置近千萬行。

另外，隨著精細化運營的深入，自動化工具需求越來越多，工具製造能力正逐漸成為瓶頸，我們也在嘗試提供一個通用平臺，封裝常用原子操作，讓使用者以搭積木的方式，自行製作工具。

3.配置管理

挑戰：配置準確性

如前面所述，配置管理是海量網路自動化運營的基石，告警收斂效果以及自動化工具運轉的結果，很大程度上依賴於配置資料的準確性，所以最關鍵的挑戰是如何保證配置資料的準確性。

應對一：自動採集

一方面是配置自動採集，現網數萬臺裝置，數百萬配置項，如果全部人工錄入，效率和準確性都無法保證，所以，在有了固資、管理IP這些關鍵資料後，其它可以從裝置上獲取的資訊，如：埠狀態、速率、IP等，則由系統自動採集併入庫，而無需人工處理。

應對二：閉環流程

另一方面，關鍵資料還是需要手工錄入，另外配置資料在現網運營過程中，會發生變化，這些變化需要實時體現在配置系統中，所以需要有閉環流程，針對配置發生變化的各種場景，提供線上流程及驗證，保障閉環操作，從裝置准入、建設、最佳化、運營、排障、退役等生命週期管理全過程，提供完備的端到端流程，杜絕垃圾配置資料產生。

應對三：週期審計

最後，即使再完備的流程，再細心的人，也會有異常產生，從而導致配置資料的準確性問題，所以需要提供雙保險：配置審計，用技術手段分析現網資料，和配置系統資料進行審計，從而發現異常。配置審計主要分幾類：一類是裝置狀態審計，如裝置狀態是否異常、管理IP是否存活等，透過這類審計保證裝置可訪問以及管理IP和固資對映的準確性;另一類是資產資訊審計，如：裝置及部件的數量和SN等，透過這類審計保證整機、部件的狀態和對應關係;還有一類是運營類審計，如：裝置OS版本、是否命中已知問題、帶外通道是否異常等，透過這類審計保證運營風險及時發現。

鵝廠數萬網路裝置，數十萬伺服器，數百萬配置項，透過自動採集+流程+審計的方式，目前配置準確率穩定保持99.99%。

4.容量管理

容量管理的理想情況是，業務的邏輯和分佈與基礎架構的能力和規劃完美匹配，如同一個完美規劃的城市一般交通永不堵塞;然而理想雖豐滿，有幾點因素，導致現實只能是骨感的：

多種挑戰

挑戰一：基礎資源不可控

基礎架構資源如伺服器、機架、電力、頻寬的供給並非自己可控，受制於供應商、運營商等各種外部環境，資源按期或快速交付的壓力非常大，甚至無法按需提供;

挑戰二：業務發展難預測

網際網路業務發展充滿不可預測性，導致對資源的需求也是難以準確規劃，資源的供給一旦脫節，只能在規劃上做出妥協，優先保障上業務，導致業務的分佈不是最優的;

挑戰三：業務部署難規劃

網際網路企業內部各業務之間，往往因為缺乏統一規劃和協調，導致業務按各自規劃來部署，而業務之間其實是有互動的，尤其平臺型業務和應用型業務之間，從而導致大量穿越流量產生;

由於前述的種種因素，網路會變得不均衡，出現區域性容量熱點。那麼如何解決?

應對一：業務流量分佈資料的獲取能力

首先，需要我們具備瞭解業務流量分佈特徵資料的能力，某個業務，在各IDC的分佈情況，在IDC內/城域內/跨城間產生了多少流量，分別流向哪些業務等。

這些資料可以從netflow和serverflow採集的會話資訊中提取，會話資訊中最少需要保留源/目的IP、源/目的埠、協議等資訊，數十萬臺伺服器規模的網路，每天的會話量將有百億量級。如此大的資料量，第一個挑戰是如何實時採集和處理，這裡需要用到前面提到的分散式採集系統，底層分別採集，然後經過初步加工和匯聚後上報;第二個挑戰是如此大量的資料如何儲存和分析，傳統關係型資料庫很難滿足高併發的讀寫效能要求以及高可擴充套件性要求，所以需要考慮使用滿足極高讀寫效能要求的key-value資料庫，甚至使用其它現有的資料倉儲，利用大資料平臺對其進行多維度分析。

應對二：區域性熱點控制能力(事中)

具備了獲取業務流量分佈資料的能力後，我們可以迅速救火，在熱點發生時，找到導致熱點的異常業務流量，並提供控制和處理能力，避免異常業務流量對其它業務的影響。

應對三：基於容量管理的基礎資源規劃和分配能力(事前)

另一方面，從長遠看，可以建立穿越流量業務分佈模型，將其納入到業務規劃流程中，使得業務部署前，可以提前考慮資源規劃和業務規劃的更優匹配;另外，在業務部署後，相應的審計、騰挪最佳化也能有序的運作。

(二)差異化/精細化服務能力

如前面第三章所述，網際網路公司網路通常會包含如下幾部分：分佈於各處的IDC、將IDC互聯的DCI、和運營商互聯的出口、安全相關的網路裝置，另外可能還有一些特殊用途的網路。不同網路架構，提供的服務有差別，同樣，網管系統也需要對其提供差異化服務能力，從而實現精細化管控。

以鵝廠為例，除了DCI、IDC、出口、安全網路，還有和其它企業互聯的ECN網路、以及金融網路等架構。如下是幾個典型的精細化管理場景。

1.DCI

首先，由於鵝廠業務的多樣性，鵝廠網路實質是一張多業務承載網，文字/語音/影片多業務混跑，不同業務，對於網路的容忍度不一樣，所以需要提供差異化流量服務，使得網路擁塞或故障時，能夠根據不同優先順序提供不同等級的服務。這裡有兩個問題，一個是如何標示不同業務，另一個是對於不同優先順序的流量，如何排程。

業務流量標示

針對第一個問題，在海量網路的情況下，靠人來維護顯然不現實。鵝廠網管提供了一套自動打標系統，使用者可以基於業務模組維度在系統中登記(業務模組資訊一般不變)，系統根據伺服器的業務歸屬以及登記的優先順序，在接入層對其設定不同的DSCP值。對於伺服器的新增/下架/遷移/業務歸屬調整，都由系統自動發現並重新整理DSCP值。這樣對於指定的業務模組，使用者一次設定，系統後續自動打標。另外，從長遠看，這種模式解決了伺服器變化的問題，對於業務模組變化的問題，還需要人工處理，我們也在探討基於流的特徵來分析其業務歸屬，從而自動打標的可能性。

業務流量排程

針對第二個問題，我們使用QoS技術來區分不同流的優先順序，同時輔以SDN排程技術，對符合條件的業務流進行排程，從而實現業務流量的差異化管理。

2.IDC

IDC網路的最大特點是數量多，建設量大，所以重點聚焦規劃、建設、驗收的自動化。

規劃線上化

規劃線上化是基礎，將當前鵝廠主流IDC網路架構的相關規劃資料(架構版本、網路層級、適用裝置型號、埠及連線關係、IP分配規則、配置特性等)納入系統，進行結構化管理，所有建設專案以規劃規格為準，避免線下操作，導致規劃和建設不一致的情況發生。

建設自動化

基於結構化的規劃資料，建設自動化也就水到渠成，網路PE只需指定建設的架構版本、規模等資訊，系統自動生成網路連線關係，用於指導施工佈線;根據匯入的引數，以及IP裂解規則，自動生成配置檔案，進行上架初始化;在完成除錯後，自動進行多維度驗收(如：3A、ADS等)，從而保證建設正確性和轉運營質量。

3.金融/安全網路

安全網路主要聚焦安全漏洞發現、防火牆策略自動實施、垃圾策略審計等;

金融網路則因為其重要程度，需要提供更嚴格的操作審計能力、更快速的異常檢測/處理能力、並和業務指標聯動，實現更快速的響應。

(三)排程能力

網際網路業務，好的使用者體驗是關鍵，如何提供好的使用者體驗，一方面依賴於業務應用的互動設計，另一方面，則依賴網路提供永不掉線的穩定服務。為了達成這個目標，網路不僅需要提供冗餘能力，還需要在故障發生後，能夠自動、實時的排程。另外，基於成本考慮，網路建成後，也希望儘量提高利用率，在流量不均衡的情況下，靈活的排程需求成為必須。其實傳統運營商也是類似的要求，但是相對來說，網際網路企業今天面臨的競爭更激烈，對網路可靠性要求更高，對成本控制更嚴，所以要求排程能力更強、更實時、更靈活。

每個網際網路企業主營業務、網路架構、以及資源分佈都不太一樣，所以面臨的排程需求和場景也不盡相同，還是以鵝廠為例，從應用場景看，鵝廠主要在DCI網路上存在排程需求。

當前長途光纖資源的租用成本很高，由於流量不均衡，一方面，整體頻寬利用率低，成本壓力大;另一方面，區域性容量預警多，業務壓力大;更窘迫的是節假日突發流量，使得區域性熱點雪上加霜。此時更好的方案應該是合理排程，而不是擴容。其實傳統網路也有排程方法，如：MPLS TE autobandwith技術，但這些方法類似於每個路口的交警，根據路口情況獨立做出判斷指揮交通，但缺乏全域性檢視，無法得出全域性最優解。所以需要提供一個控制器，整合全網路徑資訊，集中算路，得到全域性最優解，使得流量以更合理的方式排程。這其實就是SDN的思路。

(四)服務對外封裝

通常網際網路網管的使用物件是公司內部網路運維人員，所以對於管控資料很少進行封裝和抽象，但是隨著雲時代的到來，網際網路公司的網路正在成為開放平臺，越來越多的企業在之上部署業務，所以將通用網路監控能力封裝為一種服務提供給內外部企業使用者，成為一種必須。

所以在傳統的採集層、資料層、應用層之上，需要提供一個面向業務的服務抽象層，該層主要實現如下功能：

(1)根據網管管控能力，抽象出服務場景。

(2)按服務場景，將管控資料或工具增加對應的業務資訊，從網路視角轉換為業務視角。

(3)統一封裝介面服務，供使用者呼叫。

四、總結

總之，網際網路時代的網管，需要關注以下幾個關鍵問題：

(1)海量網路運營所帶來的種種挑戰及應對，如：資料規模問題、告警如何收斂、自動化處理問題、配置準確性、容量管理問題等。

(2)不同網路架構所衍生的差異化和精細化管理能力。

(3)基於成本和使用者體驗考慮，提供靈活排程能力。

(4)開放平臺的管控服務封裝，將網路管控封裝為服務提供給使用者。

鵝廠網管正是基於此思路，結合TMN模型，打造出一個覆蓋網路規劃、建設、最佳化、運營、退役全生命週期的統一管理平臺。本文試圖管中窺豹，對其總結一二，希望可以對大家有所幫助，更希望可以拋磚引玉，瞭解各位業界同仁的真知灼見。