《我眼中的DevOps》要點：
本文介紹了我眼中的DevOps，希望對您有用。如果有疑問，可以聯(lián)系我們。

過去一年以來,一批來自歐美的、不墨守陳規(guī)的系統(tǒng)管理員和開發(fā)人員一直在談?wù)撘粋€新概念：DevOps.DevOps 就是開發(fā)(Development)和運維(Operations)這兩個領(lǐng)域的合并.(如果沒錯的話,DevOps還包括產(chǎn)品管理、 QA、*winces* 甚至銷售等領(lǐng)域)

 

脫節(jié)(The Broken)

那么……為什么要合并這兩個領(lǐng)域?原因很多,但首要原因是：我們目前的工作流程是脫節(jié)的.絕對的脫節(jié).很多公司的開發(fā)部門和運維部門之間存在的深刻矛盾,其實就是這個“脫節(jié)”造成的.(意譯,求斧正)

下面是一個大家都基本熟悉的例子：部署軟件產(chǎn)品.

開發(fā)部門要開發(fā)一款新產(chǎn)品.這款產(chǎn)品要使用最新最炫的技術(shù),來保證客戶的所有花俏的需求,從而給公司帶來百萬美元的利潤.這款產(chǎn)品被要求使用最新的技術(shù)和運行平臺,還得馬上交付.于是開發(fā)部門沒日沒夜的加班、趕代碼(cuts code like crazy),終于如期完成了任務(wù).然后他們把自己的“杰作”一股腦的甩給了運維部門,后者還沒能完全接手,前者已經(jīng)迫不及待的開始了慶功會.

接到產(chǎn)品后,運維部門每個人的心中都充滿了恐懼.

下面就是運維部門的恐懼之源：({A.B.C}表示A或B或C之一)

• 這款優(yōu)秀的產(chǎn)品在目前的底層平臺上無法運行,因為這個平臺{太古老了,空間不足,不支持某某版本}
• 這款產(chǎn)品的體系結(jié)構(gòu)跟我們的{存儲,網(wǎng)絡(luò),部署,安全}模型不匹配.
• 這款產(chǎn)品的{ 報告,安全,監(jiān)視,備份,服務(wù)提供} 我們搞不懂 ,所以沒法把它做成實際可用的產(chǎn)品.

盡管伴隨著不絕于耳的抱怨和咒罵,運維部門最終還是把這款產(chǎn)品安裝好了.不幸的是,由于做了很多蹩腳的修改和不合理的強迫式運行,這款產(chǎn)品的性能最后被歸結(jié)為：終極失敗(Epic Fail).

于是非常沮喪的運維部門開始記錄各種問題,源源不斷的給開發(fā)部門提Issue.而開發(fā)部門的回應(yīng)基本上都是：

• 這不是我們的錯 —— 我們的代碼非常完美——而是(運維部門的)部署做的太差勁了.
• 運維部門比較笨,他們不懂新技術(shù)—— 為什么他們沒法實現(xiàn)最新的技術(shù)呢?為什么他們這么落伍呢?
• 在我的機器上運行的沒問題啊……

兩個部門之間的交流很快變成了一場暴風(fēng)驟雨.客戶(以及股東、投資方和管理層)則成了蒙受損失的失敗方.最終公司損失了無數(shù)的金錢,大家也都失業(yè)了.終極的失敗.

DevOps 又有啥不同?它有什么好處?

DevOps 就是想方設(shè)法的避免這種“終極失敗”,同時讓大家用更聰明更有效的方式去工作.它是一種框架,包含了很多優(yōu)秀想法和原則,它鼓勵開發(fā)部門和運維部門通力合作.在DevOps環(huán)境中,開發(fā)人員和系統(tǒng)管理員會構(gòu)建一些關(guān)系、流程和工具,從而更好的與客戶互動,最終提供更好的服務(wù).

