1、本篇文章的目的：

• 分享一種網(wǎng)絡(luò)運(yùn)維自動(dòng)化的實(shí)現(xiàn)過(guò)程，針對(duì)包含大量異構(gòu)網(wǎng)絡(luò)設(shè)備的組網(wǎng)環(huán)境。

• 運(yùn)營(yíng)商或者具有相似痛點(diǎn)的運(yùn)維團(tuán)隊(duì)；

• 希望轉(zhuǎn)型自主研發(fā)；

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

2、背景和痛點(diǎn)

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

可以看到，無(wú)論設(shè)備數(shù)量和種類如何瘋長(zhǎng)，負(fù)責(zé)網(wǎng)絡(luò)運(yùn)維的一直只有四個(gè)人，老板一直無(wú)視我們的加人請(qǐng)求，老板一直非常相信我們的能力。

正常來(lái)說(shuō)單純地增加設(shè)備數(shù)量并不會(huì)帶來(lái)多少壓力，而設(shè)備廠商的增多就是另一回事兒了，不同于X86服務(wù)器掛載相同的操作系統(tǒng)，網(wǎng)絡(luò)設(shè)備系統(tǒng)往往是封閉獨(dú)立的，有著截然不同的指令手冊(cè)，以及各種特殊的功能。總而言之，它們很難統(tǒng)一。

我再放兩張圖，是日常運(yùn)維中很常見(jiàn)的場(chǎng)景：

故障定位，從出口路由器一直沿路查到用戶虛擬機(jī)是一件很常見(jiàn)的事情，這個(gè)過(guò)程中可能會(huì)經(jīng)歷路由器、防火墻、三層交換機(jī)、二層交換機(jī)、負(fù)載均衡器等等設(shè)備（它們來(lái)自不同的廠商）

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

如果一開(kāi)始就拿這些場(chǎng)景去做自動(dòng)化，會(huì)無(wú)從下手，或者會(huì)寫出一大堆復(fù)雜重復(fù)的腳本來(lái)，效率不高；看過(guò)前面擁抱開(kāi)源系列文章的同學(xué)可能會(huì)想到用現(xiàn)成的工具，例如Ansible，很可惜它不能管到這么多種設(shè)備。

看來(lái)只能自己動(dòng)手了，接下來(lái)為了便于理解，我們不去想上面的復(fù)雜場(chǎng)景，用一個(gè)簡(jiǎn)單但又耗時(shí)的小場(chǎng)景來(lái)思考：

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

緊接著第一個(gè)想到的肯定是寫腳本來(lái)實(shí)現(xiàn)：

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

3、分析

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

（1）我們的大團(tuán)隊(duì)中包含網(wǎng)絡(luò)運(yùn)維（簡(jiǎn)稱運(yùn)維）、平臺(tái)研發(fā)（簡(jiǎn)稱開(kāi)發(fā)）、一線運(yùn)維（簡(jiǎn)稱一線）以及更多的團(tuán)隊(duì)。

（2）經(jīng)過(guò)早期團(tuán)隊(duì)標(biāo)準(zhǔn)化和自動(dòng)化工作的推進(jìn)，運(yùn)維已經(jīng)具備了全員寫腳本的能力，如果可以，他們更愿意自己寫腳本，而非到開(kāi)發(fā)那里提需求、排期，因?yàn)檫@樣太慢了。

（3）經(jīng)過(guò)早期人工運(yùn)維的時(shí)期，運(yùn)維已經(jīng)掌握了大量的運(yùn)維經(jīng)驗(yàn)，沉淀出很多的大大小小的運(yùn)維場(chǎng)景，每種場(chǎng)景需要的自動(dòng)化能力是不一樣的，所以如果能自己實(shí)現(xiàn)，運(yùn)維仍然是不愿意去交給開(kāi)發(fā)實(shí)現(xiàn)的，因?yàn)檫@樣不僅慢，而且還可能要溝通很久。

