建站
咨詢
售后
建站咨詢
新聞中心
說(shuō)到DevOps，很多人會(huì)把開(kāi)發(fā)和運(yùn)維聯(lián)系在一起，更準(zhǔn)確一點(diǎn)其實(shí)就是開(kāi)發(fā)運(yùn)營(yíng)的組合。
我們提供的服務(wù)有：成都網(wǎng)站制作、做網(wǎng)站、微信公眾號(hào)開(kāi)發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、魏縣ssl等。為超過(guò)千家企事業(yè)單位解決了網(wǎng)站和推廣的問(wèn)題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的魏縣網(wǎng)站制作公司
最近在發(fā)布關(guān)于DevOps的文章時(shí)，發(fā)現(xiàn)了一個(gè)很有趣的現(xiàn)象：在國(guó)外，很多博主都紛紛指責(zé)“DevOps”運(yùn)動(dòng)，越是受歡迎，他們就越是討厭，甚至排斥。
簡(jiǎn)單的總結(jié)一下DevOps讓其討厭的原因：
1. 沒(méi)有時(shí)間專心寫(xiě)代碼
2. 強(qiáng)迫開(kāi)發(fā)人員進(jìn)入一個(gè)龐大的知識(shí)領(lǐng)域（這里指就是需要成為一名“全?！遍_(kāi)發(fā)者）
3. 壓力大，任務(wù)重，不堪重負(fù)
事實(shí)是否這樣呢？其實(shí)不然。無(wú)論任何事物，存在即合理。再說(shuō)哪個(gè)公司都不會(huì)蠢到讓一個(gè)只會(huì)寫(xiě)代碼的開(kāi)發(fā)者去做QA，系統(tǒng)管理員或者DBA，所以我認(rèn)為不能歸到“DevOps”里面去。引用DevOps擁護(hù)者Jeff Roth的一句話，“專業(yè)知識(shí)、協(xié)作關(guān)系與知識(shí)共享之間需要找到合適的平衡點(diǎn)，只有這樣才能人盡其才、物盡其用?！?/p>
以上是對(duì)近期發(fā)布的一篇“DevOps是如何傷害一個(gè)開(kāi)發(fā)者的”文章不同的理解。下面綜合對(duì)IBMRational中國(guó)區(qū)技術(shù)總監(jiān)孫昕的采訪談?wù)勎覍?duì)DevOps的一些理解，歡迎提出意見(jiàn)，拍磚。
敏捷開(kāi)發(fā)
在剛了解DevOps不久的時(shí)候，我很自然的把它和敏捷開(kāi)發(fā)聯(lián)系在一起，認(rèn)為它們是集合的關(guān)系。在有機(jī)會(huì)和孫老師聊的時(shí)候，他并不認(rèn)為完全這樣，說(shuō)是集合關(guān)系是不完全準(zhǔn)確的，不過(guò)DevOps可以讓敏捷開(kāi)發(fā)做的更好。
怎么理解這句話呢，先說(shuō)說(shuō)下敏捷開(kāi)發(fā)，了解敏捷的人都知道現(xiàn)在做最多，也是做***的是Scrum，這是個(gè)流派。當(dāng)整個(gè)團(tuán)隊(duì)在做到一定的規(guī)模后，這時(shí)是非常依賴工具的。（因?yàn)閷?shí)施敏捷的時(shí)候不完全保證所有人員都能夠在一個(gè)地方，像那種大規(guī)模敏捷的時(shí)候，不可能把所有的人都擱置在一個(gè)小屋子里面，天天開(kāi)各種會(huì)議。像比較厲害的scrumsof scrums，我是這么理解的）。
這里有個(gè)問(wèn)題哈，當(dāng)Scrum在很大的程度上依賴工具的時(shí)候，其實(shí)很多問(wèn)題就出來(lái)了。大家都知道Scrum是一個(gè)迭代的過(guò)程，需要很多周期的迭代，不可能一次就搞定（那就不是Scrum了）。在這個(gè)迭代的過(guò)程，需要做溝通，做協(xié)調(diào)，做測(cè)試，做部署，發(fā)布等等，那么這些事情單單通過(guò)工具是否能夠完成呢？我覺(jué)得很困難。這個(gè)時(shí)候DevOps在這里能夠起到什么作用呢？回到剛才的觀點(diǎn)--加速敏捷的進(jìn)展。因?yàn)镈evOps可以利用云技術(shù)，自動(dòng)化部署，自動(dòng)化發(fā)布等技術(shù)。特別是測(cè)試，當(dāng)敏捷做到一定規(guī)模時(shí)候，需要跨部門(mén)，開(kāi)發(fā)人員可能會(huì)很主動(dòng)，有啥新功能要加進(jìn)去，運(yùn)維就不干了，很可能就會(huì)說(shuō)you can you up！
其實(shí)這個(gè)是能夠理解的，開(kāi)發(fā)人員把一個(gè)軟件版本丟給運(yùn)維人員后，其就會(huì)拿該版本產(chǎn)品開(kāi)始準(zhǔn)備將部署上線。這時(shí)有個(gè)問(wèn)題出來(lái)了，他們需要修改配置文件來(lái)適應(yīng)與開(kāi)發(fā)環(huán)境大不相同的真實(shí)生產(chǎn)環(huán)境。一般情況來(lái)說(shuō)他們是在重復(fù)之前在環(huán)境中已完成的部署工作；一旦出了問(wèn)題，他們很可能引入新的漏洞。
這就是他們所擔(dān)心的問(wèn)題，如果不反復(fù)的測(cè)試，運(yùn)維人員肯定不會(huì)上線。所以，DevOps的理念正好解決了這個(gè)問(wèn)題，但這僅僅是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è)過(guò)程，也就是只停留在研發(fā)這條工具生產(chǎn)線上，所以我們看到的軟件工程鏈條還是比較短的。DevOps概念出來(lái)了以后大家慢慢的發(fā)現(xiàn)，軟件工程現(xiàn)在前端部分已經(jīng)慢慢全新的領(lǐng)域，前端+傳統(tǒng)軟件工程+后端，無(wú)形的產(chǎn)生了一條很大的產(chǎn)業(yè)鏈，這就是我們現(xiàn)在說(shuō)的一個(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)品線工程。孫老師還舉例說(shuō)，“像華為等等一些大的企業(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í)候反過(guò)頭來(lái)看看傳統(tǒng)的軟件工程其實(shí)只是其中的一個(gè)環(huán)節(jié)，其實(shí)就是現(xiàn)在的業(yè)務(wù)需求越來(lái)越往前推了。這里也包含了傳統(tǒng)領(lǐng)域的產(chǎn)品管理，也就是大家常說(shuō)的項(xiàng)目管理，還有企業(yè)架構(gòu)，信息架構(gòu)，數(shù)據(jù)架構(gòu)，流程整合。當(dāng)知道你要做的哪些決策，投入到哪些大的IT項(xiàng)目，然后往你的業(yè)務(wù)部門(mén)，往你的終端用戶推了以后，把這些規(guī)劃好了以后需求就可以變成改軟件的實(shí)現(xiàn)，軟件才會(huì)有意義，這樣才能獲取你的需求來(lái)支持你的業(yè)務(wù)目標(biāo)。
孫老師在錄一段video的時(shí)候，講到中國(guó)食品安全時(shí)與整個(gè)大的產(chǎn)業(yè)鏈?zhǔn)敲懿豢煞值?，“?dāng)在做食品管理的時(shí)候，我們都在聚焦生產(chǎn)，比如造奶粉要看廠房有沒(méi)有無(wú)菌室，實(shí)際上食品安全管理的范疇已經(jīng)從原來(lái)擴(kuò)展的很大，原材料、運(yùn)輸過(guò)程、加工過(guò)程等是一個(gè)很大的產(chǎn)業(yè)鏈，僅僅管理一段是管不好的，其實(shí)軟件工程也一樣，我們認(rèn)為將來(lái)你的軟件跟你的運(yùn)維密不可分，頻度越快，運(yùn)維甩過(guò)來(lái)就會(huì)有問(wèn)題?！?/p>
所以，從純粹的軟件開(kāi)發(fā)上升到業(yè)務(wù)規(guī)劃，發(fā)布部署，還有上線的整個(gè)監(jiān)控，其實(shí)就是這樣，不管你認(rèn)為是概念也好，在整個(gè)過(guò)程中你是無(wú)法離開(kāi)這個(gè)產(chǎn)業(yè)鏈的。軟件工程現(xiàn)在前端部分已經(jīng)慢慢的涉及到了業(yè)務(wù)端，傳統(tǒng)的只是在研發(fā)這條工具的生產(chǎn)線上。
新角色的催生
目前來(lái)看我個(gè)人覺(jué)得是很難結(jié)合的，從前面談的業(yè)務(wù)線來(lái)看就很難。如果要改版一個(gè)傳統(tǒng)的組織架構(gòu)其實(shí)就是一個(gè)組織變革的問(wèn)題，這個(gè)跟DevOps沒(méi)有關(guān)系，不能說(shuō)我要使用DevOps就一定要把兩個(gè)部門(mén)給整合起來(lái)。
這個(gè)時(shí)候可能會(huì)有人問(wèn)，這個(gè)不是技術(shù)需要嗎？如果我把技術(shù)問(wèn)題給打通了，那么整合不成問(wèn)題了。其實(shí)組織變革跟技術(shù)是沒(méi)有太大關(guān)系的，并不是技術(shù)打通了就意味著兩者之間整合沒(méi)有了阻礙。反過(guò)來(lái)看，比如像一些比較成熟的企業(yè)，銀行，電信等，他們的組織架構(gòu)包含著研發(fā)中心，測(cè)試中心，運(yùn)維中心等的，組織架構(gòu)已經(jīng)是比較成熟，承擔(dān)的業(yè)務(wù)目標(biāo)更不可能只是從研發(fā)到運(yùn)維這兩者之間，雖然說(shuō)與技術(shù)之間尚存很大的隔閡，但這是需要時(shí)間來(lái)讓其在這些業(yè)務(wù)的邊界慢慢更好的整合在一起形成一條新的業(yè)務(wù)線。
組織變革往往也是一些新技術(shù)慢慢的改版，而這樣所導(dǎo)致的企業(yè)文化，工作習(xí)慣也會(huì)在新的角色定義中改變，進(jìn)而推進(jìn)組織變化。所以，在這種情況下，也可能會(huì)形成新的虛擬人員跨界的角色，更容易的去支撐整個(gè)業(yè)務(wù)。
分享文章：從DevOps業(yè)務(wù)談敏捷開(kāi)發(fā)、軟件工程及新角色
分享鏈接：http://www.5511xx.com/article/dpssiji.html
