1. 簡介
   DevOps所關(guān)注的不是工具本身，也不是對chef或Docker的掌握程度瓤介。DevOps是一種方法論，是一系列可以幫助開發(fā)者和運維人員在實現(xiàn)各自目標（Goal）的前提下瓷胧，向自己的客戶或用戶交付最大化價值及最高質(zhì)量成果的基本原則和實踐趟庄。
   開發(fā)者和運維人員之間最大的問題在于：雖然都是企業(yè)中大型IT部門不可或缺的括细，但他們有著截然不同的目的（Objective）。
   
   
   開發(fā)者和運維人員之間目的上的差異就叫做混亂之墻戚啥。下文會介紹這個概念的準確定義奋单，以及為什么我認為這種狀況很嚴峻并且很糟糕。
   DevOps是一種融合了一系列基本原則和實踐的方法論（并從這些實踐中派生出了各種工具）猫十，意在幫助這些人員向著一個統(tǒng)一的共同目的努力：盡可能為公司提供更多價值览濒。
   令人驚奇的是，這個問題竟然有一個非常簡單的“銀子彈”：讓生產(chǎn)端變得敏捷起來拖云！
   而這恰恰正是DevOps所要達成的唯一目標贷笛！
   但在進一步討論這一點之前，首先需要談?wù)勂渌麕准隆?br> 1.1 管理信條
   IT管理這場戰(zhàn)爭的原動力到底是什么宙项？換句話說乏苦，在軟件開發(fā)項目中，管理工作首要的尤筐，以及最重要的目的是什么汇荐？
   有什么想法嗎？
   我來提供一個線索吧：在建立一家初創(chuàng)公司時盆繁，最重要的事情是什么掀淘？
   當(dāng)然是要加快上市時間（TTM）！
   上市時間（即TTM）是指一件產(chǎn)品從最初的構(gòu)思到最終可供用戶使用或購買這一過程所需要的時間改基。對于產(chǎn)品很快會過時的行業(yè)繁疤，TTM是一個非常重要的概念。
   在軟件工程方面秕狰，所采用的方法稠腊、業(yè)務(wù)，以及具體技術(shù)幾乎每年都會變化鸣哀，因而TTM就成了一個非常重要的KPI（關(guān)鍵績效指標）架忌。
   TTM通常也會被叫做前置時間（Lead Time）。
   第一個問題在于我衬，（很多人認為）在開發(fā)過程中TTM和產(chǎn)品質(zhì)量是兩個對立的屬性叹放。在下文可以看到，改善質(zhì)量（進而提高穩(wěn)定性）是運維人員的目的挠羔，而開發(fā)者的目的在于降低前置時間（進而提高TTM）井仰。
   請容我來解釋一下。
   IT組織或部門通常會通過兩個關(guān)鍵的KPI進行評估：軟件本身的質(zhì)量破加，因而需要盡可能減少缺陷的數(shù)量俱恶；此外還有TTM，因而需要將業(yè)務(wù)構(gòu)想（通常由業(yè)務(wù)用戶提供）變?yōu)樽罱K成果，并以盡可能快的速度提供給用戶或客戶合是。
   這里的問題在于了罪，大部分情況下這兩個截然不同的目的是由兩個不同團隊提供支持的：負責(zé)構(gòu)建軟件的開發(fā)者，以及負責(zé)運行軟件的運維人員聪全。
   1.2 一個典型的IT組織
   在組織內(nèi)部負責(zé)管理重要IT部門的典型IT組織通巢磁海看起來是這樣的：
   
   
   主要由于歷史的原因（大部分運維人員來自硬件和電信業(yè)務(wù)領(lǐng)域），運維人員和開發(fā)者分屬不同的組織結(jié)構(gòu)分支难礼。開發(fā)者屬于研發(fā)部門娃圆，而運維人員大部分時候?qū)儆诨A(chǔ)架構(gòu)部門（或?qū)ｉT的運維部門）。
   別忘了鹤竭，他們有著不同的目的：
   
   
   此外作為旁注踊餐，這兩個團隊有時候會使用不同的預(yù)算來運營。開發(fā)團隊使用構(gòu)建（Build）預(yù)算臀稚，運維團隊使用運營（Run）預(yù)算吝岭。不同的預(yù)算，對控制權(quán)越來越高的需求吧寺，以及企業(yè)IT成本的縮水窜管，這些因素結(jié)合在一起會進一步放大兩個團隊各自目的的對立性。
   （依本人愚見稚机，時至今日幕帆，隨著人與人之間無時無刻隨時隨地進行的交互，以及由不同目的推動著企業(yè)和社會進行數(shù)字化轉(zhuǎn)型赖条，IT預(yù)算方面古老的“規(guī)劃/構(gòu)建/運行”框架已經(jīng)不那么合理了失乾，不過這又是另一回事了。）
   1.3 運維人員測挫敗感
   接下來看看運維人員纬乍，一起看看典型的運維團隊把大部分時間都花在哪里了：
   
   
   （來源：Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services]
   生產(chǎn)團隊有將近一半（47%）的時間花在了與部署有關(guān)的工作中：
   執(zhí)行實際的部署工作碱茁，或
   修復(fù)與部署工作有關(guān)的問題

