為什麽和什麽是 DevOps？
原文地址：https://www.aliyun.com/jiaocheng/292515.html
- 為什麽和什麽是 DevOps？
-
發布時間：2018-02-07 來源：網絡 上傳者：用戶
關鍵字:
發表文章 - 摘要：原文地址本文內容為什麽DevOps什麽是DevOpsDevOps所帶來的好處如何將DevOps落到實處?關於DevOps的澄清參考資料編寫軟件之所以難,是因為沒有哪兩個軟件是完全相同的(這也是人們喜歡編程的原因,解決問題帶給自己的快感),這跟物理、化學,建築行業等等完全不同,而且還是不可見的,物理過程、化學反應至少看得見、摸得著,建築業還有圖紙……更要命的是,需求在不斷的變……需求的變化,不僅僅在於客戶改變了想法,而是在當今移動互聯網時代,今天客戶有個銷售活動,明天就要在網站
- 原文地址本文內容
- 為什麽 DevOps
- 什麽是 DevOps
- DevOps 所帶來的好處
- 如何將 DevOps 落到實處?
- 關於 DevOps 的澄清
- 參考資料
為什麽 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:
- 使用敏捷或其他軟件開發過程與方法
- 業務負責人要求加快產品交付的速率
- 虛擬化和雲計算基礎設施(可能來自內部或外部供應商)日益普遍
- 數據中心自動化技術和配置管理工具的普及
- 有一種觀點認為,目前占主導地位的“傳統”美國式管理風格(“斯隆模型 vs 豐田模型”)[16]會導致“煙囪式自動化”,從而造成開發與運營之間的鴻溝,因此需要DevOps能力來克服由此引發的問題。
DevOps 經常被描述為“開發團隊與運營團隊之間更具協作性、更高效的關系”。由於團隊間協作關系的改善,整個組織的效率因此得到提升,伴隨頻繁變化而來的生產環境的風險也能得到降低。
DevOps 所帶來的好處
DevOps 是一個非常強大的概念,因為它可以在眾多不同層面上產生共鳴。
從開發或運維的一線人員的觀點來看,DevOps 可以讓他們從眾多煩惱中解脫出來。它雖然不是具有魔力的萬靈藥,但是如果你能夠讓 DevOps 奏效,則會節省大量時間,而且不至於打擊自己的士氣。顯而易見,投入精力將 DevOps 落到實處,我們應該會更加高效、更加敏捷和減少挫敗感。有些人可能會反駁稱DevOps 是一個遙不可及的目標,但這並非說我們不應該去嘗試實現它。
對於企業來說,DevOps 直接有助於實現兩個強大戰略性企業品質,“業務敏捷性”和“IT融合”。它們可能不是IT人士所擔憂的事情,但是卻應該獲得掌握財政大權的管理者的註意。
IT融合的一個簡單定義是,“企業渴望達到的一個狀態,能夠高效的使用信息技術來達到企業目標——通常是提高公司業績或市場競爭力。”
通過從共同企業目標角度出發來校準開發和運維的職責和流程,DevOps 有助於實現IT融合。開發和運維人員需要明白,它們僅僅是一個統一業務流程中的一部分。DevOps 思想確保個體決策和行為應力求支持和改進這個統一的業務流程,無論你是來自哪一個組織架構。
業務敏捷性的一個簡單定義是,“一個機構以高效、經濟的方式迅速適應市場和環境變化的能力。”
當然對於開發人員來說,“敏捷”有專門的含義,但目標是非常類似的。敏捷開發方法旨在保持軟件開發工作與客戶/公司的目標同步,盡管需求不斷變化,也可以產生高品質軟件。對於多數機構來說,叠代項目管理方法 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”,但卻在遵循著類似的理念。
為什麽和什麽是 DevOps？