說到DevOps，很多人會(huì)把開發(fā)和運(yùn)維聯(lián)系在一起，更準(zhǔn)確一點(diǎn)其實(shí)就是開發(fā)運(yùn)營(yíng)的組合。

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

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

1. 沒有時(shí)間專心寫代碼

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

3. 壓力大，任務(wù)重，不堪重負(fù)

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

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

[[114006]] 

敏捷開發(fā)

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

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

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

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

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

傳統(tǒng)軟件工程

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

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

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

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

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

新角色的催生

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

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

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