《DevOps 能力模型、演進及案例剖析》要點：
本文介紹了DevOps 能力模型、演進及案例剖析，希望對您有用。如果有疑問，可以聯(lián)系我們。

作者介紹

王曉偉

2009年創(chuàng)辦麥圖科技,專注于電商行業(yè)的垂直搜索, 受到多家天使、Pre-A投資機構(gòu)的關(guān)注.
有10+年互聯(lián)網(wǎng)、游戲、內(nèi)核安全從業(yè)經(jīng)驗.歷任軟件工程師、高級軟件工程師、技術(shù)經(jīng)理和總監(jiān).
目前主要從事手機游戲發(fā)行平臺的構(gòu)建,推進公司DevOps的培養(yǎng)和運維自動化的實施.

主題簡介

本次分享主要分為兩部分：

• 第一部分引入運維工程師的能力理論定義；
• 第二部分介紹DevOps的能力模型,其中引用了第一部分的定義.

部分內(nèi)容可能形而上學,所以帶好枕頭被褥,困了就瞇一會兒,后面有點小精彩.

引言

運維工作是實踐性的學科和工作,即便沒有高深的理論也可以開展工作,繼而從事這個工作的朋友不缺乏實際動手的能力.

但從事物的發(fā)展規(guī)律性和普遍性來看,從實踐出發(fā)的Ops恰恰缺乏必要的理論指導和思想探究.

本文是我對運維工作的理論、思考和定義的總結(jié),同時給出DevOps相關(guān)概念的定義,明確其工作范疇,能力要求,產(chǎn)出標準以及演進建議.一家之言尚未完善,拋磚引玉,歡迎討論.

從一次面試開始

問題1

問：如何通過Python或者Shell給Nginx添加/刪除一個虛擬站點?
答：通過Python或者Shell在nginx.conf里添加server區(qū)塊,然后如何如何……

問題2

問：如何使用Python將文本日志結(jié)構(gòu)化
答：通過python的os.system調(diào)用awk.(哭,韓國的整容術(shù)用到運維上了,給awk整成python……)

這是最近真實的面試案例.上述兩個問題的回答,讓我很不開心：

• 問題1的回答,說明面試者不具備運維的工程能力,更不具備架構(gòu)能力；
• 問題2的回答,說明面試者不具備程序的架構(gòu)能力,甚至對語言理解和標準庫的學習都不到位.

從案例里我總結(jié)了兩個核心的定義：工程能力和架構(gòu)能力.下面先給出這兩個定義.

工程能力當然是運維工!程!師所必需具備的.我對工程能力的定義是：

1. 分解問題的能力；
2. 定義執(zhí)行序列的能力；
3. 制定可重入操作行為的能力.

架構(gòu)能力,本人解釋為：

• 懂“不該”懂的；
• 想“不該”想的；
• 做“不該”做的.

比如程序猿懂了業(yè)務(wù),想了部署,做了高可用的規(guī)劃應(yīng)該算得上架構(gòu)獅了.

1. 分解問題的能力

針對問題1的分解邏輯如下：

1. nginx是如何管理虛擬站點的,是否具有模塊化能力?
2. 在具有模塊能力的情況下,如何實現(xiàn)虛擬站點模塊的添加?
3. 如何定義規(guī)則來命名虛擬站點,以保證可重入,在規(guī)則不變的情況不會再重復添加(還要支持upstream等等)?
4. python要實現(xiàn)什么樣的功能,shell要完成什么樣的工作?
5. 添加完成后,如何驗證其生效?
6. 刪除的行為是否要徹底刪除配置文件,抑或者留一個副本?

2. 定義執(zhí)行序列的能力

有些操作是高危操作或者是不可逆的,比如修改sudoers文件.在基于sudo管理的系統(tǒng)下,如果一旦sudoers被改壞是災(zāi)難性的.因此定義執(zhí)行序列是：

1. 在 Terminal下開一個窗口切換到root下；
2. 在另外的窗口下進行對sudoers/sudoers.d的修改或者添加；
3. 一旦試驗過程中sudoers被改壞,可以用root賬戶直接改回來；
4. 以上流程雖然簡單,但是這跟飛機起飛前拔掉起落架的閂是一樣致命的.

3. 制定可重入操作的能力

系統(tǒng)的管理和系統(tǒng)的狀態(tài)的獲取是兩個不同方向的工作：

