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

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

簡單的總結一下DevOps讓其討厭的原因：

1. 沒有時間專心寫代碼

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

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

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

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

[[114006]] 

敏捷開發

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

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

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

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

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

傳統軟件工程

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

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

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

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

所以，從純粹的軟件開發上升到業務規劃，發布部署，還有上線的整個監控，其實就是這樣，不管你認為是概念也好，在整個過程中你是無法離開這個產業鏈的。軟件工程現在前端部分已經慢慢的涉及到了業務端，傳統的只是在研發這條工具的生產線上。

新角色的催生

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

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

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