如果你對(duì)IT管理感興趣,，尤其是對(duì)Web運(yùn)維感興趣，那么最近一定會(huì)注意到“DevOps”這一熱詞的出現(xiàn)?，F(xiàn)在#DevOps標(biāo)簽頻繁出現(xiàn)在微博客Twitter上,，同時(shí)DevOps相關(guān)的技術(shù)交流聚會(huì)也在慢慢增多,。

DevOps在很大程度上是一個(gè)集合性概念,，指的是能夠理順開發(fā)和運(yùn)維之間相互配合關(guān)系的任何事物。但是DevOps背后的理念要比上述說(shuō)法更深遠(yuǎn),。

什么是DevOps,？

人們?cè)絹?lái)越意識(shí)到傳統(tǒng)意義上的開發(fā)行為和運(yùn)維行為存在脫節(jié)現(xiàn)象，從而導(dǎo)致沖突和低效,，因此DevOps應(yīng)運(yùn)而生,。

正如李·湯普森（Lee Thompson）和安德魯·謝福爾（Andrew Shafer）所言，在開發(fā)和運(yùn)維之間存在一面“混亂之墻”,。相互沖突的動(dòng)機(jī),、流程和工具導(dǎo)致了這面“墻”的存在。

以開發(fā)為中心的人通常認(rèn)為,，變化會(huì)帶來(lái)回報(bào),。企業(yè)依靠他們來(lái)應(yīng)對(duì)不斷變化的需求。因此他們被鼓勵(lì)盡可能進(jìn)行變革,。

而運(yùn)維人員則往往視變化為敵人,。企業(yè)依靠他們維持正常業(yè)務(wù)運(yùn)維和實(shí)施讓企業(yè)賺錢的服務(wù)。由于變化會(huì)影響穩(wěn)定性和可靠性，運(yùn)維業(yè)務(wù)有理由對(duì)它說(shuō)不,。我們已經(jīng)多次聽到過(guò)如下統(tǒng)計(jì)數(shù)字：在所有宕機(jī)事件中有80%情況是源于自殺式的改變,。

開發(fā)人員和運(yùn)維人員認(rèn)識(shí)世界的方法，以及各自所處的角色,，存在根本性的差別,。他們都認(rèn)為自己的做法是正確的。的確,，孤立的來(lái)看他們都是正確的,。

更糟糕的是，開發(fā)和運(yùn)維團(tuán)隊(duì)通常處于公司組織架構(gòu)的不同部分,，通常具有不同管理者的和競(jìng)爭(zhēng)關(guān)系,，而且通常工作在不同的地點(diǎn)。

讓混亂之墻更堅(jiān)固的還包括開發(fā)和運(yùn)維工具之間的錯(cuò)位,?？匆幌麻_發(fā)者要求和日常使用的常見工具，再看一下系統(tǒng)管理員,，你會(huì)發(fā)現(xiàn)兩者存在很大不同,，開發(fā)人員沒有興趣使用運(yùn)維人員的工具，反之亦然,；而且兩部分工具之間也不存在重要的集成,。即使在某些工具類型上有一些重疊之處，使用方式也完全不同,。

當(dāng)應(yīng)用程序變動(dòng)需要從開發(fā)團(tuán)隊(duì)推向運(yùn)維團(tuán)隊(duì)時(shí),，混亂之墻的存在則將變得更加明顯。有人將其稱為一個(gè)“版本發(fā)布（Release）”,，有人則稱其為一次“部署（deployment）”,，但有一件事情是公認(rèn)的，問(wèn)題可能會(huì)隨之而來(lái),。下圖雖然是一個(gè)抽象化場(chǎng)景,，但是如果你經(jīng)歷過(guò)這一過(guò)程，一定會(huì)感覺到它的真實(shí)性,。

開發(fā)人員把一個(gè)軟件版本“扔”給墻對(duì)面的運(yùn)維人員,。后者拿到該版本產(chǎn)品后開始準(zhǔn)備將其部署。運(yùn)維人員手動(dòng)修改由開發(fā)者提供的部署腳本或創(chuàng)建自己的腳本,。他們還需要修改配置文件來(lái)適應(yīng)與開發(fā)環(huán)境大不相同的真實(shí)生產(chǎn)環(huán)境,。最完美的情況是，他們重復(fù)在此前環(huán)境中已完成的工作,；而糟糕的情況是,，他們將引入或發(fā)現(xiàn)新的漏洞,。

