剛剛在運(yùn)維分享群里分享了主題《運(yùn)維開發(fā)流程梳理和思考》，希望有所幫助。

記得之前梳理過一個(gè)運(yùn)維開發(fā)流程，也做了一些實(shí)踐，從我的認(rèn)識(shí)和理解來看，其實(shí)這更適合一個(gè)團(tuán)隊(duì)內(nèi)的協(xié)作。

而早期的時(shí)候，整個(gè)項(xiàng)目的構(gòu)建和建設(shè)主要是我一個(gè)人來做，我貫穿了整個(gè)項(xiàng)目的開始，不能說是從0開始，也算是從0到1的開始吧。

首先來說下一個(gè)基本的心路歷程。通過這個(gè)可能對(duì)你也有一些借鑒和參考。

做自動(dòng)化運(yùn)維不是拍腦袋想的，而是這個(gè)是大勢(shì)所趨，如果還在手工化，腳本化的階段，其實(shí)整個(gè)運(yùn)維的路基本都能看到頭了。而開始提出來到要做的時(shí)候，其實(shí)也算是受到了蠻多的阻力。

做一件事情基本上是從上要支持，從下要配合，細(xì)節(jié)就不說了，總之，從上從下都很難，最后發(fā)現(xiàn)有一個(gè)目標(biāo)，但是沒法控制過程，所以這是一個(gè)隨機(jī)結(jié)果。

這個(gè)事情要做成的概率就太低了，所以早期的時(shí)候沒有這方面的技術(shù)就學(xué)，沒有哪方面的內(nèi)容就補(bǔ)，整個(gè)過程的迭代會(huì)花費(fèi)一些時(shí)間，一方面見效難，很多人都會(huì)懷疑這個(gè)事情能不能做，如果從上沒有明確的資源支持，你會(huì)發(fā)現(xiàn)就跟一個(gè)半創(chuàng)業(yè)狀態(tài)差不多。

從下來說，其實(shí)主要是運(yùn)維意識(shí)的提高，如果某個(gè)事情今天花30分鐘能做完，那么改用自動(dòng)化運(yùn)維用了5分鐘，對(duì)很多人來說確實(shí)是提高的，但是這個(gè)提高的代價(jià)對(duì)他們來說相對(duì)會(huì)比較高，所以很多人的想法就是差不多就行了，我也理解這種想法。

除了意識(shí)，還有一點(diǎn)就是技術(shù)沉淀方面，要提升一個(gè)團(tuán)隊(duì)的整體技術(shù)能力不是一個(gè)人能說了算，也能直接改變的。我最擔(dān)心的情況就是說出一個(gè)想法，其實(shí)已經(jīng)很成熟了，但是我需要做的事情是需要花很多的時(shí)間去說服別人，或者有時(shí)候別人對(duì)你的想法會(huì)有一些不大理解。碰到這種情況就兩難了，所以有的時(shí)候我確實(shí)容易上火，事情如果明顯達(dá)不到我的預(yù)期，我就會(huì)更加的急躁。有時(shí)候都在想到底這么堅(jiān)持圖個(gè)什么。

當(dāng)然同事相對(duì)都是很支持配合的，能夠在事務(wù)性工作之外給予我這么多的配合其實(shí)想想已經(jīng)很不錯(cuò)了。我覺得一定是某些環(huán)節(jié)上有些問題或者不夠清晰，導(dǎo)致事情很難推動(dòng)下去。

第一個(gè)是就是事情的形式，多多少少還是得有儀式感和角色帶入感，所以一種比較好的方式就是成立項(xiàng)目。做項(xiàng)目要寫文檔，這個(gè)之前覺得會(huì)浪費(fèi)時(shí)間，其實(shí)細(xì)細(xì)想來，也是一種工作內(nèi)容的體現(xiàn)。

第二個(gè)就是運(yùn)維開發(fā)路程的梳理，也是本次分享的主要內(nèi)容了。

前前后后做了很多磨合，最后也是撿了幾個(gè)業(yè)務(wù)場(chǎng)景，每個(gè)場(chǎng)景逐個(gè)擊破，比如部署安裝，比如服務(wù)開通，每一個(gè)功能的標(biāo)準(zhǔn)就是能夠支持線上業(yè)務(wù)，界面丑點(diǎn)沒關(guān)系，多點(diǎn)擊幾下鼠標(biāo)也沒關(guān)系，關(guān)鍵流程要對(duì)，比如權(quán)限的開通，不能做侵入性的破壞，不能多也不能漏。

所以做了一些功能，沉淀下一些思路之后，我覺得運(yùn)維開發(fā)的流程可能要分成幾個(gè)環(huán)節(jié)，如果從大了來說，就是前后端開發(fā)。

當(dāng)然這里的后端開發(fā)遠(yuǎn)比我們理解的要復(fù)雜的多。我來細(xì)掰扯下。