這樣的KPI其實相當(dāng)瘋狂，但實際上我們早就應(yīng)該采納仿贬。實際上早在40年前纽竣，計算機科學(xué)的“原始時代”就已涌現(xiàn)出運維團隊，當(dāng)時計算機主要運用在工業(yè)界茧泪，運維人員需要手工運行大量命令來執(zhí)行自己的任務(wù)蜓氨。為了履行職責(zé)，他們已經(jīng)習(xí)慣于按照清單運行各種各樣的命令或手工流程队伟。
突然有一天他們終于意識到自己“總在做著相同的事情”穴吹，然而長達四十多年的工作過程中卻幾乎沒人考慮過變革。
考慮到這一點你會發(fā)現(xiàn)嗜侮，實在是太瘋狂了刀荒。平均來說代嗤，運維人員將近一半的時間都在處理與部署有關(guān)的任務(wù)棘钞！
為了改變這種狀況缠借，必須考慮到兩個最關(guān)鍵的需求：
通過自動化部署將目前這種手工任務(wù)所需的時間減少31%。
通過產(chǎn)業(yè)化措施（類似于通過XP和敏捷實現(xiàn)的軟件開發(fā)產(chǎn)業(yè)化）將需要處理的與這些部署有關(guān)的問題減少16%宜猜。

1.4 基礎(chǔ)架構(gòu)自動化
在這方面也有一個相當(dāng)富有啟發(fā)性的統(tǒng)計結(jié)果：
以手工操作的數(shù)量所表示的成功部署概率泼返。

這些統(tǒng)計告訴我們：
只需手工運行5條命令的情況下，成功部署的概率就已跌至86%姨拥。
如需手工運行55條命令绅喉，成功部署的概率將跌至22%。
如需手工運行100條命令叫乌，成功部署的概率將趨近于0（僅2%）柴罐！

成功部署意味著軟件能夠按照預(yù)期在生產(chǎn)環(huán)境中運行。未能成功部署意味著有東西出錯憨奸，可能需要進行必要的分析才能了解部署過程中哪里出錯革屠，是否需要應(yīng)用某種補丁，或需要修改某些配置排宰。
因此讓這一切實現(xiàn)自動化并不惜一切代價避免手工操作似乎是個好主意似芝，對吧？
那么行業(yè)里這方面的現(xiàn)狀是怎樣的：

他們這種做法秘密何在饥伊？
1.5 DevOps：僅此一次象浑，一顆神奇的銀子彈
他們的秘密很簡單：將敏捷擴展至生產(chǎn)端：

