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