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

在許多方面，DevOps是一個(gè)集合性概念，指的是能夠理順開發(fā)和運(yùn)維之間相互配合關(guān)系的任何事物（51CTO編輯注：在英文中，Developer指開發(fā)者，Operations指運(yùn)維，所以DevOps一詞本身含有開發(fā)+運(yùn)維的意思）。但是DevOps背后的理念要比上述說法更深遠(yuǎn)。

51CTO推薦專題：SA，神仙與裝機(jī)男：運(yùn)維的工作到底啥樣兒？

什么是DevOps？

人們越來越意識(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ā)與運(yùn)維之間的“混亂之墻”

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

而運(yùn)維人員則往往視變化為敵人。企業(yè)依靠他們維持正常業(yè)務(wù)運(yùn)維和實(shí)施讓企業(yè)賺錢的服務(wù)。由于變化會(huì)影響穩(wěn)定性和可靠性，運(yùn)維業(yè)務(wù)有理由對它說不。我們已經(jīng)多次聽到過如下統(tǒng)計(jì)數(shù)字：在所有宕機(jī)事件中有80%情況是源于自殺式的改變（根據(jù)51CTO之前進(jìn)行的調(diào)查，很多時(shí)候，僅僅是給系統(tǒng)應(yīng)用補(bǔ)丁就會(huì)造成生產(chǎn)服務(wù)器無法正常重啟）。

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

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

開發(fā)與運(yùn)維通常工作在不同的地點(diǎn)

讓混亂之墻更堅(jiān)固的還包括開發(fā)和運(yùn)維工具之間的錯(cuò)位。看一下開發(fā)者要求和日常使用的常見工具，再看一下系統(tǒng)管理員，你會(huì)發(fā)現(xiàn)兩者存在很大不同，開發(fā)人員沒有興趣使用運(yù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)的，問題可能會(huì)隨之而來。下圖雖然是一個(gè)抽象化場景，但是如果你經(jīng)歷過這一過程，一定會(huì)感覺到它的真實(shí)性。

應(yīng)用程序變動(dòng)從開發(fā)到運(yùn)維

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

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

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

本來應(yīng)該一帆風(fēng)順的部署過程***變成一場救火行動(dòng)

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

#p#

DevOps所帶來的好處

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

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

DevOps會(huì)節(jié)省大量的時(shí)間

對于企業(yè)來說，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è)簡單定義是，“企業(yè)渴望達(dá)到的一個(gè)狀態(tài)，能夠高效的使用信息技術(shù)來達(dá)到企業(yè)目標(biāo)——通常是提高公司業(yè)績或市場競爭力。”

通過從共同企業(yè)目標(biāo)角度出發(fā)來校準(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ù)流程，無論你是來自哪一個(gè)組織架構(gòu)。

DevOps有助于實(shí)現(xiàn)IT融合

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

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

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

敏捷的開發(fā)與瀑布式企業(yè)結(jié)構(gòu)的步調(diào)不同

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

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

#p#

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

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

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

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

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

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

這是DevOps的一個(gè)重要主題，整個(gè)開發(fā)-運(yùn)維生命周期必須被看作一個(gè)端對端過流程。流程的不同階段可以采取不同的方法，只要這些流程可以被組合到一起創(chuàng)建一個(gè)統(tǒng)一的流程。與評(píng)價(jià)和激勵(lì)的問題相似的是，實(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è)問題時(shí)，***反應(yīng)往往就是直接跳轉(zhuǎn)到工具討論上。如果你關(guān)注Puppet、Chef或ControlTier等工具社區(qū)，那么你可能已經(jīng)意識(shí)到人們對在開發(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è)版本控制軟件庫

它可以確保所有系統(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)證過的相同版本。

深層模型系統(tǒng)

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

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

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

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

關(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ì)的問題。

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

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

原文：http://dev2ops.org/blog/2010/2/22/what-is-devops.html

【編輯推薦】

1. 高效程序員的45個(gè)習(xí)慣：敏捷開發(fā)修煉之道
2. 開發(fā)者與系統(tǒng)管理員的爭執(zhí):不要碰我的生產(chǎn)環(huán)境!
3. 資深系統(tǒng)管理員給Linux/Unix新人們的建議
4. 大型網(wǎng)站運(yùn)維之道漫談
5. SA，神仙與裝機(jī)男：運(yùn)維的工作到底啥樣兒？