1、本篇文章的目的：

• 分享一種網絡運維自動化的實現過程，針對包含大量異構網絡設備的組網環境。

• 運營商或者具有相似痛點的運維團隊；

• 希望轉型自主研發；

• 具備基礎python腳本編寫能力（入門快）；

2、背景和痛點

我先放兩張圖讓大家感受一下：

可以看到，無論設備數量和種類如何瘋長，負責網絡運維的一直只有四個人，老板一直無視我們的加人請求，老板一直非常相信我們的能力。

正常來說單純地增加設備數量并不會帶來多少壓力，而設備廠商的增多就是另一回事兒了，不同于X86服務器掛載相同的操作系統，網絡設備系統往往是封閉獨立的，有著截然不同的指令手冊，以及各種特殊的功能。總而言之，它們很難統一。

我再放兩張圖，是日常運維中很常見的場景：

故障定位，從出口路由器一直沿路查到用戶虛擬機是一件很常見的事情，這個過程中可能會經歷路由器、防火墻、三層交換機、二層交換機、負載均衡器等等設備（它們來自不同的廠商）

策略管理，刨去復雜的流程之外，不同的策略要定位到不同的網絡域中，要在不同的防火墻上做操作（也是不同的廠商）。

如果一開始就拿這些場景去做自動化，會無從下手，或者會寫出一大堆復雜重復的腳本來，效率不高；看過前面擁抱開源系列文章的同學可能會想到用現成的工具，例如Ansible，很可惜它不能管到這么多種設備。

看來只能自己動手了，接下來為了便于理解，我們不去想上面的復雜場景，用一個簡單但又耗時的小場景來思考：

先看一下手工要怎么操作：

緊接著第一個想到的肯定是寫腳本來實現：

不錯，我們已經把工作量壓縮到三個腳本中了，但是這樣的程度人人都可以，而且是不夠的（后面會講為什么這樣是不夠的），我們需要更高效，利用率更高的方法。

3、分析

在做這件事之前，讓我們站在高處分析一下：

（1）我們的大團隊中包含網絡運維（簡稱運維）、平臺研發（簡稱開發）、一線運維（簡稱一線）以及更多的團隊。

（2）經過早期團隊標準化和自動化工作的推進，運維已經具備了全員寫腳本的能力，如果可以，他們更愿意自己寫腳本，而非到開發那里提需求、排期，因為這樣太慢了。

（3）經過早期人工運維的時期，運維已經掌握了大量的運維經驗，沉淀出很多的大大小小的運維場景，每種場景需要的自動化能力是不一樣的，所以如果能自己實現，運維仍然是不愿意去交給開發實現的，因為這樣不僅慢，而且還可能要溝通很久。

（4）在全員實現腳本能力之前，開發是會經常收到各種各樣奇怪的需求的，并且不得不排期，一個一個實現并集成到大平臺中，時間久了這個平臺也變得臃腫不堪，喪失功能定位。

（5）運維有一部分工作是可以前移給一線的，這樣一線可以直接解決掉客戶的問題，避免后續麻煩且費時的工單流轉。當然，不是“免費”前移的，一線并不會深入學習這些復雜的組網架構，運維需要把場景濃縮成為簡易執行的腳本或工具，才適合前移。

綜上，我們應該做一個工具或者模塊（我們使用python），它可以：

• 提供網絡運維場景最底層的各種原子操作

• 實現大部分環節自動化

• 實現異構設備的標準化封裝

• 可以非常方便地自由編排，實現各種運維場景。

稱呼這個模塊叫做Forward，它的目的是使團隊的分工模式變成這樣：

完美！

開發專注于豐富底層原子操作，不再身陷各種奇怪需求中；運維可以用它自己動手、快速實現目標。

制定好目標了，然后需要決定從哪里下手，我模擬了網絡運維的場景，所有場景都可以歸納為這樣的步驟：

這張圖也解釋了為什么直接寫腳本是不夠的，當設備種類和維護場景都很多的時候，會浪費大量時間在腳本的重復功能上。

仔細檢查上圖后可以很容易分析出哪些環節適合自動化，哪些環節適合留給運維去“裝配”的：

經過這樣的處理后再去寫腳本，就舒服多了，運維也可以在第三個、第四個環節轉化自己的運維經驗了。可以說：這樣既體現了開發的價值，又保留了運維的發揮空間。

4、架構

為了實現Forward的目標狀態，我們構思了一個簡易的代碼層級架構，如下圖：

根據功能的特性：

• 把重復性最高的原子類操作放到最底層，例如底層連接協議的實現等；

• 中間層是類庫封裝，經過了這一層后所有設備對編程者來說就都是統一格式的類庫了，屏蔽掉了異構系統差異，這一層是整個模塊里比較核心的部分，下面將會用一個章節來詳細介紹；

• 上層就是模塊主程序層了，主要做一些流程初始化、多線程的事情（例如類庫批量初始化和登錄，這種密集網絡IO場景非常適合PYTHON多線程），負責和編程者腳本對接。

換到宏觀角度來看實現，如圖：

其實Forward用戶只需要關注虛線以下的部分，拿到Forward返回的標準類實例后，考慮給哪個設備執行什么功能，先后順序怎么安排，結果怎么處理等等，其他都不需要再關心了。

到目前為止，只剩一個元素沒有說明白的了，那就是標準類庫/標準類實例，它們是用戶得以快速編排場景的前提，接下來就對它們做一個介紹。

5、統一類庫

之前提到類庫層是核心，我們是為了屏蔽底層網絡設備異構差異、統一格式而設置的類庫層，那么類庫具體是什么樣子？

這張圖表示了Forward類庫層的簡化繼承關系，以用戶管理功能為視角，可以看到從上至下的屬性/方法分布，可以避免重復開發。到了最末枝的類節點時，已經有很明顯的功能區別了，根據設備種類的不同，可能會包含交換器/路由器/防火墻等不同專有方法。

經過統一類庫封裝，不同設備添加用戶的指令就簡化為統一的“addUser”方法了，這是一個比較大的進步，因為我們批量添加300個賬戶的任務可以簡化成一個幾行代碼的腳本了：

用戶甚至都不需要知道這三種設備添加賬戶的指令是什么，因為它們已經封裝在不同的類庫中了！

6、總結

Forward的實現思路分享結束了，實現它并不難，但是需要持續投入力量去擴充類庫方法以及文檔。

我習慣稱呼這張圖為“生態圖”，它表示了使用Forward的網絡運維生態圈，開發與運維和諧相處，每個人都有發揮空間，現在Forward各類封裝場景實例調用次數已經達到萬級，小到IP查詢，大到故障定位都有它的身影。

結局：有了Forward助力網絡運維后，老板更加無視了我們的加人請求，老板更加相信了網絡運維團隊的能力，然后接維了更多的網絡設備…

之后還要做什么

說來說去，Forward也僅僅是一個模塊而已，參考一個運維自研水平的套路：

手工 -> 腳本 -> 工具 -> 平臺 -> 智能

Forward頂多可以算到工具這個級別，而在團隊中和Forward同級別的運維模塊已經有4個了，一個比一個棒，在上層不做一個平臺就太對不起它們了，試想如果能用瀏覽器和鼠標完成各種運維操作，那就能前移更多的工作給一線了，那就能更高效率的完成工作了：

比如說前面提到的批量添加300個賬戶的任務，這個平臺也已經實現了，我們會放到后面的文章中介紹，歡迎繼續關注“火爐山蟻群”！