近兩年來DEVOPS如雨後春筍一樣冒了出來，很多運維人都或多或少聽過這個詞，今天我將我聽到的看到的給各位講一下，也便於各位在今後的運維工作中評估和思考.

這篇文章是我根據理解和一些經歷所得，有不當之處還請見諒。看完此篇你會了解到以下幾個問題：

什麼是DEVOPS?

誰在關注它？

它和IT運維到底有什麼關係，運維需要了解它嗎？它的錢景如何？

DEVOPS的現在與未來

一、DEVOPS是什麼？

Devops，顧名思義，就是development & operations,

• 它是一種方法，讓企業內部如何高效的將開發運維連接在一起的橋樑。

• 它體現的是效率，它的方法論能將程序員和IT人緊密鏈接在一起提高工作效率。

• 它關注的是工作流程、企業文化、效率工具，而技術並不是它關注的方向。

更形象的解釋看wiki

devops

可以把DevOps看作開發（軟件工程）、技術運營和質量保障（QA）三者的交集.

這裡面提到了3個公司部門，研發部、質量管理部、IT部，其實就這3個部門的協同互通，3者緊密結合提高工作效率，通過自動化軟件交付、架構變更的來實現構建、測試、軟件發佈等的快捷、頻繁、可靠。

這裡補充一下開發環境痛點，其實很多搞開發的人都知道，無論軟件、硬件平臺，任何一個產品開發需要很多部門的協作。至少應該是這樣的：項目立項，研發需求架構，彙總IT資源-提交給IT，IT部署開發環境，軟件進入開發初期，配置管理員進行代碼結構構建，產品測試，產品發佈，QA審核....這其中不是一個部門環節處理完畢就結束自己工作的，開發過程中，需求不斷的調整變更，IT環境需求也在變化，這種協作的模式通過規範和流程很多時候可以提升一定的效率，但過程中會產生很多扯皮、推卸責任、任務停滯、環境考慮不全等等一系列問題；畢竟絕大多數都是“各掃門前雪“的思維，很少有人顧及其它部門門口的問題，畢竟非分內事其它部門的事無暇顧及，所以給企業帶來一系列的產品發佈週期長、項目Delay等等業務問題。

---這種環境情況下，DEVOPS出現了，其實早在2009年就有，但當時太理想化了，時機不成熟，即使現在想想都不現實，你讓QA\IT\DEVELOPMENT各抽調幾人組成這樣的部門，來處理統一項目管理、協同軟件交付這樣的工作，這樣組織結構的組建想想都一腦袋包。

2016年DEVOPS調查顯示：採用DEVOPS的高效公司平均每年1460次部署，比沒有采用DEVOPS公司相比：高效公司的不是頻繁200倍，產品投入使用快2555倍，服務恢復速度快24倍。

--由此可見這DEVEOPS的潛力。。

二、誰在關注它或推動它？

很多公司都在研究它實踐它，像IBM\REDHAT\AWS\GOOGLE，其實簡單來說Devops它就是前些年提到的敏捷開發的發展和演變；

IBM

IBM是在做DEVOPS流程和文化的梳理，從而推動自身的軟件及加工。

AWS

AWS是利用雲加速DEVOPS的實施，目的還是推動雲產品。

Google,

google創造了一個職位，SRE,Google SRE負責生產運維，管理著全球上百萬臺服務器和上面數不清的應用，他們的一舉一動都會影響全球千百萬用戶。其實這幫人乾的就是DEVOPS的工作。

還有前天聽了個講座，京東部署了15萬的Docker，只有2-3個人運維5000多個應用。如果沒有這種Devops理念的深入想想這種運維工作量都是不可完成的任務。

三、Devops它和IT運維到底有什麼關係，做運維需要了解它嗎？

