主題簡介

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

    第一部分引入運(yùn)維工程師的能力理論定義；

    第二部分介紹DevOps的能力模型，其中引用了第一部分的定義。

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

    引言

    運(yùn)維工作是實(shí)踐性的學(xué)科和工作，即便沒有高深的理論也可以開展工作，繼而從事這個(gè)工作的朋友不缺乏實(shí)際動(dòng)手的能力。

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

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

    從一次面試開始

    問題1

    問：如何通過Python或者Shell給Nginx添加/刪除一個(gè)虛擬站點(diǎn)？

    答：通過Python或者Shell在nginx.conf里添加server區(qū)塊，然后如何如何……

    問題2

    問：如何使用Python將文本日志結(jié)構(gòu)化？

    答：通過python的os.system調(diào)用awk。（哭，韓國的整容術(shù)用到運(yùn)維上了，給awk整成python……）

    這是最近真實(shí)的面試案例。上述兩個(gè)問題的回答，讓我很不開心：

    問題1的回答，說明面試者不具備運(yùn)維的工程能力，更不具備架構(gòu)能力；

    問題2的回答，說明面試者不具備程序的架構(gòu)能力，甚至對語言理解和標(biāo)準(zhǔn)庫的學(xué)習(xí)都不到位。

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

    工程能力當(dāng)然是運(yùn)維工程師所必需具備的。我對工程能力的定義是：

    （1）分解問題的能力；

    （2）定義執(zhí)行序列的能力；

    （3）制定可重入操作行為的能力。

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

    （1）懂“不該”懂的；

    （2）想“不該”想的；

    （3）做“不該”做的。

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

    1.分解問題的能力

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

    （1）nginx是如何管理虛擬站點(diǎn)的，是否具有模塊化能力？

    （2）在具有模塊能力的情況下，如何實(shí)現(xiàn)虛擬站點(diǎn)模塊的添加？

    （3）如何定義規(guī)則來命名虛擬站點(diǎn)，以保證可重入，在規(guī)則不變的情況不會再重復(fù)添加（還要支持upstream等等）？

    （4）python要實(shí)現(xiàn)什么樣的功能，shell要完成什么樣的工作？

    （5）添加完成后，如何驗(yàn)證其生效？

    （6）刪除的行為是否要徹底刪除配置文件，抑或者留一個(gè)副本？

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

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

    （1）在 Terminal下開一個(gè)窗口切換到root下；

    （2）在另外的窗口下進(jìn)行對sudoers/sudoers.d的修改或者添加；

    （3）一旦試驗(yàn)過程中sudoers被改壞，可以用root賬戶直接改回來；

    （4）以上流程雖然簡單，但是這跟飛機(jī)起飛前拔掉起落架的閂是一樣致命的。

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

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

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

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

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

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

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

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

    DevOps的能力模型

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

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

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

    （1）訪問控制，實(shí)現(xiàn)基于角色的最小粒度訪問控制，此為系統(tǒng)管理的基礎(chǔ)，能力模型的關(guān)鍵之一；

    （2）權(quán)利托管，基于角色和命令的可配置授權(quán)機(jī)制，提供了可控的，可定制的提權(quán)的方案；

    （3）導(dǎo)入式的可插拔配置能力（通過類include指令), 比如 /etc/security/limits.d，/etc/sudoers.d， 此為自動(dòng)化重要設(shè)施；

    （4）包管理能力，包括二進(jìn)制和源碼包的依賴管理等；

    （5）shell編程的支持。

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

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

    （1）導(dǎo)入式配置能力，如nginx的 /etc/nginx/sites-available/；

    （2）系統(tǒng)狀態(tài)偵測能力，如php-fpm的ping/pong；

    （3）熱裝載能力，例如很多服務(wù)的relOAd功能；

    （4）高可用性以及故障恢復(fù)能力，例如MySQL的高可用配置，以及其binlog的恢復(fù)能力；

    （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等），并能利用其編程能力將工程能力提到三種能力程序化，并進(jìn)一步實(shí)現(xiàn)自動(dòng)化；

    （4）了解工作場景和業(yè)務(wù)場景，以及業(yè)務(wù)的關(guān)鍵指標(biāo)，使DevOps工作有的放矢，貼近業(yè)務(wù)。

    評估DevOps是否合格的標(biāo)準(zhǔn)：

    （1）具備DevOps能力模型提到的各項(xiàng)要求；

    （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和通用語言進(jìn)行廣泛的DevOps的工作，可以完成完整的業(yè)務(wù)流程的定義和開發(fā)，能夠熟練抽象并編寫供其他DevOps使用的接口。

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

    理論的東西說完了，下面是探討下Dev和Ops的現(xiàn)狀，Ops的演進(jìn)，Dev的演進(jìn)以及三項(xiàng)補(bǔ)充內(nèi)容。

    Dev和Ops的現(xiàn)狀

    Dev和Ops是實(shí)踐性的工作，因此即便不是一名DevOps，或許你也在做著Dev或者Ops的工作。只是這不是真正的DevOps。讓我們看兩個(gè)場景：

    （1）Dev的風(fēng)格是力求用Python/Ruby這類通用編程語言整合一堆的API，實(shí)現(xiàn)一套大系統(tǒng)，搞定一切Ops的工作；他們每天的工作就是在找Libs和看各種API的文檔，滿腦子設(shè)計(jì)思想。這種思維是Dev思維；

    （2）Ops的風(fēng)格是力求從命令行的角度，甚至腳本都不用，一行一行的把命令敲下去完成工作；或者快速的寫一個(gè)一次性腳本搞定；他們還喜歡自己編譯各種系統(tǒng)，滿世界下源碼包，喜歡自己搞幾個(gè)參數(shù)優(yōu)化一下；他們只關(guān)心當(dāng)下的結(jié)果，不關(guān)心以后的重復(fù)利用和持續(xù)集成。

    這是我以前的工作中遇到的真實(shí)情況。

    現(xiàn)在情況變了，自從Dev和Ops弄在一起變成DevOps后，又出現(xiàn)了幾個(gè)自動(dòng)化工具，搞的現(xiàn)在Dev不好好寫代碼了，Ops也不好好的寫命令行，都去學(xué)習(xí)自動(dòng)化工具去了。

    這不是DevOps的王道。這是錯(cuò)誤的。

    即便把所有的自動(dòng)化工具，不管是Ansible還是Puppet或者其他學(xué)的再熟，也只是學(xué)會了一個(gè)工具而已，很可能DevOps沒當(dāng)成，卻變成工具的奴隸。

    DevOps是先有思想，而后有工具。

    現(xiàn)在崇尚工具的思路是非�？膳碌�，很多初學(xué)者誤以為學(xué)會了這些自動(dòng)化工具就可以把運(yùn)維做好，而忽視基本功的學(xué)習(xí)，空學(xué)工具，只重其招，不重其義。

    下面分享下兩者的演進(jìn)。

    Ops的演進(jìn)

    案例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ù)很是自得，屢試不爽。

    時(shí)至今日這種方法仍然在很多初學(xué)者那里非常流行，而這種做法就是嚴(yán)重的反DevOps的做法。

    案例2：以給Nginx增加一個(gè)虛擬站點(diǎn)www.devops.org為例，很多初學(xué)者一上來就打開nginx.conf開始改，這同樣是嚴(yán)重反DevOps的。

    這可能是因?yàn)橐粊韓ginx官方文檔是這么改的，二來很多文章也是這么轉(zhuǎn)載，或者原創(chuàng)這么寫的。

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

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

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

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

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