2. 基礎(chǔ)架構(gòu)即代碼
   人總會犯錯蘸嘶，因為人腦實在是不擅長處理重復(fù)性的任務(wù)良瞧，相比Shell腳本，人類的速度實在是太慢了训唱。畢竟我們都是人類褥蚯，因此有必要像處理代碼那樣考慮和處理有關(guān)基礎(chǔ)架構(gòu)的概念！
   基礎(chǔ)架構(gòu)即代碼（IaC）是大部分通用DevOps實踐的前提要求况增，例如版本控制赞庶、代碼審閱、持續(xù)集成澳骤、自動化測試歧强。這一概念涉及計算基礎(chǔ)架構(gòu)（容器、虛擬機为肮、物理機摊册、軟件安裝等）的管理和供應(yīng)，以及通過機器可處理的定義文件或腳本對其進行的配置颊艳，交互式配置工具和手工命令的使用已經(jīng)不合時宜了茅特。
   這一原則對DevOps的重要性怎么強調(diào)都不為過忘分，它可以真正將軟件開發(fā)相關(guān)的實踐應(yīng)用給服務(wù)器和基礎(chǔ)架構(gòu)。
   云計算使得復(fù)雜的IT部署可以繼續(xù)效仿傳統(tǒng)物理拓撲白修。我們可以相對輕松地對復(fù)雜虛擬網(wǎng)絡(luò)妒峦、存儲和服務(wù)器的構(gòu)建實現(xiàn)自動化。服務(wù)器環(huán)境的方方面面熬荆，上至基礎(chǔ)架構(gòu)下至操作系統(tǒng)設(shè)置舟山，均可編碼并存儲至版本控制倉庫。
   2.1 概述
   以非常概括的方式來看卤恳，基礎(chǔ)架構(gòu)和運維所需實現(xiàn)的自動化程度可通過下圖這種架構(gòu)來表示：
   
   
   上述架構(gòu)圖中作為示例的工具主要面向不同層的構(gòu)建工作，實際上DevOps工具鏈的作用遠不止如此寒矿。
   我覺得在這里可以略微深入地談?wù)凞evOps的工具鏈了突琳。
   2.2 DevOps工具鏈
   DevOps實際是一種文化上的變遷，代表了開發(fā)符相、運維拆融、測試等環(huán)節(jié)之間的協(xié)作，因此DevOps工具是非常多種多樣的啊终，甚至可以由多種工具組成一個完整的DevOps工具鏈镜豹。此類工具可以應(yīng)用于一種或多種類別，并可體現(xiàn)出軟件開發(fā)和交付過程的不同階段：
   編碼：代碼開發(fā)和審閱蓝牲，版本控制工具趟脂、代碼合并工具
   構(gòu)建：持續(xù)集成工具、構(gòu)建狀態(tài)統(tǒng)計工具
   測試：通過測試和結(jié)果確定績效的工具
   打包：成品倉庫例衍、應(yīng)用程序部署前暫存
   發(fā)布：變更管理昔期、發(fā)布審批、發(fā)布自動化
   配置：基礎(chǔ)架構(gòu)配置和部署佛玄，基礎(chǔ)架構(gòu)即代碼工具
   監(jiān)視：應(yīng)用程序性能監(jiān)視硼一、最終用戶體驗

雖然可用工具有很多，但其中一些環(huán)節(jié)是組織內(nèi)部應(yīng)用DevOps工具鏈不可或缺的梦抢。
諸如Docker（容器化）般贼、Jenkins（持續(xù)集成）、Puppet（基礎(chǔ)架構(gòu)構(gòu)建）奥吩、Vagrant（虛擬化平臺）等常用哼蛆、廣泛使用的工具都是2016年的DevOps熱門工具。
基礎(chǔ)架構(gòu)組件的版本控制圈驼、持續(xù)集成和自動化測試
基礎(chǔ)架構(gòu)的版本控制能力（而非基礎(chǔ)架構(gòu)的構(gòu)建腳本或配置文件）及對其進行自動化測試的能力極其重要人芽。
DevOps最終會將30年前軟件工程領(lǐng)域所采用的同一套XP實踐帶至生產(chǎn)端。
此外基礎(chǔ)架構(gòu)元素應(yīng)該能向軟件交付物一樣進行持續(xù)集成绩脆。
2.3 收益
DevOps的收益有很多萤厅，包括但不限于：
可重復(fù)性與可靠性：時至今日橄抹，構(gòu)建生產(chǎn)用計算機只需要運行腳本或必要的puppet命令即可。通過恰當(dāng)?shù)厥褂肈ocker容器或Vagrant虛擬機惕味，只需運行一條命令即可配置好包含操作系統(tǒng)層以及所需軟件和配置的生產(chǎn)用計算機楼誓。當(dāng)然，隨著各種變更或軟件開發(fā)名挥、持續(xù)集成疟羹，并自動測試，這套構(gòu)建腳本或機制也會進行持續(xù)集成禀倔。最終幸虧有了XP或敏捷榄融，我們在軟件開發(fā)端所使用的同一套實踐也能讓運維端獲益。

