鵝廠網事：基於R.M.B的下一代網管系統

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

　　網管系統存在的價值，在於其自動化、智慧化管理大型網路的能力。隨著網路規模的增長，我們經歷過標準網路架構的批次自動化建設、海量狀態採集和監控、海量告警收斂的時代;再後來，業務需求的多樣性導致網路複雜度增加以及精細化運營需求井噴，催生了NetDevOps發展，使得網工可以快速靈活定製自己的應用;AI技術的興起，更讓NetAIOps成為新的熱點。

　　然而，隨著這些新技術、新方法的應用，我們可以說網路管理的自動化水平更高了，但是網路管理面臨的挑戰似乎並沒有收斂，不斷有更新更深層面的問題浮出水面。

　　比如在規劃建設階段，一個新網路架構設計出來，想要實現自動化建設，仍然需要很多人工定製化適配，例如：新架構的互聯方式需要由交叉改為口字，架構師需要將所有具體連線窮舉到系統上;又例如，新架構要求對所有埠開啟BFD特性，架構師需要窮舉出該架構的所有埠，然後對每個埠寫一遍開啟BFD的命令;諸如此類的人工強依賴必然限制了建設質量效率的水平。

　　又比如在網路運營階段，越來越多的指標被採集，流量/包量/錯包/佇列/快取等，甚至可以使用AI演算法搞定某些單指標的自動監控，但是這些單指標的異常，並不能直觀看到問題根因，例如：我們用AI搞定了流量變化的自動監控，卻不清楚A到B直通流量的繞行，僅僅是因為千里之外的“無關”裝置被敲錯一條命令列。我們有了很多監控、有了大量運營工具，但在複雜故障出現時，仍然時常發現力有未逮。

　　問題分析

　　為什麼會這樣?是因為網路結構太複雜、常變化?還是因為系統還不夠”聰明”?前者是客觀條件，後者並不能為我們指明方向。究其根因，還是因為網管系統對網路不理解，系統只是起了連線網工與裝置的通道作用，又或者針對某些固定場景，提供執行某些具體動作的能力，控制權還在人手中。在規劃和建設網路時，因為系統不理解語義，需要人工將網路架構設計(HLD)轉換為網路能夠理解的LLD(具體的連線關係、命令列等)，然後交由系統執行，因為HLD變化而導致LLD改變的工作量，呈幾何級數增長(一如前述交叉改口字、開啟BFD的例子);在運營網路時，由於系統缺乏對網路全域性的理解，無法從各種表象中找到問題根因，而經常變化的網路架構無疑對問題的定位和分析雪上加霜。

　　解決思路

　　如何解決這個問題?不妨設想一下兩個場景：

　　◆ 規劃建設階段，架構師只需要關注抽象的網路設計(HLD)，系統能夠識別這些抽象設計，並根據實際需求具象化為可落地的建設方案(LLD)，以此來應對需求的多樣性;

　　◆ 網路運營階段，系統基於網路的全量資料，能夠智慧分析各種狀態和行為之間的聯絡，找出隱患或問題，並自動解決、規避，縱使架構發生變化，系統能夠理解這些變化並自適應之。

　　我們繼續往下看，如何才能具備這樣的能力:

　　◆ 首先需要有一套方法，能夠結構化的描述整個網路的組成元素及相互關係，從網路到網元、機框、槽位、埠，乃至配置、狀態等，都能夠結構化描述，使得系統能理解網路語義;

　　◆ 其次需要有一顆智腦，一方面可以理解架構師的意圖，並將意圖轉換為可落地的方案，另一方面則能夠從各種網路表象的變化中，分析出真正的隱患或問題;

　　◆ 最後還要有一系列的自動化工具，供系統根據分析的結論，實現具體的處理邏輯，並且最終應用到網路中。

　　這些自動化”觸手”，我們稱之為Robot;這套使得系統能理解網路語義的方法，我們稱之為建模，建模最終生成的是系統可以理解的結構化模型(Model);能夠識別使用者意圖，具備分析問題能力的智腦，我們稱之為Brain;合在一起，就是今天要探討的R.M.B。

　

　　▲ 網管整體框架圖

　　1.【Model篇】

　　Model是一套可以結構化描述網路的模型，網路通常分為物理部分和邏輯部分，物理指組成網路的各種硬體(機框、單板、光模組、線纜等)，邏輯指各種軟體特性的配置(路由協議、管理特性、QoS等)，所以Model可以分為硬體模型和配置模型，以及執行過程中的狀態模型。

　　1.1【硬體模型】

　　硬體模型包含兩部分，首先是描述如何組網，然後是組網的網元具體由哪些硬體實現。

　　1.1.1【如何組網】

　　可以用一種抽象的方式來描述如何組網：

　　◆ 有哪些架構角色，例如：一個IDC內網，是接入/核心兩層，還是需要接入/匯聚/核心三層，每種架構角色的最大數量;