管理是把指令傳遞給系統(tǒng),修改系統(tǒng)的狀態(tài)和信息；查看系統(tǒng)的狀態(tài)是從系統(tǒng)獲取信息.

這兩個不同向的操作行為就導致了狀態(tài)和信息同步的問題.解決這個問題的方法有很多,但是穩(wěn)定可靠,兼容性好的方法不多,我的方法是保證操作的可重入性.

即在同等的條件下,對于系統(tǒng)發(fā)出的指令,執(zhí)行n+1次(n>0)的效果是相同的.

這樣,即便我可能知道系統(tǒng)狀態(tài)和信息是不一致的,但是由于操作行為是可重入的,我可以最終把狀態(tài)和信息一致化.

以上展開了工程能力的解釋.

由于架構(gòu)能力涉及面廣,交叉學科眾多,此處暫不作展開說明.

DevOps的能力模型

我們先介紹相關(guān)能力模型：操作系統(tǒng)能力模型和應(yīng)用系統(tǒng)能力模型,然后再由此引出DevOps能力模型.

操作系統(tǒng)能力模型

除操作系統(tǒng)核心提供的基本功能外,還給我們提供了以下功能(以Linux為例)：

1. 訪問控制,實現(xiàn)基于角色的最小粒度訪問控制,此為系統(tǒng)管理的基礎(chǔ),能力模型的關(guān)鍵之一；
2. 權(quán)利托管,基于角色和命令的可配置授權(quán)機制,提供了可控的,可定制的提權(quán)的方案；
3. 導入式的可插拔配置能力(通過類include指令), 比如 /etc/security/limits.d,/etc/sudoers.d, 此為自動化重要設(shè)施；
4. 包管理能力,包括二進制和源碼包的依賴管理等；
5. shell編程的支持.

應(yīng)用系統(tǒng)能力模型

除操作系統(tǒng)能力模型提供的功能之外,還給我們提供了以下功能：

1. 導入式配置能力,如nginx的 /etc/nginx/sites-available/；
2. 系統(tǒng)狀態(tài)偵測能力,如php-fpm的ping/pong；
3. 熱裝載能力,例如很多服務(wù)的reload功能；
4. 高可用性以及故障恢復能力,例如MySQL的高可用配置,以及其binlog的恢復能力；
   5,其他必要特性,視不同的業(yè)務(wù)系統(tǒng)而定.

DevOps能力模型

由此,我們給出DevOps能力模型的定義：

1. 了解其所管理的操作系統(tǒng)的能力模型(Linux,Windows),掌握系統(tǒng)編程語言(Shell)并能利用其能力用于DevOps工作；
2. 了解其管理的應(yīng)用系統(tǒng)的能力模型(Mysql, Nginx等),掌握系統(tǒng)編程語言(Shell)并能利用其能力用于DevOps工作；
3. 具備前文提到的工程能力,掌握系統(tǒng)編程語言(Shell)和通用語言(Python/Ruby等),并能利用其編程能力將工程能力提到三種能力程序化,并進一步實現(xiàn)自動化；
4. 了解工作場景和業(yè)務(wù)場景,以及業(yè)務(wù)的關(guān)鍵指標,使DevOps工作有的放矢,貼近業(yè)務(wù).

評估DevOps是否合格的標準：

1. 具備DevOps能力模型提到的各項要求；
2. 其產(chǎn)出的代碼腳本能夠適應(yīng)普遍需求,并且該代碼腳本符合前文的可重入要求,即執(zhí)行n和n+1次的效果相同；
3. 其產(chǎn)出的代碼腳本能夠供其他代碼腳本使用,此條尤為重要.

DevOps的級別：

符合DevOps能力模型1：為初級DevOps,可以使用shell做DevOps的一般性系統(tǒng)級別的工作,在一些第三方工具(Ansible/Fabric)的幫助下管理大量服務(wù)器；

符合DevOps能力模型2：為中級DevOps,可以使用shell做DevOps的應(yīng)用系統(tǒng)的部署和優(yōu)化工作,并能通過其產(chǎn)出的腳本大批量管理應(yīng)用系統(tǒng)

符合DevOps能力模型3：為高級DevOps,可以使用shell和通用語言進行廣泛的DevOps的工作,可以完成完整的業(yè)務(wù)流程的定義和開發(fā),能夠熟練抽象并編寫供其他DevOps使用的接口.

