關於DevOps你必須知道的11件事

轉自：http://www.infoq.com/cn/articles/11devops

關於做者

Gene Kim在多個角色上屢獲殊榮：CTO、研究者和做家。他曾是Tripwire的創始人並擔任了13年的CTO。他寫過兩本書，其中包括《The Visible Ops Handbook》，目前他正在編寫《The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win》和《DevOps Cookbook》。Gene是 IT運維的超級粉絲，癡迷於改進運維流程——在不影響當前IT生產環境的狀況下，使得開發人員能夠向生產交付更多可運行的功能，而非只是完成代碼。他與多個頂級互聯網公司合做過，致力於改進他們的發佈流程，提升IT運維流程的完整性。2007年，Computer World將Gene列入了「40歲如下的40個創新IT人士」的名單中，普度大學還給他頒發了傑出校友獎以表彰他在專業領域的成就和領導力。

目錄

1. 什麼是DevOps
2. DevOps與敏捷有什麼不一樣
3. DevOps與ITIL以及ITSM有什麼不一樣
4. DevOps與可視運維
5. DevOps的基本原則
6. DevOps模式的應用領域
7. DevOps的價值
8. 信息安全和QA如何融入DevOps的工做流
9. 我最喜歡的DevOps模式一
10. 我最喜歡的DevOps模式二
11. 我最喜歡的DevOps模式三

1. 什麼是DevOps

術語「DevOps」一般指的是新興的專業化運動，這種運動提倡開發和IT運維之間的高度協同，從而在完成高頻率部署的同時，提升生產環境的可靠性、穩定性、彈性和安全性。

 

相關廠商內容

AWS的商業價值

AWS雲上的微軟SharePoint Server 2013：快速入門參考部署

AWS上的Docker：在雲環境中運行容器方案

Amazon Web Services概述

AWS雲上的MongoDB：快速入門參考部署

 

 

爲何是開發和IT運維？由於典型的價值流就是在業務（定義需求）和客戶（交付價值）之間。

DevOps運動的起源一般被放在2009年先後，伴隨着許多運動的相輔相成和相互促進——效率研討會運動，特別是由John Allspaw和Paul Hammond展現的開創性的「一天10次部署」，基礎設施即代碼」運動(Mark Burgess 和Luke Kanies)，「敏捷基礎設施運動」 (Andrew Shafer)，「敏捷系統管理」運動(Patrick DeBois)，「精益創業」運動（Eric Ries），Jez Humble的持續集成和發佈運動，以及Amazon的「平臺即服務運動」等這些運動的相輔相成和相互促進而發展起來的。

DevOps的合著者John Willis寫了一個很是好的帖子在這裏

 

http://itrevolution.com/the-convergence-of-devops/

2. DevOps與敏捷有哪些不一樣？

相對於瀑布開發模式，敏捷開發過程的一個基本原則就是以更快的頻率交付最小化可用的軟件。在敏捷的目標裏，最明顯的是在每一個Sprint的迭代週期末尾，都具有能夠交付的功能。

部署的高頻率常常會致使部署堆積在IT運維的面前。StreamStep公司的創始人，Clyde Logue總結過一句話：「敏捷對於開發從新得到商業的信任是大有益處的，可是它無心於將IT運維拒之門外，DevOps使得IT組織做爲一個總體從新得到商業的信任」。

DevOps和敏捷軟件開發是相輔相成的，由於它拓展和完善了持續集成和發佈流程，所以能夠確保代碼是生產上可用，而且確實能給客戶帶來價值。

DevOps不只僅建立了一個面向IT運維的工做流，當代碼已經開發完成可是卻沒法被部署到生產上時，這些部署就會堆積在IT運維的面前，客戶也將於是沒法享受到任何價值，更糟糕的是，部署常常致使IT環境的中斷和服務不可用。

DevOps具備與生俱來的文化變革的基因組成，由於它革新了開發和IT運維之間的工做流和傳統的衡量標準。John Willis和Damon Edwards（兩位都是《DevOps Cookbook》合著者）就這個話題寫過不少文章：

http://itrevolution.com/devops-culture-part-1/

3. DevOps與ITIL和ITSM有什麼不一樣？

