為什么大廠一定要用DevOps？

目前很多大廠如阿里、騰訊、百度、頭條、滴滴、美團(tuán)等公司內(nèi)部都在做DevOps，那么DevOps是什么？為什么大廠都對(duì)其趨之若鶩？DevOps應(yīng)該怎么做？

首先我們來(lái)講講DevOps是什么？

DevOPs是一種方法論。DevOps=Developers+Operators，即開發(fā)團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)一體化，盡可能的為公司創(chuàng)造更多價(jià)值。

現(xiàn)在流行的做法是將兩個(gè)職能部門的人融合為一個(gè)職能部門，實(shí)現(xiàn)開發(fā)運(yùn)維一體化，而早期的時(shí)候是兩波人分別承擔(dān)不同的職能，中期的時(shí)候是要求兩波人密切配合、快速迭代，這中間的變化取決于開發(fā)模式的轉(zhuǎn)變。

早期的時(shí)候是瀑布開發(fā)模型。因?yàn)榛ヂ?lián)網(wǎng)上涌入的網(wǎng)民還不多，大家的關(guān)注點(diǎn)是能用、能解決問(wèn)題即可，所以早期在需求評(píng)審階段產(chǎn)品經(jīng)理給到的是完整、清晰、固定的需求，研發(fā)人員只需要根據(jù)需求在約定的時(shí)間點(diǎn)進(jìn)行交差即可，迭代的頻率或許是1月1次，也或許是1個(gè)季度1次，研發(fā)聚焦于功能開發(fā)，在功能開發(fā)完成后交付測(cè)試團(tuán)隊(duì)進(jìn)行測(cè)試，測(cè)試團(tuán)隊(duì)經(jīng)過(guò)反復(fù)的測(cè)試與問(wèn)題修復(fù)后，交付運(yùn)維團(tuán)隊(duì)進(jìn)行上線，此后生產(chǎn)環(huán)境的可用性穩(wěn)定性等工作全由運(yùn)維負(fù)責(zé)。

這種開發(fā)模式存在的問(wèn)題是需求不能快速得到驗(yàn)證，很有可能團(tuán)隊(duì)花費(fèi)半年的時(shí)間開發(fā)出來(lái)的東西早已經(jīng)不適合市場(chǎng)了，也還有種可能是在開發(fā)階段研發(fā)需求理解不到位，等到后期驗(yàn)證時(shí)發(fā)現(xiàn)有問(wèn)題再去做調(diào)整耽誤整體工期。

中期的時(shí)候是敏捷開發(fā)模型。因?yàn)榛ヂ?lián)網(wǎng)上涌入的網(wǎng)民開始增多，大家的關(guān)注點(diǎn)開始變成好用、好玩，而此時(shí)一些有遠(yuǎn)見(jiàn)的人開始注意到互聯(lián)網(wǎng)紅利，投身于互聯(lián)網(wǎng)，此時(shí)的開發(fā)模式演變成了敏捷開發(fā)模型。

敏捷開發(fā)模型面對(duì)的是頻繁的需求變化，要求快速開發(fā)。比較流行的實(shí)際案例則是Scrum、XP極限編程。在新迭代（一般2-6周）開始前，產(chǎn)品經(jīng)理將需求拆分成具體的開發(fā)任務(wù)，研發(fā)人員進(jìn)行任務(wù)認(rèn)領(lǐng)，每日站會(huì)進(jìn)行任務(wù)的review，直到開發(fā)完成，發(fā)布新的可用版本。

現(xiàn)在最流行的是DevOps。因?yàn)榛ヂ?lián)網(wǎng)上涌入的網(wǎng)民在海量的增加（微信用戶已破11億），互聯(lián)網(wǎng)企業(yè)的競(jìng)爭(zhēng)也開始變得激烈，同一塊蛋糕很多人來(lái)?yè)寔?lái)分（電商領(lǐng)域的淘寶、京東、網(wǎng)易嚴(yán)選、拼多多、小鵝拼拼等），快速迭代產(chǎn)品，快速占領(lǐng)市場(chǎng)，快速占據(jù)用戶心智成為了各互聯(lián)網(wǎng)公司的目標(biāo)，此時(shí)的開發(fā)模型變成了DevOps，需要持續(xù)開發(fā)、持續(xù)集成、持續(xù)測(cè)試、持續(xù)部署、持續(xù)監(jiān)控，每一次代碼的改動(dòng)都觸發(fā)一次校驗(yàn)，每天每時(shí)每刻都可進(jìn)行新版本的上線。

那么DevOps應(yīng)該怎么做呢？因?yàn)樯婕暗秸麄€(gè)軟件開發(fā)的生命周期，而軟件的起點(diǎn)之一便是代碼，所以常見(jiàn)的實(shí)現(xiàn)做法是從代碼倉(cāng)庫(kù)視角入手（如Gitlab），研發(fā)人員從版本控制系統(tǒng)中拉取代碼倉(cāng)庫(kù)，進(jìn)行新版本的開發(fā)，功能開發(fā)完成之后，提交代碼合并請(qǐng)求MergeRequest，在合并請(qǐng)求中通過(guò)gitlab.ci的yaml文件編寫去觸發(fā)CI校驗(yàn)，如代碼規(guī)范檢查、代碼安全檢查、單元測(cè)試等，CI校驗(yàn)通過(guò)之后進(jìn)行代碼合并到主干分支，觸發(fā)代碼編譯、打包、部署流程，將生成的產(chǎn)物如鏡像部署在預(yù)發(fā)布環(huán)境的物理機(jī)、虛擬機(jī)、容器中，經(jīng)過(guò)小部分用戶校驗(yàn)沒(méi)問(wèn)題后再大范圍甚至全量發(fā)布。

而有的做法則是以整個(gè)服務(wù)的視覺(jué)來(lái)看待整個(gè)軟件生命周期，通過(guò)流水線將開發(fā)的代碼、合并代碼、單元測(cè)試、編譯打包、部署、集成測(cè)試、灰度發(fā)布、上線發(fā)布全串聯(lián)起來(lái)。研發(fā)人員從代碼倉(cāng)庫(kù)拉取開發(fā)分支進(jìn)行開發(fā)，開發(fā)完成后通過(guò)流水線發(fā)起合并測(cè)試部署上線流程，其它的代碼合并功能、編譯、部署、單元測(cè)試、集成測(cè)試、灰度發(fā)布、上線發(fā)布全都是其它組件以底層的能力在去做支撐。

總體來(lái)看，在人力成本如此之高、市場(chǎng)競(jìng)爭(zhēng)如此之激烈、用戶需求變化如此之頻繁的情況下，DevOps是大廠必須選用的一條路。

目前DevOps已日趨激烈成熟，阿里的云效、騰訊工蜂等產(chǎn)品不僅內(nèi)部自用，而且已在公有云部署發(fā)布，越來(lái)越多的傳統(tǒng)企業(yè)和新創(chuàng)企業(yè)也開始接受并實(shí)施DevOps，DevOps工程師也成為當(dāng)下最炙手可熱的崗位之一，對(duì)DevOps你心動(dòng)了嗎？心動(dòng)就趕快行動(dòng)吧～