• 為什么 DevOps
• 什么是 DevOps
• DevOps 所帶來的好處
• 如何將 DevOps 落到實處？
• 關(guān)于 DevOps 的澄清
• 參考資料

編寫軟件之所以難，是因為沒有哪兩個軟件是完全相同的（這也是人們喜歡編程的原因，解決問題帶給自己的快感），這跟物理、化學(xué)，建筑行業(yè)等等完全不同，而且還是不可見的，物理過程、化學(xué)反應(yīng)至少看得見、摸得著，建筑業(yè)還有圖紙……更要命的是，需求在不斷的變……需求的變化，不僅僅在于客戶改變了想法，而是在當(dāng)今移動互聯(lián)網(wǎng)時代，今天客戶有個銷售活動，明天就要在網(wǎng)站上體現(xiàn)出來……到最后，本來架構(gòu)和設(shè)計良好的軟件，被改得面目全非~于是，人們想到并采用了“敏捷開發(fā)”，從一個原型開始，快速開發(fā)，快速部署，盡早讓客戶看見軟件，然后重構(gòu)，不斷完善……我們說，“Build”這個詞，準(zhǔn)確來說，不是“生成”，而是“構(gòu)建”，也正是編程是一個“搭建”軟件的真正含義~但是“敏捷開發(fā)”主要針對的是開發(fā)過程，可是整個軟件生命周期，開發(fā)只是第一步，還有后來的測試、部署、集成、質(zhì)量保證，我們經(jīng)常能看見開發(fā)軟件與運(yùn)維人員之間永無休止的爭論，這就造成了，開發(fā)與運(yùn)維、質(zhì)量保證的嚴(yán)重脫節(jié)，最近跳槽，測試人員每次找另一個組的開發(fā)人員，每次交流的時間都在2個小時左右（太長了，毫無意義的2個小時），測試人員說這樣，開發(fā)人員不愿意……因此 DevOps 應(yīng)運(yùn)而生，不僅僅開發(fā)要敏捷，運(yùn)維也要敏捷……

事實上，無論是哪方面的“敏捷”，它們都只是一套方法論而已，包括一套指導(dǎo)思想和相應(yīng)的工具（編程跟一些實證科學(xué)，如物理化學(xué)等，相比本身就缺乏一套理論基礎(chǔ)，數(shù)學(xué)基礎(chǔ)，有的也就是方法論了），方法論的最大弱點是，操作性比較差，要想把 DevOps 用起來，實在不容易~

有些人對 DevOps 不爽的原因是“讓開發(fā)人員做運(yùn)維的事”，其實，我倒不覺得，軟件開發(fā)的歷史并不長，還不到100年，還很幼稚，而像物理化學(xué)建筑等人類已經(jīng)有幾千年的歷史，加之硬件發(fā)展的速度實在太快，你會發(fā)現(xiàn)，幾年以前還激動人心的框架或工具，現(xiàn)在已經(jīng)落伍了，今天的 java 跟十年前的 Java 已經(jīng)大不相同了，如果你看了亞馬遜的《架構(gòu)師》的話。另一個方面，往往事情本身并不復(fù)雜，可一牽涉到人，情況就完全不同了，人越多情況越嚴(yán)峻~所以，良好的溝通和項目管理在軟件研發(fā)過程始終都比寫代碼、測試、集成重要的多。

人們越來越意識到傳統(tǒng)意義上的開發(fā)與運(yùn)維之間存在脫節(jié)現(xiàn)象，從而導(dǎo)致沖突和低效，于是 DevOps 應(yīng)運(yùn)而生。

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

以開發(fā)為中心的人通常認(rèn)為，變化會帶來回報。企業(yè)依靠他們來應(yīng)對不斷變化的市場需求（比如，打折、優(yōu)惠），因此他們被鼓勵盡可能進(jìn)行變革；而運(yùn)維人員則往往視變化為敵人，因為，變化會影響穩(wěn)定性和可靠性，運(yùn)維業(yè)務(wù)有理由對它說不。企業(yè)依靠它們維持正常業(yè)務(wù)讓企業(yè)賺錢。我們已經(jīng)多次聽到過如下統(tǒng)計數(shù)字：在所有宕機(jī)事件中有80%情況是源于自殺式的改變。

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

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