生產(chǎn)力：一鍵部署救湖，一鍵供應(yīng)愧杯，一鍵創(chuàng)建新環(huán)境……整個生產(chǎn)環(huán)境可以通過一條命令或一鍵點擊的方式創(chuàng)建。這樣的一條命令也許會運行長達數(shù)小時鞋既，但在這過程中運維人員可以從事其他更有趣的工作力九，而無需等待一條命令執(zhí)行完畢后繼續(xù)輸入下一條命令，畢竟這樣的過程有時候可能需要花費幾天時間才能完成……
恢復(fù)時間邑闺！：一鍵點擊即可恢復(fù)生產(chǎn)環(huán)境跌前，就是這么簡單。
確倍妇耍基礎(chǔ)架構(gòu)的同質(zhì)：徹底避免運維人員每次構(gòu)建環(huán)境或安裝軟件時最終獲得的結(jié)果與預(yù)期有所差異抵乓，這是確保基礎(chǔ)架構(gòu)絕對同質(zhì)（Homogeneous）并且可再現(xiàn)的唯一可行方法蹭沛。以此為基礎(chǔ)臂寝，通過對腳本或Puppet配置文件使用版本控制機制，我們甚至可以重建出與上周摊灭、上個月咆贬，或軟件特定版本發(fā)布時完全一致的生產(chǎn)環(huán)境。
維持整齊劃一的標準：基礎(chǔ)架構(gòu)標準甚至可以不復(fù)存在帚呼，代碼本身就是標準掏缎。
讓開發(fā)者自行完成大部分工作：如果開發(fā)者自己突然可以在自己的基礎(chǔ)架構(gòu)上一鍵點擊重建生產(chǎn)環(huán)境，他們也就可以自行完成很多與生產(chǎn)環(huán)境有關(guān)的任務(wù)煤杀，例如更好地理解生產(chǎn)失敗眷蜈，提供更恰當(dāng)?shù)呐渲茫瑢崿F(xiàn)部署腳本等沈自。

這只是我個人感覺IaC可提供的部分收益酌儒，相信還有很多其他收益。

3. 持續(xù)交付
   持續(xù)交付是一種可以幫助團隊以更短的周期交付軟件的方法枯途，該方法確保了團隊可以在任何時間發(fā)布出可靠的軟件忌怎。該方法意在以更快速度更高頻率進行軟件的構(gòu)建籍滴、測試和發(fā)布。
   通過對生產(chǎn)環(huán)境中的應(yīng)用程序進行更高頻次的增量更新榴啸，這種方法有助于降低交付變更過程中涉及的成本孽惰、時間和風(fēng)險。足夠簡單直接并且可重復(fù)的部署流程對持續(xù)交付而言至關(guān)重要鸥印。
   注意：持續(xù)交付 ≠ 持續(xù)部署 - 有時候很多人會把持續(xù)交付誤認為成持續(xù)部署勋功。持續(xù)部署是指每個變更可以自動部署到生產(chǎn)環(huán)境。持續(xù)交付是指團隊確保每個變更可以部署至生產(chǎn)環(huán)境库说，但也許并不需要實際部署狂鞋，這通常可能是出于業(yè)務(wù)方面的原因璃弄。只有成功實現(xiàn)持續(xù)交付的前提下要销，才能進行持續(xù)部署。
   持續(xù)交付的主要想法在于：
   部署越頻繁夏块，對部署流程就會越熟悉，自動化機制就能獲得更好的結(jié)果纤掸。如果同一件事每天需要執(zhí)行3次脐供，很快你將變的無比嫻熟，但很快也會因為日復(fù)一日解決同樣的問題而感到厭煩借跪。
   部署越頻繁政己，所部屬的變更集就越微不足道，而這些微不足道的內(nèi)容最有可能出錯掏愁，甚至可能導(dǎo)致丟失對整個變更集的控制力歇由。
   部署越頻繁，TTR（修復(fù)／解決所需時間）指標就會越出色果港，從業(yè)務(wù)用戶處獲得有關(guān)功能的各類反饋的速度越快沦泌，作出改進以便完美滿足對方需求的過程也會越簡單（這方面TTR與TTM其實非常相似）。

