【文章內(nèi)容簡(jiǎn)介】 程的，那么為什么叫它 “DevOps”呢？ 在我看來，早期 DevOps 的一個(gè)不足之處是沒有直接地明確 DevOps 問題的真實(shí)范圍，即它的問題域到底有多大。經(jīng)過一年的觀察和思考，事實(shí)證明，我們正在解決的是對(duì)所有企業(yè)來說最大的問題之一： 如何面 對(duì)市場(chǎng)壓力做出盡可能迅速的反應(yīng)從而實(shí)現(xiàn)業(yè)務(wù)目標(biāo) 。 可惜的是， DevOps 必須從某個(gè)地方開始，于是我們碰到了一個(gè)幾乎非常普遍的問題：開發(fā)者文化與運(yùn)維文化之間存在的沖突和脫節(jié)。盡管每個(gè)企業(yè) 的組織結(jié)構(gòu)圖各不相同，但是為了有個(gè)共同的討論點(diǎn)，我們能夠非常容易的將其劃分為開發(fā)陣營(yíng)與運(yùn)維陣營(yíng)（當(dāng)然，現(xiàn)實(shí)世界遠(yuǎn)比這復(fù)雜和無趣）。 如上圖所示，在開發(fā)和運(yùn)維之間存在著一面混亂之墻，在這種情況下，大部分早期DevOps 的注意力都放在在改善 部署活動(dòng) 上。因?yàn)椴渴鸹顒?dòng)構(gòu)成了整個(gè) IT 組織的大部分工作，所以從部署開始改善，這是一個(gè)合理而自然的選擇。 也許 Patrick 應(yīng)該將他的第一次活動(dòng)稱為 “業(yè)務(wù)人員開發(fā)人員質(zhì)量保障人員安全人員運(yùn)維人員云服務(wù)用戶日 ”或者 “比敏捷更牛叉日 ”又或者其他的什么東西，但是我強(qiáng)烈懷疑有人會(huì)認(rèn)為其炫耀，所以低調(diào)的結(jié)果就是 DevOps 叫了 DevOps。 DevOps的特征 DevOps是處于 軟件 產(chǎn)品開 發(fā) 和 運(yùn)營(yíng) 之間的 ，它關(guān)注于如何開發(fā)對(duì)基礎(chǔ)設(shè)施友好的軟件，而這些基礎(chǔ)設(shè)施正是商業(yè)軟件賴以生存的環(huán)境。有時(shí)， DevOps 也指代開發(fā)基礎(chǔ)設(shè)施軟件以及軟件部署。 DevOps 有如下的特征： 1) 編寫復(fù)雜應(yīng)用的能力， 而不僅僅是簡(jiǎn)單的腳本 顯而易見的必要條件 2) 關(guān)注穩(wěn)定性和無故障時(shí)間 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 穩(wěn)定性和無故障時(shí)間永遠(yuǎn)對(duì) DevOps們充滿吸引力 3) 額外關(guān)注狀態(tài)間的遷移 在開發(fā)領(lǐng)域，我發(fā)現(xiàn)人們很少跳出功能點(diǎn)本身考慮軟件。一個(gè)系統(tǒng)如何從它當(dāng)前的狀態(tài)遷移到未來我們所希望達(dá)到的狀態(tài)？這一點(diǎn)很少被納入考慮， DevOps運(yùn)動(dòng)對(duì)這個(gè)容易出錯(cuò)的領(lǐng)域格外關(guān)注 。 4) 關(guān)于營(yíng)業(yè)收入的不同視角 開發(fā)人員通常工作于增加或者保持營(yíng)業(yè)收入，而 DevOps常常工作在那些可以避免營(yíng)業(yè)收入減少的事情上，這很象體育中進(jìn)攻與防守的概念，關(guān)鍵點(diǎn)在于 “平衡 ” 5) 我們是自己軟件的用戶 這是一個(gè)非常重要的區(qū)分，與開發(fā)人員創(chuàng)造別人使用（內(nèi)部客戶，終端客戶，網(wǎng)站訪問者）的軟件不同， DevOps更關(guān)注內(nèi)部需求，比如，你當(dāng)然可以草草的寫下錯(cuò)誤日志，但為此付出代價(jià)，花費(fèi)大量時(shí)間查找的人將是你自己，而不是別人。 6) 架構(gòu)師、開發(fā)者、測(cè)試人員、產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理五位一體 ? 我的個(gè)人經(jīng)驗(yàn)是，在 DevOps團(tuán)隊(duì)中， 個(gè)人／團(tuán)隊(duì)更有舍我其誰的氣質(zhì)，指定優(yōu)先級(jí)，找出依賴，對(duì)意料之外的事情做出響應(yīng)，管理資源，所有一切都被同一個(gè)團(tuán)隊(duì)中的不同個(gè)體完成。 7) 對(duì)意外更為關(guān)注 8) 工作于產(chǎn)品環(huán)境的 QA 一些 DevOps任務(wù)無法在小規(guī)模的測(cè)試環(huán)境中被充分測(cè)試。缺乏大規(guī)模的集群，缺少獨(dú)特的硬件，缺乏足夠的用戶數(shù)，這一切都會(huì)決定測(cè)試是否充分，結(jié)果是否可信。被劃分為不同階段的部署以及其它技術(shù)常被用于減少徹底不工作的風(fēng)險(xiǎn)，但真相是，我常常發(fā)現(xiàn)我不得不在產(chǎn)品環(huán)境下運(yùn)行測(cè)試以得到可信的結(jié)果。 9) 先手動(dòng)，再自動(dòng) 在我的經(jīng)驗(yàn)里，一個(gè) DevOps 任務(wù)常常是首先 手工完成，在稍后自動(dòng)化，而在開發(fā)人員的世界里，寫程序之前很少還存在一個(gè)手工過程。 10) 分布或者超級(jí)分布式環(huán)境 關(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)槟鞘?DevOps 團(tuán)隊(duì)的問題。 設(shè)想一下，你不會(huì)說 “我需要招聘一個(gè) Agile”或 “我需要招聘一個(gè) Scrum”或 “我需 要招聘一個(gè) ITIL”，而只是會(huì)說需要招聘了解這些概念或方法的開發(fā)人員、項(xiàng)目經(jīng)理、測(cè)試人員或系統(tǒng)管理員。 DevOps 也是同樣道理。 2 為 什么 要引入 DevOps？ 當(dāng)軟件行業(yè)進(jìn)入互聯(lián)網(wǎng)時(shí)代，市場(chǎng)對(duì)軟件產(chǎn)品和服務(wù)的交付提出了更高的要求：不僅要快速實(shí)現(xiàn)需求，而且要快速發(fā)布上線，并且必須保證業(yè)務(wù)可靠、高效運(yùn)行。為了滿足這些要求， IT組織需要強(qiáng)有力的流程、技術(shù)和人員作為保障 ，而 人們 也 越來越意識(shí)到傳統(tǒng)意義上的 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 開發(fā)行為和運(yùn)維行為存在脫節(jié)現(xiàn)象，從而導(dǎo)致沖突和低效，因此 DevOps應(yīng)運(yùn)而生。 。 ThoughtWorks 很早就認(rèn)識(shí) 到發(fā)布與運(yùn)營(yíng)對(duì)于成功交付的重要性。我們的創(chuàng)始人 Roy Singham 在《走完業(yè)務(wù)軟件的 “最后一公里 ”》一文中指出： 所謂 [軟件開發(fā)的 ]“最后一公里 ”，是指軟件滿足了功能需求之后，尚未投入實(shí)際運(yùn)行并創(chuàng)造業(yè)務(wù)價(jià)值的階段。軟件開發(fā)者 ── 尤其是面對(duì)交付壓力的軟件開發(fā)者 ── 常常對(duì) “最后一公里 ”視而不見。但它確實(shí)正在成為業(yè)務(wù)軟件交付中最大的壓力點(diǎn)。 混亂之墻 正如李 湯普森（ Lee Thompson）和安德魯 謝福爾（ Andrew Shafer）所言， 在開發(fā)和運(yùn)維之間存在一面 “混亂之墻 ”。相互沖突的 動(dòng)機(jī) 、 流程 和 工具 導(dǎo)致 了這面 “墻 ”的存在。 角色認(rèn)知不同 ? 以開發(fā)為中心的人 通常認(rèn)為， 變化會(huì)帶來回報(bào)。 企業(yè)依靠他們來應(yīng)對(duì)不斷變化的需求。因此他們被鼓勵(lì)盡可能進(jìn)行變革。 ? 而運(yùn)維人員則往往視變化為敵人 。企業(yè)依靠他們維持正常業(yè)務(wù)運(yùn)維和實(shí)施讓企業(yè)賺錢的服務(wù)。由于變化會(huì)影響穩(wěn)定性和可靠性，運(yùn)維業(yè)務(wù)有理由對(duì)它說不。我們已經(jīng)多次聽到過如下統(tǒng)計(jì)數(shù)字：在所有宕機(jī)事件中有 80%情況是源于自殺式的改變。 開發(fā)人員和運(yùn)維人員認(rèn)識(shí)世界的方法，以及各自所處的角色，存在根本性的差別。他們都認(rèn)為自己的做法是正確的。的確，孤立的來看他們都是正確的。 更糟糕的是， 開發(fā)和運(yùn)維團(tuán)隊(duì)通常處于公司組織架構(gòu)的不同部分 ，通常具有不同管理者的和競(jìng)爭(zhēng)關(guān)系，而且通常工作在不同的地點(diǎn)。 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 所用工具差異 讓混亂之墻更堅(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)的，問題可能會(huì)隨之而來。下圖雖然是一個(gè)抽象化場(chǎng)景，但是如果你經(jīng)歷過這一過程，一定會(huì)感覺到它的真實(shí)性。 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 開發(fā)人員把一個(gè)軟件版本 “扔 ”給墻對(duì)面的運(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)順的部署過程最后變成一場(chǎng)救火行動(dòng)，經(jīng)過反復(fù)測(cè)試之后才讓生產(chǎn)環(huán)境恢復(fù)到正常狀態(tài)。 部署階段已經(jīng)非常明顯的需要 DevOps理念來解決問題，但需要 DevOps的絕不僅 僅是這一階段。正如約翰 阿爾斯帕瓦（ John Allspaw）所指出的那樣， 開發(fā)和運(yùn)維之間的協(xié)作需求在部署之前就已存在，同時(shí)也會(huì)在部署之后的長(zhǎng)時(shí)間之內(nèi)繼續(xù)存在 。 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 企業(yè) 的需求分析 企業(yè)的 需求 1. 快速響應(yīng) 傳統(tǒng)觀念中規(guī)模龐大、發(fā)布周期長(zhǎng)達(dá)數(shù)月乃至數(shù)年的軟件產(chǎn)品研發(fā)方式正在發(fā)生變化。在 “快魚吃慢魚 ”的互聯(lián)網(wǎng)時(shí)代，上市時(shí)間（ Time To Market）成為衡量軟件組織能力的重要因素：能快速接納需求、快速完成開發(fā)、快速上線投入使用的軟件產(chǎn)品，才能有效占領(lǐng)市場(chǎng)、吸引用戶。 在以迭代式開發(fā)為特征的敏捷開發(fā)方法和以 Ruby on Rails 為代表的一批高效開發(fā)工具幫助下，很多軟件組織在實(shí)現(xiàn)功能性需求方面的能力得到了顯著提升。然而從業(yè)務(wù)負(fù)責(zé)人的角度來說，僅僅提升開發(fā)階段的效率還不足以實(shí)現(xiàn)端到端的快速響應(yīng)。很多軟件組織雖然以迭代方式進(jìn)行開發(fā)，但發(fā)布和部署仍然按照從前的節(jié)奏，每隔幾個(gè)月才進(jìn)行一次。這時(shí)從客戶與最終用戶的視角看來，這些軟件組織的交付仍然是以瀑布方式進(jìn)行：客戶與最終用戶并沒有直接感知到開發(fā)能力提升所帶來的利益（如圖 1）。 不能有效縮短部署上線的周期，就無法真正實(shí)現(xiàn)快速響應(yīng)業(yè) 務(wù)需求、快速實(shí)現(xiàn)業(yè)務(wù)價(jià)值。如何縮短發(fā)布和運(yùn)維工作的周期，已經(jīng)成為困擾很多軟件組織領(lǐng)導(dǎo)者的問題。 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 圖 1：迭代式開發(fā) +瀑布式發(fā)布 2. 質(zhì)量 大型軟件組織通常都很重視產(chǎn)品質(zhì)量，并在開發(fā) /測(cè)試階段投入大量成本與精力進(jìn)行 質(zhì)量保障活動(dòng)。但軟件產(chǎn)品的質(zhì)量問題不僅在開發(fā)階段引入，靠傳統(tǒng)意義上的測(cè)試工作也不能完全發(fā)現(xiàn)。有相當(dāng)比例的質(zhì)量問題是在開發(fā) /測(cè)試階段之后引入或發(fā)現(xiàn)的。造成這一現(xiàn)象的原因有： ? 開發(fā)人員對(duì)生產(chǎn)環(huán)境缺乏了解，在代碼中引入了只有在生產(chǎn)環(huán)境才會(huì)暴露的缺陷。 ? 開發(fā)人員對(duì)非功能性需求缺乏關(guān)注，并且沒有相應(yīng)驗(yàn)證環(huán)境，導(dǎo)致非功能性缺陷。 ? 生產(chǎn)環(huán)境和測(cè)試環(huán)境缺乏有效管理，因?yàn)榄h(huán)境差異引入缺陷。 ? 部署和維護(hù)工作缺乏自動(dòng)化，在發(fā)布過程中手工操作引入缺陷。 ? 缺乏針對(duì)生產(chǎn)環(huán)境的回歸測(cè)試，導(dǎo)致缺陷不能及時(shí)被發(fā)現(xiàn)。 通過引入自動(dòng)化測(cè)試、測(cè)試 驅(qū)動(dòng)開發(fā)、持續(xù)集成等敏捷實(shí)踐，開發(fā) /測(cè)試階段的質(zhì)量保障活動(dòng)能夠得到有效改善。然而對(duì)于客戶和最終用戶來說，不論哪個(gè)環(huán)節(jié)引入的缺陷都同樣會(huì)給業(yè)務(wù)造成損失。如何在部署上線的緊迫壓力下保證質(zhì)量，這也是眾多軟件組織領(lǐng)導(dǎo)者關(guān)注的一個(gè)問題。 3. 敏捷拉通的嘗試 一些軟件組織意識(shí)到這些問題的存在，并希望以敏捷開發(fā)方法為出發(fā)點(diǎn)，將下游的發(fā)布、部署、運(yùn)維等工作環(huán)節(jié)拉通，從而提升整體響應(yīng)能力。但由于軟件開發(fā)與運(yùn)營(yíng)之間存在一些固有的差異，這樣的拉通活動(dòng)往往困難重重： ? 開發(fā)團(tuán)隊(duì)與運(yùn)營(yíng)團(tuán)隊(duì)的關(guān)注點(diǎn)不同。開發(fā)團(tuán)隊(duì)重視以功能性需求實(shí)現(xiàn)業(yè)務(wù)價(jià)值 ；運(yùn)營(yíng)團(tuán)隊(duì)重視以非功能性需求（穩(wěn)定性、性能、安全性等）實(shí)現(xiàn)業(yè)務(wù)價(jià)值。 ? 開發(fā)團(tuán)隊(duì)與運(yùn)營(yíng)團(tuán)隊(duì)的技能結(jié)構(gòu)不同。開發(fā)人員通常缺乏服務(wù)器管理的技能，運(yùn)營(yíng)人員通常缺乏軟件編程的技能。 ? 開發(fā)團(tuán)隊(duì)與運(yùn)營(yíng)團(tuán)隊(duì)日常使用的工具不同。針對(duì)開發(fā)階段引入的配置管理、 IDE、測(cè)試工具等很少為運(yùn)營(yíng)團(tuán)隊(duì)使用。 ? 開發(fā)團(tuán)隊(duì)與運(yùn)營(yíng)團(tuán)隊(duì)日常工作的環(huán)境不同。開發(fā)人員通常在公司內(nèi)的桌面電腦上工作，運(yùn)營(yíng)人員經(jīng)常在客戶現(xiàn)場(chǎng)、在服務(wù)器上工作。 ? 開發(fā)團(tuán)隊(duì)與運(yùn)營(yíng)團(tuán)隊(duì)通常屬于不同的部門。 由于存在這些固有的差異，單純從開發(fā)團(tuán)隊(duì)的角度出發(fā)、將敏捷軟件開發(fā)的實(shí)踐推廣到運(yùn)營(yíng)團(tuán)隊(duì)，很難有效幫助運(yùn)營(yíng)團(tuán)隊(duì)改善。需要從運(yùn)營(yíng)維護(hù)工作本身的特點(diǎn)出發(fā)，引入符合客觀情況的流程、技術(shù)和工具，才能有效改善運(yùn)營(yíng)維護(hù)工作的質(zhì)量和效率。 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 對(duì)策 針對(duì)現(xiàn)代大型軟件組織在軟件發(fā)布、運(yùn)營(yíng)與維護(hù)過程中面臨的種種挑戰(zhàn)， ThoughtWorks 建議在軟件組織中建設(shè) DevOps[3]能力， 從而提升整個(gè)組織的 IT 融合程度，改善軟件交付 “最后一公里 ”的質(zhì)量和效率，為實(shí)現(xiàn)業(yè)務(wù)敏捷打好基礎(chǔ)。 DevOps 是一組流程、技術(shù)與工具的統(tǒng)稱，用于促進(jìn)開發(fā)、技術(shù)運(yùn)營(yíng)和質(zhì)量保障部門之間的溝通、協(xié)作與整合。 “DevOps”這個(gè)名稱即是指開發(fā)（ dev）與運(yùn)營(yíng)（ op）的無縫融合。具備DevOps 能力的組織能夠開展快速、反應(yīng)靈敏同時(shí)又穩(wěn)定可靠的業(yè)務(wù)運(yùn)維，使其能夠與開發(fā)過程的創(chuàng)新保持同步，從而使得敏捷開發(fā)的優(yōu)勢(shì)在組織層面上得到展現(xiàn)。 1. 精益運(yùn)維 傳統(tǒng)的軟件運(yùn)營(yíng)人員通常傾向于盡量避免修改功能，從而降低滿足非功能性需求的風(fēng)險(xiǎn)。 但如果拒絕了小的修改，而給定時(shí)間段內(nèi)需要修改的總量不變，那么每次變更的規(guī)模就會(huì)變大，從而增加每次發(fā)布的風(fēng)險(xiǎn)（因?yàn)樽兏婕暗姆秶螅? DevOps 的指導(dǎo)思想是 “精益運(yùn)維 ”。精益生產(chǎn)的很多原則，例如縮短交付周期、消除浪費(fèi)