（4）在全員實(shí)現(xiàn)腳本能力之前，開(kāi)發(fā)是會(huì)經(jīng)常收到各種各樣奇怪的需求的，并且不得不排期，一個(gè)一個(gè)實(shí)現(xiàn)并集成到大平臺(tái)中，時(shí)間久了這個(gè)平臺(tái)也變得臃腫不堪，喪失功能定位。

（5）運(yùn)維有一部分工作是可以前移給一線的，這樣一線可以直接解決掉客戶的問(wèn)題，避免后續(xù)麻煩且費(fèi)時(shí)的工單流轉(zhuǎn)。當(dāng)然，不是“免費(fèi)”前移的，一線并不會(huì)深入學(xué)習(xí)這些復(fù)雜的組網(wǎng)架構(gòu)，運(yùn)維需要把場(chǎng)景濃縮成為簡(jiǎn)易執(zhí)行的腳本或工具，才適合前移。

綜上，我們應(yīng)該做一個(gè)工具或者模塊（我們使用python），它可以：

• 提供網(wǎng)絡(luò)運(yùn)維場(chǎng)景最底層的各種原子操作

• 實(shí)現(xiàn)大部分環(huán)節(jié)自動(dòng)化

• 實(shí)現(xiàn)異構(gòu)設(shè)備的標(biāo)準(zhǔn)化封裝

• 可以非常方便地自由編排，實(shí)現(xiàn)各種運(yùn)維場(chǎng)景。

稱呼這個(gè)模塊叫做Forward，它的目的是使團(tuán)隊(duì)的分工模式變成這樣：

完美！

開(kāi)發(fā)專注于豐富底層原子操作，不再身陷各種奇怪需求中；運(yùn)維可以用它自己動(dòng)手、快速實(shí)現(xiàn)目標(biāo)。

制定好目標(biāo)了，然后需要決定從哪里下手，我模擬了網(wǎng)絡(luò)運(yùn)維的場(chǎng)景，所有場(chǎng)景都可以歸納為這樣的步驟：

這張圖也解釋了為什么直接寫腳本是不夠的，當(dāng)設(shè)備種類和維護(hù)場(chǎng)景都很多的時(shí)候，會(huì)浪費(fèi)大量時(shí)間在腳本的重復(fù)功能上。

仔細(xì)檢查上圖后可以很容易分析出哪些環(huán)節(jié)適合自動(dòng)化，哪些環(huán)節(jié)適合留給運(yùn)維去“裝配”的：

經(jīng)過(guò)這樣的處理后再去寫腳本，就舒服多了，運(yùn)維也可以在第三個(gè)、第四個(gè)環(huán)節(jié)轉(zhuǎn)化自己的運(yùn)維經(jīng)驗(yàn)了。可以說(shuō)：這樣既體現(xiàn)了開(kāi)發(fā)的價(jià)值，又保留了運(yùn)維的發(fā)揮空間。

4、架構(gòu)

為了實(shí)現(xiàn)Forward的目標(biāo)狀態(tài)，我們構(gòu)思了一個(gè)簡(jiǎn)易的代碼層級(jí)架構(gòu)，如下圖：

根據(jù)功能的特性：

• 把重復(fù)性最高的原子類操作放到最底層，例如底層連接協(xié)議的實(shí)現(xiàn)等；

• 中間層是類庫(kù)封裝，經(jīng)過(guò)了這一層后所有設(shè)備對(duì)編程者來(lái)說(shuō)就都是統(tǒng)一格式的類庫(kù)了，屏蔽掉了異構(gòu)系統(tǒng)差異，這一層是整個(gè)模塊里比較核心的部分，下面將會(huì)用一個(gè)章節(jié)來(lái)詳細(xì)介紹；

• 上層就是模塊主程序?qū)?/span>了，主要做一些流程初始化、多線程的事情（例如類庫(kù)批量初始化和登錄，這種密集網(wǎng)絡(luò)IO場(chǎng)景非常適合PYTHON多線程），負(fù)責(zé)和編程者腳本對(duì)接。

換到宏觀角度來(lái)看實(shí)現(xiàn)，如圖：

