從敏捷開發到敏捷運維：DevOps將帶來革命？
原創【51CTO精選譯文】如果你對IT管理感興趣，尤其是對Web運維感興趣，那么最近一定會注意到“DevOps”這一熱詞的出現?，F在#DevOps標簽頻繁出現在微博客Twitter上，同時DevOps相關的技術交流聚會也在慢慢增多。
在許多方面，DevOps是一個集合性概念，指的是能夠理順開發和運維之間相互配合關系的任何事物（51CTO編輯注：在英文中，Developer指開發者，Operations指運維，所以DevOps一詞本身含有開發+運維的意思）。但是DevOps背后的理念要比上述說法更深遠。
51CTO推薦專題：SA，神仙與裝機男：運維的工作到底啥樣兒？
什么是DevOps？
人們越來越意識到傳統意義上的開發行為和運維行為存在脫節現象，從而導致沖突和低效，因此DevOps應運而生。
正如李·湯普森（Lee Thompson）和安德魯·謝福爾（Andrew Shafer）所言，在開發和運維之間存在一面“混亂之墻”。相互沖突的動機、流程和工具導致了這面“墻”的存在。
開發與運維之間的“混亂之墻”
以開發為中心的人通常認為，變化會帶來回報。企業依靠他們來應對不斷變化的需求。因此他們被鼓勵盡可能進行變革。
而運維人員則往往視變化為敵人。企業依靠他們維持正常業務運維和實施讓企業賺錢的服務。由于變化會影響穩定性和可靠性，運維業務有理由對它說不。我們已經多次聽到過如下統計數字：在所有宕機事件中有80%情況是源于自殺式的改變（根據51CTO之前進行的調查，很多時候，僅僅是給系統應用補丁就會造成生產服務器無法正常重啟）。
開發人員和運維人員認識世界的方法，以及各自所處的角色，存在根本性的差別。他們都認為自己的做法是正確的。的確，孤立的來看他們都是正確的。
更糟糕的是，開發和運維團隊通常處于公司組織架構的不同部分，通常具有不同管理者的和競爭關系，而且通常工作在不同的地點。
開發與運維通常工作在不同的地點
讓混亂之墻更堅固的還包括開發和運維工具之間的錯位?？匆幌麻_發者要求和日常使用的常見工具，再看一下系統管理員，你會發現兩者存在很大不同，開發人員沒有興趣使用運維人員的工具，反之亦然；而且兩部分工具之間也不存在重要的集成。即使在某些工具類型上有一些重疊之處，使用方式也完全不同。
開發與運維常用工具的不集成
當應用程序變動需要從開發團隊推向運維團隊時，混亂之墻的存在則將變得更加明顯。有人將其稱為一個“版本發布（Release）”，有人則稱其為一次“部署（deployment）”，但有一件事情是公認的，問題可能會隨之而來。下圖雖然是一個抽象化場景，但是如果你經歷過這一過程，一定會感覺到它的真實性。
應用程序變動從開發到運維
開發人員把一個軟件版本“扔”給墻對面的運維人員。后者拿到該版本產品后開始準備將其部署。運維人員手動修改由開發者提供的部署腳本或創建自己的腳本。他們還需要修改配置文件來適應與開發環境大不相同的真實生產環境。最***的情況是，他們重復在此前環境中已完成的工作；而糟糕的情況是，他們將引入或發現新的漏洞。
運維人員然后開始進行他們自認為正確的部署過程。由于開發和運維之間的腳本、配置、過程和環境存在差別，這一部署過程實際上也是***被執行。當然，期間如果發生一個問題，開發人員會被要求來幫助進行排障。運維人員會說開發團隊給的產品存在問題。而開發人員則會回應稱該產品在他們的環境下運行良好，因此一定是運維人員在部署的過程中做錯了什么。由于配置、文件存儲位置和過程的不同，開發人員診斷問題也并非一件易事。
沒有一個可靠的方式來把環境回滾到此前已知的正常狀態。本來應該一帆風順的部署過程***變成一場救火行動，經過反復測試之后才讓生產環境恢復到正常狀態。
本來應該一帆風順的部署過程***變成一場救火行動
部署階段已經非常明顯的需要DevOps理念來解決問題，但需要DevOps的絕不僅僅是這一階段。正如約翰·阿爾斯帕瓦（John Allspaw）所指出的那樣，開發和運維之間的協作需求在部署之前就已存在，同時也會在部署之后的長時間之內繼續存在。
#p#
DevOps所帶來的好處
DevOps是一個非常強大的概念，因為它可以在眾多不同層面上產生共鳴。
從開發或運維的一線人員的觀點來看，DevOps可以讓他們從眾多煩惱中解脫出來。它雖然不是具有魔力的萬靈藥，但是如果你能夠讓DevOps奏效，則會節省大量時間，而且不至于打擊自己的士氣。顯而易見，投入精力將DevOps落到實處，我們應該會更加高效、更加敏捷和減少挫敗感。有些人可能會反駁稱DevOps是一個遙不可及的目標，但這并非說我們不應該去嘗試實現它。
DevOps會節省大量的時間
對于企業來說，DevOps直接有助于實現兩個強大戰略性企業品質，“業務敏捷性”和“IT融合”。它們可能不是IT人士所擔憂的事情，但是卻應該獲得掌握財政大權的管理者的注意。
IT融合的一個簡單定義是，“企業渴望達到的一個狀態，能夠高效的使用信息技術來達到企業目標——通常是提高公司業績或市場競爭力。”
通過從共同企業目標角度出發來校準開發和運維的職責和流程，DevOps有助于實現IT融合。開發和運維人員需要明白，它們僅僅是一個統一業務流程中的一部分。DevOps思想確保個體決策和行為應力求支持和改進這個統一的業務流程，無論你是來自哪一個組織架構。
DevOps有助于實現IT融合
業務敏捷性的一個簡單定義是，“一個機構以高效、經濟的方式迅速適應市場和環境變化的能力。”
當然對于開發人員來說，“敏捷”有專門的含義（參考51CTO開發頻道的專題：初探敏捷開發），但目標是非常類似的。敏捷開發方法旨在保持軟件開發工作與客戶/公司的目標同步，盡管需求不斷變化，也可以產生高品質軟件。對于多數機構來說，迭代項目管理方法Scrum是敏捷的代名詞。
Scrum
業務敏捷性承諾，在企業權益集團作出決策和開發者進行響應之間能夠緊密互動和快速反饋。看一下一家運轉良好的敏捷開發團體的產品，你會看到一個與業務需求保持一致的穩定持續改進。
但是，當你從企業角度回顧一下整個開發-運維周期，敏捷方法的相關優勢通常會變得非常模糊。混亂之墻導致了應用程序生命周期的分裂。開發和運維分別按照不同的節奏進行。實際上，產品部署之間的長期間隔使得一個團體的敏捷工作變成了它一直試圖避免的瀑布生命周期。當存在混亂之墻時，無論開發團體有多么敏捷，改變企業緩慢和遲鈍的特點是極其困難的。
敏捷的開發與瀑布式企業結構的步調不同
DevOps使得敏捷開發的優勢可以體現在機構層面上。通過考慮到快速、反應靈敏但穩定的業務運維，使其能夠與開發過程的創新保持同步，DevOps可以做到這一點。
如果你希望在自己的組織內建立一個DevOps項目，務必牢記“IT融合” 和“業務敏捷性”。
#p#
如何將DevOps落到實處？
和多數新出現的話題一樣，發現問題的共性特點要比找到解決方案容易的多。
要想實現DevOps相關解決方案，以下三方面需要關注：
1、評價和鼓勵改變文化
改變文化和激勵系統從來不是一件易事。但是，如果你不改變企業文化，兌現DevOps的承諾將非常困難?？疾煲粋€企業的主導文化時，你需要緊密關注如何評價和判斷企業業績。評價的內容將影響和刺激行為的發生。開發-運維生命周期中的所有當事方需要明白，在更大的企業流程中自己只是其中一部分。個體和團隊的成功都要放在整個開發-運維生命周期內來進行評價。對于許多機構來說，這是一個轉變，不再是孤立的來進行業績評價，每一個團隊不再是基于自己的團隊來評價和判斷業績好壞。
2、統一標準化的流程
這是DevOps的一個重要主題，整個開發-運維生命周期必須被看作一個端對端過流程。流程的不同階段可以采取不同的方法，只要這些流程可以被組合到一起創建一個統一的流程。與評價和激勵的問題相似的是，實現這個統一的流程時每個組織可能會有略微不同的需求。
3、統一的工具
這是大多數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
【編輯推薦】