理論來講，IT運維，也就是說DEVOPS中的Opration角色其實只能說它包含運維,它應該算是開發中的運維，運維中的開發，開發的角色更重一些。IT運維精通powershell/python/shell在運維圈裡已經算是人才了，但DEVOPS對opration的職位要求更高，我們看一個DEVOPS工程師的招聘需求吧。

估計有的人看到這，啥也不說了，這不僅僅是運維了，這是配置管理員、研發的合併要求，有機會各位可以在招聘網站看看。

51job招聘devops的又700多條，看似不多，其實也能看出一個趨勢，很多公司已經開始重視DEVOPS,無論它是為了解決自身問題還是客戶問題，這個devops的發展大方向是美好的；並且國內外很多培訓機構已經開始著手佈局。

市場錢景？那是相當不錯，就上面那個把3年以上工作經驗月薪30K。所以這麼有錢景的工作，IT運維能不關注嗎？

看到這，很多人看到“開發技能”這條就退縮了；同是計算機專業畢業的為啥有的人做開發，有的只能幹運維，為什麼？因為多數幹運維的選擇運維的原因就是不愛做開發。（現在很多非專業的也搞運維了，我遇到過採礦專業、化工專業、醫藥專業，總之運維這行入門門檻畢竟要比開發低很多）

看到千萬不要退縮，你之所以怕它的開發難度，是你還沒有真正瞭解DEVOPS的核心思想。

devops的核心思想

DEVOPS的核心思想：自動化、信息透明、文化。目的就是持續改進的工作，目的減少不必要的資源浪費和重複性工作。（虛擬機模板，docker應用其實也是這個思想）

這裡文化我不去說，我只說這裡的和IT相關的自動化和通明度；自動化就是自動化運維工具，puppet/ansible(我之前的文章有介紹過，有興趣可以看看）/chef等等，透明度指的是監控，nagios/cacti/icinga(之前我也介紹過），看到這是不是有信心了。

這些雖然是IT運維的領域，只不過要求高了，在Devops裡已經不再是簡單的操作，因為DEVOPS最重要的要求就是快，要求你對這些技能的熟悉程度是精通的級別；而且你要會git/svn/jekins,也許你還要學學docker。最加分的是如果你之前是開發對開發流程很熟悉，那再有一定的運維經驗，像你這樣的經驗不去搞Devops豈不是白瞎了。

四、DEVOPS現在和未來

IBM曾在白皮書中說了DEVOPS十個誤區，其實你可以理解為下面提到的不是不可實現，只是有的領域做的並不好有難度，需要靈活的看待它。

devops的誤區

從看到的聽到的市場看，很多互聯網公司都已在佈局，但總是不溫不火的鳥樣子，但這東西就像ITIL推行多年，Itil看上去已經很成熟了，但有多少公司又真正完全按照ITIL的指導做呢？Itil強調的流程管理有時限制了效率，而Devops你只要把握快、穩、準即可，流程都是為它而變的。

DEVOPS現狀

devops--盲人摸象

就像盲人摸象：每個人或部門或公司都在摸索中，她的投入產出比到底多大沒有一個明確的標準，只要業務滿意度高了，那TCO就算超標了。

DEVOPS的未來

就像中國功夫，招式套路變化多端，關鍵是每一種功夫都有它的自有特色。

devops&功夫

總之，Devops的方法及工具都是為業務服務的，快節奏的社會需要快節奏的思想和方法，快節奏的思想需要快速的步伐，快速的同時還要保質保量；就像這表的時間一樣，準確的背後其實是各個零部件的團體協作。

協作

最後想說的還是那句老話，火的東西不一定適合你。對於公司來講，即使你看到DEVOPS的好處想要引入此方法，也需要仔細評估的，你的公司文化是否可以接納它；對於個人來講，市場上賺錢的技術多樣，每種技術花少量時間看看，結合到自己的工作場景，沒準哪天你就成為你公司Devops的佈道者。

給所有看此篇的IT人一句話，加油，距離2018年還有262天。

如有興趣請關注頭條號：it老炮兒