說到DevOps，很多人會把開發(fā)和運維聯(lián)系在一起，更準確一點其實就是開發(fā)運營的組合。

最近在發(fā)布關(guān)于DevOps的文章時，發(fā)現(xiàn)了一個很有趣的現(xiàn)象：在國外，很多博主都紛紛指責“DevOps”運動，越是受歡迎，他們就越是討厭，甚至排斥。

簡單的總結(jié)一下DevOps讓其討厭的原因：

1. 沒有時間專心寫代碼

2. 強迫開發(fā)人員進入一個龐大的知識領(lǐng)域（這里指就是需要成為一名“全棧”開發(fā)者）

3. 壓力大，任務重，不堪重負

事實是否這樣呢？其實不然。無論任何事物，存在即合理。再說哪個公司都不會蠢到讓一個只會寫代碼的開發(fā)者去做QA，系統(tǒng)管理員或者DBA，所以我認為不能歸到“DevOps”里面去。引用DevOps擁護者Jeff Roth的一句話，“專業(yè)知識、協(xié)作關(guān)系與知識共享之間需要找到合適的平衡點，只有這樣才能人盡其才、物盡其用。”

以上是對近期發(fā)布的一篇“DevOps是如何傷害一個開發(fā)者的”文章不同的理解。下面綜合對IBMRational中國區(qū)技術(shù)總監(jiān)孫昕的采訪談談我對DevOps的一些理解，歡迎提出意見，拍磚。

[[114006]] 

敏捷開發(fā)

在剛了解DevOps不久的時候，我很自然的把它和敏捷開發(fā)聯(lián)系在一起，認為它們是集合的關(guān)系。在有機會和孫老師聊的時候，他并不認為完全這樣，說是集合關(guān)系是不完全準確的，不過DevOps可以讓敏捷開發(fā)做的更好。

怎么理解這句話呢，先說說下敏捷開發(fā)，了解敏捷的人都知道現(xiàn)在做最多，也是做***的是Scrum，這是個流派。當整個團隊在做到一定的規(guī)模后，這時是非常依賴工具的。（因為實施敏捷的時候不完全保證所有人員都能夠在一個地方，像那種大規(guī)模敏捷的時候，不可能把所有的人都擱置在一個小屋子里面，天天開各種會議。像比較厲害的scrumsof scrums，我是這么理解的）。

這里有個問題哈，當Scrum在很大的程度上依賴工具的時候，其實很多問題就出來了。大家都知道Scrum是一個迭代的過程，需要很多周期的迭代，不可能一次就搞定（那就不是Scrum了）。在這個迭代的過程，需要做溝通，做協(xié)調(diào)，做測試，做部署，發(fā)布等等，那么這些事情單單通過工具是否能夠完成呢？我覺得很困難。這個時候DevOps在這里能夠起到什么作用呢？回到剛才的觀點--加速敏捷的進展。因為DevOps可以利用云技術(shù)，自動化部署，自動化發(fā)布等技術(shù)。特別是測試，當敏捷做到一定規(guī)模時候，需要跨部門，開發(fā)人員可能會很主動，有啥新功能要加進去，運維就不干了，很可能就會說you can you up！

其實這個是能夠理解的，開發(fā)人員把一個軟件版本丟給運維人員后，其就會拿該版本產(chǎn)品開始準備將部署上線。這時有個問題出來了，他們需要修改配置文件來適應與開發(fā)環(huán)境大不相同的真實生產(chǎn)環(huán)境。一般情況來說他們是在重復之前在環(huán)境中已完成的部署工作；一旦出了問題，他們很可能引入新的漏洞。

這就是他們所擔心的問題，如果不反復的測試，運維人員肯定不會上線。所以，DevOps的理念正好解決了這個問題，但這僅僅是DevOps很小的一部分。如果再把敏捷往前推，業(yè)務管理，生命周期管理，監(jiān)控管理等等，需要擴張更大的時候，很大程度上都會依賴DevOps。兩者之間的關(guān)系就是，DevOps可以驅(qū)動敏捷加速周期，敏捷也能在某種意義上推廣DevOps。

傳統(tǒng)軟件工程