儘管不少人視DevOps爲ITIL和ITSM的顛覆，而我則有着不一樣的見解，在支撐IT運維的業務流程方面，ITIL和ITSM流程無疑仍是最好的。實際上，他們描述了須要被IT運維支持的功能集合，這些功能集合足以支撐DevOps式的工做流。

敏捷和持續集成以及持續發佈是開發的輸出，這些輸出同時做爲IT運維的輸入，爲了適用跟DevOps相關的快速部署的節奏，ITIL流程的不少方面，特別是圍繞着變動、配置和發佈流程方面，須要自動化。

DevOps的目標不只只是增長變動的頻率，並且也支持在不中斷和破壞當前服務的基礎上，確保功能部署成功，同時也能夠快速檢測和修復缺陷。這引入了服務設計，事故和問題管理方面的ITIL新準則。

4. DevOps和可視運維如何搭配

2004年，我與Kevin Behr以及George Spafford合著了《The Visible Ops Handbook》，可視運維是一個說明性的指南，該指南使得高性能IT運維能順利實現「從優秀到卓越」的轉變，關鍵點之一是如何控制和減小計劃外的工做。

在開發和IT運維之間，DevOps不只聚焦在建立快速和穩定的計劃工做流，並且DevOps也有一個更全面的方法來系統的消除計劃外工做，定義開發彈性準則，並負責管理和減小技術債務。

5. DevOps的基本原則

在《The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win》和《DevOps Cookbook》的書裏，咱們描述了DevOps的支撐原則——「DevOps三個基本點」，全部的DevOps模式均可以源自這3個基本點。

第一個基本點強調整個系統的性能，而非將性能侷限於特定的工做領域裏，這個工做領域能夠大到一個部門（例如開發和IT運維）或者小到一個我的貢獻者（例如開發者，系統管理員等）。

重點是由IT推進的的業務價值流，換句話說，它始於需求定義（好比被業務或IT部門定義），進行開發構建，又交給IT運維，最後價值以一種服務的形式交付給客戶。

實踐第一個基本點的結果——決不傳遞一個已知缺陷至下游，決不因小失大，老是致力於改進流程，執着於深入理解系統需求（根據戴明的理論）

第二個基本點是關於建立從右至左的反饋迴路，幾乎全部的流程改進計劃的目標都是縮短和放大反饋迴路，以即可以持續進行必要的修正。

應用第二個基本點的結果——包括理解和迴應全部內部和外部客戶，縮短和放大全部的反饋迴路，必要時，很是容易的嵌入客戶須要的知識。

第三個基本點是打造一種文化用來促進兩件事情——持續不斷的探索精神，勇擔風險的精神以及從成功和失敗中來學習的能力，同時也得謹記：重複和實踐是融會貫通的前提。

這兩件事情對咱們來講同等重要，探索精神和勇擔風險的精神能夠確保咱們持續改進，它甚至意味着咱們可能到達了以前曾未到過的危險區域，所以這也迫使咱們去學習，掌握並融會貫通那些技能，於是使得咱們可以順利離開危險區。

第三個基本點的結果——分配時間去改進天天的例行工做，培養一種獎勵冒險精神的風氣，同時主動引入故障到系統中，從而提升彈性。

6．DevOps模式的應用領域

在《DevOps Cookbook》裏，咱們將DevOps模式分紅4個領域，

領域一，將開發延伸至生產中——包括拓展持續集成和發佈功能至生產，集成QA和信息安全至整個工做流，確保代碼和環境可在生產中直接部署，。

領域二，向開發中加入生產反饋——包括創建開發和IT運營事件的完整時間表用於幫助事件的解決，使得開發融入無指責的生產反思，儘量使得開發能夠自助服務，同時建立信息指示器用來代表本地的決策如何影響全局的目標。

領域三，開發嵌入到IT運維中——包括開發投入到整個生產問題處理鏈，分配開發資源用於生產問題管理，並協助退回技術債務，並且開發爲IT運維提供交叉培訓，增長IT運維處理問題的能力，從而下降升級問題的數量。

領域四，將IT運維嵌入至開發——包括嵌入和聯絡IT運維資源至開發，幫助開發建立爲IT運維(部署，生產代碼的管理等)使用的可重用的用戶故事，定義一些能夠被全部項目共用的非功能性需求。