第一個(gè)階段就是業(yè)務(wù)需求的提煉，比如我們現(xiàn)在需要解決的需求是什么，可能一二三四有好多個(gè)，但是我們可以按照優(yōu)先級(jí)來排個(gè)順序，哪個(gè)是痛點(diǎn)需要優(yōu)先解決，這個(gè)重要性不用再強(qiáng)調(diào)了。

第二個(gè)就是梳理腳本，腳本的部分可能和大家的理解有很大偏差，每個(gè)運(yùn)維其實(shí)多多少少都會(huì)沉淀下來不少的腳本，少則十多個(gè)，多則上百個(gè)或者是寫個(gè)工具之類的。

所以有這么多的腳本或者工具，其實(shí)我們可以在這個(gè)基礎(chǔ)上做提煉，滿足當(dāng)前需求的腳本有哪些，然后不同的方向上可能都會(huì)有一些相關(guān)的，接下來要做的而就是腳本的標(biāo)準(zhǔn)化，這個(gè)是腳本梳理的一個(gè)核心點(diǎn)。

比如運(yùn)維同學(xué)A有10個(gè)腳本，有的是shell，有的是Python,沒關(guān)系，都可以考慮接入，但是我們要指定一個(gè)接入的標(biāo)準(zhǔn)，這里我們就要組哦一個(gè)接入管理的工作，比如我們統(tǒng)一設(shè)置一個(gè)目錄結(jié)構(gòu)，os,mysql,redis。。。。 然后按照功能在每個(gè)目錄下放入相應(yīng)的腳本，結(jié)構(gòu)的部分還可以細(xì)化。

然后我們需要制定腳本的標(biāo)準(zhǔn)，比如參數(shù)的使用說明，哪些是必須的，參數(shù)的含義，還有調(diào)用方式，腳本的返回結(jié)果等，這些都要明確，要不從開始就是一團(tuán)糟。比如其中的一個(gè)標(biāo)準(zhǔn)就是腳本在本地是能夠正常執(zhí)行的，能夠輸出執(zhí)行結(jié)果的標(biāo)識(shí)的。

如果做了這些工作，后續(xù)去接入腳本其實(shí)就是一個(gè)標(biāo)準(zhǔn)化的工作了，其實(shí)放長遠(yuǎn)來說，其實(shí)這個(gè)過程單純的運(yùn)維也能夠參與到整個(gè)運(yùn)維開發(fā)工作中了，我們可以不斷的merge腳本，盡可能做裁剪和邊界劃分，最重要的一點(diǎn)，這個(gè)腳本的接入管理需要有一個(gè)人來專門負(fù)責(zé)，這樣入口是統(tǒng)一的，改進(jìn)方式后續(xù)再細(xì)說。

第三步是REST接口和API化，我們的腳本可以使用很多種方式調(diào)用，比如salt,比如ansible,比如paramiko等等，這些都是接入方式而已。其實(shí)對(duì)于執(zhí)行結(jié)果來說是沒有差別的。

那么我們可以抽象成REST的接口服務(wù)，直接出發(fā)這個(gè)REST的接口就能夠完成相應(yīng)的指定任務(wù)。比如一個(gè)具體的例子，我們使用Django的rest_framework來做REST接口服務(wù)，可以很方便的使用認(rèn)證體系。

這里的REST接口這是一個(gè)調(diào)用方式，不是我們說的重點(diǎn)，我這里說的是REST接口和REST API,這里的重點(diǎn)其實(shí)是API的環(huán)節(jié)。

比如我們查看防火墻的操作，我們可以輸入一些基本參數(shù)，就得到一個(gè)防火墻信息列表，這個(gè)邏輯在Django中是需要在View層中來寫的，其實(shí)我們可以上移到API層來做。

這樣一來運(yùn)維同學(xué)就可以直接調(diào)用REST接口來做調(diào)試了，是否滿足需求其實(shí)通過這種測(cè)試就可以很清晰的測(cè)試。

到了這里可能是很多人理解的后端開發(fā)了。如果配合上前端，基本就是一個(gè)前后端分離的開發(fā)過程了，其實(shí)我要補(bǔ)充的是，我們可以做的更靈活，全面一些。

我們?cè)谶@兩個(gè)層之間做一些補(bǔ)充。Django的前端其實(shí)也還可以用啊，或者自己寫也可以，但是我們的使用基礎(chǔ)就是純粹的API,這樣一來，view層的邏輯上移，只負(fù)責(zé)分發(fā)和跳轉(zhuǎn)，就能夠很方便的和當(dāng)前的前端方案整合起來。

如果要做后續(xù)的前后端分離這就是一種相對(duì)可行的迭代方案，如果再深入一步，其實(shí)我們的View層已經(jīng)只負(fù)責(zé)最簡(jiǎn)單的分發(fā)任務(wù)了，那么這個(gè)工作其實(shí)我們可以繼續(xù)抽象，比如把跳轉(zhuǎn)的工作干脆直接放到數(shù)據(jù)配置中得了，通過前端的配置頁面來完成跳轉(zhuǎn)的配合，這樣我們就可以在線維護(hù)這種看似負(fù)責(zé)的關(guān)系了。

