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

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

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

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

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

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

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

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

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

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

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

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

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

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

當然這里的后端開發(fā)遠比我們理解的要復雜的多。我來細掰扯下。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

整個完成的圖其實通過下面的描述就會比較清晰了，我畫個圖先。整個流程圖就會是這樣

如果劃分下邊界，其實就是這樣。

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

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

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

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

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

純粹的前后端分離其實也有很多的弊端，一個是溝通成本。在調(diào)試的時候可能因為后端API或者邏輯，或者是前端的支持情況，基本不大可能一口氣調(diào)通的。反反復復可能會做很多次。

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

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

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

可以打個比方，你去菜市場買菜，順路去買個早點吃，如果你已經(jīng)吃過早點了，那么去買菜的時候就不用那么趕了。這里的吃早點就是我們需要先解放基礎(chǔ)運維的工作，這個工作做好了，我們再去想其他的事情。

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

問答:

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

答：

防火墻這個比較有意思，最近是做了改進和提煉。把防火墻信息做成屬性信息?？梢詷俗R幾個維度（操作人，發(fā)起方，操作時間），讀iptables信息的時候做成跟讀數(shù)據(jù)庫表類似的方式

類似這樣

斑*^O^*竹:

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

答：

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

時間戳和操作員可以做成隱式的，自動錄入。就是先做加法再做減法。

斑*^O^*竹:

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

答：

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