【51CTO精選譯文】若是你對IT管理感興趣，尤爲是對Web運維感興趣，那麼最近必定會注意到「DevOps」這一熱詞的出現。如今#DevOps標籤頻繁出如今微博客Twitter上，同時DevOps相關的技術交流聚會也在慢慢增多。html
在許多方面，DevOps是一個集合性概念，指的是可以理順開發和運維之間相互配合關係的任何事物（51CTO編輯注：在英文中，Developer指開發者，Operations指運維，因此DevOps一詞自己含有開發+運維的意思）。可是DevOps背後的理念要比上述說法更深遠。安全
什麼是DevOps？服務器
人們愈來愈意識到傳統意義上的開發行爲和運維行爲存在脫節現象，從而致使衝突和低效，所以DevOps應運而生。架構
正如李·湯普森（Lee Thompson）和安德魯·謝福爾（Andrew Shafer）所言，在開發和運維之間存在一面「混亂之牆」。相互衝突的動機、流程和工具致使了這面「牆」的存在。運維
開發與運維之間的「混亂之牆」ide
以開發爲中心的人一般認爲，變化會帶來回報。企業依靠他們來應對不斷變化的需求。所以他們被鼓勵儘量進行變革。工具
而運維人員則每每視變化爲敵人。企業依靠他們維持正常業務運維和實施讓企業賺錢的服務。因爲變化會影響穩定性和可靠性，運維業務有理由對它說不。咱們已經屢次聽到過以下統計數字：在全部宕機事件中有80%狀況是源於自殺式的改變（根據51CTO以前進行的調查，不少時候，僅僅是給系統應用補丁就會形成生產服務器沒法正常重啓）。post
開發人員和運維人員認識世界的方法，以及各自所處的角色，存在根本性的差異。他們都認爲本身的作法是正確的。的確，孤立的來看他們都是正確的。測試
更糟糕的是，開發和運維團隊一般處於公司組織架構的不一樣部分，一般具備不一樣管理者的和競爭關係，並且一般工做在不一樣的地點。spa
開發與運維一般工做在不一樣的地點
讓混亂之牆更堅固的還包括開發和運維工具之間的錯位。看一下開發者要求和平常使用的常見工具，再看一下系統管理員，你會發現二者存在很大不一樣，開發人員沒有興趣使用運維人員的工具，反之亦然；並且兩部分工具之間也不存在重要的集成。即便在某些工具類型上有一些重疊之處，使用方式也徹底不一樣。
開發與運維經常使用工具的不集成
當應用程序變更須要從開發團隊推向運維團隊時，混亂之牆的存在則將變得更加明顯。有人將其稱爲一個「版本發佈（Release）」，有人則稱其爲一次「部署（deployment）」，但有一件事情是公認的，問題可能會隨之而來。下圖雖然是一個抽象化場景，可是若是你經歷過這一過程，必定會感受到它的真實性。
應用程序變更從開發到運維
開發人員把一個軟件版本「扔」給牆對面的運維人員。後者拿到該版本產品後開始準備將其部署。運維人員手動修改由開發者提供的部署腳本或建立本身的腳本。他們還須要修改配置文件來適應與開發環境大不相同的真實生產環境。最完美的狀況是，他們重複在此前環境中已完成的工做；而糟糕的狀況是，他們將引入或發現新的漏洞。
運維人員而後開始進行他們自認爲正確的部署過程。因爲開發和運維之間的腳本、配置、過程和環境存在差異，這一部署過程實際上也是首次被執行。固然，期間若是發生一個問題，開發人員會被要求來幫助進行排障。運維人員會說開發團隊給的產品存在問題。而開發人員則會迴應稱該產品在他們的環境下運行良好，所以必定是運維人員在部署的過程當中作錯了什麼。因爲配置、文件存儲位置和過程的不一樣，開發人員診斷問題也並不是一件易事。
沒有一個可靠的方式來把環境回滾到此前已知的正常狀態。原本應該一路順風的部署過程最後變成一場救火行動，通過反覆測試以後才讓生產環境恢復到正常狀態。
原本應該一路順風的部署過程最後變成一場救火行動
部署階段已經很是明顯的須要DevOps理念來解決問題，但須要DevOps的毫不僅僅是這一階段。正如約翰·阿爾斯帕瓦（John Allspaw）所指出的那樣，開發和運維之間的協做需求在部署以前就已存在，同時也會在部署以後的長時間以內繼續存在。
DevOps所帶來的好處
DevOps是一個很是強大的概念，由於它能夠在衆多不一樣層面上產生共鳴。
從開發或運維的一線人員的觀點來看，DevOps可讓他們從衆多煩惱中解脫出來。它雖然不是具備魔力的萬靈藥，可是若是你可以讓DevOps奏效，則會節省大量時間，並且不至於打擊本身的士氣。顯而易見，投入精力將DevOps落到實處，咱們應該會更加高效、更加敏捷和減小挫敗感。有些人可能會反駁稱DevOps是一個高不可攀的目標，但這並不是說咱們不該該去嘗試實現它。
DevOps會節省大量的時間
對於企業來講，DevOps直接有助於實現兩個強大戰略性企業品質，「業務敏捷性」和「IT融合」。它們可能不是IT人士所擔心的事情，可是卻應該得到掌握財政大權的管理者的注意。
IT融合的一個簡單定義是，「企業渴望達到的一個狀態，可以高效的使用信息技術來達到企業目標——一般是提升公司業績或市場競爭力。」
經過從共同企業目標角度出發來校準開發和運維的職責和流程，DevOps有助於實現IT融合。開發和運維人員須要明白，它們僅僅是一個統一業務流程中的一部分。DevOps思想確保個體決策和行爲應力求支持和改進這個統一的業務流程，不管你是來自哪個組織架構。
DevOps有助於實現IT融合
業務敏捷性的一個簡單定義是，「一個機構以高效、經濟的方式迅速適應市場和環境變化的能力。」
固然對於開發人員來講，「敏捷」有專門的含義（參考51CTO開發頻道的專題：初探敏捷開發），但目標是很是相似的。敏捷開發方法旨在保持軟件開發工做與客戶/公司的目標同步，儘管需求不斷變化，也能夠產生高品質軟件。對於多數機構來講，迭代項目管理方法Scrum是敏捷的代名詞。
Scrum
業務敏捷性承諾，在企業權益集團做出決策和開發者進行響應之間可以緊密互動和快速反饋。看一下一家運轉良好的敏捷開發團體的產品，你會看到一個與業務需求保持一致的穩定持續改進。
可是，當你從企業角度回顧一下整個開發-運維週期，敏捷方法的相關優點一般會變得很是模糊。混亂之牆致使了應用程序生命週期的分裂。開發和運維分別按照不一樣的節奏進行。實際上，產品部署之間的長期間隔使得一個團體的敏捷工做變成了它一直試圖避免的瀑布生命週期。當存在混亂之牆時，不管開發團體有多麼敏捷，改變企業緩慢和遲鈍的特色是極其困難的。
敏捷的開發與瀑布式企業結構的步調不一樣
DevOps使得敏捷開發的優點能夠體如今機構層面上。經過考慮到快速、反應靈敏但穩定的業務運維，使其可以與開發過程的創新保持同步，DevOps能夠作到這一點。
若是你但願在本身的組織內創建一個DevOps項目，務必牢記「IT融合」 和「業務敏捷性」。
如何將DevOps落到實處？
和多數新出現的話題同樣，發現問題的共性特色要比找到解決方案容易的多。
要想實現DevOps相關解決方案，如下三方面須要關注：
一、評價和鼓勵改變文化
改變文化和激勵系統歷來不是一件易事。可是，若是你不改變企業文化，兌現DevOps的承諾將很是困難。考察一個企業的主導文化時，你須要緊密關注如何評價和判斷企業業績。評價的內容將影響和刺激行爲的發生。開發-運維生命週期中的全部當事方須要明白，在更大的企業流程中本身只是其中一部分。個體和團隊的成功都要放在整個開發-運維生命週期內來進行評價。對於許多機構來講，這是一個轉變，再也不是孤立的來進行業績評價，每個團隊再也不是基於本身的團隊來評價和判斷業績好壞。
二、統一標準化的流程
這是DevOps的一個重要主題，整個開發-運維生命週期必須被看做一個端對端過流程。流程的不一樣階段能夠採起不一樣的方法，只要這些流程能夠被組合到一塊兒建立一個統一的流程。與評價和激勵的問題類似的是，實現這個統一的流程時每一個組織可能會有略微不一樣的需求。
三、統一的工具
這是大多數DevOps討論一直在關注的領域。這一點不使人吃驚，由於當技術專家在考慮解決一個問題時，第一反應每每就是直接跳轉到工具討論上。若是你關注Puppet、Chef或ControlTier等工具社區，那麼你可能已經意識到人們對在開發和運維工具之間創建橋樑的重大關注。「基礎設施即代碼（Infrastructure as code）」、「模型驅動自動化（model driven automation）」和「持續性部署（continuous deployment）」都是能夠劃歸DevOps旗下的概念。
關於把DevOps變爲現實須要哪些類型的工具，傑克·索羅夫曼（Jake Sorofman）提出以下建議：
一個版本控制軟件庫
它能夠確保全部系統產品在整個版本發佈生命週期中被很好的定義，且可以實現一致性共享，同時保持最新信息。開發和QA機構可以從中取得相同平臺版本，生產機構部署已經被QA機構驗證過的相同版本。
深層模型系統
它的版本系統清晰的描述了軟件系統相關的全部組件、策略和依賴性，從而能夠簡單的根據須要複製一個系統或在無衝突的狀況下引入變化。
人工任務的自動化
在依賴關係發現、系統構造、配置、更新和回滾等過程當中，減小人工干涉。自動操做變爲高速、無衝突和大規模系統管理的命令和控制基礎。
在從開發到運維的生命週期中存在許多不一樣的工具。工具選擇和執行決策須要根據它們對端到端生命週期的影響來決定。
關於DevOps的澄清
如今某些系統管理員正在試圖把本身的崗位名稱改成「DevOps」。可是，DevOps不該該是一個單一的位置或職稱。把DevOps變成一個新職位名稱或特定角色是一件很是危險的事情。例如這會致使如下錯誤端點：你是一個DBA？或者是一個安全專家？那麼不用擔憂DevOps，由於那是DevOps團隊的問題。
設想一下，你不會說「我須要招聘一個Agile」或「我須要招聘一個Scrum」或「我須要招聘一個ITIL」，而只是會說須要招聘瞭解這些概念或方法的開發人員、項目經理、測試人員或系統管理員。DevOps也是一樣道理。
與DevOps具備相同理念的術語不少，例如敏捷運維（Agile Operations）、敏捷基礎設施（Agile Infrastructure）和Dev2Ops。還有不少人雖然沒有說起「DevOps」，但卻在遵循着相似的理念。
原文：http://dev2ops.org/blog/2010/2/22/what-is-devops.html