　　◆ 各架構角色之間應該如何互聯，例如：和哪些架構角色互聯，互聯單埠頻寬，最大鏈路數，連線方式用口字還是交叉，鏈路數需要滿足2的n次方還是等分頻寬，對底層傳輸的容災依賴等;

　　1.1.2【硬體實現】

　　透過設計組網的步驟，得到了對每臺裝置的埠數量和頻寬需求，根據這些需求，需要找到對應的硬體實現，主要包括：

　　◆ 有哪些硬體物料(機框、板卡、光模組等);

　　◆ 各物料之間的配套關係;

　　◆ 埠功能區的規劃，即：哪些埠用於連線哪些架構角色，例如：接入裝置的45~48號埠組成“To 內網核心”功能區。圖3展示了功能區的設計，每種顏色對應一種功能區。

　

　　▲ 硬體物料及配套關係定義

　

　　▲ 埠功能區規劃

　　至此，一款架構角色的硬體模型構建完成。

　　1.2【配置模型】

　　配置模型主要描述三個內容：

　　◆ 一臺裝置要完成設計的網路功能，需要配置哪些特性;

　　◆ 這些特性需要在哪些物件上開啟，物件可以是物理的(例如：某塊板卡/某個埠)，也可以是邏輯的(例如：某個BGP鄰居/某個捆綁口);

　　◆ 這些特性具體的值，例如：IP地址是多少，MTU配多少等;

　　網路發展到今天，各廠商的特性其實大同小異，使得一套統一的配置模型成為可能，一如OpenConfig組織提出的 OpenConfig YANG Model，這套Model描述了一個網路裝置應該有哪些物件，有哪些特性，這些物件/特性應該叫什麼名稱，是怎樣的資料型別，以及物件和物件，物件和特性之間的關係。

　　配置建模的構建，分為如下幾步：

　　◆ 架構師基於全量的Model(例如 OpenConfig YANG Model)，結合實際需求，選擇該架構需要使用哪些特性;

　　◆ 然後是架構師定義這些特性需要在哪些物件上開啟，和定義硬體模型類似，使用列舉並不是一種好的方法，需要對這些物件進行抽象定義，物理物件的抽象定義可以複用硬體模型中的抽象，例如：類似 “To MAN的所有埠”這種定義，邏輯物件其實也可以用類似的方法定義，例如：“所有互聯IP”，“所有BGP鄰居”，需要有一個專門的模組來管理這些邏輯物件，例如：IP管理、BGP鄰居管理等。

　　◆ 第三步，架構師定義這些特性的值，可以支援直接賦值，但更多的場景是定義賦值的方法，因為很多值在具體的建設方案確定以後才能生成，例如：某臺裝置的管理IP、某個埠的描述(通常是對端裝置名+埠名的組合)等。

　

　　▲ BGP配置模型

　　1.3【狀態模型】

　　狀態模型主要描述不同的網路物件，能提供哪些狀態監控的能力，由於OpenConfig YANG Model中描述了網路物件之間的關係，所以基於這套模型，將狀態監控項作為一種特性掛載其上，也是水到渠成的事情，實際上OpenConfig正是如此做的。

　　狀態模型的構建和配置模型基本一樣，不再贅述。

　　2.【Robot篇】

　　建模是網路自動化的基礎，硬體/配置/狀態模型結構化描述了網路中各種物件以及物件之間的關係，將網路轉換為一套抽象的模型，使得系統可以全域性的理解網路語義。一款Model Driven的Robot，其實質是理解這套模型，基於這套模型開發應用邏輯，透過對模型的增刪改查，從而實現對網路的管理。

　　2.1【如何快速構建Robot應用】

　　這裡有兩個關鍵點：

　　◆ 傳統的開發模式，針對每個具體的場景，從業務邏輯到資料結構以及底層的互動，全部自己實現，這種垂直式的開發，不僅重複造輪子，而且對網路的整體變化缺乏把握，基於一套統一的模型來開發應用，使得系統更容易理解網路整體的狀態，便於快速發現根因問題，另外基於一套資料模型進行開發，也使開發效率更快;

　　◆ 另外一個關鍵點是：基於模型開發的應用，輸出的是對模型例項的增刪改查操作，這些操作如何能轉換為實際裝置可識別的指令?當前網管與裝置互動協議繁多，SNMP/CLI/Netconf/rest API等，即使協議一樣，各廠商的具體指令也不盡相同，甚至某些時候，網管需要互動的物件是控制器而不是裝置，適配的工作佔用大量的開發時間，這就需要系統能夠提供一個平臺，根據裝置的實際能力，自動將應用生成的模型例項轉換為裝置/控制器可以識別的指令，從而遮蔽底層差異，應用開發者只需關注業務邏輯，快速實現各種自動化應用。

　　2.2【Robot應用場景】

　　從場景看，Robot可以應用於網路規劃建設和運營的全生命週期。

　　◆ 規劃建設階段：提供自動化建設系統，基於架構師設計的抽象模型，結合實際建設需求，系統能夠自動生成具體的建設方案。

　　◆ 基於硬體模型生成物料清單、安裝方案、連線關係等，用於指導採購、安裝、佈線;