3.1 從實踐中學(xué)習(xí)
持續(xù)交付的關(guān)鍵在于要能從實踐中學(xué)習(xí)。真理并不存在于開發(fā)團隊中萝衩，而在于業(yè)務(wù)用戶中回挽。然而無論花多長時間，沒人能真正清楚地表達自己的想法猩谊，或者將自己的想法用清晰的文檔概括出來千劈。也正是因此，敏捷方法論強調(diào)將功能提供給用戶牌捷，并不惜一切代價從用戶處獲得盡可能多的反饋墙牌。
持續(xù)交付與持續(xù)部署類似涡驮，需要盡可能減少前置時間，這也是盡快從用戶處獲得“真理”的關(guān)鍵憔古。
但真理絕對不會來自正規(guī)形式的用戶反饋遮怜。我們絕不能盡信自己的用戶或寄希望于通過正規(guī)形式的反饋了解用戶。我們只能相信自己的度量鸿市。
癡迷于度量是精益創(chuàng)業(yè)（Lean Startup）活動中一個重要的概念锯梁，但這一概念對DevOps同樣重要。我們應(yīng)該度量一切焰情！確定最恰當(dāng)?shù)亩攘恐笜丝梢宰寛F隊了解某種方法最終能否成功或失敗陌凳，了解怎樣做可以獲得更好的結(jié)果，以及哪些最成功的做法同時也蘊含著一定的風(fēng)險内舟。為了幫助團隊做出更明智的決策和悦，在確定要衡量的指標時，一定要抱著“寧多勿少”的原則衡楞。
不需要“考慮”泄隔，只需要“知道”！“知道”的唯一方法就是度量耕蝉，度量一切：響應(yīng)時間崔梗、用戶思考時間、展示次數(shù)垒在、API調(diào)用次數(shù)蒜魄、點擊率等，但這些并非需要度量的全部场躯。找出所有能讓你更進一步了解用戶對功能看法的度量指標谈为，對所有這些指標進行度量！
這種方法可以表示為如下形式：

第二個原因在于反饋次乓。大部分敏捷思維關(guān)注的是設(shè)置反饋環(huán)路吓歇，借此讓我們更快速地學(xué)習(xí)了解。反饋已經(jīng)是極限編程（Extreme Programming）中一個非常重要票腰，蘊含巨大價值的概念城看。在諸如軟件開發(fā)等復(fù)雜流程中，我們需要更頻繁地檢查自己的最新進展杏慰，并進行必要的糾正测柠。為此我們必須盡一切可能創(chuàng)建反饋環(huán)路，并提高反饋的頻率缘滥，這樣才能更快速地酌情做出調(diào)整轰胁。
第三個原因是實踐。對于任何活動朝扼，越頻繁地從事就越能獲得完善赃阀。實踐可以幫助我們理清整個流程，讓我們更熟悉代表有事情出錯的征兆擎颖。只要認真琢磨自己從事的工作榛斯，就能提煉出近一步完善所需的實踐观游。對于軟件開發(fā)，也有可能實現(xiàn)一定程度的自動化驮俗。一旦有人將某件事做了多次懂缕，就可以更容易地確定該如何進行自動化，更重要的是王凑，這樣的人在對這些事情實現(xiàn)自動化方面將有更大的動機搪柑。此時自動化尤為重要，因為可以加快速度并降低出錯的概率荤崇。

另外在管理重大功能和演進時家卖，還需要具備健全的軟件開發(fā)實踐眨层，例如零停機部署技術(shù)。
3.5 零停機部署
“零停機部署（ZDD）可在不中斷現(xiàn)有服務(wù)的情況下部署新版系統(tǒng)上荡∨坑＃”
通過ZDD方式部署應(yīng)用程序時，可在確保用戶不會遭遇應(yīng)用程序停機的前提下將新版應(yīng)用引入生產(chǎn)環(huán)境酪捡。從用戶和公司的角度來看叁征，這應(yīng)該是最佳部署方式，因為可以在不造成任何中斷的情況下引入新功能并修復(fù)Bug逛薇。
下文將介紹4種技術(shù)：
功能開關(guān)（Feature Flipping）
摸黑啟動（Dark launch）
藍／綠部署（Blue/Green Deployment）
金絲雀發(fā)布（Canari release）