運(yùn)維人員然后開始進(jìn)行他們自認(rèn)為正確的部署過(guò)程。由于開發(fā)和運(yùn)維之間的腳本,、配置,、過(guò)程和環(huán)境存在差別，這一部署過(guò)程實(shí)際上也是首次被執(zhí)行,。當(dāng)然,，期間如果發(fā)生一個(gè)問(wèn)題，開發(fā)人員會(huì)被要求來(lái)幫助進(jìn)行排障,。運(yùn)維人員會(huì)說(shuō)開發(fā)團(tuán)隊(duì)給的產(chǎn)品存在問(wèn)題,。而開發(fā)人員則會(huì)回應(yīng)稱該產(chǎn)品在他們的環(huán)境下運(yùn)行良好，因此一定是運(yùn)維人員在部署的過(guò)程中做錯(cuò)了什么,。由于配置,、文件存儲(chǔ)位置和過(guò)程的不同，開發(fā)人員診斷問(wèn)題也并非一件易事,。

沒有一個(gè)可靠的方式來(lái)把環(huán)境回滾到此前已知的正常狀態(tài),。本來(lái)應(yīng)該一帆風(fēng)順的部署過(guò)程最后變成一場(chǎng)救火行動(dòng)，經(jīng)過(guò)反復(fù)測(cè)試之后才讓生產(chǎn)環(huán)境恢復(fù)到正常狀態(tài),。

部署階段已經(jīng)非常明顯的需要DevOps理念來(lái)解決問(wèn)題,，但需要DevOps的絕不僅僅是這一階段。正如約翰·阿爾斯帕瓦（John Allspaw）所指出的那樣,，開發(fā)和運(yùn)維之間的協(xié)作需求在部署之前就已存在,，同時(shí)也會(huì)在部署之后的長(zhǎng)時(shí)間之內(nèi)繼續(xù)存在。

DevOps所帶來(lái)的好處

DevOps是一個(gè)非常強(qiáng)大的概念,，因?yàn)樗梢栽诒姸嗖煌瑢用嫔袭a(chǎn)生共鳴,。

從開發(fā)或運(yùn)維的一線人員的觀點(diǎn)來(lái)看，DevOps可以讓他們從眾多煩惱中解脫出來(lái),。它雖然不是具有魔力的萬(wàn)靈藥,，但是如果你能夠讓DevOps奏效,，則會(huì)節(jié)省大量時(shí)間,，而且不至于打擊自己的士氣。顯而易見,，投入精力將DevOps落到實(shí)處,，我們應(yīng)該會(huì)更加高效、更加敏捷和減少挫敗感,。有些人可能會(huì)反駁稱DevOps是一個(gè)遙不可及的目標(biāo),，但這并非說(shuō)我們不應(yīng)該去嘗試實(shí)現(xiàn)它。

對(duì)于企業(yè)來(lái)說(shuō),，DevOps直接有助于實(shí)現(xiàn)兩個(gè)強(qiáng)大戰(zhàn)略性企業(yè)品質(zhì),，“業(yè)務(wù)敏捷性”和“IT融合”。它們可能不是IT人士所擔(dān)憂的事情，但是卻應(yīng)該獲得掌握財(cái)政大權(quán)的管理者的注意,。

IT融合的一個(gè)簡(jiǎn)單定義是,，“企業(yè)渴望達(dá)到的一個(gè)狀態(tài)，能夠高效的使用信息技術(shù)來(lái)達(dá)到企業(yè)目標(biāo)——通常是提高公司業(yè)績(jī)或市場(chǎng)競(jìng)爭(zhēng)力,。”

通過(guò)從共同企業(yè)目標(biāo)角度出發(fā)來(lái)校準(zhǔn)開發(fā)和運(yùn)維的職責(zé)和流程,，DevOps有助于實(shí)現(xiàn)IT融合。開發(fā)和運(yùn)維人員需要明白,，它們僅僅是一個(gè)統(tǒng)一業(yè)務(wù)流程中的一部分,。DevOps思想確保個(gè)體決策和行為應(yīng)力求支持和改進(jìn)這個(gè)統(tǒng)一的業(yè)務(wù)流程，無(wú)論你是來(lái)自哪一個(gè)組織架構(gòu),。