符合DevOps能力模型4：為架構(gòu)師級別的DevOps,根據(jù)業(yè)務(wù)需求,規(guī)劃系統(tǒng)部署架構(gòu)；根據(jù)業(yè)務(wù)指標要求優(yōu)化部署結(jié)構(gòu)和性能,保證高可用等；定義腳本代碼接口,制定開發(fā)規(guī)范和操作規(guī)范.

理論的東西說完了,下面是探討下Dev和Ops的現(xiàn)狀,Ops的演進,Dev的演進以及三項補充內(nèi)容.

Dev和Ops的現(xiàn)狀

Dev和Ops是實踐性的工作,因此即便不是一名DevOps,或許你也在做著Dev或者Ops的工作.只是這不是真正的DevOps.讓我們看兩個場景：

1. Dev的風格是力求用Python/Ruby這類通用編程語言整合一堆的API,實現(xiàn)一套大系統(tǒng),搞定一切Ops的工作；他們每天的工作就是在找Libs和看各種API的文檔,滿腦子設(shè)計思想.這種思維是Dev思維；
2. Ops的風格是力求從命令行的角度,甚至腳本都不用,一行一行的把命令敲下去完成工作；或者快速的寫一個一次性腳本搞定；他們還喜歡自己編譯各種系統(tǒng),滿世界下源碼包,喜歡自己搞幾個參數(shù)優(yōu)化一下；他們只關(guān)心當下的結(jié)果,不關(guān)心以后的重復利用和持續(xù)集成.

這是我以前的工作中遇到的真實情況.

現(xiàn)在情況變了,自從Dev和Ops弄在一起變成DevOps后,又出現(xiàn)了幾個自動化工具,搞的現(xiàn)在Dev不好好寫代碼了,Ops也不好好的寫命令行,都去學習自動化工具去了.

這不是DevOps的王道.這是錯誤的.

即便把所有的自動化工具,不管是Ansible還是Puppet或者其他學的再熟,也只是學會了一個工具而已,很可能DevOps沒當成,卻變成工具的奴隸.

DevOps是先有思想,而后有工具.

現(xiàn)在崇尚工具的思路是非常可怕的,很多初學者誤以為學會了這些自動化工具就可以把運維做好,而忽視基本功的學習,空學工具,只重其招,不重其義.

下面分享下兩者的演進.

Ops的演進

案例1：以在RedHat上安裝Nginx為例子,網(wǎng)上很多文章的步驟大概如下：

• PCRE庫的安裝：wget, tar, configure, make,make install
• OpenSSL庫的安裝,wget, tar, configure, make,make install
• nginx安裝,wget, tar, configure, make,make install

這種做法早些年是非常流行的,而且很多人對于在configure后面帶的那些參數(shù)很是自得,屢試不爽.

時至今日這種方法仍然在很多初學者那里非常流行,而這種做法就是嚴重的反DevOps的做法.

案例2：以給Nginx增加一個虛擬站點www.devops.org為例,很多初學者一上來就打開nginx.conf開始改,這同樣是嚴重反DevOps的.

這可能是因為一來nginx官方文檔是這么改的,二來很多文章也是這么轉(zhuǎn)載,或者原創(chuàng)這么寫的.

案例3：再以網(wǎng)絡(luò)性能優(yōu)化的為例,很多Ops同學直接沖到/etc/sysctl.conf這里面瘋狂的修改一通,添加了各種參數(shù).

這仍然是反DevOps的.一來過不久以后也不知道哪些是自己改的,哪些的默認的,二來如果想用腳本批量更新也是大問題.

針對上面提到的,我認為DevOps應(yīng)該是這么做的：

對于案例1：首先根據(jù)自己的系統(tǒng)設(shè)置好nginx的源,而設(shè)置源的方法也不是直接沖到/etc/yum.conf,而是建立一個/etc/yum.repos.d/nginx.repo文件,用于保存nginx的源信息.然后然后通過yum install nginx 安裝.(如果一定非得必須特定版本,稍后討論).

對于案例2：給Nginx添加一個虛擬站點.RPM包的結(jié)構(gòu)如下

盡管這個結(jié)構(gòu)不是很令人滿意,但是仍然可以將就.

至少我們可以看出Redhat的潛在建議是讓我們把新的站點放在conf.d下面,我建議的命名是www.devops.org.conf.

那么問題來了,如果我要暫時關(guān)閉這個站點怎么辦呢?在這個結(jié)構(gòu)下,我們只要把www.devops.org.conf從conf.d里移出來再reload一下就可以了……對,是移出來,不是刪除.因為我們后面可能還要用.