功能開關(guān)
功能開關(guān)可供我們在軟件運行過程中啟用／禁用相應(yīng)的功能捺疼。這種技術(shù)其實非常容易理解和使用：為生產(chǎn)版本提供一個能徹底禁用某項功能的配置，并只在對應(yīng)功能徹底完工可以正常工作后才將該屬性激活永罚。
舉例來說啤呼，若要將某個應(yīng)用程序內(nèi)的一個功能全局禁用或激活：
if Feature.isEnabled('new_awesome_feature') # Do something new, cool and awesomeelse # Do old, same as always stuffend
或者如果要真對具體用戶實現(xiàn)類似目的：
if Feature.isEnabled('new_awesome_feature', current_user) # Do something new, cool and awesomeelse # Do old, same as always stuffend
摸黑啟動
摸黑啟動的目的在于通過生產(chǎn)環(huán)境進行負載模擬！
在測試環(huán)境中呢袱，通常很難為軟件模擬出成百上千萬用戶規(guī)模的負載媳友。
如果不進行切實的負載測試，就無法知道基礎(chǔ)架構(gòu)能否承受住最終面臨的壓力产捞。
此時并不需要模擬負載，而是可以實際部署這樣的功能哼御，然后看看在不影響可用性的前提下到底會發(fā)生什么坯临。
Facebook將這種做法稱之為功能的“摸黑啟動”。
假設(shè)我們要將一個有5億用戶使用的靜態(tài)搜索字段變成一個包含自動補全功能的字段恋昼，借此讓用戶可以更快速獲得搜索結(jié)果看靠。為該功能構(gòu)建一個Web服務(wù)，并且希望模擬所有用戶同時輸入文字液肌，向該Web服務(wù)生成大量請求的場景挟炬。
此時即可通過摸黑啟動策略為現(xiàn)有表單添加一個隱藏的后臺進程，通過該進程將輸入的搜索關(guān)鍵字發(fā)送給新增的自動補全服務(wù)，并自動發(fā)送多次谤祖。
就算新增的Web服務(wù)徹底崩潰了婿滓，也不會造成任何實質(zhì)損害。網(wǎng)頁上可以完全忽略服務(wù)器錯誤粥喜。而就算該服務(wù)崩潰了凸主，我們至少還可以對該服務(wù)進行優(yōu)化和完善，直到能承受如此大量的負載额湘。
這就等于在現(xiàn)實世界中進行了一次負載測試卿吐。
藍／綠部署
藍／綠部署是指為下一版產(chǎn)品構(gòu)建另一個完整的生產(chǎn)環(huán)境。開發(fā)和運維團隊可以在這個單獨的生產(chǎn)環(huán)境中放心地構(gòu)建下一版產(chǎn)品锋华。
當(dāng)下一版產(chǎn)品全部完成后嗡官，可以修改負載均衡器的配置，以透明的方式將用戶自動重定向至新發(fā)布的下一版毯焕。
隨后可將上一版的生產(chǎn)環(huán)境回收衍腥，用于構(gòu)建下下一版的產(chǎn)品。
以此類推芥丧。