圖1 RPM包結(jié)構(gòu)

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

    至少我們可以看出Redhat的潛在建議是讓我們把新的站點(diǎn)放在conf.d下面，我建議的命名是www.devops.org.conf。

    那么問題來了，如果我要暫時(shí)關(guān)閉這個(gè)站點(diǎn)怎么辦呢？在這個(gè)結(jié)構(gòu)下，我們只要把www.devops.org.conf從conf.d里移出來再reload一下就可以了……對，是移出來，不是刪除。因?yàn)槲覀兒竺婵赡苓�要用。

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

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

圖2 RPM包結(jié)構(gòu)

    把站點(diǎn)放在sites-*里。available里放置所有站點(diǎn)的配置文件，通過符號連接到enabled目錄下啟用。

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

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

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

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

    如果沒有Ops的演進(jìn)，再牛X的Dev他也無法完成自動(dòng)批量管理以上的業(yè)務(wù)需求。

    Dev的演進(jìn)

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

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

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

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

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

    我認(rèn)為這是Dev要借鑒的，也是思想上最大的差別。

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

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

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

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

    （1）試做一個(gè)有經(jīng)驗(yàn)的Ops，放下編程語言，從命令行開始，從Shell開始；

    （2）理解操作系統(tǒng)的哲學(xué)，Unix-like下管道連接一切命令，文件代表一切配置；

    （3）理解Ops的核心指標(biāo)，比如高可用，兼容穩(wěn)定，可重入，故障容災(zāi)；

    （4）在堅(jiān)持Ops-style的前提下，通過程序設(shè)計(jì)思想將DevOps的代碼腳本的產(chǎn)出層次化，模塊化，使之達(dá)到高復(fù)用；

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

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

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

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

    基于ssh；

    基于Agent（姑且認(rèn)為是RPC的一種方式）。

    因此Python/Ruby作用是：編排和啟動(dòng)Shell語句的作用；具體實(shí)現(xiàn)功能，則仍是Shell語句。

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

    眾多命令執(zhí)行情況下，ssh效率不高；

    Agent效率雖然高，但是開發(fā)和調(diào)試成本很高，另外Agent對于Ops是透明、不可控的，一線Ops在Agent出了問題后，很難介入調(diào)試。 

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

    結(jié)論：DevOps的落點(diǎn)是Ops，Python/Ruby的落點(diǎn)是shell和commands。

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

    補(bǔ)充2：編程語言在DevOps的意義

    Python/Ruby體現(xiàn)的重要性是程序設(shè)計(jì)的思想，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è)，估計(jì)飯都吃不上，互聯(lián)網(wǎng)也就不存在了。

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

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

    試想如果沒有yum/apt，沒有sed，沒有iptables，沒有virsh這樣的指令，我們是否寸步難行？答案當(dāng)然是肯定的。

    有人說，可以通過c/python/ruby實(shí)現(xiàn)，反正都有api，這是錯(cuò)誤的輪子思路。

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

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

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

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

    （1）提供了統(tǒng)一的調(diào)用方式，并且封裝業(yè)務(wù)邏輯，便于其他腳本使用；

    （2）統(tǒng)一的文件存放位置，便于自動(dòng)加載，管理和備份；

    （3）同時(shí)提供了restore的命令。

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

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

    練手：

    （1）是否可以基于iptables實(shí)現(xiàn)一個(gè)命令，在添加一條iptables規(guī)則時(shí)，先檢測是否存在同樣的規(guī)則，避免重復(fù)？

    （2）是否可以基于sed實(shí)現(xiàn)兩個(gè)命令，delete_line和delete_line_by_no：第一個(gè)命令給定一個(gè)表達(dá)式和一個(gè)文件名刪除含有表達(dá)式的行；第二個(gè)命令根據(jù)行號刪除指定文件行？

    （3）實(shí)現(xiàn)一個(gè)命令，安裝memcached，根據(jù)傳入的參數(shù)設(shè)定監(jiān)聽地址，內(nèi)存大小和監(jiān)聽端口等。

核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。

轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/

本文標(biāo)題：DevOps 能力模型、演進(jìn)及案例剖析

本文網(wǎng)址：http://www.ezxoed.cn/html/solutions/14019320495.html