當然，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。
容器技術問題
1.為什麼會出現容器技術？容器是針對以下問題的解決方案 在切換執行環境後，如何保證軟體能夠可靠地執行？這種切換可能是從程式設計師的膝上型電腦到測試環境 從某個測試階段部署到線上，也可能是從資料中心的某台物理機到私有雲或者公有雲上的某台虛擬機器。2.容器是什麼？3.容器技術的未來發展趨勢？截至今天，業...
不是錢，而是原則問題
當某人告訴你 不是錢，而是原則問題 時，十有 就是錢的問題。照一般的說法，金錢是價值的尺度，交換的媒介，財富的貯藏。但是這種說法忽略了它的另一面，它令人陶醉 令人瘋狂 令人激動的一面，也撇開了愛錢的心理不談。馬克思說，金錢是 人情的離心力 就是指這一方面而言。關於金錢的本質 作用和功過，從古到今，人...
非技術問題彙總
1 您在前一家公司的離職原因是什麼？2 講一件你印象最深的一件事情 3 介紹乙個你影響最深的專案 4 介紹你最熱愛最擅長的專業領域 5 公司實習最大的收穫是什麼 6 與上級意見不一致時，你將怎麼辦 7 自己的優點和缺點是什麼？並舉例說明？8 你的學習方法是什麼樣的？實習過程中如何學習？實習專案中遇到...