其實(shí)Forward用戶只需要關(guān)注虛線以下的部分，拿到Forward返回的標(biāo)準(zhǔn)類實(shí)例后，考慮給哪個(gè)設(shè)備執(zhí)行什么功能，先后順序怎么安排，結(jié)果怎么處理等等，其他都不需要再關(guān)心了。

到目前為止，只剩一個(gè)元素沒(méi)有說(shuō)明白的了，那就是標(biāo)準(zhǔn)類庫(kù)/標(biāo)準(zhǔn)類實(shí)例，它們是用戶得以快速編排場(chǎng)景的前提，接下來(lái)就對(duì)它們做一個(gè)介紹。

5、統(tǒng)一類庫(kù)

之前提到類庫(kù)層是核心，我們是為了屏蔽底層網(wǎng)絡(luò)設(shè)備異構(gòu)差異、統(tǒng)一格式而設(shè)置的類庫(kù)層，那么類庫(kù)具體是什么樣子？

這張圖表示了Forward類庫(kù)層的簡(jiǎn)化繼承關(guān)系，以用戶管理功能為視角，可以看到從上至下的屬性/方法分布，可以避免重復(fù)開(kāi)發(fā)。到了最末枝的類節(jié)點(diǎn)時(shí)，已經(jīng)有很明顯的功能區(qū)別了，根據(jù)設(shè)備種類的不同，可能會(huì)包含交換器/路由器/防火墻等不同專有方法。

經(jīng)過(guò)統(tǒng)一類庫(kù)封裝，不同設(shè)備添加用戶的指令就簡(jiǎn)化為統(tǒng)一的“addUser”方法了，這是一個(gè)比較大的進(jìn)步，因?yàn)槲覀兣刻砑?00個(gè)賬戶的任務(wù)可以簡(jiǎn)化成一個(gè)幾行代碼的腳本了：

用戶甚至都不需要知道這三種設(shè)備添加賬戶的指令是什么，因?yàn)樗鼈円呀?jīng)封裝在不同的類庫(kù)中了！

6、總結(jié)

Forward的實(shí)現(xiàn)思路分享結(jié)束了，實(shí)現(xiàn)它并不難，但是需要持續(xù)投入力量去擴(kuò)充類庫(kù)方法以及文檔。

我習(xí)慣稱呼這張圖為“生態(tài)圖”，它表示了使用Forward的網(wǎng)絡(luò)運(yùn)維生態(tài)圈，開(kāi)發(fā)與運(yùn)維和諧相處，每個(gè)人都有發(fā)揮空間，現(xiàn)在Forward各類封裝場(chǎng)景實(shí)例調(diào)用次數(shù)已經(jīng)達(dá)到萬(wàn)級(jí)，小到IP查詢，大到故障定位都有它的身影。

結(jié)局：有了Forward助力網(wǎng)絡(luò)運(yùn)維后，老板更加無(wú)視了我們的加人請(qǐng)求，老板更加相信了網(wǎng)絡(luò)運(yùn)維團(tuán)隊(duì)的能力，然后接維了更多的網(wǎng)絡(luò)設(shè)備…

之后還要做什么

說(shuō)來(lái)說(shuō)去，F(xiàn)orward也僅僅是一個(gè)模塊而已，參考一個(gè)運(yùn)維自研水平的套路：

手工 -> 腳本 -> 工具 -> 平臺(tái) -> 智能

Forward頂多可以算到工具這個(gè)級(jí)別，而在團(tuán)隊(duì)中和Forward同級(jí)別的運(yùn)維模塊已經(jīng)有4個(gè)了，一個(gè)比一個(gè)棒，在上層不做一個(gè)平臺(tái)就太對(duì)不起它們了，試想如果能用瀏覽器和鼠標(biāo)完成各種運(yùn)維操作，那就能前移更多的工作給一線了，那就能更高效率的完成工作了：

比如說(shuō)前面提到的批量添加300個(gè)賬戶的任務(wù)，這個(gè)平臺(tái)也已經(jīng)實(shí)現(xiàn)了，我們會(huì)放到后面的文章中介紹，歡迎繼續(xù)關(guān)注“火爐山蟻群”！