為什么 DevOps編寫軟件之所以難，是因為沒有哪兩個軟件是完全相同的（這也是人們喜歡編程的原因，解決問題帶給自己的快感），這跟物理、化學，建筑行業等等完全不同，而且還是不可見的，物理過程、化學反應至少看得見、摸得著，建筑業還有圖紙……更要命的是，需求在不斷的變……需求的變化，不僅僅在于客戶改變了想法，而是在當今移動互聯網時代，今天客戶有個銷售活動，明天就要在網站上體現出來……到最后，本來架構和設計良好的軟件，被改得面目全非~于是，人們想到并采用了“敏捷開發”，從一個原型開始，快速開發，快速部署，盡早讓客戶看見軟件，然后重構，不斷完善……我們說，“Build”這個詞，準確來說，不是“生成”，而是“構建”，也正是編程是一個“搭建”軟件的真正含義~但是“敏捷開發”主要針對的是開發過程，可是整個軟件生命周期，開發只是第一步，還有后來的測試、部署、集成、質量保證，我們經常能看見開發軟件與運維人員之間永無休止的爭論，這就造成了，開發與運維、質量保證的嚴重脫節，最近跳槽，測試人員每次找另一個組的開發人員，每次交流的時間都在2個小時左右（太長了，毫無意義的2個小時），測試人員說這樣，開發人員不愿意……因此 DevOps 應運而生，不僅僅開發要敏捷，運維也要敏捷……
事實上，無論是哪方面的“敏捷”，它們都只是一套方法論而已，包括一套指導思想和相應的工具（編程跟一些實證科學，如物理化學等，相比本身就缺乏一套理論基礎，數學基礎，有的也就是方法論了），方法論的最大弱點是，操作性比較差，要想把 DevOps 用起來，實在不容易~
有些人對 DevOps 不爽的原因是“讓開發人員做運維的事”，其實，我倒不覺得，軟件開發的歷史并不長，還不到100年，還很幼稚，而像物理化學建筑等人類已經有幾千年的歷史，加之硬件發展的速度實在太快，你會發現，幾年以前還激動人心的框架或工具，現在已經落伍了，今天的 java 跟十年前的 Java 已經大不相同了，如果你看了亞馬遜的《架構師》的話。另一個方面，往往事情本身并不復雜，可一牽涉到人，情況就完全不同了，人越多情況越嚴峻~所以，良好的溝通和項目管理在軟件研發過程始終都比寫代碼、測試、集成重要的多。
人們越來越意識到傳統意義上的開發與運維之間存在脫節現象，從而導致沖突和低效，于是 DevOps 應運而生。
正如李·湯普森（Lee Thompson）和安德魯·謝福爾（Andrew Shafer）所說：“在開發和運維之間存在一面‘混亂之墻’”。相互沖突的動機、流程和工具導致了這面“墻”的存在。
以開發為中心的人通常認為，變化會帶來回報。企業依靠他們來應對不斷變化的市場需求（比如，打折、優惠），因此他們被鼓勵盡可能進行變革；而運維人員則往往視變化為敵人，因為，變化會影響穩定性和可靠性，運維業務有理由對它說不。企業依靠它們維持正常業務讓企業賺錢。我們已經多次聽到過如下統計數字：在所有宕機事件中有80%情況是源于自殺式的改變。
開發人員和運維人員認識世界的方法，以及各自所處的角色，存在根本性的差別。他們都認為自己的做法是正確的。的確，孤立的來看他們都是正確的。
更糟糕的是，開發團隊和運維團隊通常處于公司組織架構的不同部分，具有不同管理者和競爭關系，甚至工作地點都可能不同。
讓”混亂之墻“更堅固的還包括開發和運維工具之間的錯位?？匆幌麻_發者與系統管理員日常使用的工具，你會發現兩者存在很大不同，開發人員沒有興趣使用運維人員的工具，反之亦然；而且它們之間也不存在重要的集成。即使在某些工具類型上有一些重疊，使用方式也完全不同。
當應用程序需要從開發團隊推向運維團隊時，”混亂之墻“將變得更加明顯。有人將其稱為一個“版本發布（Release）”，有人則稱其為一次“部署（deployment）”，但有一件事情是公認的，問題可能會隨之而來。下圖雖然是一個抽象化場景，但是如果你經歷過這一過程，一定會感覺到它的真實性。
開發人員把一個軟件版本“扔”給墻對面的運維人員，后者拿后開始準備部署。運維人員手動修改由開發者提供的部署腳本或創建自己的腳本。他們還需要修改配置文件來適應與開發環境大不相同的真實生產環境。最完美的情況是，他們成功地重復了之前的工作；糟糕的是，他們將引入或發現新的漏洞。
然后，運維人員進行他們自認為正確的部署過程。由于開發和運維之間的腳本、配置、過程和環境存在差別，這一部署實際上也是首次被執行。當然，期間如果發生一個問題，開發人員會被要求來幫助。運維人員會說開發團隊給的產品存在問題（相比你也知道，當別人對你說，你的程序有問題時，你的第一反應）。而開發人員則會回應，該產品在他們的環境下運行良好，一定是運維人員在部署過程中做錯了什么。由于配置、文件存儲位置和過程的不同，開發人員診斷問題也并非一件易事。
沒有一個可靠的方式來把環境回滾到之前已知的正常狀態。本應該一帆風順的部署過程最后變成一場救火行動，經過反復測試后才讓生產環境恢復到正常狀態。
正如約翰·阿爾斯帕瓦（John Allspaw）所指出的那樣，開發和運維之間的協作需求在部署之前就已存在，同時也會在部署之后的長時間之內繼續存在。
這就是需要 DevOps 的原因，但需要 DevOps 絕不僅僅是這些。
什么是 DevOps
DevOps（英文 Development 和 Operations 的組合）是一組過程、方法與系統的統稱，用于促進軟件開發、技術運營和質量保障（QA）部門之間的溝通、協作與整合。它的出現是由于軟件行業日益清晰地認識到：為了按時交付軟件產品和服務，開發和運營工作必須緊密合作。
傳統的軟件組織將開發、IT運營和質量保障設為各自分離的部門。在這種環境下如何采用新的開發方法（例如敏捷軟件開發），這是一個重要的課題：按照從前的工作方式，開發和部署不需要IT支持或者QA深入的、跨部門的支持，而現在卻需要極其緊密的多部門協作。然而 DevOps 考慮的還不止是軟件部署。它是一套針對這幾個部門間溝通與協作問題的流程和方法。
需要頻繁交付的企業可能更需要對 DevOps 有一個大致的了解。Flickr 發展了自己的 DevOps 能力，使之能夠支撐業務部門“每天部署10次”的要求──如果一個組織要生產面向多種用戶、具備多樣功能的應用程序，其部署周期必然會很短。這種能力也被稱為持續部署，并且經常與精益創業方法聯系起來。從2009年起，相關的工作組、專業組織和博客快速涌現。
DevOps 的引入能對產品交付、測試、功能開發和維護（包括──曾經罕見但如今已屢見不鮮的──“熱補丁”）起到意義深遠的影響。在缺乏 DevOps 能力的組織中，開發與運營之間存在著信息“鴻溝”──例如運營人員要求更好的可靠性和安全性，開發人員則希望基礎設施響應更快，而業務用戶的需求則是更快地將更多的特性發布給最終用戶使用。這種信息鴻溝就是最常出問題的地方。
以下幾方面因素可能促使一個組織引入 DevOps：
DevOps 經常被描述為“開發團隊與運營團隊之間更具協作性、更高效的關系”。由于團隊間協作關系的改善，整個組織的效率因此得到提升，伴隨頻繁變化而來的生產環境的風險也能得到降低。
DevOps 所帶來的好處DevOps 是一個非常強大的概念，因為它可以在眾多不同層面上產生共鳴。
從開發或運維的一線人員的觀點來看，DevOps 可以讓他們從眾多煩惱中解脫出來。它雖然不是具有魔力的萬靈藥，但是如果你能夠讓 DevOps 奏效，則會節省大量時間，而且不至于打擊自己的士氣。顯而易見，投入精力將 DevOps 落到實處，我們應該會更加高效、更加敏捷和減少挫敗感。有些人可能會反駁稱DevOps 是一個遙不可及的目標，但這并非說我們不應該去嘗試實現它。
對于企業來說，DevOps 直接有助于實現兩個強大戰略性企業品質，“業務敏捷性”和“IT融合”。它們可能不是IT人士所擔憂的事情，但是卻應該獲得掌握財政大權的管理者的注意。
IT融合的一個簡單定義是，“企業渴望達到的一個狀態，能夠高效的使用信息技術來達到企業目標——通常是提高公司業績或市場競爭力?！?/p>
通過從共同企業目標角度出發來校準開發和運維的職責和流程，DevOps 有助于實現IT融合。開發和運維人員需要明白，它們僅僅是一個統一業務流程中的一部分。DevOps 思想確保個體決策和行為應力求支持和改進這個統一的業務流程，無論你是來自哪一個組織架構。
業務敏捷性的一個簡單定義是，“一個機構以高效、經濟的方式迅速適應市場和環境變化的能力?！?/p>
當然對于開發人員來說，“敏捷”有專門的含義，但目標是非常類似的。敏捷開發方法旨在保持軟件開發工作與客戶/公司的目標同步，盡管需求不斷變化，也可以產生高品質軟件。對于多數機構來說，迭代項目管理方法 Scrum 是敏捷的代名詞。
業務敏捷性承諾，在企業權益集團作出決策和開發者進行響應之間能夠緊密互動和快速反饋?？匆幌乱患疫\轉良好的敏捷開發團體的產品，你會看到一個與業務需求保持一致的穩定持續改進。
但是，當你從企業角度回顧一下整個開發-運維周期，敏捷方法的相關優勢通常會變得非常模糊。混亂之墻導致了應用程序生命周期的分裂。開發和運維分別按照不同的節奏進行。實際上，產品部署之間的長期間隔使得一個團體的敏捷工作變成了它一直試圖避免的瀑布生命周期。當存在混亂之墻時，無論開發團體有多么敏捷，改變企業緩慢和遲鈍的特點是極其困難的。
DevOps 使得敏捷開發的優勢可以體現在機構層面上。通過考慮到快速、反應靈敏但穩定的業務運維，使其能夠與開發過程的創新保持同步，DevOps可以做到這一點。
如果你希望在自己的組織內建立一個 DevOps 項目，務必牢記“IT融合” 和“業務敏捷性”。
如何將 DevOps 落到實處？與多數新出現的話題一樣，發現問題的共性特點要比找到解決方案容易得多。
要想實現 DevOps 相關解決方案，以下三方面需要關注：
關于把 DevOps 變為現實需要哪些類型的工具，杰克·索羅夫曼（Jake Sorofman）提出如下建議：
在從開發到運維的生命周期中存在許多不同的工具。工具選擇和執行決策需要根據它們對端到端生命周期的影響來決定。
關于 DevOps 的澄清現在某些系統管理員正在試圖把自己的崗位名稱改為“DevOps”。但是，DevOps不應該是一個單一的位置或職稱。把DevOps變成一個新職位名稱或特定角色是一件非常危險的事情。例如這會導致以下錯誤端點：你是一個DBA？或者是一個安全專家？那么不用擔心DevOps，因為那是 DevOps團隊的問題。
設想一下，你不會說“我需要招聘一個Agile”或“我需要招聘一個Scrum”或“我需要招聘一個 ITIL”，而只是會說需要招聘了解這些概念或方法的開發人員、項目經理、測試人員或系統管理員。DevOps也是同樣道理。
與 DevOps 具有相同理念的術語很多，例如敏捷運維（Agile Operations）、敏捷基礎設施（Agile Infrastructure）和 Dev2Ops。還有很多人雖然沒有提及“DevOps”，但卻在遵循著類似的理念。
參考資料新聞熱點
疑難解答