讓”混亂之墻“更堅固的還包括開發(fā)和運(yùn)維工具之間的錯位。看一下開發(fā)者與系統(tǒng)管理員日常使用的工具，你會發(fā)現(xiàn)兩者存在很大不同，開發(fā)人員沒有興趣使用運(yùn)維人員的工具，反之亦然；而且它們之間也不存在重要的集成。即使在某些工具類型上有一些重疊，使用方式也完全不同。

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

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

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

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

正如約翰·阿爾斯帕瓦（John Allspaw）所指出的那樣，開發(fā)和運(yùn)維之間的協(xié)作需求在部署之前就已存在，同時也會在部署之后的長時間之內(nèi)繼續(xù)存在。

這就是需要 DevOps 的原因，但需要 DevOps 絕不僅僅是這些。

DevOps（英文 Development 和 Operations 的組合）是一組過程、方法與系統(tǒng)的統(tǒng)稱，用于促進(jìn)軟件開發(fā)、技術(shù)運(yùn)營和質(zhì)量保障（QA）部門之間的溝通、協(xié)作與整合。它的出現(xiàn)是由于軟件行業(yè)日益清晰地認(rèn)識到：為了按時交付軟件產(chǎn)品和服務(wù)，開發(fā)和運(yùn)營工作必須緊密合作。

傳統(tǒng)的軟件組織將開發(fā)、IT運(yùn)營和質(zhì)量保障設(shè)為各自分離的部門。在這種環(huán)境下如何采用新的開發(fā)方法（例如敏捷軟件開發(fā)），這是一個重要的課題：按照從前的工作方式，開發(fā)和部署不需要IT支持或者QA深入的、跨部門的支持，而現(xiàn)在卻需要極其緊密的多部門協(xié)作。然而 DevOps 考慮的還不止是軟件部署。它是一套針對這幾個部門間溝通與協(xié)作問題的流程和方法。

需要頻繁交付的企業(yè)可能更需要對 DevOps 有一個大致的了解。Flickr 發(fā)展了自己的 DevOps 能力，使之能夠支撐業(yè)務(wù)部門“每天部署10次”的要求──如果一個組織要生產(chǎn)面向多種用戶、具備多樣功能的應(yīng)用程序，其部署周期必然會很短。這種能力也被稱為持續(xù)部署，并且經(jīng)常與精益創(chuàng)業(yè)方法聯(lián)系起來。從2009年起，相關(guān)的工作組、專業(yè)組織和博客快速涌現(xiàn)。

DevOps 的引入能對產(chǎn)品交付、測試、功能開發(fā)和維護(hù)（包括──曾經(jīng)罕見但如今已屢見不鮮的──“熱補(bǔ)丁”）起到意義深遠(yuǎn)的影響。在缺乏 DevOps 能力的組織中，開發(fā)與運(yùn)營之間存在著信息“鴻溝”──例如運(yùn)營人員要求更好的可靠性和安全性，開發(fā)人員則希望基礎(chǔ)設(shè)施響應(yīng)更快，而業(yè)務(wù)用戶的需求則是更快地將更多的特性發(fā)布給最終用戶使用。這種信息鴻溝就是最常出問題的地方。

以下幾方面因素可能促使一個組織引入 DevOps：

• 使用敏捷或其他軟件開發(fā)過程與方法
• 業(yè)務(wù)負(fù)責(zé)人要求加快產(chǎn)品交付的速率
• 虛擬化和云計算基礎(chǔ)設(shè)施（可能來自內(nèi)部或外部供應(yīng)商）日益普遍
• 數(shù)據(jù)中心自動化技術(shù)和配置管理工具的普及
• 有一種觀點認(rèn)為，目前占主導(dǎo)地位的“傳統(tǒng)”美國式管理風(fēng)格（“斯隆模型 vs 豐田模型”）[16]會導(dǎo)致“煙囪式自動化”，從而造成開發(fā)與運(yùn)營之間的鴻溝，因此需要DevOps能力來克服由此引發(fā)的問題。