4. 協(xié)作
   敏捷軟件開發(fā)破除了需求分析、測試和開發(fā)之間的一些隔閡属百。部署记劝、運維和維護等其他活動與軟件開發(fā)過程中的其他環(huán)節(jié)也存在類似的分隔。DevOps方法意在破除所有這些隔閡族扰，鼓勵開發(fā)和運維人員之間的協(xié)作厌丑。
   如果沒有培養(yǎng)出正確的文化定欧，就算有最棒的工具，DevOps對你而言也不過是另一個熱門詞匯罷了怒竿。
   DevOps文化的主要特征在于開發(fā)和運維角色之間日益增加的協(xié)作砍鸠。這是一種在團隊內(nèi)部以及組織層面上很重要的文化變遷，通過這樣的變遷才能促進更好的協(xié)作愧口。
   這種方式解決了一個非常重要的問題睦番，而這個問題完全可以用下面這個網(wǎng)絡(luò)流行話來體現(xiàn)：
   

   
   （來源：DevOps Memes @ EMCworld 2015 ）
   團隊合作對DevOps是如此的重要，大部分方法論所要實現(xiàn)的最終目標總的來說可以通過兩個C來實現(xiàn)：協(xié)作（Collaboration）和溝通（Communication）耍属。雖然單純做到這些距離真正的DevOps工作環(huán)境還有很大的差距托嚣，但任何公司只要能堅持這兩個C，就等于邁出了最正確的第一步厚骗。
   但為什么會那么難做到示启？
   4.1 混亂之墻
   因為有一堵混亂之墻：
   
   
   在傳統(tǒng)開發(fā)周期中，開發(fā)團隊將新發(fā)布的軟件“隔墻扔給”運維人員领舰，意味著自己的工作已經(jīng)順利完成夫嗓。
   運維人員接手開發(fā)者的成果，準備開始進行部署冲秽。運維人員手工修改由開發(fā)者提供的部署腳本舍咖，當(dāng)然更多時候這些腳本都是運維人員自己維護的。
   運維人員還需要手工修改配置文件锉桑，以反映生產(chǎn)環(huán)境的需求排霉，而生產(chǎn)環(huán)境往往與開發(fā)或QA環(huán)境有很大差異。
   就算最理想的情況民轴，運維人員可能只是做了一些在上一個環(huán)境中已經(jīng)做過的重復(fù)工作攻柠，而最糟糕的情況，可能會引入或發(fā)現(xiàn)新的Bug后裸。
   隨后IT運維團隊開始討論他們所認為的瑰钮，目前最正確的部署流程，然而由于開發(fā)和運維在腳本微驶、配置浪谴、流程，甚至環(huán)境等方面的差異因苹，基本上等同于要從零開始將所有工作重新執(zhí)行一遍较店。
   當(dāng)然這一過程中不可避免會遇到問題，他們聯(lián)系開發(fā)者希望進行排錯容燕。運維稱開發(fā)者提供的代碼本身有問題，開發(fā)者則回應(yīng)稱代碼在自己的環(huán)境中一切正常婚度，因此錯誤肯定源自運維端蘸秘。
   由于配置官卡、文件位置，以及面臨這種狀態(tài)所執(zhí)行的操作與自己的預(yù)期等因素存在較大差異醋虏，開發(fā)者甚至很難對這樣的問題進行診斷寻咒。變更窗口留下的時間所剩無幾，當(dāng)然也沒什么足夠靠譜的方法將環(huán)境回滾至上一個正常狀態(tài)颈嚼。
   那么原本應(yīng)該一帆風(fēng)順的部署過程毛秘，為什么最后卻變成了“眾志成城”的應(yīng)急演習(xí)？必須經(jīng)歷大量指責(zé)和錯誤才能最終讓生產(chǎn)環(huán)境恢復(fù)可用狀態(tài)阻课？
   這種情況經(jīng)常發(fā)生叫挟，經(jīng)常！
   DevOps來救場了
   通過在共同的業(yè)務(wù)目的情境中讓開發(fā)和運維角色與流程變的一致限煞，DevOps有助于促進IT的統(tǒng)一抹恳。開發(fā)和運維都需要明確，自己是統(tǒng)一業(yè)務(wù)流程的一份子署驻。DevOps思維確保了無論組織結(jié)構(gòu)是怎樣的奋献，個體決策與行為需要盡力為統(tǒng)一的業(yè)務(wù)流程提供支持和促進作用。
   亞馬遜CTOWerner Vogel甚至在2014年說過：
   “誰開發(fā)旺上，誰運行瓶蚂。”
   4.2 軟件開發(fā)流程
   下圖簡要描述了敏捷軟件開發(fā)流程通常的樣子宣吱。
   最開始窃这，業(yè)務(wù)代表與產(chǎn)品負責(zé)人以及架構(gòu)團隊合作定義軟件，這一過程可能會使用Story Mapping和用戶故事凌节，或者使用更完整的規(guī)范钦听。
   隨后開發(fā)團隊通過短暫的開發(fā)沖刺開發(fā)出軟件，并在每個沖刺結(jié)束后將生產(chǎn)就緒版本的軟件發(fā)布給業(yè)務(wù)用戶倍奢，進而收集反饋并盡可能頻繁地調(diào)整方向朴上。
   最后，經(jīng)歷過每個新的里程碑后卒煞，將軟件部署給整個業(yè)務(wù)線更廣泛的用戶群體痪宰。
   
   
   DevOps造成的最大挑戰(zhàn)在于需要理解運維人員是軟件的另一個用戶群體！因此他們也應(yīng)該被全面納入軟件開發(fā)流程中畔裕。
   在預(yù)定的時間里衣撬，運維應(yīng)該給出自己的非功能需求，就如同業(yè)務(wù)用戶給出自己的功能需求一樣扮饶。開發(fā)團隊應(yīng)該按照同等程度的重要性和優(yōu)先級處理這種非功能需求具练。
   在實現(xiàn)的過程中，運維應(yīng)該持續(xù)提供反饋和非功能測試規(guī)范甜无，就像業(yè)務(wù)用戶針對功能特性提供反饋一樣扛点。
   最后哥遮，運維和業(yè)務(wù)用戶一樣，成為了軟件的用戶陵究。
   
   
   通過采用DevOps方法眠饮，運維可以全面融入軟件開發(fā)流程中。
   4.3 共享工具
   在傳統(tǒng)的大型企業(yè)中铜邮，運維團隊和開發(fā)團隊分別使用專用的仪召，沒有什么交集的工具集。
   運維人員通常并不想了解開發(fā)團隊所使用的SCM系統(tǒng)以及持續(xù)集成環(huán)境松蒜。他們認為這些并非自己的本職工作扔茅，害怕自己在觸及這些系統(tǒng)后會被開發(fā)者的各種請求所淹沒。畢竟他們?yōu)榱苏樟仙a(chǎn)系統(tǒng)就有忙不完的工作了牍鞠。
   另一方面咖摹，開發(fā)者通常無法訪問生產(chǎn)系統(tǒng)的日志和監(jiān)視日志，有時這是因為沒有這樣的意愿难述，有時則是因為制度或安全方面的顧慮萤晴。
   這種狀況需要改變！DevOps應(yīng)運而生胁后。
   
   
   這個目標其實很難實現(xiàn)店读。舉例來說，出于制度或安全方面的原因攀芯，日志可能會被實時匿名化屯断，同時需要對監(jiān)管工具進行必要的保護，以避免未經(jīng)培訓(xùn)或本應(yīng)被禁止的開發(fā)者更改生產(chǎn)環(huán)境的配置侣诺。因此實現(xiàn)這一目標需要付出大量時間和成本資源殖演。但這樣做所能獲得的收益遠大于所需進行的投入，這種方法對整個公司的投資回報非常明顯年鸳。
   4.4 協(xié)同工作
   DevOps的一種基本哲學(xué)是認為趴久，開發(fā)者和運維人員必須定期進行密切的合作。
   這就意味著他們必須將對方視作重要的利益相關(guān)者搔确，并積極主動地尋求合作彼棍。
   受到XP實踐中“現(xiàn)場客戶”的啟發(fā)，敏捷開發(fā)者受此激勵可以與業(yè)務(wù)進行更緊密的合作膳算，自律的敏捷者還可以更進一步將這樣的實踐運用給更廣泛的利益相關(guān)者座硕，例如可以讓開發(fā)者與所有其他相關(guān)者進行合作，包括運維和支持人員涕蜂。
   這是一條雙行道：運維和支持人員也必須愿意與開發(fā)者進行密切的合作华匾。
   
   
   此外還可以通過協(xié)作：
   讓運維人員參與敏捷儀式（每日Scrum、沖刺規(guī)劃机隙、再次沖刺等）
   讓開發(fā)者參與生產(chǎn)環(huán)境的推出任務(wù)
   在開發(fā)和運維之間打造統(tǒng)一的持續(xù)改進目標