DevOps 也不僅僅是一種軟件的部署方法.它通過一種全新的方式,來思考如何讓軟件的作者(開發(fā)部門)和運營者(運營部門)進行合作與協(xié)同.使用了DevOps模型之后,會使兩個部門更好的交互,使兩者的關(guān)系得到改善,從而讓很多領(lǐng)域從中受益,例如：自動化、監(jiān)視、能力規(guī)劃和性能、備份與恢復(fù)、安全、網(wǎng)絡(luò)以及服務(wù)提 供(provisioning)等等.

“對于DevOps是什么?” 這個問題,DevOps社區(qū)中的每個人的回答都不盡相同.因為我們的工作經(jīng)驗不同,關(guān)注的問題也不同.就我個人而言,DevOps分成四大部分：

簡單

KISS(Keep it Simple and Stupid,簡單就是美)原則是最重要的.所以本段文字也很簡單.我們要盡量提供簡單、可重用的解決方案.“簡單”節(jié)約了書寫文檔、培訓(xùn)和提供支持的時間.“簡單”增加了溝通的速度、避免混淆、減少了開發(fā)和運維出錯時的風(fēng)險.“簡單”讓人更快的發(fā)布產(chǎn)品.

部門之間關(guān)系

早參與,多參與.對于開發(fā)人員,要讓運維人員常駐到開發(fā)部門,全程參與開發(fā)流程.邀請運維人員參與你的Scrum或者開發(fā)會議,與他們分享項目計劃、分享新技術(shù)的點子和心得.搜集功能性需求(指開發(fā)人員用到的需求)的同時也要搜集運維方面的需求.把對于“發(fā)布、備份、監(jiān)控、安全、配置管理和系統(tǒng)功能”的測試作為一項獨立的項目流程.軟件產(chǎn)品在開發(fā)時解決的問題越多,那么在使用時暴露給用戶的問題就越少.給運維人員做培訓(xùn),讓他們弄清楚項目的體系結(jié) 構(gòu)和核心代碼.如果運維人員在反饋bug時提供的信息越多,那么你花在排查問題(trouble-shooting) 的時間就越少,這個bug也就會更快的被解決掉.

對于運維人員,在遇到問題時需要把開發(fā)人員加進來,大家一起解決問題.邀請開發(fā)人員參與你們的會議,分享項目進度(roadmaps),并且共同修訂工作計劃.運維人員一定要了解開發(fā)部門下一步的工作方向,從而確保產(chǎn)品運行的底層平臺能夠良好的支持最新技術(shù).開發(fā)人員也會帶來相關(guān)的技術(shù)、知識和工 作,幫助你們改善產(chǎn)品的運行環(huán)境,使其更加易于維護、簡潔有效.

有一些開發(fā)領(lǐng)域的概念,例如：“要根據(jù)API而非封閉的interface來構(gòu)建工具”,分布式版本控制,驅(qū)動測試開發(fā),以及諸如敏捷開發(fā)、看板管理(Kanban)和Scrum等方法論.如果把這些概念應(yīng)用在運維領(lǐng)域,同樣會產(chǎn)生革命性的變革.

不要懼怕新點子和新技術(shù).我們可以隨時隨地的向他人學(xué)習(xí),哪怕是一句“我們再也不要那樣做了!”也會讓我們從中獲益.盡管處于不同的部門,但是我們要共同學(xué)習(xí)、共同成長,這樣才能協(xié)同工作的更好!

按照從高到低的順序,有效的溝通方式應(yīng)該是：面對面交流 、視頻會議、電話、即時通訊軟件、Email.

工作中的流程

有自己的流程管理(process engineering)—— 從原始的筆錄到 ISO9001.但它們都存在一個關(guān)鍵的缺陷：過于理想化,它要求每個步驟都必須成功執(zhí)行.例如：為了搭建一臺新主機,會有下列一套簡單的流程：

• 步驟一：裝機(把各個硬件組裝到一起).
• 步驟二：接線、通電.
• 步驟三：安裝操作系統(tǒng).
• 接下來還有步驟四、五、六.