7. DevOps的價值

我相信企業在應用了DevOps以後能夠獲得3個業務優點：產品快速推向市場（好比，縮短開發週期時間和更高的部署頻率），提升質量（好比，提升可用性，提升變動成功率，減小故障，等等）並提升組織的有效性（好比，將時間花在價值增長活動中，減小浪費，同時交付更多的價值至客戶手中）。

產品快速推向市場：

2007年，在IT流程協會，在評測了超過1500個IT組織結構以後，咱們得出結論：相比較於通常的組織，高效的IT組織的效率要高出5到7倍。變動要多出14倍，變動故障率只有前者的1/2，第一次修復率要高出4倍，並且一級事故時間要短10倍。 重複審計發現要少4倍，經過內部控制來檢測漏洞方面要高出5倍左右，而且8倍於前者的項目到期日表現！

在咱們的研究中，觀察到的最高部署頻率大約是每週1000次生產變動，變動成功率爲99.5%，咱們認爲這真得很快……

其中一個高績效的特色是，最好正在繼續變得更好。這絕對是發生在部署頻率的領域內。 在應用了DevOps實踐的組織正表現出更快的快速部署和實施，並且相比於通常組織要快幾個數量級。

埃森哲最近作了一個研究：互聯網公司都在作什麼？ 經過亞馬遜的記錄顯示，他們在保持目前每週部署1000次的狀況下，同時還能保證99.999%的成功率！

http://www.youtube.com/watch?v=dxk8b9rSKOo

http://www.slideshare.net/slideshow/embed_code/9466635?startSlide=33)

維持高部署率（即，快速的迭代次數）的能力轉化爲業務價值的兩種主要方式：

組織如何快速的把一個想法變成價值交付到客戶手中(好比，Damon Edwards 和John Willis說得「概念到落地」),組織同時能夠作多個嘗試。

對我來講，若是我在一個每9個月才能部署一次的機構裏，而個人競爭對手能夠天天部署10次，那麼無疑我將有着明顯的競爭劣勢。

高頻率部署也實現了快速和持續不斷的部署。Intuit公司的創始人，Scott Cook一直在組織的各個層面，不停的倡導「犀利創新文化」，我最喜歡的例子之一就記錄在http://network.intuit.com/2011/04/20/leadership-in-the-agile-age/。

「每一位員工應該可以作到快速，高速的交付……Dan Maurer負責咱們的消費者部門，包括TurboTax網站。當他接手的時候，咱們一年只作幾回部署，可是經過營造一個犀利的創新文化，在報稅季節的3個月裏，他們如今能作165次部署。商業價值？ 網站轉化率高達50%。員工價值？這幫傢伙們真得喜好它，由於能夠將他們的想法很快交付到市場中」

對我來講，Scott Cook的故事最使人震驚的是，他們在繁忙的報稅季節作全部這些部署！在旺季，大多數組織都會凍結任何變動（例如，從十月到一月，零售商可能常常有變動凍結）。但若是在旺季，若你能提升轉換率，而你的競爭對手不能，那麼這就是一個真正的競爭優點。

達到這個效果的前提就是，在不影響客戶的基礎上，能夠快速的完成並部署不少小的變動。

減小IT浪費總量：

Mike Orzen和我很早就談到了IT價值流中的巨大浪費，這些浪費是緣起於交付期限延長，不良的交接，計劃外工做和返工。基於Michael Krigsman的一篇文章，在應用了DevOps的原則以後，能夠挽回不少價值而非浪費。

咱們計算過，若是可以減小一半的IT浪費量，而後把這些省下來的錢從新投資，若能獲得5倍的投資回報，那麼每一年能夠產生30萬億美圓的價值。

這就是溜過咱們指尖的巨大的價值和機會。佔了全球GDP的4.7%，甚至超越整個德國的經濟產出。

我以爲這真的很重要，尤爲是當我想到個人三個孩子將繼承的這個世界，這些浪費對生產率，生活水平和經濟繁榮的潛在影響正在不斷增長，讓我以爲不得不改變。

