引言：在運(yùn)營(yíng)商背景環(huán)境下，運(yùn)維是阻擋不了各路大佬的規(guī)則的，當(dāng)面對(duì)一個(gè)龐大組網(wǎng)架構(gòu)，而其中包含了14種品牌廠商、30多種設(shè)備型號(hào)的網(wǎng)絡(luò)設(shè)備時(shí)，我們一開(kāi)始是拒絕的….但是***算是艱難成功了。這篇文章給大家分享一下我們是怎樣實(shí)現(xiàn)統(tǒng)一自動(dòng)化管理的。 

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腳本編寫(xiě)能力（入門(mén)快）；

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ì)寫(xiě)出一大堆復(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)思考：

[[217108]]

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

緊接著***個(gè)想到的肯定是寫(xiě)腳本來(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)具備了全員寫(xiě)腳本的能力，如果可以，他們更愿意自己寫(xiě)腳本，而非到開(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ì)的分工模式變成這樣：

[[217109]]

***！

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

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

這張圖也解釋了為什么直接寫(xiě)腳本是不夠的，當(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ò)這樣的處理后再去寫(xiě)腳本，就舒服多了，運(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ū)?/strong>了，主要做一些流程初始化、多線程的事情（例如類庫(kù)批量初始化和登錄，這種密集網(wǎng)絡(luò)IO場(chǎng)景非常適合PYTHON多線程），負(fù)責(zé)和編程者腳本對(duì)接。