業(yè)務(wù)敏捷性的一個(gè)簡(jiǎn)單定義是,，“一個(gè)機(jī)構(gòu)以高效、經(jīng)濟(jì)的方式迅速適應(yīng)市場(chǎng)和環(huán)境變化的能力,。”

當(dāng)然對(duì)于開發(fā)人員來(lái)說(shuō),，“敏捷”有專門的含義，但目標(biāo)是非常類似的,。敏捷開發(fā)方法旨在保持軟件開發(fā)工作與客戶/公司的目標(biāo)同步,，盡管需求不斷變化，也可以產(chǎn)生高品質(zhì)軟件,。對(duì)于多數(shù)機(jī)構(gòu)來(lái)說(shuō),，迭代項(xiàng)目管理方法Scrum是敏捷的代名詞。

業(yè)務(wù)敏捷性承諾,，在企業(yè)權(quán)益集團(tuán)作出決策和開發(fā)者進(jìn)行響應(yīng)之間能夠緊密互動(dòng)和快速反饋,。看一下一家運(yùn)轉(zhuǎn)良好的敏捷開發(fā)團(tuán)體的產(chǎn)品,，你會(huì)看到一個(gè)與業(yè)務(wù)需求保持一致的穩(wěn)定持續(xù)改進(jìn),。

但是，當(dāng)你從企業(yè)角度回顧一下整個(gè)開發(fā)-運(yùn)維周期,，敏捷方法的相關(guān)優(yōu)勢(shì)通常會(huì)變得非常模糊,。混亂之墻導(dǎo)致了應(yīng)用程序生命周期的分裂,。開發(fā)和運(yùn)維分別按照不同的節(jié)奏進(jìn)行,。實(shí)際上，產(chǎn)品部署之間的長(zhǎng)期間隔使得一個(gè)團(tuán)體的敏捷工作變成了它一直試圖避免的瀑布生命周期,。當(dāng)存在混亂之墻時(shí),，無(wú)論開發(fā)團(tuán)體有多么敏捷，改變企業(yè)緩慢和遲鈍的特點(diǎn)是極其困難的,。

DevOps使得敏捷開發(fā)的優(yōu)勢(shì)可以體現(xiàn)在機(jī)構(gòu)層面上,。通過(guò)考慮到快速,、反應(yīng)靈敏但穩(wěn)定的業(yè)務(wù)運(yùn)維，使其能夠與開發(fā)過(guò)程的創(chuàng)新保持同步,，DevOps可以做到這一點(diǎn),。

如果你希望在自己的組織內(nèi)建立一個(gè)DevOps項(xiàng)目，務(wù)必牢記“IT融合” 和“業(yè)務(wù)敏捷性”,。

如何將DevOps落到實(shí)處,？

和多數(shù)新出現(xiàn)的話題一樣，發(fā)現(xiàn)問(wèn)題的共性特點(diǎn)要比找到解決方案容易的多,。

要想實(shí)現(xiàn)DevOps相關(guān)解決方案,，以下三方面需要關(guān)注：

1、評(píng)價(jià)和鼓勵(lì)改變文化

改變文化和激勵(lì)系統(tǒng)從來(lái)不是一件易事,。但是,，如果你不改變企業(yè)文化，兌現(xiàn)DevOps的承諾將非常困難,?？疾煲粋€(gè)企業(yè)的主導(dǎo)文化時(shí)，你需要緊密關(guān)注如何評(píng)價(jià)和判斷企業(yè)業(yè)績(jī),。評(píng)價(jià)的內(nèi)容將影響和刺激行為的發(fā)生,。開發(fā)-運(yùn)維生命周期中的所有當(dāng)事方需要明白，在更大的企業(yè)流程中自己只是其中一部分,。個(gè)體和團(tuán)隊(duì)的成功都要放在整個(gè)開發(fā)-運(yùn)維生命周期內(nèi)來(lái)進(jìn)行評(píng)價(jià),。對(duì)于許多機(jī)構(gòu)來(lái)說(shuō)，這是一個(gè)轉(zhuǎn)變,，不再是孤立的來(lái)進(jìn)行業(yè)績(jī)?cè)u(píng)價(jià),，每一個(gè)團(tuán)隊(duì)不再是基于自己的團(tuán)隊(duì)來(lái)評(píng)價(jià)和判斷業(yè)績(jī)好壞。

2,、統(tǒng)一標(biāo)準(zhǔn)化的流程