此時www.devops.org.conf放在nginx目錄下,顯得有點格格不入,那么我們干脆建一個文件夾叫disabled-sites,把www.devops.org.conf放在disabled-sites下面得了,以后要是再啟用該站點,就直接符號連接到conf.d下面.

再演進一步我們就有了如下的結(jié)構(gòu)：

把站點放在sites-*里.available里放置所有站點的配置文件,通過符號連接到enabled目錄下啟用.

如果要臨時關(guān)閉站點,可以刪除enabled下的符號連接.這個結(jié)構(gòu)就非常適合DevOps用腳本進行管理.

對于案例3：關(guān)于sysctl的修改,DevOps方法是在/etc/sysctl.d下面,按照命名規(guī)則添加一個文件,把需要添加的參數(shù)放到新文件即可.

這樣一來可以方便查看自己修改了哪些,便于確認,二來可以持續(xù)集成,通過文件的形式保留自己思考的路徑.

通過上面3個事例的演進,我們已經(jīng)清晰的感覺到,上面三個步驟現(xiàn)在可以馬上用腳本自動化起來.但是演進之前確實很難辦到.

如果沒有Ops的演進,再牛X的Dev他也無法完成自動批量管理以上的業(yè)務(wù)需求.

Dev的演進

我作為Dev的時間要比作為Ops的時間長很多.8年前從Windows轉(zhuǎn)到Unix-like下,我們看下兩個不同系統(tǒng)下,Dev的思路的差別.

寫過Windows程序的人都有一個非常堅定的信念就是API,Windows系統(tǒng)下事無巨細都會有對應(yīng)的API,尤為著名的是注冊表的API,還有一個典型的是服務(wù)API(Windows Services).

你要改個啥配置,要創(chuàng)建一個Service都必須得用API來完成.復雜點的比如寫一個端口掃描的要用到socket和多線程的API等等.這個端口掃描說來業(yè)務(wù)邏輯本身很簡單,倒是程序邏輯搞的復雜的不得了.

而Unix-like的系統(tǒng),沿襲著Unix的哲學其Dev的思路又是另外一套.修改配置,直接沖到文件里改,創(chuàng)建一個daemon/service直接寫個shell腳本放到系統(tǒng)即可,完全不必要API.

所有的一切無論是在Dev還是Ops面前都是一目了然.前面提到的端口掃描更是直接用python/ruby/shell 直接調(diào)用nmap搞定,效率高,功能強大,穩(wěn)定性和兼容性都不錯.

我認為這是Dev要借鑒的,也是思想上最大的差別.

統(tǒng)統(tǒng)用API做出來的東西,一是容易讓Ops一頭霧水,搞不清楚,很難參與,二是有些功能實現(xiàn)起來要達到足夠的性能,強大,穩(wěn)定以及良好的兼容性是非常困難的.

nmap第一版本是1997.9發(fā)布的,歷經(jīng)18個年頭,這樣的工具我們一朝一夕是難以實現(xiàn)的.

關(guān)于Dev轉(zhuǎn)DevOps的建議

鑒于以上的討論,我給Dev即將轉(zhuǎn)到DevOps的同學們的建議是：

1. 試做一個有經(jīng)驗的Ops,放下編程語言,從命令行開始,從Shell開始；
2. 理解操作系統(tǒng)的哲學,Unix-like下管道連接一切命令,文件代表一切配置；
3. 理解Ops的核心指標,比如高可用,兼容穩(wěn)定,可重入,故障容災(zāi)；
4. 在堅持Ops-style的前提下,通過程序設(shè)計思想將DevOps的代碼腳本的產(chǎn)出層次化,模塊化,使之達到高復用；

Dev和Ops的另外一個區(qū)別是,以往Dev注重的是具體功能開發(fā),而Ops天生要關(guān)注的是系統(tǒng)的整體管理.

功能開發(fā)注重邏輯的正確,1＋1=2；但是Ops要求業(yè)務(wù)和結(jié)果導向,有時1+1可能是無窮大,比如磁盤滿了.

補充1：編程語言和Shell在DevOps的關(guān)系

從自動化部署工具來看他們的關(guān)系,Python/Ruby通過業(yè)務(wù)邏輯把產(chǎn)生出相關(guān)文件和Shell語句通過下面兩種方式執(zhí)行：