大家都應該知道傳統(tǒng)的軟件工程就是從需求-發(fā)布-測試這個過程，也就是只停留在研發(fā)這條工具生產(chǎn)線上，所以我們看到的軟件工程鏈條還是比較短的。DevOps概念出來了以后大家慢慢的發(fā)現(xiàn)，軟件工程現(xiàn)在前端部分已經(jīng)慢慢全新的領(lǐng)域，前端+傳統(tǒng)軟件工程+后端，無形的產(chǎn)生了一條很大的產(chǎn)業(yè)鏈，這就是我們現(xiàn)在說的一個全新的軟件工程。（PS：據(jù)我了解，現(xiàn)在很多企業(yè)都在招聘 軟件工程（DevOps方向）的崗位，很有趣。）

在軟件工程的前端方面，也可以稱為業(yè)務端吧，比如做業(yè)務規(guī)劃。那么產(chǎn)業(yè)鏈的后端負責什么呢？在和孫昕老師聊天的時候他強調(diào)的PRE（全稱應該是ProductLine Engineer）產(chǎn)品線工程。孫老師還舉例說，“像華為等等一些大的企業(yè)，它們不僅僅是在做軟件，它們所有的嵌入式軟件，機械設計，電氣設計，軟件設計的時候，這些大產(chǎn)品線的本身，其實就是受到很好的工程化管理，從規(guī)劃到實現(xiàn)，軟件在這個部分其實已經(jīng)占據(jù)非常重要的地位，你可以看到PRE當中非常強調(diào)的就是后端”。

所以在整個軟件的大框架下如何去支撐這些產(chǎn)品線的規(guī)劃？這時候反過頭來看看傳統(tǒng)的軟件工程其實只是其中的一個環(huán)節(jié)，其實就是現(xiàn)在的業(yè)務需求越來越往前推了。這里也包含了傳統(tǒng)領(lǐng)域的產(chǎn)品管理，也就是大家常說的項目管理，還有企業(yè)架構(gòu)，信息架構(gòu)，數(shù)據(jù)架構(gòu)，流程整合。當知道你要做的哪些決策，投入到哪些大的IT項目，然后往你的業(yè)務部門，往你的終端用戶推了以后，把這些規(guī)劃好了以后需求就可以變成改軟件的實現(xiàn)，軟件才會有意義，這樣才能獲取你的需求來支持你的業(yè)務目標。

孫老師在錄一段video的時候，講到中國食品安全時與整個大的產(chǎn)業(yè)鏈是密不可分的，“當在做食品管理的時候，我們都在聚焦生產(chǎn)，比如造奶粉要看廠房有沒有無菌室，實際上食品安全管理的范疇已經(jīng)從原來擴展的很大，原材料、運輸過程、加工過程等是一個很大的產(chǎn)業(yè)鏈，僅僅管理一段是管不好的，其實軟件工程也一樣，我們認為將來你的軟件跟你的運維密不可分，頻度越快，運維甩過來就會有問題。”

所以，從純粹的軟件開發(fā)上升到業(yè)務規(guī)劃，發(fā)布部署，還有上線的整個監(jiān)控，其實就是這樣，不管你認為是概念也好，在整個過程中你是無法離開這個產(chǎn)業(yè)鏈的。軟件工程現(xiàn)在前端部分已經(jīng)慢慢的涉及到了業(yè)務端，傳統(tǒng)的只是在研發(fā)這條工具的生產(chǎn)線上。

新角色的催生

目前來看我個人覺得是很難結(jié)合的，從前面談的業(yè)務線來看就很難。如果要改版一個傳統(tǒng)的組織架構(gòu)其實就是一個組織變革的問題，這個跟DevOps沒有關(guān)系，不能說我要使用DevOps就一定要把兩個部門給整合起來。

這個時候可能會有人問，這個不是技術(shù)需要嗎？如果我把技術(shù)問題給打通了，那么整合不成問題了。其實組織變革跟技術(shù)是沒有太大關(guān)系的，并不是技術(shù)打通了就意味著兩者之間整合沒有了阻礙。反過來看，比如像一些比較成熟的企業(yè)，銀行，電信等，他們的組織架構(gòu)包含著研發(fā)中心，測試中心，運維中心等的，組織架構(gòu)已經(jīng)是比較成熟，承擔的業(yè)務目標更不可能只是從研發(fā)到運維這兩者之間，雖然說與技術(shù)之間尚存很大的隔閡，但這是需要時間來讓其在這些業(yè)務的邊界慢慢更好的整合在一起形成一條新的業(yè)務線。

組織變革往往也是一些新技術(shù)慢慢的改版，而這樣所導致的企業(yè)文化，工作習慣也會在新的角色定義中改變，進而推進組織變化。所以，在這種情況下，也可能會形成新的虛擬人員跨界的角色，更容易的去支撐整個業(yè)務。