當(dāng)然，DevOps不乏反對(duì)者。反對(duì)意見(jiàn)不一而足，有人認(rèn)為DevOps是個(gè)誤導(dǎo)（DevOps只是系統(tǒng)管理的一個(gè)新名字而已，新瓶裝老酒），有人對(duì)DevOps不屑一顧（DevOps只是一些瘋狂開(kāi)發(fā)者的瘋狂想法，他們想擺脫運(yùn)維人員，或者，DevOps只是一些瘋狂運(yùn)維人員的瘋狂想法，他們想像開(kāi)發(fā)者一樣工作），甚至有人公開(kāi)抨擊（可惜的很，他們的言論往往毫無(wú)邏輯）。

　　在過(guò)去的九個(gè)多月時(shí)間里，我在公共論壇和客戶公司內(nèi)部竭力推進(jìn)DevOps運(yùn)動(dòng)。正是在那段時(shí)間里，我開(kāi)始注意到人們對(duì)DevOps存在一些常見(jiàn)的誤解，我認(rèn)為正是這些誤解使得一些人在初次接觸DevOps時(shí)產(chǎn)生消極的反應(yīng)。在這里，我將嘗試澄清這些誤解：

　　DevOps不是個(gè)技術(shù)問(wèn)題。

　　盡管在解決DevOps問(wèn)題的方案中，技術(shù)是個(gè)關(guān)鍵的組成部分，但是，DevOps它自己本質(zhì)上是個(gè)業(yè)務(wù)問(wèn)題。

　　什么業(yè)務(wù)與DevOps有關(guān)？

　　在任何公司里，最根本的業(yè)務(wù)流程都是這樣：使一個(gè)最初的想法經(jīng)過(guò)流程最終賺到錢(qián)。

　　需要各種各樣的活動(dòng)組成這個(gè)業(yè)務(wù)流程，這其中一些活動(dòng)是技術(shù)驅(qū)動(dòng)的，其他一些則是人驅(qū)動(dòng)的。這里正是IT所有不同功能所發(fā)揮作用的地方。開(kāi)發(fā)者、QA、架構(gòu)、發(fā)布工程、安全、運(yùn)維，它們都在這一流程中發(fā)揮自己的作用。

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

　　如果沒(méi)有業(yè)務(wù)流程這一上下文，還會(huì)發(fā)生什么事呢？我們的工作將失去意義并最終消失。實(shí)現(xiàn)業(yè)務(wù)目標(biāo)是我們得到薪水和花時(shí)間做事的原因。如果沒(méi)有業(yè)務(wù)目標(biāo)或者我們所做的事情根本對(duì)實(shí)現(xiàn)業(yè)務(wù)目標(biāo)都沒(méi)有助益又會(huì)怎樣呢？糟糕，我們所做的一切都變成了一種愛(ài)好。想想吧，有誰(shuí)會(huì)傻到給愛(ài)好付薪水呢。

　　DevOps的立足點(diǎn)正在于對(duì)市場(chǎng)壓力做出盡可能快速、高效和可靠的反應(yīng)，從而實(shí)現(xiàn)業(yè)務(wù)目標(biāo)。拋開(kāi)業(yè)務(wù)，談?wù)揇evOps問(wèn)題毫無(wú)意義，跟別提花時(shí)間解決這些問(wèn)題了。

　　DevOps聽(tīng)起來(lái)非常像敏捷所要達(dá)到的目標(biāo)，難道不是這樣嗎？

　　如果DevOps和敏捷所要達(dá)到的目標(biāo)聽(tīng)起來(lái)很相似，那是因?yàn)樗麄兊哪繕?biāo)就是一致的。但是敏捷和DevOps是兩個(gè)截然不同的事物。我們可以在敏捷開(kāi)發(fā)里做得很好，但是我們依然會(huì)面臨很多DevOps問(wèn)題。相反，我們完全可以不采用任何敏捷開(kāi)發(fā)方法（盡管這越來(lái)越不現(xiàn)實(shí)），但是卻在解決DevOps問(wèn)題方面做得很好。

