DevOps的出現受到眾多的企業人士熱捧，每個人的引用也只是只言片語，真正了解的人極少。更多的只是單純從“研發團隊”與“運維團隊”之間的轉變談起。現在大家的關注慢慢從最開始的開發轉移到了狹義當中來講DevOps的概念或者方法論，特別是創業中的企業或者中小型企業紛紛效仿，慢慢的覺得這個概念很好，從自動化代替了大部分開發人力時，短期見效很快，然后開始量化。但是當更高的業務端去擴展的時候就會發現財力（新技術財力，新角色財力，工具購買財力等等）支撐不住，又開始去抱怨。當然，土豪公司除外。

[[87564]] 

在前段時間，IBM收購DevOp(開發與運營合作)解決方案提供商UrbanCode，如果從狹義的DevOps去定義UrbanCode這個領域，它實際上就是全球的NO.1，而在去年1月也收購了Greenhat公司，對其在測試領域中的DevOP概念形成了支持；再去年5月收購了Tealeaf公司，則是在反饋領域中加強了這種概念。那么這一連串的收購，IBM真正的目的是為了什么？小編認為，IBM真正的目的就是為了加快DevOps的落地，減少開發流程費用，把開發測試打通到運維發布端，穩固自己在軟件行業的競爭力。

這時候問題來了，中小企業和創業公司沒有那么大的財力支撐怎么辦？其實對于DevOps很多人理解不同，根據小編的理解以及對前段時間與IBM 大中華區技術總監 孫昕對DevOps交流的總結，給大家列出一二三，如有不同觀點歡迎共同探討。

DevOps為什么盛行

這個我們得從軟件工程開始說起，從軟件工程初期發展的獨立主義，那時候的軟件其實就是一個人獨立開發，從需求到開發到測試，都一個人完成。因此那時候的軟件很簡單，功能單一，所以一個人完全可以。當從90年代開始強調了軟件工程化至今完全進化成為一個產業鏈，軟件工程應是由最早的需求、架構設計、開發、測試、發布一個完整的過程進化的時候，這時孫昕談到了一個概念， 那就是ALM。如何去理解這個ALM？就是把你的軟件當成一個應用，這個應用就像人一樣，有出生到成熟到死亡。官方專業的說法就是應用程序生命周期管理。但是時代在進步，我們的需求越來越大，軟件的生產鏈條還要擴展，所以就是這次談的DevOps這個概念。

為什么這么說？

在任何公司里，開發一個軟件最終都是為了賺到錢，于是它有了大的商業規劃，產品的需求，才有軟件的開發這樣的一個流程。那么軟件再往上端走就直接到業務層，而軟件的下一端理所當然是運維了。為什么這么說？如果在金融業，電信業，一出問題不及時解決就是個災難。所以軟件往下走一定是運維，不斷產生缺陷不斷及時修復，所以現在的軟件工程鏈條變得非常長，這就是DevOps這么個概念。

DevOps為什么這幾年才開始提提及？用孫昕在IT客上的話說，就是有一個重要的技術瓶頸是這幾年才突破的，在前幾年一直在談的一個概念叫JAZZ，翻譯過來就是爵士樂，意思是需要協同起來才能奏出非常好的爵士樂。JAZZ的出現就是為了讓軟件真正的與底層全部打穿數據，讓數據在說話。在之前還沒有這個國際化標準的時候，但是今天我們能夠看到了希望。

JAZZ的出現對整個行業包括軟件，從業者等都會有著一定的改變。這個改變就是把程序員或者測試人員一直一來做的復雜且重復性的工作完全脫離出來，用更多的時間去做更有創造性的工作。小編記得孫昕說過這么一句話，如果沒有JAZZ提及出來，就不會有今天的DevOps真正的出現。（詳細請關注DevOps專題）

說到這里用一句話來感慨一下：軟件從業者本身就是一個藝術家，不停地用創意改變著世界。

“土豪”的本質

如果從上面來看你對DevOps的概念有了了解，那么DevOps到底是用來解決什么問題呢？是解決公司的技術問題還是業務問題？

剛剛也說了，軟件的上一端是業務端，任何一家企業開發軟件，其實目的就是為了賺到錢。雖然說技術也是DevOps中的關鍵部分，但是從DevOps本質來說就是個就是個業務問題。不解決業務如何賺錢？光靠技術當然是不行的。

