過去一年以來，一批來自歐美的、不墨守陳規的系統管理員和開發人員一直在談論一個新概念：DevOps。DevOps就是開發（Development）和運維（Operations）這兩個領域的合併。（若是沒錯的話，DevOps還包括產品管理、QA、*winces* 甚至銷售等領域）前端
脫節(The Broken)git
那麼……爲何要合併這兩個領域？緣由不少，但首要緣由是：咱們目前的工做流程是脫節的。絕對的脫節。不少公司的開發部門和運維部門之間存在的深入矛盾，其實就是這個「脫節」形成的。（意譯，求斧正）程序員
下面是一個你們都基本熟悉的例子：部署軟件產品。web
開發部門要開發一款新產品。這款產品要使用最新最炫的技術，來保證客戶的全部花俏的需求，從而給公司帶來百萬美圓的利潤。這款產品被要求使用最新的技術和運行平臺，還得立刻交付。因而開發部門沒日沒夜的加班、趕代碼（cuts code like crazy），終於如期完成了任務。而後他們把本身的「傑做」一股腦的甩給了運維部門，後者還沒能徹底接手，前者已經火燒眉毛的開始了慶功會。數據庫
接到產品後，運維部門每一個人的心中都充滿了恐懼。編程
下面就是運維部門的恐懼之源：（{A.B.C}表示A或B或C之一）後端
- 這款優秀的產品在目前的底層平臺上沒法運行，由於這個平臺{太古老了，空間不足，不支持某某版本}
- 這款產品的體系結構跟咱們的{存儲，網絡，部署，安全}模型不匹配。
- 這款產品的{ 報告，安全，監視，備份，服務提供} 咱們搞不懂 ，因此無法把它作成實際可用的產品。
儘管伴隨着不絕於耳的抱怨和咒罵，運維部門最終仍是把這款產品安裝好了。不幸的是，因爲作了不少蹩腳的修改和不合理的強迫式運行，這款產品的性能最後被歸結爲：終極失敗（Epic Fail）。安全
因而很是沮喪的運維部門開始記錄各類問題，源源不斷的給開發部門提Issue。而開發部門的迴應基本上都是：網絡
- 這不是咱們的錯 —— 咱們的代碼很是完美——而是（運維部門的）部署作的太差勁了。
- 運維部門比較笨，他們不懂新技術—— 爲何他們無法實現最新的技術呢？爲何他們這麼落伍呢？
- 在個人機器上運行的沒問題啊……
兩個部門之間的交流很快變成了一場狂風暴雨。客戶（以及股東、投資方和管理層）則成了蒙受損失的失敗方。最終公司損失了無數的金錢，你們也都失業了。終極的失敗。架構
DevOps 又有啥不一樣？它有什麼好處？
DevOps 就是千方百計的避免這種「終極失敗」，同時讓你們用更聰明更有效的方式去工做。它是一種框架，包含了不少優秀想法和原則，它鼓勵開發部門和運維部門通力合做。在DevOps環境中，開發人員和系統管理員會構建一些關係、流程和工具，從而更好的與客戶互動，最終提供更好的服務。
DevOps 也不只僅是一種軟件的部署方法。它經過一種全新的方式，來思考如何讓軟件的做者（開發部門）和運營者（運營部門）進行合做與協同。使用了DevOps模型以後，會使兩個部門更好的交互，使二者的關係獲得改善，從而讓不少領域從中受益，例如：自動化、監視、能力規劃和性能、備份與恢復、安全、網絡以及服務提供（provisioning）等等。
「對於DevOps是什麼？」 這個問題，DevOps社區中的每一個人的回答都不盡相同。由於咱們的工做經驗不一樣，關注的問題也不一樣。就我我的而言，DevOps分紅四大部分：
簡單
KISS（Keep it Simple and Stupid，簡單就是美）原則是最重要的。因此本段文字也很簡單。咱們要儘可能提供簡單、可重用的解決方案。「簡單」節約了書寫文檔、培訓和提供支持的時間。「簡單」增長了溝通的速度、避免混淆、減小了開發和運維出錯時的風險。「簡單」讓人更快的發佈產品。
部門之間關係
早參與，多參與。對於開發人員，要讓運維人員常駐到開發部門，全程參與開發流程。邀請運維人員參與你的Scrum或者開發會議，與他們分享項目計劃、分享新技術的點子和心得。蒐集功能性需求（指開發人員用到的需求）的同時也要蒐集運維方面的需求。把對於「發佈、備份、監控、安全、配置管理和系統功能」的測試做爲一項獨立的項目流程。軟件產品在開發時解決的問題越多，那麼在使用時暴露給用戶的問題就越少。給運維人員作培訓，讓他們弄清楚項目的體系結構和核心代碼。若是運維人員在反饋bug時提供的信息越多，那麼你花在排查問題（trouble-shooting) 的時間就越少，這個bug也就會更快的被解決掉。
對於運維人員，在遇到問題時須要把開發人員加進來，你們一塊兒解決問題。邀請開發人員參與大家的會議，分享項目進度（roadmaps），而且共同修訂工做計劃。運維人員必定要了解開發部門下一步的工做方向，從而確保產品運行的底層平臺可以良好的支持最新技術。開發人員也會帶來相關的技術、知識和工做，幫助大家改善產品的運行環境，使其更加易於維護、簡潔有效。
有一些開發領域的概念，例如：「要根據API而非封閉的interface來構建工具」，分佈式版本控制，驅動測試開發，以及諸如敏捷開發、看板管理（Kanban）和Scrum等方法論。若是把這些概念應用在運維領域，一樣會產生革命性的變革。
不要害怕新點子和新技術。咱們能夠隨時隨地的向他人學習，哪怕是一句「咱們不再要那樣作了！」也會讓咱們從中獲益。儘管處於不一樣的部門，可是咱們要共同窗習、共同成長，這樣才能協同工做的更好！
按照從高到低的順序，有效的溝通方式應該是：面對面交流 、視頻會議、電話、即時通信軟件、Email。
工做中的流程
有本身的流程管理(process engineering)—— 從原始的筆錄到 ISO9001。但它們都存在一個關鍵的缺陷：過於理想化，它要求每一個步驟都必須成功執行。例如：爲了搭建一臺新主機，會有下列一套簡單的流程：
- 步驟一：裝機（把各個硬件組裝到一塊兒）。
- 步驟二：接線、通電。
- 步驟三：安裝操做系統。
- 接下來還有步驟4、5、六。
若是一切順利的話，第N步結束以後就會有一個功能完整、運行正常的新主機。但萬一有個流程沒跑通怎麼辦？好比說在某個步驟斷了，走不下去了，或者在這一步獲得了異常的輸出，有沒有另外的步驟來處理這個異常？
因此，流程絕對不會從頭至尾一路順風，因此咱們要把每一步流程都認真對待，找出全部潛在的問題和障礙。跟軟件產品同樣，在流程的管理中也要有異常處理。咱們沒必要作到精確預見每個問題，但必定要保證：即便流程出錯，它還能往下走。
把不一樣領域的全部流程串到一塊兒。這些領域包括：部署、監控、能力計劃(capacity planning) 等等。從邏輯上講，「部署」是軟件開發週期的最後一環，因此它應該屬於「開發流程」，而非「運維流程」。另外一個例子是度量和監控。在開發領域，若是不理解底線標準和估算，就什麼評估都作不了。把開發部門和運維部門的流程銜接在一塊兒，也會讓兩個部門更好的配合、相互理解、承擔共同的責任。最後還有個優勢：文檔只須要一份而不是兩份（開發一份、運維一份），從而節省了資金。
自動化，自動化，仍是自動化。構建或使用簡單、可擴展的工具（確保提供API, 機器可讀的輸入、輸出 -- 參考 James White的文章：Infrastructure Manifesto）。使用Puppet一類的工具作配置管理。要擴展這些自動化工具，使其可以支持多個領域（開發領域和運維領域），而且在產品的不一樣環境（開發環境、測試環境、發佈環境和生產環境）中使用相同的工具（也叫end-to-end）。這樣不但會在產品支持和管理方面帶來經濟效益，並且也能夠在編寫新代碼的同時，進行產品的發佈和管理。
最後，在構建流程和自動化時，要把KISS原則牢記於心。越複雜就越易錯。只有簡單的流程和工具才易於實現、易於管理和易於維護。
持續改進
不要中止創新和學習。當今技術發展的很快，客戶的需求也每每如此。把「持續改進和持續集成」 加入到你的工具和流程中去，這也是運維人員向（優秀的）開發人員學習的好途徑，能夠學到諸如測試驅動開發等最佳實踐。例如：能夠向你的部署流程中加入單元測試。作監控時也應該增長些行爲測試，提升交付質量。嘗試用開發領域中的工具（例如Hudson）在運維領域中作些工做（例如瀏覽數據(explore）、測量性能（measure)等等）。
要不斷的總結教訓。要積極主動的、在不一樣領域尋找錯誤的根源。 一旦收到錯誤報告，就果斷把開發小組和運維小組找來，一塊兒解決這個問題。有時候開發人員很簡單的幾回代碼重構，就能夠很好的避免底層運行環境的改變，減小運維人員的負擔。總之，遇到問題時，開發部門和運維部門要密切配合、共同解決，而不是互相推諉、踢皮球。
歷史回顧
爲了可以更好的理解什麼是DevOps，咱們頗有必要對當時還只有程序員(此前尚未派生出開發者，前臺工程師，後臺工程師之類)這個稱號存在的歷史進行一下回顧。
如編程之道中所言：
老一輩的程序員是神祕且深奧的。咱們無法揣摩他們的想法，咱們所能作的只是描述一下他們的表象。
清醒的像一隻遊過水面的狐狸
警戒的像一位戰場上的將軍
友善的像一位招待客人的女主人
單純的像一塊未經雕琢的木頭
深邃的像一潭幽深洞穴中漆黑的池水
程序員開發了機器語言，機器語言又產生了彙編語言，彙編語言產生了編譯器，現在的語言已經多不勝數。每一種語言都有其各自的謙卑用途。每一種語言都表達出軟件的陰和陽。每一種語言都在此道之中有其一席之地。
遙想當年，軟件程序員的大部分辦公司那時還被稱做實驗室，程序員那時還叫作科學家。爲了開發出一套優秀的軟件，程序員們必須深刻了解他們須要的應用相關的全部問題。他們必須清楚知道這個軟件應用在什麼場合，這個軟件是必須在什麼系統上運行。本質上說，程序員對所要開發的軟件的全部環節都有透徹的瞭解，從規格說明書編寫、到軟件開發、到測試、到部署、再到技術支持。
過了不久，人類(客戶)貪婪的特性就開始表現出來，他們開始不斷的進行更多的索求。更快的速度，更多的功能，更多的用戶，更多的全部全部。
做爲一類謙虛、謙卑、且平靜的生物，咱們的老一輩程序員們將很難在這種爆發性的過分的需求索取中倖存。最好的取勝辦法就是往不一樣的方向進化成不一樣的新物種。很快，程序員這個稱號就開始絕跡於江湖，而那些叫作開發者、軟件工程師、網絡管理員、數據庫開發者、網頁開發者、系統架構師、測試工程師等等更多的新物種就開始誕生。快速進化和快速適應外界的挑戰成爲了他們的DNA的一部分。這些新的種族能夠在幾個星期內就完成進化。網頁開發者很快就能進化成後臺開發者，前臺開發者，PHP開發者，Ruby開發者，Angular開發者…多得讓人側目。
很快他們就都忘卻了他們都是起源於程序員這個共同的祖先的事實，忘卻了曾經有過這麼一個單純且平靜的，想要讓這個世界變得更好的科學家。而後他們開始不斷的劍拔弩張，都聲稱本身才是「程序員」的純血統繼承人。
隨着時間的轉移，各門各派開始獨佔山頭，不多進行交流互動，只有在無可奈何的時刻纔會進行溝通。他們開始再也不爲同源的遙遠的同宗兄弟們的成功而歡呼雀躍，甚至不再會時把的遙寄張明信片進行噓寒問暖。
可是在深夜仰望星空的時候，他們仍是會發現他們的心底深處的程序員基因仍是會不停的閃爍着，期盼着這閃爍的火花能照亮整個銀河系並帶來和平。
在這場自私且以自我爲中心的欲征服世界的賽跑旅程裏，程序員的子孫們早把他們真正的工做目標置之腦後-爲客戶解決問題。面對一拖再拖的項目交付日期，昂貴的開發代價，甚至最終失敗的項目，客戶們開始對這種狀況深惡痛絕。
偶爾，也會有一個閃亮的明星站出來，靈機一動的提供一種辦法來嘗試結束這種混亂並帶來和平。因此瀑布開發流程就應運而生了。這是一個很是了不得的創意，由於它利用了不一樣團隊的開發者們只在必須的時候才進行溝通的這個事實。當一個團隊完成了他們的工做的時候，它就會和下游的團隊進行交流並把任務進行往下傳，如此一級接一級的傳遞下去，永不回首。
這種方式在一段時間內發揮了效用，但很快，一如既往，貪婪的人們(客戶)又開始提出更多的訴求。他們但願可以更多地參加到整個軟件的開發流程中來，不時的提出他們的建議，甚至在很晚的時候還提出改需求這種喪心病狂的事情來。
結果就是如你們有目共睹的事實同樣，軟件項目很是容易失敗這個說法已經做爲一個行業標準被人們所接受。數據代表超過50%的項目最終都是以失敗了結的。更可悲的是，在當時看來，人們對這種狀況是一籌莫展。
值得慶幸的是，每個時代總會有那麼幾個思想開放的英雄如漆黑中的螢火蟲般冒出來。他們知道這些不一樣團隊的開發者們必需要找到一個能夠協同工做、進行交流、而且可以彈性的向客戶保證對方將會拿到最優的解決方案的方式。這種嘗試最先能夠追溯到1957年，偉大的約翰·馮·諾依曼和同行們的努力。可是咱們最終倒是等到2001年才收穫到革命的果實，當時行業的十多個精英創造出了現在聞名世界的「敏捷宣言」。
敏捷宣言基於如下十二條原則：
咱們的首要任務是經過儘早地、持續地交付可評價的軟件來使客戶滿意。
樂於接受需求變動，即便是在開發後期也應如此。敏捷過程可以駕馭變化，從而爲客戶贏得競爭優點。
頻繁交付可以使用的軟件，交付間隔越短越好，能夠從幾個星期到幾個月。
在整個項目開發期間，業務人員和開發人員必須朝夕工做在一塊兒。
圍繞那些有推進力的人們來構建項目。給予他們所需的環境和支持，而且信任他們可以把工做完成好。
與開發團隊以及在開發團隊內部最快速、有效的傳遞信息的方法就是，面對面的交談。
可以使用的軟件是進度的主要衡量指標。
敏捷過程提倡可持續發展。出資人、開發人員以及使用者應該老是共同維持穩定的開發速度。
爲了加強敏捷能力，應持續關注技術上的傑出成果和良好的設計。
簡潔——最大化沒必要要工做量的藝術——是相當重要的。
最好的架構、需求和設計都源自自我組織的團隊。
團隊應該按期反思如何能變得更有戰鬥力，而後相應地轉變並調整其行爲。
敏捷宣言是爲銀河系帶來和平以及維護各自的平衡所邁出的很重要的第一步。在很長的時間裏，相比此前基於流程和機械化的方式，這是第一次基於文化和「人性」來將不一樣的關鍵項目關係人鏈接在一塊兒的方式。人們開始互相交流，進行基本的碰頭會議，並開始不斷的交流意見和見解。他們開始意識到他們是有着不少比想象中還多的共同點的，客戶也開始成爲他們之中的一員，而再也不是像以往同樣只是往項目砸錢而後開始求神拜佛祈求一切順利如願。
儘管前面仍是有很多的障礙須要克服，可是將來已經光明瞭許多。敏捷意味着開放和擁抱(需求)改變。可是，若是改變過多的話，人們就很難專一到最終的目標和交付上來。此時精益軟件開發就開始破土而出了。
由於對精益軟件開發的着迷以及爲了達成放逐和驅趕風險的目的，一些程序員的子孫們就開始探首窗外，開始向軟件以外的行業進行取經。他們從一家主要的汽車生產商身上找到了救贖。豐田生產系統在精益上面的成就是難以想象的，同時它們的精益生產的經驗也是很容易應用到軟件開發上來的。
精益有如下7個原則：
杜絕浪費
內建質量
建立知識(放大學習)
延遲決策(儘可能延遲決定)
快速交付
尊重人員(團隊受權)
全局優化
將這些放到敏捷上去的話，精益原則就能讓人們在從精神上關注作正確的事情，同時還可以讓整個開發流程擁有足夠的彈性。
一旦敏捷和精益軟件開發被軟件開發團隊採納，那麼下一步就是把這一套原則應用到IT團隊上來。把IT也歸入到總體戰略上，而後咱們就來到了DevOps跟前了！
進入DevOps – 高速公路的三條車道
老一派的軟件開發團隊成員會包含業務分析員，系統架構師，前端開發者，後端開發者，測試員，等等。優化如敏捷和精益原則等的軟件開發流程的關注點就在這些地方。好比，軟件一旦達到」能夠生產「的程度，就會發到系統工程師、發佈工程師、DBA、網絡工程師，安全專家這些「運維人員」的手上。這裏該如何將橫在Dev(開發)和Ops(運維)之間的鴻溝給填平，這就是DevOps的主要關注點了。
DevOps是在整個IT價值流中實施精益原則的結果。IT價值流將開發延伸至生產，將由程序員這個遙遠的祖宗所繁衍的全部子孫給聯合在一塊兒。
這是來自Gene Kim的對DevOps的最好的解析，若是你尚未看過他的《鳳凰項目》這本書的話，我建議你真的該好好花時間看看。
你不該該從新招聘DevOps工程師，且DevOps也不該該是一個IT的新部門。DevOps是一種文化，一種理念，且是和IT糅合成一總體的。世間沒有任何工具能夠把你的IT變成一個DevOps組織，也沒有任何自動化方式能夠指引你該如何爲你的客戶提供最大化的效益。
DevOps一般做爲下面這三個方式而爲人所熟知，而在我眼裏我是把它們當作是一條高速公路上的三條車道。你從第一條車道開始，而後加速進入到第二條車道，最終在第三車道上高速行駛。
車道1 – 系統級別的總體效率考量是最主要的關注點，這超過對系統中任何一個單獨個體元素的考慮
車道2 – 確保能提供持續不斷的反饋循環，且這些反饋不被忽視。
車道3 – 持續的學習和吸收經驗，不停的進步，快速的失敗。
車道1 – 獲取速度
要採納DevOps的原則，理解整個運做系統的重要性並對工做事項進行合適的優先級排序是組織首先要學的事情。在整個價值流中不能容許任何人產生瓶頸並下降整個工做流程。
確保工做流程的不可中斷是身處流程中的全部成員的終極目標。不管一個成員或者團隊的角色是什麼，他們都必須力圖對整個系統進行深刻的理解。這種思惟方式對質量會有着直接的影響，由於缺陷永遠不會被下放到「下游「中，這樣作的話將會致使瓶頸的產生。
確保整個工做流程不會被瓶頸堵塞住還不夠。一個高產的組織應該時常考慮該如何提高整個工做流程。有不少方法論能夠作到這一點，你不妨去看下「約束理論」，「六西格瑪」，精益，或者豐田生產系統。
DevOps原則不關心你身處哪一個團隊，你是不是系統架構師，DBA，QA，或者是網絡管理員。相同的規則覆蓋全部的成員，每一個成員都應該遵循兩個簡單的原則：
保持系統運做流程不可中斷
隨時提高和優化工做流程
車道2 – 換擋加速
不可中斷的系統流程是定向的，且預期是從開發流向運維。在一個理想的世界中，這就意味着快速的開發出高質量的軟件，部署，併爲客戶提供價值。
可是，DevOps並不是烏托邦式的理想國。若是單向的交付方式是可行的話，咱們的瀑布模式早就能勝任了。評估可交付產品和整個流程中的交流對確保質量是相當重要的。這裏首個必須實現的」面向上游」的交流通道是從Ops到Dev。
咱們獨自意淫是件很是容易的事情，可是獲取別人的反饋和提供反饋給別人纔是探究事實真相的正確方法。下游的每一步(反饋)都必須緊跟着有一個上游的肯定。
你如何創建反饋循環機制並不重要。你能夠邀請開發人員加入技術支持團隊的會議，或者將網絡管理員放到Sprint計劃會議中去。一旦你的反饋機制就緒，反饋可以被接收並被處理，你就已經能夠說是走到了DevOps高速車道上來了。
車道3 – 飛速前進
DevOps這條快速車道並不適合意志脆弱的人。爲了進入這條車道，你的組織必需要足夠的成熟。這裏充滿了冒險和對失敗教訓的學習，不斷的嘗試，並認同屢敗屢戰和不斷的實踐是走向成功這條康莊大道的前提條件。在這裏你應該會常常聽到」套路「這個詞，這是有緣由的。不斷的訓練和重複因此能培養出大師，是由於其讓複雜的動做常規化。
可是在你要將這些複雜的動做鏈接起來以前，你頗有必要先去掌握好每個單獨步驟。
「適合大師的動做並不適合新手，脫胎換骨以前你必須先要明白道的真諦。「
DevOps的第三個方式/快速車道包括天天分配時間來持續的進行試驗，時常的獎勵勇於冒險的團隊，並將缺陷特地引入到運做系統上來以增長系統的抗擊打能力。
爲了確保你的組織可以消化好這些方法，你必須在每一個團隊之間創建好頻繁的反饋循環，同時須要確保全部的瓶頸都可以及時的被清理掉，並確保整個系統的運做流程是不可中斷的。
實施好這些措施可讓你的組織時刻保持警戒，並可以快速且高效的應對挑戰。
概要 – DevOps清單
下面是一張你能夠用來檢驗你的組織對DevOps的應用狀況的清單。固然你也能夠在文章評論後面給出你的觀點。
開發團隊和運維團隊之間沒有障礙。二者皆是DevOps統一流程的一部分。
從一個團隊流到另外一個團隊的工做都可以獲得高質量的驗證
工做沒有堆積，全部的瓶頸都已經被處理好。
開發團隊沒有佔用運維團隊的時間，由於部署和維護都是處於同一個時間盒裏面的。
開發團隊不會在週五下午5點後把代碼交付進行部署，剩下運維團隊週末加班加點來給他們擦屁股
開發環境標準化，運維人員能夠很容易將之擴展並進行部署
開發團隊能夠找到合適的方式交付新版本，且運維團隊能夠輕易的進行部署。
每一個團隊之間的通訊線路都很明確
全部的團隊成員都有時間去爲改善系統進行試驗和實踐
常規性的引入(或者模擬)缺陷到系統中來並獲得處理。每次學習到的經驗都應該文檔化下來並分享給相關人員。事故處理成爲平常工做的一部分，且處理方式是已知的
總結
使用現代化的DevOps工具，如Chef、Docker、Ansible、Packer、Troposphere、Consul、Jenkins、SonarQube、AWS等，並不表明你就在正確的應用DevOps的原則。DevOps是一種思惟方式。咱們全部人都是該系統流程的一部分，咱們一塊兒分享共同的時光和交付價值。每一個參加到這個軟件交付流程上來的成員都可以加速或減緩整個系統的運做速度。系統出現的一個缺陷，以及錯誤配置的團隊之間的「防火牆」，均可能會使得整個系統癱瘓，
全部的人都是DevOps的一部分，一旦你的組織明白了這一點，可以幫你管理好這些的工具和技術棧就天然而然的會出如今你眼前了。