1. 基于ssh；
2. 基于Agent(姑且認為是RPC的一種方式).

因此Python/Ruby作用是：編排和啟動Shell語句的作用；具體實現(xiàn)功能,則仍是Shell語句.

根據(jù)這種關(guān)系,我們不難發(fā)現(xiàn)以上兩種方式存在現(xiàn)實的局限性：

1. 眾多命令執(zhí)行情況下,ssh效率不高；
2. Agent效率雖然高,但是開發(fā)和調(diào)試成本很高,另外Agent對于Ops是透明、不可控的,一線Ops在Agent出了問題后,很難介入調(diào)試.

我的建議是在shell做文章,即基于shell腳本的機制完成遠端業(yè)務(wù)邏輯的工作,通過ssh或者agent調(diào)用腳本執(zhí)行功能,這樣提高了效率又便于Ops參與腳本的編寫和調(diào)試.

結(jié)論：DevOps的落點是Ops,Python/Ruby的落點是shell和commands.

Python/Ruby的優(yōu)勢是業(yè)務(wù)邏輯,文件處理等,莫用Python/Ruby去實現(xiàn)shell和commands擅長的.

補充2：編程語言在DevOps的意義

Python/Ruby體現(xiàn)的重要性是程序設(shè)計的思想,shell和commands的重要性在于,系統(tǒng)最終由他們改變.

以前是Ops玩shell和commands,現(xiàn)在是DevOps通過Python/Ruby玩shell和commands,所以本質(zhì)還是shell和commands.

就像互聯(lián)網(wǎng)和傳統(tǒng)行業(yè)一樣,有互聯(lián)網(wǎng)傳統(tǒng)行業(yè)轉(zhuǎn)的更好,但是沒有互聯(lián)網(wǎng)傳統(tǒng)行業(yè)一樣轉(zhuǎn)；而如果沒有傳統(tǒng)行業(yè),估計飯都吃不上,互聯(lián)網(wǎng)也就不存在了.

補充3：操作系統(tǒng)能力模型

根據(jù)前面的結(jié)論,我認為DevOps的核心競爭是在Shell和Commands的競爭.而操作系統(tǒng)能力的提升也將是Shell和commands的提升.

試想如果沒有yum/apt,沒有sed,沒有iptables,沒有virsh這樣的指令,我們是否寸步難行?答案當然是肯定的.

有人說,可以通過c/python/ruby實現(xiàn),反正都有api,這是錯誤的輪子思路.

我可以肯定的說,我們幾乎沒有能力超越先賢們歷經(jīng)數(shù)十年累積的成果.即便可以我們做出來類似的東西,也很難超越這些既有的工具,這些工具優(yōu)秀之處除了智慧,還有時間以及實踐的檢驗.

但是有一件事我們是可以做的,就是把操作系統(tǒng)業(yè)務(wù)能力提升起來.我認為的操作系統(tǒng)能力模型里,唯缺此一項.

我們不需要再寫一個iptables,sed,yum/apt,我們可以包裝他們,通過命令的組合和邏輯的判斷,衍生出專用的業(yè)務(wù)能力.

RedHat下有不少好的例子,比如service iptables save的功能.此功能的意義如下：

1. 提供了統(tǒng)一的調(diào)用方式,并且封裝業(yè)務(wù)邏輯,便于其他腳本使用；
2. 統(tǒng)一的文件存放位置,便于自動加載,管理和備份；
3. 同時提供了restore的命令.

這就是一種操作系統(tǒng)的能力.這種能力在Linux的一些分支上是沒有的,我們就必須自己編寫腳本實現(xiàn)此功能.但是寫來寫去,寫得最好也就是跟RedHat大同小異,但是卻花了我們的寶貴的時間.

試想在擁有這種能力的RedHat上面,DevOps開發(fā)一個批量保存iptables的功能是否更容易呢?

練手：

1. 是否可以基于iptables實現(xiàn)一個命令,在添加一條iptables規(guī)則時,先檢測是否存在同樣的規(guī)則,避免重復?
2. 是否可以基于sed實現(xiàn)兩個命令,delete_line和delete_line_by_no：第一個命令給定一個表達式和一個文件名刪除含有表達式的行；第二個命令根據(jù)行號刪除指定文件行?
3. 實現(xiàn)一個命令,安裝memcached,根據(jù)傳入的參數(shù)設(shè)定監(jiān)聽地址,內(nèi)存大小和監(jiān)聽端口等.

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/4350.html