整個(gè)完成的圖其實(shí)通過下面的描述就會(huì)比較清晰了，我畫個(gè)圖先。整個(gè)流程圖就會(huì)是這樣

如果劃分下邊界，其實(shí)就是這樣。

中間的部分就是后端的開發(fā)，而右側(cè)的部分是前端的部分。

這樣做的好處是只需要少數(shù)的幾個(gè)人就可以負(fù)責(zé)某一個(gè)方向，而且能夠保持持續(xù)交付的質(zhì)量。比如交付的腳本，有了參數(shù)的說明和腳本規(guī)范，那么接入到API的時(shí)候會(huì)輕松許多，而在接入前端之前，其實(shí)后端就可以開始測(cè)試任務(wù)了。

相對(duì)原來所說的前后端分離，我們加入了中間的邏輯分發(fā)接入，可以很快的在本地構(gòu)建出一個(gè)前端的方案，至于獨(dú)立的前端方案我們完全可以持續(xù)的構(gòu)建。

所以整個(gè)的過程就是一個(gè)異步開發(fā)，不需要串行強(qiáng)依賴。

而且還有一個(gè)好處就是能夠充分的融合運(yùn)維和運(yùn)維開發(fā)。其實(shí)在這個(gè)過程中運(yùn)維同學(xué)就可以參與很多的角色了。

純粹的前后端分離其實(shí)也有很多的弊端，一個(gè)是溝通成本。在調(diào)試的時(shí)候可能因?yàn)楹蠖薃PI或者邏輯，或者是前端的支持情況，基本不大可能一口氣調(diào)通的。反反復(fù)復(fù)可能會(huì)做很多次。

而且前后端分離的一個(gè)主要出發(fā)點(diǎn)其實(shí)是對(duì)于代碼的復(fù)制所帶來的維護(hù)代價(jià)，比如有ios版本，有android版本還有pc版本，如果按照原來的方式，就是快速復(fù)制代碼，后期引入維護(hù)的時(shí)候成本巨大，這算是前后端分離的一個(gè)主要出發(fā)點(diǎn)。

相比到了我們很多工作環(huán)境中，前后端架構(gòu)要分離，但是前后端的技術(shù)不一定完全分離，當(dāng)然專業(yè)的前端可以做高級(jí)的前端功能，后端還是需要掌握基本的前端能力，而高級(jí)的前端也需要掌握一些后端的技能。

后續(xù)如何改進(jìn)，其實(shí)最近把基礎(chǔ)運(yùn)維的事情搞定，不如部署，服務(wù)開通，如果我能夠全部通過界面來搞定，完全不需要登錄服務(wù)器，那么這就是一個(gè)初步的里程碑，然后后續(xù)就是簡(jiǎn)化流程，不斷的迭代改進(jìn)了，比如很多抽象出的任務(wù)可以組裝成一個(gè)流程，這就又上升了一個(gè)臺(tái)階。

可以打個(gè)比方，你去菜市場(chǎng)買菜，順路去買個(gè)早點(diǎn)吃，如果你已經(jīng)吃過早點(diǎn)了，那么去買菜的時(shí)候就不用那么趕了。這里的吃早點(diǎn)就是我們需要先解放基礎(chǔ)運(yùn)維的工作，這個(gè)工作做好了，我們?cè)偃ハ肫渌氖虑椤?/p>

要不忙忙碌碌，自己的事情都解決不掉，工作的價(jià)值也不高，慢慢就會(huì)陷入一個(gè)惡性循環(huán)。

問答:

防火墻還是基于操作系統(tǒng)的iptables？ 添加規(guī)則主要就是調(diào)用命令去添加？ 防火墻這個(gè)主要有什么應(yīng)用場(chǎng)景？

答：

防火墻這個(gè)比較有意思，最近是做了改進(jìn)和提煉。把防火墻信息做成屬性信息。可以標(biāo)識(shí)幾個(gè)維度（操作人，發(fā)起方，操作時(shí)間），讀iptables信息的時(shí)候做成跟讀數(shù)據(jù)庫表類似的方式

類似這樣

斑*^O^*竹:

最起碼知道什么時(shí)候添加的 誰提的要求

答：

防火墻信息里的文本備注其實(shí)不靠譜，很不好參考。

時(shí)間戳和操作員可以做成隱式的，自動(dòng)錄入。就是先做加法再做減法。

斑*^O^*竹:

主要看寫備注的時(shí)候靠譜不 手工填入的數(shù)據(jù)

答：

后續(xù)可以改進(jìn)的話，比如根據(jù)開通時(shí)間排序。。。