　　我喜歡將敏捷和DevOps描述為兩個(gè)相關(guān)聯(lián)的思想，它們都有一個(gè)共同的祖先，這個(gè)祖先就是精益，但是它們關(guān)注了不同的層面。敏捷深度關(guān)注于改善一個(gè)主要的IT功能（交付軟件），同時(shí)，DevOps關(guān)注于對(duì)跨IT功能的流程和交互的改善（它拉伸了整個(gè)開(kāi)發(fā)生命周期的長(zhǎng)度，使其包括了運(yùn)維）。

　　可是，我所理解的DevOps，全部是關(guān)于很酷的工具？

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

　　很有可能，我們?cè)敬蛩愀纳莆覀兊慕M織，但是新工具的使用卻使得原有的壞習(xí)慣和支離破碎的流程更加惡化。如果想在改善業(yè)務(wù)流程上取得理想的效果，那么我們必須明確為什么要使用該工具以及如何最有效的利用該工具。

　　實(shí)際上，當(dāng)我們明確我們的DevOps問(wèn)題究竟是什么，以及如何改善流程以減少DevOps問(wèn)題時(shí)，對(duì)工具的討論往往變得非常簡(jiǎn)單（如果還值得討論的話）。

　　因?yàn)樾屡d的DevOps運(yùn)動(dòng)主要是技術(shù)人員在推動(dòng)，所以很容易理解為什么人們很興奮的直接去討論工具。但是，在爭(zhēng)論究竟是Puppet好還是Chef更好（譯者注：Puppet、Chef都是開(kāi)源的系統(tǒng)配置管理工具），應(yīng)該圍繞文件還是圍繞包部署之前，也許我們更應(yīng)該做的是：讓所有人都知道為什么需要這些工具以及期望中的業(yè)務(wù)流程改進(jìn)是什么，這才是重點(diǎn)！

　　既然DevOps是關(guān)于業(yè)務(wù)流程的，那么為什么叫它“DevOps”呢？

　　在我看來(lái)，早期DevOps的一個(gè)不足之處是沒(méi)有直接地明確DevOps問(wèn)題的真實(shí)范圍，即它的問(wèn)題域到底有多大。經(jīng)過(guò)一年的觀察和思考，事實(shí)證明，我們正在解決的是對(duì)所有企業(yè)來(lái)說(shuō)最大的問(wèn)題之一：如何面對(duì)市場(chǎng)壓力做出盡可能迅速的反應(yīng)從而實(shí)現(xiàn)業(yè)務(wù)目標(biāo)。

　　可惜的是，DevOps必須從某個(gè)地方開(kāi)始，于是我們碰到了一個(gè)幾乎非常普遍的問(wèn)題：開(kāi)發(fā)者文化與運(yùn)維文化之間存在的沖突和脫節(jié)。盡管每個(gè)企業(yè)的組織結(jié)構(gòu)圖各不相同，但是為了有個(gè)共同的討論點(diǎn)，我們能夠非常容易的將其劃分為開(kāi)發(fā)陣營(yíng)與運(yùn)維陣營(yíng)（當(dāng)然，現(xiàn)實(shí)世界遠(yuǎn)比這復(fù)雜和無(wú)趣）。

　　如上圖所示，在開(kāi)發(fā)和運(yùn)維之間存在著一面混亂之墻，在這種情況下，大部分早期DevOps的注意力都放在在改善部署活動(dòng)上。因?yàn)?a >部署活動(dòng)構(gòu)成了整個(gè)IT組織的大部分工作，所以從部署開(kāi)始改善，這是一個(gè)合理而自然的選擇。

　　也許Patrick應(yīng)該將他的第一次活動(dòng)稱為“業(yè)務(wù)人員開(kāi)發(fā)人員質(zhì)量保障人員安全人員運(yùn)維人員云服務(wù)用戶日”或者“比敏捷更牛叉日”又或者其他的什么東西，但是我強(qiáng)烈懷疑有人會(huì)認(rèn)為其炫耀，所以低調(diào)的結(jié)果就是DevOps叫了DevOps。

　　聲明：本文已獲原創(chuàng)作者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知識(shí)庫(kù)：DevOps不是個(gè)技術(shù)問(wèn)題，而是個(gè)業(yè)務(wù)問(wèn)題，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。