DevOps 經(jīng)常被描述為“開發(fā)團(tuán)隊與運(yùn)營團(tuán)隊之間更具協(xié)作性、更高效的關(guān)系”。由于團(tuán)隊間協(xié)作關(guān)系的改善，整個組織的效率因此得到提升，伴隨頻繁變化而來的生產(chǎn)環(huán)境的風(fēng)險也能得到降低。 

DevOps 是一個非常強(qiáng)大的概念，因為它可以在眾多不同層面上產(chǎn)生共鳴。

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

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

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

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

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

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

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

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

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

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

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

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

• 評價和鼓勵改變文化。改變文化和激勵系統(tǒng)從來不是一件易事。但是，如果你不改變企業(yè)文化，兌現(xiàn) DevOps 的承諾將非常困難。考察一個企業(yè)的主導(dǎo)文化時，你需要緊密關(guān)注如何評價和判斷企業(yè)業(yè)績。評價的內(nèi)容將影響和刺激行為的發(fā)生。開發(fā)-運(yùn)維生命周期中的所有當(dāng)事方需要明白，在更大的企業(yè)流程中自己只是其中一部分。個體和團(tuán)隊的成功都要放在整個開發(fā)-運(yùn)維生命周期內(nèi)來進(jìn)行評價。對于許多機(jī)構(gòu)來說，這是一個轉(zhuǎn)變，不再是孤立的來進(jìn)行業(yè)績評價，每一個團(tuán)隊不再是基于自己的團(tuán)隊來評價和判斷業(yè)績好壞。
• 統(tǒng)一標(biāo)準(zhǔn)化的流程。這是 DevOps 的一個重要主題，整個開發(fā)-運(yùn)維生命周期必須被看作一個端對端過流程。流程的不同階段可以采取不同的方法，只要這些流程可以被組合到一起創(chuàng)建一個統(tǒng)一的流程。與評價和激勵的問題相似的是，實現(xiàn)這個統(tǒng)一的流程時每個組織可能會有略微不同的需求。
• 統(tǒng)一的工具。這是大多數(shù) DevOps 討論一直在關(guān)注的領(lǐng)域。這一點不令人吃驚，因為當(dāng)技術(shù)專家在考慮解決一個問題時，第一反應(yīng)往往就是直接跳轉(zhuǎn)到工具討論上。如果你關(guān)注 Puppet、Chef 或 ControlTier 等工具社區(qū)，那么你可能已經(jīng)意識到人們對在開發(fā)和運(yùn)維工具之間建立橋梁的重大關(guān)注。“基礎(chǔ)設(shè)施即代碼（Infrastructure as code）”、“模型驅(qū)動自動化（model driven automation）”和“持續(xù)性部署（continuous deployment）”都是可以劃歸DevOps 旗下的概念。

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

• 一個版本控制軟件庫。它可以確保所有系統(tǒng)產(chǎn)品在整個版本發(fā)布生命周期中被很好的定義，且能夠?qū)崿F(xiàn)一致性共享，同時保持最新信息。開發(fā)和QA機(jī)構(gòu)能夠從中取得相同平臺版本，生產(chǎn)機(jī)構(gòu)部署已經(jīng)被QA機(jī)構(gòu)驗證過的相同版本。
• 深層模型系統(tǒng)。它的版本系統(tǒng)清晰的描述了軟件系統(tǒng)相關(guān)的所有組件、策略和依賴性，從而可以簡單的根據(jù)需要復(fù)制一個系統(tǒng)或在無沖突的情況下引入變化。
• 人工任務(wù)的自動化。在依賴關(guān)系發(fā)現(xiàn)、系統(tǒng)構(gòu)造、配置、更新和回滾等過程中，減少人工干涉。自動操作變?yōu)楦咚佟o沖突和大規(guī)模系統(tǒng)管理的命令和控制基礎(chǔ)。

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

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

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

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

• Wiki DevOps
• devopsbookmarks