5. 結(jié)論
   DevOps是一次革命蜘拉，主要是為了消除擁有大規(guī)模IT部門的大型企業(yè)中刊头，開發(fā)團隊和運維團隊之間由于歷史原因產(chǎn)生的隔閡與孤立所造成的混亂現(xiàn)狀。
   在我15年的職業(yè)生涯中诸尽，2/3的時間就職于此類大行機構(gòu)，其中大部分是金融機構(gòu)印颤，每天我都在見證者這堵混亂之墻的存在您机。例如我經(jīng)常會聽到這樣的說法：
   “在我的Tomcat上工作很正常，很抱歉年局，但我完全不懂你所用的Websphere际看，幫不上你了∈阜瘢”（開發(fā)者說）
   “我們真的不能從生產(chǎn)數(shù)據(jù)庫中給你提取這張表仲闽，里面包含了與客戶有關(guān)的機密數(shù)據(jù)〗├剩”（運維人員說）

每天都會遇到其他很多類似的對話……天天如此赖欣！
好在DevOps日漸成熟，越來越多傳統(tǒng)企業(yè)也在開始逐漸走上正途验庙，開始接受DevOps的原則和實踐顶吮。但還有很多企業(yè)無動于衷。
那么對于那些小規(guī)模的粪薛，開發(fā)和運維職能之間通常不會產(chǎn)生那么大分歧的企業(yè)呢悴了？
這樣的企業(yè)應(yīng)用DevOps原則和實踐，例如自動化部署违寿、持續(xù)交付和功能開關(guān)湃交，一樣能獲益匪淺。
我認為DevOps原則可以總結(jié)為：