如果一切順利的話,第N步結(jié)束之后就會有一個功能完整、運行正常的新主機.但萬一有個流程沒跑通怎么辦?比如說在某個步驟斷了,走不下去了,或者在這一步得到了異常的輸出,有沒有另外的步驟來處理這個異常?

所以,流程絕對不會從頭到尾一帆風(fēng)順,所以我們要把每一步流程都認(rèn)真對待,找出所有潛在的問題和障礙.跟軟件產(chǎn)品一樣,在流程的管理中也要有異常處理.我們不必做到精確預(yù)見每一個問題,但一定要保證：即使流程出錯,它還能往下走.

把不同領(lǐng)域的所有流程串到一起.這些領(lǐng)域包括：部署、監(jiān)控、能力計劃(capacity planning) 等等.從邏輯上講,“部署”是軟件開發(fā)周期的最后一環(huán),所以它應(yīng)該屬于“開發(fā)流程”,而非“運維流程”.另一個例子是度量和監(jiān)控.在開發(fā)領(lǐng)域,如果不理解 底線標(biāo)準(zhǔn)和估算,就什么評估都做不了.把開發(fā)部門和運維部門的流程銜接在一起,也會讓兩個部門更好的配合、相互理解、承擔(dān)共同的責(zé)任.最后還有個優(yōu)點：文 檔只需要一份而不是兩份(開發(fā)一份、運維一份),從而節(jié)省了資金.

自動化,自動化,還是自動化.構(gòu)建或使用簡單、可擴展的工具(確保提供API, 機器可讀的輸入、輸出 — 參考 James White的文章：Infrastructure Manifesto).使用Puppet一 類的工具做配置管理.要擴展這些自動化工具,使其能夠支持多個領(lǐng)域(開發(fā)領(lǐng)域和運維領(lǐng)域),并且在產(chǎn)品的不同環(huán)境(開發(fā)環(huán)境、測試環(huán)境、發(fā)布環(huán)境和生產(chǎn)環(huán) 境)中使用相同的工具(也叫end-to-end).這樣不但會在產(chǎn)品支持和管理方面帶來經(jīng)濟效益,而且也可以在編寫新代碼的同時,進行產(chǎn)品的發(fā)布和管 理.

最后,在構(gòu)建流程和自動化時,要把KISS原則牢記于心.越復(fù)雜就越易錯.只有簡單的流程和工具才易于實現(xiàn)、易于管理和易于維護.

持續(xù)改進

不要停止創(chuàng)新和學(xué)習(xí).當(dāng)今技術(shù)發(fā)展的很快,客戶的需求也往往如此.把“持續(xù)改進和持續(xù)集成” 加入到你的工具和流程中去,這也是運維人員向(優(yōu)秀的)開發(fā)人員學(xué)習(xí)的好途徑,可以學(xué)到諸如測試驅(qū)動開發(fā)等最佳實踐.例如：可以向你的部署流程中加入單元測試.做監(jiān)控時也應(yīng)該增加些行為測試,提高交付質(zhì)量.嘗試用開發(fā)領(lǐng)域中的工具(例如Hudson)在運維領(lǐng)域中做些工作(例如瀏覽數(shù)據(jù)(explore)、測量性能(measure)等等).

要不斷的總結(jié)教訓(xùn).要積極主動的、在不同領(lǐng)域?qū)ふ义e誤的根源. 一旦收到錯誤報告,就果斷把開發(fā)小組和運維小組找來,一起解決這個問題.有時候開發(fā)人員很簡單的幾次代碼重構(gòu),就可以很好的避免底層運行環(huán)境的改變,減少 運維人員的負(fù)擔(dān).總之,遇到問題時,開發(fā)部門和運維部門要密切配合、共同解決,而不是互相推諉、踢皮球.

對我來說…

最后,對我來說,DevOps 的主要內(nèi)容是：跟誰共同工作、如何共同工作.它最吸引我的地方就是致力于把不同部門不同分工的人召集到一起,共同努力解決問題.這樣的工作環(huán)境,是我所憧憬的樂園.

作者 James Turnbull ,譯者 申思維

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