然而，還有一個更大的成本，在大部分的IT組織結構裏，工做是吃力不討好和使人沮喪的，人們以爲他們本身就像被困在一部不斷重複的恐怖電影裏，沒法改變最終的結局。管理人員本應將IT管理的很好，可是他們放棄了這樣的職責，直接致使開發，IT運維與信息安全之間無休止的部門衝突，而審計師的出現只會讓事情變得更糟。

長期來講，必然的結果就是進步遲緩。IT專業人士的生活每每使人泄氣和沮喪的，一般致使滲透在生活方方面面的無力感和高壓狀態。IT專業人員面臨着壓力相關的健康問題、社交問題、宅在家裏等問題，這樣使得他們不但不健康，同時生活也極可能難覺得繼。

做爲人，咱們註定就是去貢獻，感受就好像咱們正在積極發揮做用，不同凡響。可是，每每當IT專業人員向他們的組織尋求幫助的時候，他們會獲得回答：「你不明白」，更糟的是，他們甚至會獲得「你不重要」這樣的待遇。

8. 信息安全和QA如何融入DevOps工做流

DevOps的高部署頻率一般會給QA和信息安全帶來很大的壓力，考慮這樣一種情形，開發天天部署10次，而信息安全一般須要4個月的時間來評估應用的安全。很顯然，在代碼開發和代碼安全審計方面的速率一點都不匹配。

2011年Dropbox故障就是一個著名的例子，其體現了未經充分測試的開發代碼帶來的風險有多大。由於此次事故，認證功能被關閉了4個小時，從而致使未受權的用戶能夠訪問全部存儲的數據。

固然對QA和信息安全來講，也不全是壞消息， 開發會經過持續集成和好的發佈慣例(持續測試的文化)來維持高頻率部署。換句話說，一旦代碼被提交，自動測試便開始運行，並且一旦發現問題，必須立刻解決，就像開發人員在檢查還沒編譯的代碼。

經過集成功能測試，集成測試和信息安全測試到開發的天天例行工做中，問題將會被更快發現，同時也會被更快解決。

一樣，也有着愈來愈多的信息安全工具，好比Gauntlet和Security Monkey， 能夠幫助咱們在開發和上線的過程當中測試安全對象，達到信息安全目標。

可是也有一個很重要的問題須要考慮，靜態代碼分析工具一般須要花費很長時間才能運行完，以數小時或天記。在這種狀況下，信息安全就必須註明特定的有安全隱患的模塊，好比加密，認證模塊。只要這些模塊變化，一輪全面的信息安全測試就運行，不然部署就能夠繼續，而不須要全覆蓋信息安全測試。

須要特別提到的一點是，咱們觀察到，相較於標準的功能單元測試，DevOps工做流依賴於檢測和恢復更多一點。換句話說，固然開發以軟件套件的方式交付的時候，那麼部署變動和補丁就比較困難，同時QA也嚴重依賴代碼測試來驗證功能的正確性。另外一方面，當軟件以服務的形式交付，缺陷就能夠被很快修復。並且QA也能夠減小測試依賴，取而代之的更多依賴缺陷的生產監控，只要缺陷能被快速的修復。

代碼故障恢復可藉助於「功能標籤」等手段，經過以配置的形式來啓用或禁用某些代碼功能，從而達到避免推出一個全功能部署，而只部署經過測試的功能至生產。

當功能不可用或性能出現降低等較壞的狀況發生的時候，依賴於檢測和恢復進行QA將會一種更好的選擇。可是當面對損失保密性或數據和系統一致性的時候，咱們就不能夠依賴檢測和恢復這種方法。取而代之的是，在部署以前，必須進行充分的測試，不然可能致使重大的安全事故。

9. 我最喜歡的DevOps模式一

一般，在軟件開發項目中，開發都會用完全部計劃中的時間用於開發功能。這樣會致使沒法充分解決IT運維的問題，因而他們就在定義，建立和測試數據庫、操做系統、網絡、虛擬化等代碼依賴的方面直接抄捷徑，以此節省時間。

因此這就是開發和IT運維以及次優結果之間的永恆的緊張關係的主要緣由。後果很嚴重，好比不適當的定義和指定環境、沒法重部署、代碼和環境的不兼容等等。

