從敏捷開(kāi)發(fā)到敏捷運(yùn)維：DevOps將帶來(lái)革命？
原創(chuàng)【51CTO精選譯文】如果你對(duì)IT管理感興趣，尤其是對(duì)Web運(yùn)維感興趣，那么最近一定會(huì)注意到“DevOps”這一熱詞的出現(xiàn)。現(xiàn)在#DevOps標(biāo)簽頻繁出現(xiàn)在微博客Twitter上，同時(shí)DevOps相關(guān)的技術(shù)交流聚會(huì)也在慢慢增多。
在許多方面，DevOps是一個(gè)集合性概念，指的是能夠理順開(kāi)發(fā)和運(yùn)維之間相互配合關(guān)系的任何事物（51CTO編輯注：在英文中，Developer指開(kāi)發(fā)者，Operations指運(yùn)維，所以DevOps一詞本身含有開(kāi)發(fā)+運(yùn)維的意思）。但是DevOps背后的理念要比上述說(shuō)法更深遠(yuǎn)。
51CTO推薦專題：SA，神仙與裝機(jī)男：運(yùn)維的工作到底啥樣兒？
什么是DevOps？
人們?cè)絹?lái)越意識(shí)到傳統(tǒng)意義上的開(kāi)發(fā)行為和運(yùn)維行為存在脫節(jié)現(xiàn)象，從而導(dǎo)致沖突和低效，因此DevOps應(yīng)運(yùn)而生。
正如李·湯普森（Lee Thompson）和安德魯·謝福爾（Andrew Shafer）所言，在開(kāi)發(fā)和運(yùn)維之間存在一面“混亂之墻”。相互沖突的動(dòng)機(jī)、流程和工具導(dǎo)致了這面“墻”的存在。
開(kāi)發(fā)與運(yùn)維之間的“混亂之墻”
以開(kāi)發(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è)賺錢(qián)的服務(wù)。由于變化會(huì)影響穩(wěn)定性和可靠性，運(yùn)維業(yè)務(wù)有理由對(duì)它說(shuō)不。我們已經(jīng)多次聽(tīng)到過(guò)如下統(tǒng)計(jì)數(shù)字：在所有宕機(jī)事件中有80%情況是源于自殺式的改變（根據(jù)51CTO之前進(jìn)行的調(diào)查，很多時(shí)候，僅僅是給系統(tǒng)應(yīng)用補(bǔ)丁就會(huì)造成生產(chǎn)服務(wù)器無(wú)法正常重啟）。
開(kāi)發(fā)人員和運(yùn)維人員認(rèn)識(shí)世界的方法，以及各自所處的角色，存在根本性的差別。他們都認(rèn)為自己的做法是正確的。的確，孤立的來(lái)看他們都是正確的。
更糟糕的是，開(kāi)發(fā)和運(yùn)維團(tuán)隊(duì)通常處于公司組織架構(gòu)的不同部分，通常具有不同管理者的和競(jìng)爭(zhēng)關(guān)系，而且通常工作在不同的地點(diǎn)。
開(kāi)發(fā)與運(yùn)維通常工作在不同的地點(diǎn)
讓混亂之墻更堅(jiān)固的還包括開(kāi)發(fā)和運(yùn)維工具之間的錯(cuò)位?？匆幌麻_(kāi)發(fā)者要求和日常使用的常見(jiàn)工具，再看一下系統(tǒng)管理員，你會(huì)發(fā)現(xiàn)兩者存在很大不同，開(kāi)發(fā)人員沒(méi)有興趣使用運(yùn)維人員的工具，反之亦然；而且兩部分工具之間也不存在重要的集成。即使在某些工具類(lèi)型上有一些重疊之處，使用方式也完全不同。
開(kāi)發(fā)與運(yùn)維常用工具的不集成
當(dāng)應(yīng)用程序變動(dòng)需要從開(kāi)發(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ì)感覺(jué)到它的真實(shí)性。
應(yīng)用程序變動(dòng)從開(kāi)發(fā)到運(yùn)維
開(kāi)發(fā)人員把一個(gè)軟件版本“扔”給墻對(duì)面的運(yùn)維人員。后者拿到該版本產(chǎn)品后開(kāi)始準(zhǔn)備將其部署。運(yùn)維人員手動(dòng)修改由開(kāi)發(fā)者提供的部署腳本或創(chuàng)建自己的腳本。他們還需要修改配置文件來(lái)適應(yīng)與開(kāi)發(fā)環(huán)境大不相同的真實(shí)生產(chǎn)環(huán)境。最***的情況是，他們重復(fù)在此前環(huán)境中已完成的工作；而糟糕的情況是，他們將引入或發(fā)現(xiàn)新的漏洞。
運(yùn)維人員然后開(kāi)始進(jìn)行他們自認(rèn)為正確的部署過(guò)程。由于開(kāi)發(fā)和運(yùn)維之間的腳本、配置、過(guò)程和環(huán)境存在差別，這一部署過(guò)程實(shí)際上也是***被執(zhí)行。當(dāng)然，期間如果發(fā)生一個(gè)問(wèn)題，開(kāi)發(fā)人員會(huì)被要求來(lái)幫助進(jìn)行排障。運(yùn)維人員會(huì)說(shuō)開(kāi)發(fā)團(tuán)隊(duì)給的產(chǎn)品存在問(wèn)題。而開(kāi)發(fā)人員則會(huì)回應(yīng)稱該產(chǎn)品在他們的環(huán)境下運(yùn)行良好，因此一定是運(yùn)維人員在部署的過(guò)程中做錯(cuò)了什么。由于配置、文件存儲(chǔ)位置和過(guò)程的不同，開(kāi)發(fā)人員診斷問(wèn)題也并非一件易事。
沒(méi)有一個(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)。
本來(lái)應(yīng)該一帆風(fēng)順的部署過(guò)程***變成一場(chǎng)救火行動(dòng)
部署階段已經(jīng)非常明顯的需要DevOps理念來(lái)解決問(wèn)題，但需要DevOps的絕不僅僅是這一階段。正如約翰·阿爾斯帕瓦（John Allspaw）所指出的那樣，開(kāi)發(fā)和運(yùn)維之間的協(xié)作需求在部署之前就已存在，同時(shí)也會(huì)在部署之后的長(zhǎng)時(shí)間之內(nèi)繼續(xù)存在。
#p#
DevOps所帶來(lái)的好處
DevOps是一個(gè)非常強(qiáng)大的概念，因?yàn)樗梢栽诒姸嗖煌瑢用嫔袭a(chǎn)生共鳴。
從開(kāi)發(fā)或運(yùn)維的一線人員的觀點(diǎn)來(lái)看，DevOps可以讓他們從眾多煩惱中解脫出來(lái)。它雖然不是具有魔力的萬(wàn)靈藥，但是如果你能夠讓DevOps奏效，則會(huì)節(jié)省大量時(shí)間，而且不至于打擊自己的士氣。顯而易見(jiàn)，投入精力將DevOps落到實(shí)處，我們應(yīng)該會(huì)更加高效、更加敏捷和減少挫敗感。有些人可能會(huì)反駁稱DevOps是一個(gè)遙不可及的目標(biāo)，但這并非說(shuō)我們不應(yīng)該去嘗試實(shí)現(xiàn)它。
DevOps會(huì)節(jié)省大量的時(shí)間
對(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)開(kāi)發(fā)和運(yùn)維的職責(zé)和流程，DevOps有助于實(shí)現(xiàn)IT融合。開(kāi)發(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)。
DevOps有助于實(shí)現(xiàn)IT融合
業(yè)務(wù)敏捷性的一個(gè)簡(jiǎn)單定義是，“一個(gè)機(jī)構(gòu)以高效、經(jīng)濟(jì)的方式迅速適應(yīng)市場(chǎng)和環(huán)境變化的能力。”
當(dāng)然對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，“敏捷”有專門(mén)的含義（參考51CTO開(kāi)發(fā)頻道的專題：初探敏捷開(kāi)發(fā)），但目標(biāo)是非常類(lèi)似的。敏捷開(kāi)發(fā)方法旨在保持軟件開(kāi)發(fā)工作與客戶/公司的目標(biāo)同步，盡管需求不斷變化，也可以產(chǎn)生高品質(zhì)軟件。對(duì)于多數(shù)機(jī)構(gòu)來(lái)說(shuō)，迭代項(xiàng)目管理方法Scrum是敏捷的代名詞。
Scrum
業(yè)務(wù)敏捷性承諾，在企業(yè)權(quán)益集團(tuán)作出決策和開(kāi)發(fā)者進(jìn)行響應(yīng)之間能夠緊密互動(dòng)和快速反饋?？匆幌乱患疫\(yùn)轉(zhuǎn)良好的敏捷開(kāi)發(fā)團(tuán)體的產(chǎn)品，你會(huì)看到一個(gè)與業(yè)務(wù)需求保持一致的穩(wěn)定持續(xù)改進(jìn)。
但是，當(dāng)你從企業(yè)角度回顧一下整個(gè)開(kāi)發(fā)-運(yùn)維周期，敏捷方法的相關(guān)優(yōu)勢(shì)通常會(huì)變得非常模糊?；靵y之墻導(dǎo)致了應(yīng)用程序生命周期的分裂。開(kāi)發(fā)和運(yùn)維分別按照不同的節(jié)奏進(jìn)行。實(shí)際上，產(chǎn)品部署之間的長(zhǎng)期間隔使得一個(gè)團(tuán)體的敏捷工作變成了它一直試圖避免的瀑布生命周期。當(dāng)存在混亂之墻時(shí)，無(wú)論開(kāi)發(fā)團(tuán)體有多么敏捷，改變企業(yè)緩慢和遲鈍的特點(diǎn)是極其困難的。
敏捷的開(kāi)發(fā)與瀑布式企業(yè)結(jié)構(gòu)的步調(diào)不同
DevOps使得敏捷開(kāi)發(fā)的優(yōu)勢(shì)可以體現(xiàn)在機(jī)構(gòu)層面上。通過(guò)考慮到快速、反應(yīng)靈敏但穩(wěn)定的業(yè)務(wù)運(yùn)維，使其能夠與開(kāi)發(fā)過(guò)程的創(chuàng)新保持同步，DevOps可以做到這一點(diǎn)。
如果你希望在自己的組織內(nèi)建立一個(gè)DevOps項(xiàng)目，務(wù)必牢記“IT融合” 和“業(yè)務(wù)敏捷性”。
#p#
如何將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ā)生。開(kāi)發(fā)-運(yùn)維生命周期中的所有當(dāng)事方需要明白，在更大的企業(yè)流程中自己只是其中一部分。個(gè)體和團(tuán)隊(duì)的成功都要放在整個(gè)開(kāi)發(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è)開(kāi)發(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ì)在開(kāi)發(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í)需要哪些類(lèi)型的工具，杰克·索羅夫曼（Jake Sorofman）提出如下建議：
一個(gè)版本控制軟件庫(kù)
它可以確保所有系統(tǒng)產(chǎn)品在整個(gè)版本發(fā)布生命周期中被很好的定義，且能夠?qū)崿F(xiàn)一致性共享，同時(shí)保持***信息。開(kāi)發(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ǔ)。
在從開(kāi)發(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ō)需要招聘了解這些概念或方法的開(kāi)發(fā)人員、項(xiàng)目經(jīng)理、測(cè)試人員或系統(tǒng)管理員。DevOps也是同樣道理。
與DevOps具有相同理念的術(shù)語(yǔ)很多，例如敏捷運(yùn)維（Agile Operations）、敏捷基礎(chǔ)設(shè)施（Agile Infrastructure）和Dev2Ops。還有很多人雖然沒(méi)有提及“DevOps”，但卻在遵循著類(lèi)似的理念。
原文：http://dev2ops.org/blog/2010/2/22/what-is-devops.html
【編輯推薦】
