何為DevOps，知乎的漫畫
鏈接：https://www.zhihu.com/question/24413538/answer/308246508
來源：知乎
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。
加班熬夜趕需求！暴怒吐血改需求！發(fā)布謹(jǐn)慎怕事故！技術(shù)“猿”就一定要承受“傷害”和吸引“仇恨”嗎？說了這么多年DevOps，到底是啥？
來，阿里云應(yīng)用服務(wù)的技術(shù)、文藝"騷年"策劃了小漫畫，讓你秒懂DevOps！
真正的dev+ops有那些了？轉(zhuǎn)之前公司同事翻譯的文章，讓理解猛然一亮。
最近我閱讀了很多有關(guān)DevOps的文章，其中一些非常有趣，然而一些內(nèi)容也很欠考慮。貌似很多人越來越堅(jiān)定地在DevOps與chef、puppet或Docker容器的熟練運(yùn)用方面劃了等號(hào)。對(duì)此我有不同看法。DevOps的范疇遠(yuǎn)遠(yuǎn)超過puppet或Docker等工具。
這樣的看法甚至讓我感覺有些氣憤。DevOps在我看來極為重要，過去15年來，我一直在大型機(jī)構(gòu)，主要是大型金融機(jī)構(gòu)中從事工程業(yè)務(wù)。DevOps是一種非常重要的方法論，該方法將解決一些最大型問題的基本原則和實(shí)踐恰如其分地融為一體，很好地解決了此類機(jī)構(gòu)的軟件開發(fā)項(xiàng)目中一種最令人感覺悲涼的失敗要素：開發(fā)者和運(yùn)維人員之間的混亂之墻。
請(qǐng)不要誤會(huì)我的這種觀點(diǎn)，除了某些XP實(shí)踐，大部分此類大型機(jī)構(gòu)對(duì)敏捷開發(fā)方法論的運(yùn)用還有很長(zhǎng)的路要走，同時(shí)還有很多其他原因會(huì)導(dǎo)致軟件開發(fā)項(xiàng)目的失敗或延誤。
但在我看來，混亂之墻目前依然是他們所面臨的最令人沮喪、最浪費(fèi)時(shí)間、同時(shí)也相當(dāng)愚蠢的問題。
與其獨(dú)自生悶氣，我覺得不如說點(diǎn)更實(shí)在的東西，寫一篇盡可能精準(zhǔn)的文章，向大家介紹DevOps到底是什么，能為我們帶來什么。長(zhǎng)話短說，DevOps并不是某一套工具。DevOps是一種方法論，其中包含一系列基本原則和實(shí)踐，僅此而已。而所用的工具（或者說“工具鏈”吧，畢竟用于為這些實(shí)踐提供支持的工具集有著極高的擴(kuò)展性）只是為了對(duì)這樣的實(shí)踐提供支持。
最終來說，這些工具本身并不重要。相比兩年前，目前的DevOps工具鏈已經(jīng)產(chǎn)生了翻天覆地的變化，可想而知，兩年后還會(huì)產(chǎn)生更大的差異。不過這并不重要。重要的是能夠合理地理解這些基本原則和實(shí)踐。
本文并不準(zhǔn)備介紹某些工具鏈，甚至完全不會(huì)提到這些工具。網(wǎng)上討論DevOps工具鏈的文章已經(jīng)太多了。我想在本文中談?wù)勛罨镜脑瓌t和實(shí)踐，它們的主要目的，畢竟這些才是對(duì)我而言最重要的。
DevOps是一種方法論，歸納總結(jié)了面臨獨(dú)一無二的機(jī)遇和強(qiáng)有力需求的網(wǎng)絡(luò)巨頭們，結(jié)合自身業(yè)務(wù)本質(zhì)構(gòu)思出全新工作方式的過程中所采用的實(shí)踐，而他們的業(yè)務(wù)需求也很直接：以史無前例的節(jié)奏對(duì)自己的系統(tǒng)進(jìn)行演進(jìn)，有時(shí)候可能還需要以天為單位對(duì)系統(tǒng)或業(yè)務(wù)進(jìn)行擴(kuò)展。
雖然DevOps對(duì)初創(chuàng)公司來說很明顯是不可或缺的，但我認(rèn)為那些有著龐大的老式IT部門的大企業(yè)才是能從這些基本原則和實(shí)踐中獲得最大收益的。本文將試圖解釋得出這個(gè)結(jié)論的原因和實(shí)現(xiàn)方法。
本文的部分內(nèi)容已發(fā)布為Slideshare演示幻燈片，可在這里瀏覽：http://www.slideshare.net/JrmeKehrli/devops-explained-72091158
目錄
1. 簡(jiǎn)介
1.1 管理信條
1.2 一個(gè)典型的IT組織
1.3 運(yùn)維人員測(cè)挫敗感
1.4 基礎(chǔ)架構(gòu)自動(dòng)化
1.5 DevOps：僅此一次，一顆神奇的銀子彈
2. 基礎(chǔ)架構(gòu)即代碼
2.1 概述
2.2 DevOps工具鏈
2.3 收益
3. 持續(xù)交付
3.1 從實(shí)踐中學(xué)習(xí)
3.2 自動(dòng)化
3.3 更頻繁的部署
3.4 持續(xù)交付的前提需求
3.5 零停機(jī)部署
4. 協(xié)作
4.1 混亂之墻
4.2 軟件開發(fā)流程
4.3 共享工具
4.4 協(xié)同工作
5. 結(jié)論
1. 簡(jiǎn)介
DevOps所關(guān)注的不是工具本身，也不是對(duì)chef或Docker的掌握程度。DevOps是一種方法論，是一系列可以幫助開發(fā)者和運(yùn)維人員在實(shí)現(xiàn)各自目標(biāo)（Goal）的前提下，向自己的客戶或用戶交付最大化價(jià)值及最高質(zhì)量成果的基本原則和實(shí)踐。
開發(fā)者和運(yùn)維人員之間最大的問題在于：雖然都是企業(yè)中大型IT部門不可或缺的，但他們有著截然不同的目的（Objective）。
開發(fā)者和運(yùn)維人員之間目的上的差異就叫做混亂之墻。下文會(huì)介紹這個(gè)概念的準(zhǔn)確定義，以及為什么我認(rèn)為這種狀況很嚴(yán)峻并且很糟糕。
DevOps是一種融合了一系列基本原則和實(shí)踐的方法論（并從這些實(shí)踐中派生出了各種工具），意在幫助這些人員向著一個(gè)統(tǒng)一的共同目的努力：盡可能為公司提供更多價(jià)值。
令人驚奇的是，這個(gè)問題竟然有一個(gè)非常簡(jiǎn)單的“銀子彈”：讓生產(chǎn)端變得敏捷起來！
而這恰恰正是DevOps所要達(dá)成的唯一目標(biāo)！
但在進(jìn)一步討論這一點(diǎn)之前，首先需要談?wù)勂渌麕准隆?/p>
1.1 管理信條
IT管理這場(chǎng)戰(zhàn)爭(zhēng)的原動(dòng)力到底是什么？換句話說，在軟件開發(fā)項(xiàng)目中，管理工作首要的，以及最重要的目的是什么？
有什么想法嗎？
我來提供一個(gè)線索吧：在建立一家初創(chuàng)公司時(shí)，最重要的事情是什么？
當(dāng)然是要加快上市時(shí)間（TTM）！
上市時(shí)間（即TTM）是指一件產(chǎn)品從最初的構(gòu)思到最終可供用戶使用或購(gòu)買這一過程所需要的時(shí)間。對(duì)于產(chǎn)品很快會(huì)過時(shí)的行業(yè)，TTM是一個(gè)非常重要的概念。
在軟件工程方面，所采用的方法、業(yè)務(wù)，以及具體技術(shù)幾乎每年都會(huì)變化，因而TTM就成了一個(gè)非常重要的KPI（關(guān)鍵績(jī)效指標(biāo)）。
TTM通常也會(huì)被叫做前置時(shí)間（Lead Time）。
第一個(gè)問題在于，（很多人認(rèn)為）在開發(fā)過程中TTM和產(chǎn)品質(zhì)量是兩個(gè)對(duì)立的屬性。在下文可以看到，改善質(zhì)量（進(jìn)而提高穩(wěn)定性）是運(yùn)維人員的目的，而開發(fā)者的目的在于降低前置時(shí)間（進(jìn)而提高TTM）。
請(qǐng)容我來解釋一下。
IT組織或部門通常會(huì)通過兩個(gè)關(guān)鍵的KPI進(jìn)行評(píng)估：軟件本身的質(zhì)量，因而需要盡可能減少缺陷的數(shù)量；此外還有TTM，因而需要將業(yè)務(wù)構(gòu)想（通常由業(yè)務(wù)用戶提供）變?yōu)樽罱K成果，并以盡可能快的速度提供給用戶或客戶。
這里的問題在于，大部分情況下這兩個(gè)截然不同的目的是由兩個(gè)不同團(tuán)隊(duì)提供支持的：負(fù)責(zé)構(gòu)建軟件的開發(fā)者，以及負(fù)責(zé)運(yùn)行軟件的運(yùn)維人員。
1.2 一個(gè)典型的IT組織
在組織內(nèi)部負(fù)責(zé)管理重要IT部門的典型IT組織通常看起來是這樣的：
主要由于歷史的原因（大部分運(yùn)維人員來自硬件和電信業(yè)務(wù)領(lǐng)域），運(yùn)維人員和開發(fā)者分屬不同的組織結(jié)構(gòu)分支。開發(fā)者屬于研發(fā)部門，而運(yùn)維人員大部分時(shí)候?qū)儆诨A(chǔ)架構(gòu)部門（或?qū)ｉT的運(yùn)維部門）。
別忘了，他們有著不同的目的：
此外作為旁注，這兩個(gè)團(tuán)隊(duì)有時(shí)候會(huì)使用不同的預(yù)算來運(yùn)營(yíng)。開發(fā)團(tuán)隊(duì)使用構(gòu)建（Build）預(yù)算，運(yùn)維團(tuán)隊(duì)使用運(yùn)營(yíng)（Run）預(yù)算。不同的預(yù)算，對(duì)控制權(quán)越來越高的需求，以及企業(yè)IT成本的縮水，這些因素結(jié)合在一起會(huì)進(jìn)一步放大兩個(gè)團(tuán)隊(duì)各自目的的對(duì)立性。
（依本人愚見，時(shí)至今日，隨著人與人之間無時(shí)無刻隨時(shí)隨地進(jìn)行的交互，以及由不同目的推動(dòng)著企業(yè)和社會(huì)進(jìn)行數(shù)字化轉(zhuǎn)型，IT預(yù)算方面古老的“規(guī)劃/構(gòu)建/運(yùn)行”框架已經(jīng)不那么合理了，不過這又是另一回事了。）
1.3 運(yùn)維人員測(cè)挫敗感
接下來看看運(yùn)維人員，一起看看典型的運(yùn)維團(tuán)隊(duì)把大部分時(shí)間都花在哪里了：
生產(chǎn)團(tuán)隊(duì)有將近一半（47%）的時(shí)間花在了與部署有關(guān)的工作中：
執(zhí)行實(shí)際的部署工作，或
修復(fù)與部署工作有關(guān)的問題
這樣的KPI其實(shí)相當(dāng)瘋狂，但實(shí)際上我們?cè)缇蛻?yīng)該采納。實(shí)際上早在40年前，計(jì)算機(jī)科學(xué)的“原始時(shí)代”就已涌現(xiàn)出運(yùn)維團(tuán)隊(duì)，當(dāng)時(shí)計(jì)算機(jī)主要運(yùn)用在工業(yè)界，運(yùn)維人員需要手工運(yùn)行大量命令來執(zhí)行自己的任務(wù)。為了履行職責(zé)，他們已經(jīng)習(xí)慣于按照清單運(yùn)行各種各樣的命令或手工流程。
突然有一天他們終于意識(shí)到自己“總在做著相同的事情”，然而長(zhǎng)達(dá)四十多年的工作過程中卻幾乎沒人考慮過變革。
考慮到這一點(diǎn)你會(huì)發(fā)現(xiàn)，實(shí)在是太瘋狂了。平均來說，運(yùn)維人員將近一半的時(shí)間都在處理與部署有關(guān)的任務(wù)！
為了改變這種狀況，必須考慮到兩個(gè)最關(guān)鍵的需求：
通過自動(dòng)化部署將目前這種手工任務(wù)所需的時(shí)間減少31%。
通過產(chǎn)業(yè)化措施（類似于通過XP和敏捷實(shí)現(xiàn)的軟件開發(fā)產(chǎn)業(yè)化）將需要處理的與這些部署有關(guān)的問題減少16%。
1.4 基礎(chǔ)架構(gòu)自動(dòng)化
在這方面也有一個(gè)相當(dāng)富有啟發(fā)性的統(tǒng)計(jì)結(jié)果：
以手工操作的數(shù)量所表示的成功部署概率。
這些統(tǒng)計(jì)告訴我們：
只需手工運(yùn)行5條命令的情況下，成功部署的概率就已跌至86%。
如需手工運(yùn)行55條命令，成功部署的概率將跌至22%。
如需手工運(yùn)行100條命令，成功部署的概率將趨近于0（僅2%）！
成功部署意味著軟件能夠按照預(yù)期在生產(chǎn)環(huán)境中運(yùn)行。未能成功部署意味著有東西出錯(cuò)，可能需要進(jìn)行必要的分析才能了解部署過程中哪里出錯(cuò)，是否需要應(yīng)用某種補(bǔ)丁，或需要修改某些配置。
因此讓這一切實(shí)現(xiàn)自動(dòng)化并不惜一切代價(jià)避免手工操作似乎是個(gè)好主意，對(duì)吧？
那么行業(yè)里這方面的現(xiàn)狀是怎樣的：
（來源：IT Ops & DevOps Productivity Report 2013 - Rebellabs?）
（說實(shí)話，這個(gè)統(tǒng)計(jì)信息比較老了，是2013年的結(jié)果，相信現(xiàn)在的結(jié)果會(huì)有所不同）
然而這也可以讓我們明確的知道，在基礎(chǔ)架構(gòu)自動(dòng)化方面我們還有多遠(yuǎn)的路要走，并且DevOps的基本原則和實(shí)踐依然是那么的重要。
網(wǎng)絡(luò)巨頭們當(dāng)然會(huì)通過新的方法和實(shí)踐及時(shí)滿足自己的需求，他們?cè)缫验_始構(gòu)建自己的工程業(yè)務(wù)，而正是他們所確立的實(shí)踐逐漸衍生出當(dāng)今我們所熟悉的DevOps。
看看這些網(wǎng)絡(luò)巨頭們?cè)谶@方面目前所處的位置吧，舉幾個(gè)例子：
Facebook有數(shù)千名開發(fā)和運(yùn)維人員，成千上萬臺(tái)服務(wù)器。平均來說一位運(yùn)維人員負(fù)責(zé)500臺(tái)服務(wù)器（還認(rèn)為自動(dòng)化是可選的嗎？）他們每天部署兩次（環(huán)式部署，Deployment ring的概念）。
Flickr每天部署10次。
Netflix明確針對(duì)失敗進(jìn)行各種設(shè)計(jì)！他們的軟件按照設(shè)計(jì)從最底層即可容忍系統(tǒng)失敗，他們會(huì)在生產(chǎn)環(huán)境中進(jìn)行全面的測(cè)試：每天通過隨機(jī)關(guān)閉虛擬機(jī)的方式在生產(chǎn)環(huán)境中執(zhí)行65000次失敗測(cè)試…… 并確保這種情況下一切依然可以正常工作。
他們這種做法秘密何在？
1.5 DevOps：僅此一次，一顆神奇的銀子彈
他們的秘密很簡(jiǎn)單：將敏捷擴(kuò)展至生產(chǎn)端：
DevOps的共存主要是為了擴(kuò)展敏捷開發(fā)實(shí)踐，進(jìn)一步完善軟件變更在構(gòu)建、驗(yàn)證、部署、交付等階段中的流動(dòng)，同時(shí)通過軟件應(yīng)用程序的全面所有權(quán)予力跨職能團(tuán)隊(duì)完成從設(shè)計(jì)到生產(chǎn)支持等各環(huán)節(jié)的工作。
DevOps鼓勵(lì)軟件開發(fā)者和IT運(yùn)維人員之間所進(jìn)行的溝通、協(xié)作、集成和自動(dòng)化，借此有助于改善雙方在交付軟件過程中的速度和質(zhì)量。
DevOps團(tuán)隊(duì)更側(cè)重于通過標(biāo)準(zhǔn)化開發(fā)環(huán)境和自動(dòng)化交付流程改善交付工作的可預(yù)測(cè)性、效率、安全性，以及可維護(hù)性。理想情況下，DevOps可以為開發(fā)者提供更可控的生產(chǎn)環(huán)境，幫助他們更好地理解生產(chǎn)基礎(chǔ)架構(gòu)。
DevOps鼓勵(lì)團(tuán)隊(duì)自主進(jìn)行自己應(yīng)用程序的構(gòu)建、驗(yàn)證、交付和支持。
那么核心原則到底是什么？
下文將介紹最重要的三大基本原則。
2. 基礎(chǔ)架構(gòu)即代碼
人總會(huì)犯錯(cuò)，因?yàn)槿四X實(shí)在是不擅長(zhǎng)處理重復(fù)性的任務(wù)，相比Shell腳本，人類的速度實(shí)在是太慢了。畢竟我們都是人類，因此有必要像處理代碼那樣考慮和處理有關(guān)基礎(chǔ)架構(gòu)的概念！
基礎(chǔ)架構(gòu)即代碼（IaC）是大部分通用DevOps實(shí)踐的前提要求，例如版本控制、代碼審閱、持續(xù)集成、自動(dòng)化測(cè)試。這一概念涉及計(jì)算基礎(chǔ)架構(gòu)（容器、虛擬機(jī)、物理機(jī)、軟件安裝等）的管理和供應(yīng)，以及通過機(jī)器可處理的定義文件或腳本對(duì)其進(jìn)行的配置，交互式配置工具和手工命令的使用已經(jīng)不合時(shí)宜了。
這一原則對(duì)DevOps的重要性怎么強(qiáng)調(diào)都不為過，它可以真正將軟件開發(fā)相關(guān)的實(shí)踐應(yīng)用給服務(wù)器和基礎(chǔ)架構(gòu)。
云計(jì)算使得復(fù)雜的IT部署可以繼續(xù)效仿傳統(tǒng)物理拓?fù)洹Ｎ覀兛梢韵鄬?duì)輕松地對(duì)復(fù)雜虛擬網(wǎng)絡(luò)、存儲(chǔ)和服務(wù)器的構(gòu)建實(shí)現(xiàn)自動(dòng)化。服務(wù)器環(huán)境的方方面面，上至基礎(chǔ)架構(gòu)下至操作系統(tǒng)設(shè)置，均可編碼并存儲(chǔ)至版本控制倉庫。
2.1 概述
以非常概括的方式來看，基礎(chǔ)架構(gòu)和運(yùn)維所需實(shí)現(xiàn)的自動(dòng)化程度可通過下圖這種架構(gòu)來表示：
上述架構(gòu)圖中作為示例的工具主要面向不同層的構(gòu)建工作，實(shí)際上DevOps工具鏈的作用遠(yuǎn)不止如此。
我覺得在這里可以略微深入地談?wù)凞evOps的工具鏈了。
2.2 DevOps工具鏈
DevOps實(shí)際是一種文化上的變遷，代表了開發(fā)、運(yùn)維、測(cè)試等環(huán)節(jié)之間的協(xié)作，因此DevOps工具是非常多種多樣的，甚至可以由多種工具組成一個(gè)完整的DevOps工具鏈。此類工具可以應(yīng)用于一種或多種類別，并可體現(xiàn)出軟件開發(fā)和交付過程的不同階段：
編碼：代碼開發(fā)和審閱，版本控制工具、代碼合并工具
構(gòu)建：持續(xù)集成工具、構(gòu)建狀態(tài)統(tǒng)計(jì)工具
測(cè)試：通過測(cè)試和結(jié)果確定績(jī)效的工具
打包：成品倉庫、應(yīng)用程序部署前暫存
發(fā)布：變更管理、發(fā)布審批、發(fā)布自動(dòng)化
配置：基礎(chǔ)架構(gòu)配置和部署，基礎(chǔ)架構(gòu)即代碼工具
監(jiān)視：應(yīng)用程序性能監(jiān)視、最終用戶體驗(yàn)
雖然可用工具有很多，但其中一些環(huán)節(jié)是組織內(nèi)部應(yīng)用DevOps工具鏈不可或缺的。
諸如Docker（容器化）、Jenkins（持續(xù)集成）、Puppet（基礎(chǔ)架構(gòu)構(gòu)建）、Vagrant（虛擬化平臺(tái)）等常用、廣泛使用的工具都是2016年的DevOps熱門工具。
基礎(chǔ)架構(gòu)組件的版本控制、持續(xù)集成和自動(dòng)化測(cè)試
基礎(chǔ)架構(gòu)的版本控制能力（而非基礎(chǔ)架構(gòu)的構(gòu)建腳本或配置文件）及對(duì)其進(jìn)行自動(dòng)化測(cè)試的能力極其重要。
DevOps最終會(huì)將30年前軟件工程領(lǐng)域所采用的同一套XP實(shí)踐帶至生產(chǎn)端。
此外基礎(chǔ)架構(gòu)元素應(yīng)該能向軟件交付物一樣進(jìn)行持續(xù)集成。
2.3 收益
DevOps的收益有很多，包括但不限于：
可重復(fù)性與可靠性：時(shí)至今日，構(gòu)建生產(chǎn)用計(jì)算機(jī)只需要運(yùn)行腳本或必要的puppet命令即可。通過恰當(dāng)?shù)厥褂肈ocker容器或Vagrant虛擬機(jī)，只需運(yùn)行一條命令即可配置好包含操作系統(tǒng)層以及所需軟件和配置的生產(chǎn)用計(jì)算機(jī)。當(dāng)然，隨著各種變更或軟件開發(fā)、持續(xù)集成，并自動(dòng)測(cè)試，這套構(gòu)建腳本或機(jī)制也會(huì)進(jìn)行持續(xù)集成。
最終幸虧有了XP或敏捷，我們?cè)谲浖_發(fā)端所使用的同一套實(shí)踐也能讓運(yùn)維端獲益。
生產(chǎn)力：一鍵部署，一鍵供應(yīng)，一鍵創(chuàng)建新環(huán)境……整個(gè)生產(chǎn)環(huán)境可以通過一條命令或一鍵點(diǎn)擊的方式創(chuàng)建。這樣的一條命令也許會(huì)運(yùn)行長(zhǎng)達(dá)數(shù)小時(shí)，但在這過程中運(yùn)維人員可以從事其他更有趣的工作，而無需等待一條命令執(zhí)行完畢后繼續(xù)輸入下一條命令，畢竟這樣的過程有時(shí)候可能需要花費(fèi)幾天時(shí)間才能完成……
恢復(fù)時(shí)間！：一鍵點(diǎn)擊即可恢復(fù)生產(chǎn)環(huán)境，就是這么簡(jiǎn)單。
確保基礎(chǔ)架構(gòu)的同質(zhì)：徹底避免運(yùn)維人員每次構(gòu)建環(huán)境或安裝軟件時(shí)最終獲得的結(jié)果與預(yù)期有所差異，這是確保基礎(chǔ)架構(gòu)絕對(duì)同質(zhì)（Homogeneous）并且可再現(xiàn)的唯一可行方法。以此為基礎(chǔ)，通過對(duì)腳本或Puppet配置文件使用版本控制機(jī)制，我們甚至可以重建出與上周、上個(gè)月，或軟件特定版本發(fā)布時(shí)完全一致的生產(chǎn)環(huán)境。
維持整齊劃一的標(biāo)準(zhǔn)：基礎(chǔ)架構(gòu)標(biāo)準(zhǔn)甚至可以不復(fù)存在，代碼本身就是標(biāo)準(zhǔn)。
讓開發(fā)者自行完成大部分工作：如果開發(fā)者自己突然可以在自己的基礎(chǔ)架構(gòu)上一鍵點(diǎn)擊重建生產(chǎn)環(huán)境，他們也就可以自行完成很多與生產(chǎn)環(huán)境有關(guān)的任務(wù)，例如更好地理解生產(chǎn)失敗，提供更恰當(dāng)?shù)呐渲茫瑢?shí)現(xiàn)部署腳本等。
這只是我個(gè)人感覺IaC可提供的部分收益，相信還有很多其他收益。
3. 持續(xù)交付
持續(xù)交付是一種可以幫助團(tuán)隊(duì)以更短的周期交付軟件的方法，該方法確保了團(tuán)隊(duì)可以在任何時(shí)間發(fā)布出可靠的軟件。該方法意在以更快速度更高頻率進(jìn)行軟件的構(gòu)建、測(cè)試和發(fā)布。
通過對(duì)生產(chǎn)環(huán)境中的應(yīng)用程序進(jìn)行更高頻次的增量更新，這種方法有助于降低交付變更過程中涉及的成本、時(shí)間和風(fēng)險(xiǎn)。足夠簡(jiǎn)單直接并且可重復(fù)的部署流程對(duì)持續(xù)交付而言至關(guān)重要。
注意：持續(xù)交付 ≠ 持續(xù)部署?- 有時(shí)候很多人會(huì)把持續(xù)交付誤認(rèn)為成持續(xù)部署。持續(xù)部署是指每個(gè)變更可以自動(dòng)部署到生產(chǎn)環(huán)境。持續(xù)交付是指團(tuán)隊(duì)確保每個(gè)變更可以部署至生產(chǎn)環(huán)境，但也許并不需要實(shí)際部署，這通常可能是出于業(yè)務(wù)方面的原因。只有成功實(shí)現(xiàn)持續(xù)交付的前提下，才能進(jìn)行持續(xù)部署。
持續(xù)交付的主要想法在于：
部署越頻繁，對(duì)部署流程就會(huì)越熟悉，自動(dòng)化機(jī)制就能獲得更好的結(jié)果。如果同一件事每天需要執(zhí)行3次，很快你將變的無比嫻熟，但很快也會(huì)因?yàn)槿諒?fù)一日解決同樣的問題而感到厭煩。
部署越頻繁，所部屬的變更集就越微不足道，而這些微不足道的內(nèi)容最有可能出錯(cuò)，甚至可能導(dǎo)致丟失對(duì)整個(gè)變更集的控制力。
部署越頻繁，TTR（修復(fù)／解決所需時(shí)間）指標(biāo)就會(huì)越出色，從業(yè)務(wù)用戶處獲得有關(guān)功能的各類反饋的速度越快，作出改進(jìn)以便完美滿足對(duì)方需求的過程也會(huì)越簡(jiǎn)單（這方面TTR與TTM其實(shí)非常相似）。
（來源：Ops Meta-Metrics: The Currency You Pay For Change?）
但持續(xù)交付并不僅僅是盡可能頻繁地構(gòu)建可發(fā)布、生產(chǎn)就緒版本的軟件產(chǎn)品那么簡(jiǎn)單。持續(xù)交付包含3個(gè)關(guān)鍵實(shí)踐：
從實(shí)踐中學(xué)習(xí)
自動(dòng)化
更頻繁的部署
3.1 從實(shí)踐中學(xué)習(xí)
持續(xù)交付的關(guān)鍵在于要能從實(shí)踐中學(xué)習(xí)。真理并不存在于開發(fā)團(tuán)隊(duì)中，而在于業(yè)務(wù)用戶中。然而無論花多長(zhǎng)時(shí)間，沒人能真正清楚地表達(dá)自己的想法，或者將自己的想法用清晰的文檔概括出來。也正是因此，敏捷方法論強(qiáng)調(diào)將功能提供給用戶，并不惜一切代價(jià)從用戶處獲得盡可能多的反饋。
持續(xù)交付與持續(xù)部署類似，需要盡可能減少前置時(shí)間，這也是盡快從用戶處獲得“真理”的關(guān)鍵。
但真理絕對(duì)不會(huì)來自正規(guī)形式的用戶反饋。我們絕不能盡信自己的用戶或寄希望于通過正規(guī)形式的反饋了解用戶。我們只能相信自己的度量。
癡迷于度量是精益創(chuàng)業(yè)（Lean Startup）活動(dòng)中一個(gè)重要的概念，但這一概念對(duì)DevOps同樣重要。我們應(yīng)該度量一切！確定最恰當(dāng)?shù)亩攘恐笜?biāo)可以讓團(tuán)隊(duì)了解某種方法最終能否成功或失敗，了解怎樣做可以獲得更好的結(jié)果，以及哪些最成功的做法同時(shí)也蘊(yùn)含著一定的風(fēng)險(xiǎn)。為了幫助團(tuán)隊(duì)做出更明智的決策，在確定要衡量的指標(biāo)時(shí)，一定要抱著“寧多勿少”的原則。
不需要“考慮”，只需要“知道”！“知道”的唯一方法就是度量，度量一切：響應(yīng)時(shí)間、用戶思考時(shí)間、展示次數(shù)、API調(diào)用次數(shù)、點(diǎn)擊率等，但這些并非需要度量的全部。找出所有能讓你更進(jìn)一步了解用戶對(duì)功能看法的度量指標(biāo)，對(duì)所有這些指標(biāo)進(jìn)行度量！
這種方法可以表示為如下形式：
3.2 自動(dòng)化
自動(dòng)化已經(jīng)在上文2. 基礎(chǔ)架構(gòu)即代碼一節(jié)進(jìn)行了討論。
在這里我想強(qiáng)調(diào)的是，在沒有將與基礎(chǔ)架構(gòu)有關(guān)的所有供應(yīng)和任務(wù)實(shí)現(xiàn)妥善、全面的自動(dòng)化之前，持續(xù)交付根本無從談起。
這一點(diǎn)很重要，因此有必要再重復(fù)一遍：環(huán)境的搭建和生產(chǎn)就緒版本軟件的部署只需要一鍵點(diǎn)擊，只需要運(yùn)行一條命令，整個(gè)過程應(yīng)該自動(dòng)完成。否則根本無法設(shè)想能一天多次部署同一個(gè)軟件。
在下文的3.5 零停機(jī)部署一節(jié)中，還將介紹有助于自動(dòng)化交付的其他重要技術(shù)。
3.3 更頻繁的部署
DevOps的信條在于：
“越是困難的事，需要更頻繁地進(jìn)行！”
敏捷思維中，困難任務(wù)更要迎難而上，更頻繁地去做，這中想法非常重要。
自動(dòng)化測(cè)試、重構(gòu)、數(shù)據(jù)庫遷移、面向客戶的產(chǎn)品規(guī)格、規(guī)劃、發(fā)布 - 所有這些活動(dòng)都要盡可能頻繁地進(jìn)行。
原因主要有三點(diǎn)：
首先，隨著要做的工作量逐漸增加，這些任務(wù)也會(huì)變的愈加困難，但如果能拆解為小塊，則會(huì)變的相對(duì)容易些。
以數(shù)據(jù)庫遷移為例：一些涉及大量表的大規(guī)模數(shù)據(jù)庫遷移工作很麻煩，容易出錯(cuò)。但如果一次只遷移一部分，則可以相對(duì)較容易地成功完成整個(gè)遷移任務(wù)。此外還可以輕松地將多個(gè)小規(guī)模的遷移任務(wù)安排成一定的序列，在將一個(gè)艱難的大任務(wù)拆解為一系列容易實(shí)現(xiàn)的小目標(biāo)后，處理起來就簡(jiǎn)單多了。（這也是數(shù)據(jù)庫重構(gòu)的本質(zhì)）
第二個(gè)原因在于反饋。大部分敏捷思維關(guān)注的是設(shè)置反饋環(huán)路，借此讓我們更快速地學(xué)習(xí)了解。反饋已經(jīng)是極限編程（Extreme Programming）中一個(gè)非常重要，蘊(yùn)含巨大價(jià)值的概念。在諸如軟件開發(fā)等復(fù)雜流程中，我們需要更頻繁地檢查自己的最新進(jìn)展，并進(jìn)行必要的糾正。為此我們必須盡一切可能創(chuàng)建反饋環(huán)路，并提高反饋的頻率，這樣才能更快速地酌情做出調(diào)整。
第三個(gè)原因是實(shí)踐。對(duì)于任何活動(dòng)，越頻繁地從事就越能獲得完善。實(shí)踐可以幫助我們理清整個(gè)流程，讓我們更熟悉代表有事情出錯(cuò)的征兆。只要認(rèn)真琢磨自己從事的工作，就能提煉出近一步完善所需的實(shí)踐。
對(duì)于軟件開發(fā)，也有可能實(shí)現(xiàn)一定程度的自動(dòng)化。一旦有人將某件事做了多次，就可以更容易地確定該如何進(jìn)行自動(dòng)化，更重要的是，這樣的人在對(duì)這些事情實(shí)現(xiàn)自動(dòng)化方面將有更大的動(dòng)機(jī)。此時(shí)自動(dòng)化尤為重要，因?yàn)榭梢约涌焖俣炔⒔档统鲥e(cuò)的概率。
那么這就產(chǎn)生了一個(gè)問題：使用DevOps方法時(shí)，該選擇怎樣的交付頻率？
這個(gè)問題沒有標(biāo)準(zhǔn)答案，而是取決于產(chǎn)品、團(tuán)隊(duì)、市場(chǎng)、公司、用戶、運(yùn)維需求等各種因素。
我認(rèn)為最佳答案應(yīng)該是：如果不能實(shí)現(xiàn)至少每?jī)芍芤淮谓桓叮蛟跊_刺階段結(jié)束時(shí)交付，那么連敏捷都談不上，DevOps又從何談起呢？
DevOps鼓勵(lì)我們盡可能頻繁的交付。在我看來，你需要對(duì)團(tuán)隊(duì)進(jìn)行培訓(xùn)，讓他們能夠做到盡可能頻繁的交付。我在我的團(tuán)隊(duì)中使用的一種較為可行的方法是在QA環(huán)境中每天交付兩次。交付過程是完全自動(dòng)化的：每天兩次，中午和午夜各一次，計(jì)算機(jī)啟動(dòng)起來，構(gòu)建軟件組件，運(yùn)行集成測(cè)試，構(gòu)建并啟動(dòng)虛擬機(jī)，部署軟件組件，對(duì)其進(jìn)行配置，運(yùn)行功能測(cè)試等。
3.4 持續(xù)交付的前提需求
在改為使用持續(xù)交付方式之前，需要滿足哪些要求？
我草擬的需求清單如下：
對(duì)軟件組件的開發(fā)和平臺(tái)的供應(yīng)和設(shè)置進(jìn)行持續(xù)集成。
TDD - 測(cè)試驅(qū)動(dòng)的開發(fā)。這一點(diǎn)還有待商榷……但始終還是需要面對(duì)：TDD是目前唯一能通過單元測(cè)試對(duì)代碼和分支進(jìn)行可接受程度覆蓋的方法（單元測(cè)試使得問題的修復(fù)過程比集成測(cè)試或功能測(cè)試容易很多）。
代碼審閱！至少要進(jìn)行代碼審閱……如果能進(jìn)行結(jié)對(duì)編程（Pair programming）當(dāng)然就更好了。
軟件的持續(xù)審計(jì) - 例如使用Sonar。
在生產(chǎn)級(jí)環(huán)境實(shí)現(xiàn)功能測(cè)試的自動(dòng)化。
更強(qiáng)大的非功能測(cè)試自動(dòng)化（性能、可用性等）。
獨(dú)立于目標(biāo)環(huán)境的自動(dòng)化打包和部署。
另外在管理重大功能和演進(jìn)時(shí)，還需要具備健全的軟件開發(fā)實(shí)踐，例如零停機(jī)部署技術(shù)。
3.5 零停機(jī)部署
“零停機(jī)部署（ZDD）可在不中斷現(xiàn)有服務(wù)的情況下部署新版系統(tǒng)。”
通過ZDD方式部署應(yīng)用程序時(shí)，可在確保用戶不會(huì)遭遇應(yīng)用程序停機(jī)的前提下將新版應(yīng)用引入生產(chǎn)環(huán)境。從用戶和公司的角度來看，這應(yīng)該是最佳部署方式，因?yàn)榭梢栽诓辉斐扇魏沃袛嗟那闆r下引入新功能并修復(fù)Bug。
下文將介紹4種技術(shù)：
功能開關(guān)（Feature Flipping）
摸黑啟動(dòng)（Dark launch）
藍(lán)／綠部署（Blue/Green Deployment）
金絲雀發(fā)布（Canari release）
功能開關(guān)
功能開關(guān)可供我們?cè)谲浖\(yùn)行過程中啟用／禁用相應(yīng)的功能。這種技術(shù)其實(shí)非常容易理解和使用：為生產(chǎn)版本提供一個(gè)能徹底禁用某項(xiàng)功能的配置，并只在對(duì)應(yīng)功能徹底完工可以正常工作后才將該屬性激活。
舉例來說，若要將某個(gè)應(yīng)用程序內(nèi)的一個(gè)功能全局禁用或激活：
if Feature.isEnabled('new_awesome_feature')
? ? # Do something new, cool and awesome
else
? ? # Do old, same as always stuff
end
或者如果要真對(duì)具體用戶實(shí)現(xiàn)類似目的：
if Feature.isEnabled('new_awesome_feature', current_user)
? ? # Do something new, cool and awesome
else
? ? # Do old, same as always stuff
end
摸黑啟動(dòng)
摸黑啟動(dòng)的目的在于通過生產(chǎn)環(huán)境進(jìn)行負(fù)載模擬！
在測(cè)試環(huán)境中，通常很難為軟件模擬出成百上千萬用戶規(guī)模的負(fù)載。
如果不進(jìn)行切實(shí)的負(fù)載測(cè)試，就無法知道基礎(chǔ)架構(gòu)能否承受住最終面臨的壓力。
此時(shí)并不需要模擬負(fù)載，而是可以實(shí)際部署這樣的功能，然后看看在不影響可用性的前提下到底會(huì)發(fā)生什么。
Facebook將這種做法稱之為功能的“摸黑啟動(dòng)”。
假設(shè)我們要將一個(gè)有5億用戶使用的靜態(tài)搜索字段變成一個(gè)包含自動(dòng)補(bǔ)全功能的字段，借此讓用戶可以更快速獲得搜索結(jié)果。為該功能構(gòu)建一個(gè)Web服務(wù)，并且希望模擬所有用戶同時(shí)輸入文字，向該Web服務(wù)生成大量請(qǐng)求的場(chǎng)景。
此時(shí)即可通過摸黑啟動(dòng)策略為現(xiàn)有表單添加一個(gè)隱藏的后臺(tái)進(jìn)程，通過該進(jìn)程將輸入的搜索關(guān)鍵字發(fā)送給新增的自動(dòng)補(bǔ)全服務(wù)，并自動(dòng)發(fā)送多次。
就算新增的Web服務(wù)徹底崩潰了，也不會(huì)造成任何實(shí)質(zhì)損害。網(wǎng)頁上可以完全忽略服務(wù)器錯(cuò)誤。而就算該服務(wù)崩潰了，我們至少還可以對(duì)該服務(wù)進(jìn)行優(yōu)化和完善，直到能承受如此大量的負(fù)載。
這就等于在現(xiàn)實(shí)世界中進(jìn)行了一次負(fù)載測(cè)試。
藍(lán)／綠部署
藍(lán)／綠部署是指為下一版產(chǎn)品構(gòu)建另一個(gè)完整的生產(chǎn)環(huán)境。開發(fā)和運(yùn)維團(tuán)隊(duì)可以在這個(gè)單獨(dú)的生產(chǎn)環(huán)境中放心地構(gòu)建下一版產(chǎn)品。
當(dāng)下一版產(chǎn)品全部完成后，可以修改負(fù)載均衡器的配置，以透明的方式將用戶自動(dòng)重定向至新發(fā)布的下一版。
隨后可將上一版的生產(chǎn)環(huán)境回收，用于構(gòu)建下下一版的產(chǎn)品。
以此類推。
（來源：Les Patterns des Géants du Web – Zero Downtime Deployment?）
這是一種相當(dāng)有效簡(jiǎn)單的方法，但問題在于這種方式需要雙倍的基礎(chǔ)架構(gòu)以及更多的服務(wù)器等。
假設(shè)一下Facebook希望將包含成千上萬臺(tái)服務(wù)器的環(huán)境“照原樣再來一套”……
其實(shí)還有更好的方法。
金絲雀發(fā)布
從本質(zhì)來看，金絲雀發(fā)布與藍(lán)／綠部署非常類似，但無需準(zhǔn)備額外的一套生產(chǎn)環(huán)境。
這種方式的目標(biāo)在于以增量的方式將用戶切換至新版本：隨著越來越多的服務(wù)器從當(dāng)前版本遷移至下一版，相同比例的用戶也會(huì)被同時(shí)遷移。
通過這種方式，每個(gè)生產(chǎn)環(huán)境都能獲得與負(fù)載需求相匹配的服務(wù)器數(shù)量。
首先，只將少量服務(wù)器和少部分用戶遷移至下一版，借此還可以在無須冒險(xiǎn)影響所有用戶的前提下對(duì)新版進(jìn)行測(cè)試。
當(dāng)所有服務(wù)器最終從當(dāng)前版遷移至下一版后，發(fā)布工作已經(jīng)完成，又可以從頭開始準(zhǔn)備下下一版了。
（來源：Les Patterns des Géants du Web – Zero Downtime Deployment?）
4. 協(xié)作
敏捷軟件開發(fā)破除了需求分析、測(cè)試和開發(fā)之間的一些隔閡。部署、運(yùn)維和維護(hù)等其他活動(dòng)與軟件開發(fā)過程中的其他環(huán)節(jié)也存在類似的分隔。DevOps方法意在破除所有這些隔閡，鼓勵(lì)開發(fā)和運(yùn)維人員之間的協(xié)作。
如果沒有培養(yǎng)出正確的文化，就算有最棒的工具，DevOps對(duì)你而言也不過是另一個(gè)熱門詞匯罷了。
DevOps文化的主要特征在于開發(fā)和運(yùn)維角色之間日益增加的協(xié)作。這是一種在團(tuán)隊(duì)內(nèi)部以及組織層面上很重要的文化變遷，通過這樣的變遷才能促進(jìn)更好的協(xié)作。
這種方式解決了一個(gè)非常重要的問題，而這個(gè)問題完全可以用下面這個(gè)網(wǎng)絡(luò)流行話來體現(xiàn)：
（來源：DevOps Memes @ EMCworld 2015?）
團(tuán)隊(duì)合作對(duì)DevOps是如此的重要，大部分方法論所要實(shí)現(xiàn)的最終目標(biāo)總的來說可以通過兩個(gè)C來實(shí)現(xiàn)：協(xié)作（Collaboration）和溝通（Communication）。雖然單純做到這些距離真正的DevOps工作環(huán)境還有很大的差距，但任何公司只要能堅(jiān)持這兩個(gè)C，就等于邁出了最正確的第一步。
但為什么會(huì)那么難做到？
4.1 混亂之墻
因?yàn)橛幸欢禄靵y之墻：
在傳統(tǒng)開發(fā)周期中，開發(fā)團(tuán)隊(duì)將新發(fā)布的軟件“隔墻扔給”運(yùn)維人員，意味著自己的工作已經(jīng)順利完成。
運(yùn)維人員接手開發(fā)者的成果，準(zhǔn)備開始進(jìn)行部署。運(yùn)維人員手工修改由開發(fā)者提供的部署腳本，當(dāng)然更多時(shí)候這些腳本都是運(yùn)維人員自己維護(hù)的。
運(yùn)維人員還需要手工修改配置文件，以反映生產(chǎn)環(huán)境的需求，而生產(chǎn)環(huán)境往往與開發(fā)或QA環(huán)境有很大差異。
就算最理想的情況，運(yùn)維人員可能只是做了一些在上一個(gè)環(huán)境中已經(jīng)做過的重復(fù)工作，而最糟糕的情況，可能會(huì)引入或發(fā)現(xiàn)新的Bug。
隨后IT運(yùn)維團(tuán)隊(duì)開始討論他們所認(rèn)為的，目前最正確的部署流程，然而由于開發(fā)和運(yùn)維在腳本、配置、流程，甚至環(huán)境等方面的差異，基本上等同于要從零開始將所有工作重新執(zhí)行一遍。
當(dāng)然這一過程中不可避免會(huì)遇到問題，他們聯(lián)系開發(fā)者希望進(jìn)行排錯(cuò)。運(yùn)維稱開發(fā)者提供的代碼本身有問題，開發(fā)者則回應(yīng)稱代碼在自己的環(huán)境中一切正常，因此錯(cuò)誤肯定源自運(yùn)維端。
由于配置、文件位置，以及面臨這種狀態(tài)所執(zhí)行的操作與自己的預(yù)期等因素存在較大差異，開發(fā)者甚至很難對(duì)這樣的問題進(jìn)行診斷。變更窗口留下的時(shí)間所剩無幾，當(dāng)然也沒什么足夠靠譜的方法將環(huán)境回滾至上一個(gè)正常狀態(tài)。
那么原本應(yīng)該一帆風(fēng)順的部署過程，為什么最后卻變成了“眾志成城”的應(yīng)急演習(xí)？必須經(jīng)歷大量指責(zé)和錯(cuò)誤才能最終讓生產(chǎn)環(huán)境恢復(fù)可用狀態(tài)？
這種情況經(jīng)常發(fā)生，經(jīng)常！
DevOps來救場(chǎng)了
通過在共同的業(yè)務(wù)目的情境中讓開發(fā)和運(yùn)維角色與流程變的一致，DevOps有助于促進(jìn)IT的統(tǒng)一。開發(fā)和運(yùn)維都需要明確，自己是統(tǒng)一業(yè)務(wù)流程的一份子。DevOps思維確保了無論組織結(jié)構(gòu)是怎樣的，個(gè)體決策與行為需要盡力為統(tǒng)一的業(yè)務(wù)流程提供支持和促進(jìn)作用。
亞馬遜CTOWerner Vogel甚至在2014年說過：
“誰開發(fā)，誰運(yùn)行。”
4.2 軟件開發(fā)流程
下圖簡(jiǎn)要描述了敏捷軟件開發(fā)流程通常的樣子。
最開始，業(yè)務(wù)代表與產(chǎn)品負(fù)責(zé)人以及架構(gòu)團(tuán)隊(duì)合作定義軟件，這一過程可能會(huì)使用Story Mapping和用戶故事，或者使用更完整的規(guī)范。
隨后開發(fā)團(tuán)隊(duì)通過短暫的開發(fā)沖刺開發(fā)出軟件，并在每個(gè)沖刺結(jié)束后將生產(chǎn)就緒版本的軟件發(fā)布給業(yè)務(wù)用戶，進(jìn)而收集反饋并盡可能頻繁地調(diào)整方向。
最后，經(jīng)歷過每個(gè)新的里程碑后，將軟件部署給整個(gè)業(yè)務(wù)線更廣泛的用戶群體。
DevOps造成的最大挑戰(zhàn)在于需要理解運(yùn)維人員是軟件的另一個(gè)用戶群體！因此他們也應(yīng)該被全面納入軟件開發(fā)流程中。
在預(yù)定的時(shí)間里，運(yùn)維應(yīng)該給出自己的非功能需求，就如同業(yè)務(wù)用戶給出自己的功能需求一樣。開發(fā)團(tuán)隊(duì)?wèi)?yīng)該按照同等程度的重要性和優(yōu)先級(jí)處理這種非功能需求。
在實(shí)現(xiàn)的過程中，運(yùn)維應(yīng)該持續(xù)提供反饋和非功能測(cè)試規(guī)范，就像業(yè)務(wù)用戶針對(duì)功能特性提供反饋一樣。
最后，運(yùn)維和業(yè)務(wù)用戶一樣，成為了軟件的用戶。
通過采用DevOps方法，運(yùn)維可以全面融入軟件開發(fā)流程中。
4.3 共享工具
在傳統(tǒng)的大型企業(yè)中，運(yùn)維團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)分別使用專用的，沒有什么交集的工具集。
運(yùn)維人員通常并不想了解開發(fā)團(tuán)隊(duì)所使用的SCM系統(tǒng)以及持續(xù)集成環(huán)境。他們認(rèn)為這些并非自己的本職工作，害怕自己在觸及這些系統(tǒng)后會(huì)被開發(fā)者的各種請(qǐng)求所淹沒。畢竟他們?yōu)榱苏樟仙a(chǎn)系統(tǒng)就有忙不完的工作了。
另一方面，開發(fā)者通常無法訪問生產(chǎn)系統(tǒng)的日志和監(jiān)視日志，有時(shí)這是因?yàn)闆]有這樣的意愿，有時(shí)則是因?yàn)橹贫然虬踩矫娴念檻]。
這種狀況需要改變！DevOps應(yīng)運(yùn)而生。
這個(gè)目標(biāo)其實(shí)很難實(shí)現(xiàn)。舉例來說，出于制度或安全方面的原因，日志可能會(huì)被實(shí)時(shí)匿名化，同時(shí)需要對(duì)監(jiān)管工具進(jìn)行必要的保護(hù)，以避免未經(jīng)培訓(xùn)或本應(yīng)被禁止的開發(fā)者更改生產(chǎn)環(huán)境的配置。因此實(shí)現(xiàn)這一目標(biāo)需要付出大量時(shí)間和成本資源。但這樣做所能獲得的收益遠(yuǎn)大于所需進(jìn)行的投入，這種方法對(duì)整個(gè)公司的投資回報(bào)非常明顯。
4.4 協(xié)同工作
DevOps的一種基本哲學(xué)是認(rèn)為，開發(fā)者和運(yùn)維人員必須定期進(jìn)行密切的合作。
這就意味著他們必須將對(duì)方視作重要的利益相關(guān)者，并積極主動(dòng)地尋求合作。
受到XP實(shí)踐中“現(xiàn)場(chǎng)客戶”的啟發(fā)，敏捷開發(fā)者受此激勵(lì)可以與業(yè)務(wù)進(jìn)行更緊密的合作，自律的敏捷者還可以更進(jìn)一步將這樣的實(shí)踐運(yùn)用給更廣泛的利益相關(guān)者，例如可以讓開發(fā)者與所有其他相關(guān)者進(jìn)行合作，包括運(yùn)維和支持人員。
這是一條雙行道：運(yùn)維和支持人員也必須愿意與開發(fā)者進(jìn)行密切的合作。
此外還可以通過協(xié)作：
讓運(yùn)維人員參與敏捷儀式（每日Scrum、沖刺規(guī)劃、再次沖刺等）
讓開發(fā)者參與生產(chǎn)環(huán)境的推出任務(wù)
在開發(fā)和運(yùn)維之間打造統(tǒng)一的持續(xù)改進(jìn)目標(biāo)
5. 結(jié)論
DevOps是一次革命，主要是為了消除擁有大規(guī)模IT部門的大型企業(yè)中，開發(fā)團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)之間由于歷史原因產(chǎn)生的隔閡與孤立所造成的混亂現(xiàn)狀。
在我15年的職業(yè)生涯中，2/3的時(shí)間就職于此類大行機(jī)構(gòu)，其中大部分是金融機(jī)構(gòu)，每天我都在見證者這堵混亂之墻的存在。例如我經(jīng)常會(huì)聽到這樣的說法：
“在我的Tomcat上工作很正常，很抱歉，但我完全不懂你所用的Websphere，幫不上你了。”（開發(fā)者說）
“我們真的不能從生產(chǎn)數(shù)據(jù)庫中給你提取這張表，里面包含了與客戶有關(guān)的機(jī)密數(shù)據(jù)。”（運(yùn)維人員說）
每天都會(huì)遇到其他很多類似的對(duì)話……天天如此！
好在DevOps日漸成熟，越來越多傳統(tǒng)企業(yè)也在開始逐漸走上正途，開始接受DevOps的原則和實(shí)踐。但還有很多企業(yè)無動(dòng)于衷。
那么對(duì)于那些小規(guī)模的，開發(fā)和運(yùn)維職能之間通常不會(huì)產(chǎn)生那么大分歧的企業(yè)呢？
這樣的企業(yè)應(yīng)用DevOps原則和實(shí)踐，例如自動(dòng)化部署、持續(xù)交付和功能開關(guān)，一樣能獲益匪淺。
我認(rèn)為DevOps原則可以總結(jié)為：
DevOps實(shí)際上是向著大規(guī)模敏捷（Scaling Agility）邁出的另一步！