那么這個業務的流程是怎么組成的呢？從DevOps的活動組成部分中分為兩種，第一是技術的驅動，第二是人為的驅動。比如說開發者，QA，架構，發布，安全，運維，其實都在這一流程中發揮了自己的作用。

無論是在傳統行業或者軟件研發這條工具生產線上做一些業務的規劃，我們叫做產品線工程（PRE），在這些產品線本身其實就受到很好的工程化管理。從規劃到實現，業務這部分已經占據了非常重要的地位。其實大家可以理解為項目管理，企業架構，數據架構，或者流程整合等等，做好哪些決策，投入到哪些大的項目中，這些都跟DevOps相關，實際上這些規劃好了以后需求才會變成業務往前推，這樣才能更好的獲取你的需求是來自于支撐你的業務目標，對市場的壓力做出快速，高效，經濟，可靠的變化能力。小編認為，如果把業務拋開去談DevOps，其實毫無意義。

也許有人會說，既然DevOps是業務流程的，為什么還要管它叫“DevOps”？

在早期，DevOps的出現就是為了解決開發與運維之間的問題，沒有指明DevOps到底真是的范圍，即使是解決問題到底多大，工程鏈條到底有多長。但是經過了在不斷的實踐過程中，大多的實踐者就認識到面對市場壓力的業務問題不解決，再怎么實踐DevOps都沒法真正意義上去解決企業上的問題。

所以要解決業務問題，我們就要從開發與運維兩者之間的文化開始說起，這兩者從誕生以來到現在已經存在著很大的沖突與脫節，每個企業的組織結構不同也會影響他們之間劃分程度。要解決兩者之間的脫節，所以你現在看到的談DevOps最多的就是如何改善部署問題上，這是一種合理的選擇。但是如果你說DevOps的出現就是為了改善部署問題那就是誤導別人了。

#p#

發掘“土豪”的共性

現在我們來談談DevOps的發展需要落實哪些事情，其實小編認為，新的話題出現都有一個共性特點，找到解決方案發展就越來越快。下面說3個共性：

1.標準流程統一化

回歸到上面概念講到應用程序生命周期管理，其實就是一個點對點的過程，那么在這個過程中不同階段采取什么樣的方法，這都需要建立起一套標準流程規范。這就得是國內外的土豪廠商們聯合起來規劃一個行業標準。

2.統一的工具使用

簡單的說，一個大的團隊，分布到世界各地的時候要做溝通和協調，你的第一反應是必須依賴工具，你必須花大量的金錢去購買工具，無論是利用云的技術，或者自動化部署，自動化發布，這都要依賴工具建立起來的橋梁下完成。

3.公司文化

我們都知道如果企業有心的技術出現，當你需要把其中某個部門合并了，那么他們之間就會造成很大的隔閡。這些隔閡可能會造成公司文化，工作習慣的改變，再者是一些角色的改變。如何讓他們慢慢的整合在一起形成一條業務線，這也是一件不易的事。總而言之，不改變企業文化，就別談DevOps。

所以，三者的依賴關系決定著企業實現DevOps的成敗關鍵。

認識DevOps的落地

說到落地才是本文的關鍵，但小編的理解甚少，所以這里更多的借用孫昕的話來表達。

一個新興技術或者方法的落地，其實我們不能用狹義的眼光去看它，廣義才是它真正的本意，也是最有說服力的。

從狹義方面去講的話其實DevOps已經落地，如果從廣義來講，目前DevOps還只是雛形。孫昕認為，落地現在主要是聚焦在開發和運維本身現在兩部分，其實現在就已經有非常多的企業做到了，當然這只能說是市場的成熟度。在國外，特別是美國很多地方其實都已經有很多大的應用案例，但是在國內，據孫昕所說，據他觀察，尤其是在國內的開發領域，我們經常比別人晚2-4年的時間。所以這就造成了為什么國外在實踐，國內開始談的局面。

想真正的落地你就要認識到：按時交付軟件產品和服務，開發和運營工作必須緊密合作，只有才能更快，更安全，更準確的推進公司的業務，這才是DevOps的過程。

愿景：

最后總結的話其實對于DevOps也不好說，我們就來說說對它的愿景吧。

我們之所以能看到軟件工程的將來，DevOps實際上就是軟件從事于行業下一代發展的一個未來。那么所有以軟件為驅動的創新將來是一個軟件爆炸的時代，同時DevOps也將會是解決當代大數據上的移動互聯，云計算轉型的關鍵，將會更加驅動很多創新來改變人類的生活。