在這種模式下，咱們會再開發過程的早期提出環境要求，並強制代碼和環境必須被一塊兒測試的策略，一旦使用敏捷開發方法，咱們能夠作到很是簡潔和優雅。

按敏捷的要求，在每一個迭代結束後，咱們就會發布能運行且可被部署的代碼，一般時間爲兩週。咱們將修改敏捷迭代週期策略，不只僅只交付能運行且可被部署的代碼，同時在每一個迭代週期的早期，還必須準備好環境用於部署這些代碼。

由此，咱們再也不讓IT運維負責建立生產環境的規格要求，取而代之的，創建一個自動化的環境建立流程，這種機制不只僅只建立生產環境，同時也包括開發和QA環境。

經過使得環境早期便可用，甚至可能早於軟件項目開始以前，開發和QA能夠在統一和穩定的環境中運行和測試他們的代碼，從而控制不一樣環境之間的差別。

此外，經過保持不一樣階段（例如，開發、QA、集成測試、生產）儘量小的差別，在生產部署以前，咱們就能發現並修復代碼和環境之間的互操做性問題。

理想狀況下，咱們創建的部署機制是徹底自動化的。可使用像Shell腳本、Puppet、Chef、Soaris Jumpstart、Redhat Kickstart、Debian Preseed等等不少工具來完成。

10. 我最喜歡的DevOps模式二：

BrowserMob前CEO，Patrick Lightbody曾經說過，「當咱們在凌晨2點叫醒開發工程師來解決問題時，缺陷被修復的比之前更快了，這真是一個驚人的反饋迴路」，

這是我最喜歡的引用之一。

它強調了問題的關鍵點，開發通常會在週五的5點提交代碼，而後高高興興的回家，而IT運維則要花費一整個週末來收拾殘局。更糟的是，缺陷和已知錯誤在生產上不斷遞歸，迫使IT運維不停的救火，而根本緣由從不被修復，形成這種現象的緣由就是開發老是關注開發新功能。

第二種模式的一個重要要素就是縮短和放大反饋迴路，使得開發更貼近客戶體驗(包括IT運維和最終用戶)

注意這裏的對稱性，模式一討論的儘早讓環境統一併可用便是將IT運維嵌入到開中發，而模式二則爲將開發嵌入到IT運維中。

咱們將開發嵌入進IT運維的問題升級鏈中，能夠將他們放在三級支持中，甚至使開發對整個代碼的部署成功負責。要麼回滾，要麼修復缺陷，直到服務恢復。

咱們的目標不是讓開發取代IT運維，相反，就是想確開發看到他們工做和變動的下游變化，激勵他們以IT運維的視角來更快的解決問題，從而達到一個全局的目標。

11. 我最喜歡的DevOps模式三：

在開發和IT運維之間DevOps價值流中，另外一個常常發生的問題就是不夠規範。這方面的例子是，每一個部署都帶有其特殊性，所以也使得每次部署後的環境帶有特殊性，一旦這樣的事情發生，那麼這個組織裏就沒有針對流程配置的控制。

在這種模式下，咱們定義可重用且可跨多個項目的部署流程，敏捷方法裏有個很簡單的解決方案。就是將部署的活動變成一個用戶故事。例如，咱們爲IT運維構建一個可重用的用戶故事，叫作「部署到高可用環境」，這個用戶故事定義了明確的構建環境的步驟、須要多長時間、須要哪些資源等等。

那麼這些信息能夠被項目經理用來集成部署內容到項目計劃中去。例如，若是咱們知道在過去的3年時間裏，「部署到高可用環境」用戶故事被部署了15次，每次的平均部署時間爲3天，加或減一天，那麼咱們對本身的部署計劃將會很是有信心。

此外，咱們還能夠因部署活動被合適的集成到軟件項目中而得到信心。

咱們也得認識到有些特定的軟件項目要求特別的環境，且其不被IT運維官方支持，咱們能夠容許這些被生產容許的環境中的例外，可是被IT運維部門外面的人提供支持的。

經過這種方法，咱們即得到了環境標準化的好處（好比，減小生產差別，環境更一致，IT運維的支持和維護能力增長），又能再容許的特殊狀況下，提供業務須要的靈活性。