　　◆ 基於配置和狀態模型則生成相應的配置和狀態例項，並最終轉換為裝置可以識別的資訊;架構師只需聚焦於網路的抽象設計(HLD)，具體的建設方案(LLD)由系統自動生成，以此來面對網路架構頻繁變化的挑戰。

　

　　▲ 自動生成的連線方案

　　◆ 網路運營階段：規劃和建設階段，網路的複雜性主要體現在方案的差異上，設計、生成方案的方法是通用的，但是運營階段則不盡然，不同架構、不同裝置、不同故障場景，業務恢復和故障處理的方式都不盡相同，網路的差異性在運營階段體現的淋漓盡致，這也是運營工具需求井噴的原因，這種工具相對獨立，相互間耦合不多，一個工具解決一個問題，並且會隨著網路情況的變化經常調整，在網管智慧化能力未全面覆蓋之前，大量的運營工具需求將長期存在。這也是我們推行NetDevOps的原因之一，基於Model的開發，無需自己定義資料結構，無需關注底層裝置差異，使得應用可以快速上線;使用Devops模式，減少了運營人員/產品經理/開發之間的溝通，使得Robot應用開發更敏捷。

　　總之，Robot主要聚焦各種自動化應用的實現，考慮到運營場景的多樣和變化，提供一套基於Model的NetDevOps平臺，讓運營人員快速DIY自己的Robot應用，是個不錯的思路。

　　3.【Brain篇】

　　Model提供了一套資料模型，Robot負責基於這套模型做事情，相當於手和眼，還缺一個大腦(Brain)來控制這些Robot，以前的大腦是人，人來控制工具的執行，要真正實現自動化閉環，還需要一顆智腦。

　　3.1【Big Data】

　　討論智腦之前，先說說資料，不論是人工智慧，還是大資料分析，都離不開海量的有效資料。傳統網路不論是資料實時性(SNMP/CLI只能支援分鐘級的採集)，還是資料完整性(當前主要是CPU/記憶體/流量/包量/丟錯包/光功率等指標， 缺乏對裝置底層例如晶片層面的監控)，都很難滿足大資料分析和AI對資料的需求。

　　所幸近年來透過業界的努力，秒級上報的telemetry技術已開始商用，可程式設計晶片+ P4語言的組合，使得更多晶片級的狀態可以被監控起來，而狀態建模則建立了這些狀態項之間的聯絡，使得大資料分析和AI具備了資料基礎。

　　3.2【Brain】

　　有了資料基礎，再來談談智腦，這顆智腦應該具備兩方面的能力：

　　◆ 一是面向網路的，能夠理解網路中的變化，並將各種錯綜複雜的變化，歸納收斂為具體的根因事件，這種能力常應用於故障定位、故障預防等場景中，透過智腦分析出網路的具體變化或變化趨勢，然後驅動Robot進行處理。

　　舉個例子：透過對狀態模型的分析，可以得到當前裝置狀態是否異常，將狀態異常的裝置找出來，然後根據拓撲、IP連線、協議鄰居等關係，透過一套計算聚合度的方法，可以找到這些異常裝置的中心點，這個中心點即為根因裝置，然後在根因裝置內繼續深挖，根據硬體模型、配置模型可以得到機框/板卡/埠/捆綁口/IP/路由協議這些物件之間的對映關係，將狀態異常的物件標示出來，則很容易找到本次異常的根因。

　　◆ 另一種能力是面向人的，智腦能夠理解人想幹預網路的意圖，並將其轉換為可以落地的方案並實施，這種能力常應用於網路變更場景中。

　　但這種對於人意圖的理解，還不同於前面提到的基於Model的架構設計和自動化建設，前者要求架構師還是要將HLD設計出來，例如裝置架構角色定義、互聯規範選擇、功能區定義等，這些事情還是需要很高的專業度才能做，然後系統將HLD轉換為LLD;基於意圖的網路則更加抽象，人更多關注的是需求，是要做什麼，如何做由系統來考慮。

　　還是舉個例子：業務需要在某個園區部署一批機器，人主要關注這個部署需求是否合理，系統能夠根據業務的歷史流量模型，分析出流量的頻寬需求，然後結合對現有網路的智慧學習或者人工內建的各種規則，自動生成擴容方案。

　　以上兩個場景，都依賴智腦的規則，這種規則可以是人工指定，也可以是基於AI自動生成，不論哪種方法，都需要實時、完整的網路大資料支撐。

　　總結

　　Robot是各種自動化應用，相當於網路管理的眼睛和手;Model提供了一套結構化描述網路硬體、配置、狀態的方法，使得系統能夠理解網路語義，快速開發Robot成為可能，同時也為Brain提供實時、完整的資料;Brain是大腦，基於大資料，用各種人工指定或者機器學習生成的規則，驅動各種Robot工作。下一代基於Robot.Model.Brain(R.M.B)的網管，將網路結構化、抽象化、智慧化，大大降低網路設計、建設、運營過程中人的參與，使得全自動網路管理成為可能。