這是DevOps的一個(gè)重要主題,，整個(gè)開發(fā)-運(yùn)維生命周期必須被看作一個(gè)端對(duì)端過(guò)流程。流程的不同階段可以采取不同的方法,，只要這些流程可以被組合到一起創(chuàng)建一個(gè)統(tǒng)一的流程,。與評(píng)價(jià)和激勵(lì)的問(wèn)題相似的是，實(shí)現(xiàn)這個(gè)統(tǒng)一的流程時(shí)每個(gè)組織可能會(huì)有略微不同的需求,。

3,、統(tǒng)一的工具

這是大多數(shù)DevOps討論一直在關(guān)注的領(lǐng)域,。這一點(diǎn)不令人吃驚,，因?yàn)楫?dāng)技術(shù)專家在考慮解決一個(gè)問(wèn)題時(shí)，第一反應(yīng)往往就是直接跳轉(zhuǎn)到工具討論上,。如果你關(guān)注Puppet,、Chef或ControlTier等工具社區(qū),，那么你可能已經(jīng)意識(shí)到人們對(duì)在開發(fā)和運(yùn)維工具之間建立橋梁的重大關(guān)注。“基礎(chǔ)設(shè)施即代碼（Infrastructure as code）”,、“模型驅(qū)動(dòng)自動(dòng)化（model driven automation）”和“持續(xù)性部署（continuous deployment）”都是可以劃歸DevOps旗下的概念,。

關(guān)于把DevOps變?yōu)楝F(xiàn)實(shí)需要哪些類型的工具，杰克·索羅夫曼（Jake Sorofman）提出如下建議：

一個(gè)版本控制軟件庫(kù)

它可以確保所有系統(tǒng)產(chǎn)品在整個(gè)版本發(fā)布生命周期中被很好的定義,，且能夠?qū)崿F(xiàn)一致性共享,，同時(shí)保持最新信息。開發(fā)和QA機(jī)構(gòu)能夠從中取得相同平臺(tái)版本,，生產(chǎn)機(jī)構(gòu)部署已經(jīng)被QA機(jī)構(gòu)驗(yàn)證過(guò)的相同版本,。

深層模型系統(tǒng)

它的版本系統(tǒng)清晰的描述了軟件系統(tǒng)相關(guān)的所有組件、策略和依賴性,，從而可以簡(jiǎn)單的根據(jù)需要復(fù)制一個(gè)系統(tǒng)或在無(wú)沖突的情況下引入變化,。

人工任務(wù)的自動(dòng)化

在依賴關(guān)系發(fā)現(xiàn)、系統(tǒng)構(gòu)造,、配置,、更新和回滾等過(guò)程中，減少人工干涉,。自動(dòng)操作變?yōu)楦咚?、無(wú)沖突和大規(guī)模系統(tǒng)管理的命令和控制基礎(chǔ)。

在從開發(fā)到運(yùn)維的生命周期中存在許多不同的工具,。工具選擇和執(zhí)行決策需要根據(jù)它們對(duì)端到端生命周期的影響來(lái)決定,。

關(guān)于DevOps的澄清

現(xiàn)在某些系統(tǒng)管理員正在試圖把自己的崗位名稱改為“DevOps”。但是,，DevOps不應(yīng)該是一個(gè)單一的位置或職稱,。把DevOps變成一個(gè)新職位名稱或特定角色是一件非常危險(xiǎn)的事情。例如這會(huì)導(dǎo)致以下錯(cuò)誤端點(diǎn)：你是一個(gè)DBA,？或者是一個(gè)安全專家,？那么不用擔(dān)心DevOps，因?yàn)槟鞘荄evOps團(tuán)隊(duì)的問(wèn)題,。

設(shè)想一下,，你不會(huì)說(shuō)“我需要招聘一個(gè)Agile”或“我需要招聘一個(gè)Scrum”或“我需要招聘一個(gè)ITIL”，而只是會(huì)說(shuō)需要招聘了解這些概念或方法的開發(fā)人員,、項(xiàng)目經(jīng)理,、測(cè)試人員或系統(tǒng)管理員。DevOps也是同樣道理,。

與DevOps具有相同理念的術(shù)語(yǔ)很多,，例如敏捷運(yùn)維（Agile Operations）、敏捷基礎(chǔ)設(shè)施（Agile Infrastructure）和Dev2Ops,。還有很多人雖然沒有提及“DevOps”,，但卻在遵循著類似的理念,。