當然，DevOps不乏反對者。反對意見不一而足，有人認為DevOps是個誤導（DevOps只是系統管理的一個新名字而已，新瓶裝老酒），有人對DevOps不屑一顧（DevOps只是一些瘋狂開發者的瘋狂想法，他們想擺脫運維人員，或者，DevOps只是一些瘋狂運維人員的瘋狂想法，他們想像開發者一樣工作），甚至有人公開抨擊（可惜的很，他們的言論往往毫無邏輯）。

　　在過去的九個多月時間里，我在公共論壇和客戶公司內部竭力推進DevOps運動。正是在那段時間里，我開始注意到人們對DevOps存在一些常見的誤解，我認為正是這些誤解使得一些人在初次接觸DevOps時產生消極的反應。在這里，我將嘗試澄清這些誤解：

　　DevOps不是個技術問題。

　　盡管在解決DevOps問題的方案中，技術是個關鍵的組成部分，但是，DevOps它自己本質上是個業務問題。

　　什么業務與DevOps有關？

　　在任何公司里，最根本的業務流程都是這樣：使一個最初的想法經過流程最終賺到錢。

　　需要各種各樣的活動組成這個業務流程，這其中一些活動是技術驅動的，其他一些則是人驅動的。這里正是IT所有不同功能所發揮作用的地方。開發者、QA、架構、發布工程、安全、運維，它們都在這一流程中發揮自己的作用。

　　但是如果拋開這一業務流程的上下文，看看我們還剩下什么？是的，我們有一伙人，還有一些部門，它們各自做著它們自己的分內事。但是我們失去了真正做事的動力，到處是效率低下的工作、浪費、沖突和部門間的孤立。從表面上看，每個人都在僅僅為自己工作。

　　如果沒有業務流程這一上下文，還會發生什么事呢？我們的工作將失去意義并最終消失。實現業務目標是我們得到薪水和花時間做事的原因。如果沒有業務目標或者我們所做的事情根本對實現業務目標都沒有助益又會怎樣呢？糟糕，我們所做的一切都變成了一種愛好。想想吧，有誰會傻到給愛好付薪水呢。

　　DevOps的立足點正在于對市場壓力做出盡可能快速、高效和可靠的反應，從而實現業務目標。拋開業務，談論DevOps問題毫無意義，跟別提花時間解決這些問題了。

　　DevOps聽起來非常像敏捷所要達到的目標，難道不是這樣嗎？

　　如果DevOps和敏捷所要達到的目標聽起來很相似，那是因為他們的目標就是一致的。但是敏捷和DevOps是兩個截然不同的事物。我們可以在敏捷開發里做得很好，但是我們依然會面臨很多DevOps問題。相反，我們完全可以不采用任何敏捷開發方法（盡管這越來越不現實），但是卻在解決DevOps問題方面做得很好。

　　我喜歡將敏捷和DevOps描述為兩個相關聯的思想，它們都有一個共同的祖先，這個祖先就是精益，但是它們關注了不同的層面。敏捷深度關注于改善一個主要的IT功能（交付軟件），同時，DevOps關注于對跨IT功能的流程和交互的改善（它拉伸了整個開發生命周期的長度，使其包括了運維）。

　　可是，我所理解的DevOps，全部是關于很酷的工具？

　　技術幾乎能使所有業務流程更加高效、可擴展和可靠。但是，我們必須記住：工具始終只是工具。

　　很有可能，我們原本打算改善我們的組織，但是新工具的使用卻使得原有的壞習慣和支離破碎的流程更加惡化。如果想在改善業務流程上取得理想的效果，那么我們必須明確為什么要使用該工具以及如何最有效的利用該工具。

　　實際上，當我們明確我們的DevOps問題究竟是什么，以及如何改善流程以減少DevOps問題時，對工具的討論往往變得非常簡單（如果還值得討論的話）。

　　因為新興的DevOps運動主要是技術人員在推動，所以很容易理解為什么人們很興奮的直接去討論工具。但是，在爭論究竟是Puppet好還是Chef更好（譯者注：Puppet、Chef都是開源的系統配置管理工具），應該圍繞文件還是圍繞包部署之前，也許我們更應該做的是：讓所有人都知道為什么需要這些工具以及期望中的業務流程改進是什么，這才是重點！

　　既然DevOps是關于業務流程的，那么為什么叫它“DevOps”呢？

　　在我看來，早期DevOps的一個不足之處是沒有直接地明確DevOps問題的真實范圍，即它的問題域到底有多大。經過一年的觀察和思考，事實證明，我們正在解決的是對所有企業來說最大的問題之一：如何面對市場壓力做出盡可能迅速的反應從而實現業務目標。

　　可惜的是，DevOps必須從某個地方開始，于是我們碰到了一個幾乎非常普遍的問題：開發者文化與運維文化之間存在的沖突和脫節。盡管每個企業的組織結構圖各不相同，但是為了有個共同的討論點，我們能夠非常容易的將其劃分為開發陣營與運維陣營（當然，現實世界遠比這復雜和無趣）。

　　如上圖所示，在開發和運維之間存在著一面混亂之墻，在這種情況下，大部分早期DevOps的注意力都放在在改善部署活動上。因為部署活動構成了整個IT組織的大部分工作，所以從部署開始改善，這是一個合理而自然的選擇。

　　也許Patrick應該將他的第一次活動稱為“業務人員開發人員質量保障人員安全人員運維人員云服務用戶日”或者“比敏捷更牛叉日”又或者其他的什么東西，但是我強烈懷疑有人會認為其炫耀，所以低調的結果就是DevOps叫了DevOps。

　　聲明：本文已獲原創作者Damon Edwards的許可。

　　原文鏈接：http://article.yeeyan.org/view/139551/170318

　　英文鏈接：http://dev2ops.org/blog/2010/11/7/devops-is-not-a-technology-problem-devops-is-a-business-prob.html

it知識庫：DevOps不是個技術問題，而是個業務問題，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。