基于最近幾年從事與DevOps的相關(guān)實(shí)踐，對(duì)這篇文章的觀點(diǎn)深有體會(huì)，所以記錄在這里。加粗部分是我比較深有體會(huì)的，但是對(duì)于最后作者對(duì)于“運(yùn)維”有些悲觀，我有點(diǎn)不敢茍同，反而對(duì)于運(yùn)維的要求其實(shí)是更高了，”自動(dòng)化-容器化-集群-智能化“代替了傳統(tǒng)的“人肉”

1. DevOps 的本質(zhì)

DevOps從本質(zhì)來(lái)講只是倡導(dǎo)開(kāi)發(fā)運(yùn)維一體化的理念（MindSet）。這個(gè)理念的提出是為了解決很多企業(yè)面臨的轉(zhuǎn)型挑戰(zhàn)，也就是將業(yè)務(wù)數(shù)字化，并且縮短數(shù)字化業(yè)務(wù)上線的周期，快速試錯(cuò)，快速占領(lǐng)市場(chǎng)。

DevOps并沒(méi)有改變固有的軟件生命周期：需求，設(shè)計(jì)，開(kāi)發(fā)，測(cè)試，交付。但伴隨著基礎(chǔ)設(shè)施，軟件設(shè)計(jì)方法等的改變，軟件開(kāi)發(fā)的思路，或者方式產(chǎn)生了比較大的變化。

DevOps帶來(lái)的最大好處是，軟件生命周期數(shù)據(jù)鏈路的打通

這不僅僅是運(yùn)維和開(kāi)發(fā)的結(jié)合。從頂層視角看，這是業(yè)務(wù)和生產(chǎn)的緊密結(jié)合。以前從業(yè)務(wù)和開(kāi)發(fā)是脫節(jié)的。想要查看需求的實(shí)現(xiàn)進(jìn)度，需要大量的人工匯報(bào)，更別提運(yùn)營(yíng)了。而現(xiàn)在以一個(gè)微服務(wù)實(shí)現(xiàn)一個(gè)特性的粒度來(lái)看，可以從需求，開(kāi)發(fā)，測(cè)試，部署一直追溯到這個(gè)特性運(yùn)營(yíng)情況。這也是DevOps成為數(shù)字化企業(yè)基因的原因，業(yè)務(wù)和生產(chǎn)實(shí)現(xiàn)了完美的結(jié)合。

從敏捷實(shí)踐的角度來(lái)講，你會(huì)發(fā)現(xiàn)開(kāi)發(fā)組織中參與者好似生物體中的神經(jīng)元，大家各司其職，自成一體，接受反饋，并向外主動(dòng)反饋。團(tuán)隊(duì)的自組織使得工作更加自然，能產(chǎn)生更大的效能。由以前的項(xiàng)目經(jīng)理驅(qū)動(dòng)，改為自我驅(qū)動(dòng)的協(xié)作方式。每個(gè)人都可以給相關(guān)的團(tuán)隊(duì)以及責(zé)任人提需求，大家有機(jī)的協(xié)調(diào)在一起。

2. 一個(gè)DevOps改造案例

這里給大家分享一個(gè)改造案例，公司A存在的問(wèn)題：

1. 軟件交付周期很長(zhǎng)，一年只能交付一個(gè)大版本，以及一個(gè)小版本。
2. 人員分工不明確，一個(gè)決定的做出往往需要很多人參與。
3. 用大量的時(shí)間挖掘需求。在真正的開(kāi)發(fā)期，會(huì)發(fā)現(xiàn)用戶的需求仍在改變。需求分析的時(shí)間被浪費(fèi)。
4. 采用瀑布模式開(kāi)發(fā)，在不同時(shí)期，某些角色的人員會(huì)無(wú)事可做。
5. 在軟件交付過(guò)程中，開(kāi)發(fā)與運(yùn)維人員需要花費(fèi)大量的時(shí)間去協(xié)調(diào)產(chǎn)品安裝，配置中出現(xiàn)的問(wèn)題。

改造步驟：

• 第一階段：
  行動(dòng)：為了實(shí)行DevOps，公司A為不同的生命周期購(gòu)置了支撐工具，涵蓋JIRA, PagerDuty，GitHubEnterprise，Jenkins等。公司針對(duì)每個(gè)工具都進(jìn)行了專門培訓(xùn)，專人管理。

  結(jié)果：大家開(kāi)始將不同的工具應(yīng)用到軟件生產(chǎn)的各個(gè)環(huán)節(jié)中，統(tǒng)一的工具塑造了統(tǒng)一的工作方式，創(chuàng)造了工作契約。統(tǒng)一工具的運(yùn)用確實(shí)對(duì)軟件交付帶來(lái)了一些積極的改變。

• 第二階段：

  問(wèn)題：各個(gè)工具仍舊是割裂的，代碼管理和任務(wù)管理無(wú)法協(xié)調(diào)。開(kāi)發(fā)人員聲明已經(jīng)完成的工作，測(cè)試人員卻發(fā)現(xiàn)無(wú)法找到構(gòu)建來(lái)完成測(cè)試。運(yùn)維人員和開(kāi)發(fā)人員只是利用了同一種工具，而沒(méi)有做到工作產(chǎn)物的共享。

  行動(dòng)：公司A開(kāi)始關(guān)注工具所提供的能力而不是功能，將不同工具的關(guān)鍵交付物連接起來(lái)，形成可追溯的管理。開(kāi)發(fā)人員發(fā)現(xiàn)提交的代碼可以產(chǎn)生可用構(gòu)建后才聲明功能完成。并且用同一個(gè)任務(wù)來(lái)追溯開(kāi)發(fā)到上線的工作。尤在開(kāi)發(fā)與運(yùn)維結(jié)合方面，運(yùn)維人員可以利用開(kāi)發(fā)人員已經(jīng)實(shí)現(xiàn)的部署設(shè)計(jì)，進(jìn)行發(fā)布演練，確保軟件平滑交付。

• 第三階段：

  問(wèn)題：有了好的工具，但是公司A發(fā)現(xiàn)雖然開(kāi)發(fā)到運(yùn)維的路通了，但是軟件質(zhì)量卻難以保證，甚至在產(chǎn)品發(fā)布日期鄰近的時(shí)候，仍有很多未完成的任務(wù)，測(cè)試團(tuán)隊(duì)頂著很大的壓力，最終還是會(huì)發(fā)生不少測(cè)試逃逸，產(chǎn)品的技術(shù)欠債比較大。

  行動(dòng)：在開(kāi)發(fā)階段采取分支開(kāi)發(fā)的方法，功能實(shí)現(xiàn)并且通過(guò)一定的代碼測(cè)試之后才能合并到主干。開(kāi)發(fā)人員負(fù)責(zé)部分的測(cè)試任務(wù)，由于對(duì)產(chǎn)品比較熟悉，所以加快了測(cè)試效率。專門的測(cè)試團(tuán)隊(duì)會(huì)承擔(dān)例如性能測(cè)試等更加專業(yè)的測(cè)試任務(wù)。有節(jié)奏的控制軟件開(kāi)發(fā)的進(jìn)度，在軟件發(fā)布的穩(wěn)定期嚴(yán)格控制代碼提交，每個(gè)新功能的開(kāi)發(fā)負(fù)責(zé)人會(huì)和運(yùn)維人員一起進(jìn)行發(fā)布演練，DevOps的好處終于開(kāi)始見(jiàn)效。

• 第四階段：
  問(wèn)題：團(tuán)隊(duì)前期在需求分析中會(huì)花費(fèi)大量的時(shí)間進(jìn)行文檔編寫，但開(kāi)發(fā)開(kāi)始后，開(kāi)發(fā)人員會(huì)花費(fèi)大量的時(shí)間對(duì)文檔進(jìn)行理解，并且用戶對(duì)需求的調(diào)整最終導(dǎo)致文檔失去維護(hù)的意義；大家的主動(dòng)性不強(qiáng)，需要領(lǐng)導(dǎo)的督促才能進(jìn)行工作安排。

  行動(dòng)：公司A意識(shí)到他們之前只是采用看似敏捷的方式，實(shí)際瀑布的方式做開(kāi)發(fā)。比如說(shuō)項(xiàng)目經(jīng)理變成了Scrum主管，周會(huì)變成了每天的站會(huì)。在進(jìn)行調(diào)研分析后，公司A決定開(kāi)始進(jìn)行敏捷實(shí)踐。分階段的按照重要程度以及優(yōu)先級(jí)進(jìn)行需求規(guī)劃，周期性的互動(dòng)使得客戶在第一時(shí)間可以看到期望的需求被逐步實(shí)現(xiàn)，雙方都避免最后一科的意外。開(kāi)發(fā)人員發(fā)現(xiàn)可以對(duì)自己負(fù)責(zé)的任務(wù)有話語(yǔ)權(quán)之后，大大激發(fā)了積極性，大家開(kāi)始主動(dòng)的從Backlog中尋找重要的任務(wù)去實(shí)現(xiàn)。

從以上的例子可以看出，一個(gè)好工具的運(yùn)用會(huì)對(duì)工作產(chǎn)生積極的影響，但是更核心的是人做事思維，以及人與人之間的協(xié)作方式才會(huì)體現(xiàn)DevOps的好處，我想從這點(diǎn)大家可以看到為什么DevOps是一種Mindset。

3. 微服務(wù)、容器和DevOps的關(guān)系

微服務(wù)只是一種設(shè)計(jì)思路，或者說(shuō)他給出了如何用正確的方法來(lái)進(jìn)行SOA的實(shí)施。理論上來(lái)講他的確和DevOps沒(méi)什么關(guān)系，但是從如何實(shí)踐DevOps的角度來(lái)講，微服務(wù)是非常有意義的。此外，隨著諸如Spring Cloud以及微軟Fabric等SDK的完善，微服務(wù)開(kāi)發(fā)模式也逐步完善，實(shí)現(xiàn)了概念的落地

Docker可謂是一種敏捷化的虛擬化技術(shù)（較之虛擬機(jī)而言）。其實(shí)微軟Fabric或者CloudFoundry也都脫離開(kāi)容器的概念提供了微服務(wù)開(kāi)發(fā)的解決方案，所以這兩者并不是強(qiáng)綁定的關(guān)系。但是容器用不可變配置架構(gòu)實(shí)現(xiàn)了微服務(wù)從開(kāi)發(fā)到運(yùn)維的質(zhì)量保真度，這恰好解決了粒度小，數(shù)量多的微服務(wù)所帶來(lái)的運(yùn)維難題。再加上K8S，Swarm等容器云的支持，docker容器已經(jīng)形成了事實(shí)上的標(biāo)準(zhǔn)。

如何利用這個(gè)強(qiáng)大的運(yùn)行環(huán)境幫助企業(yè)敏捷，推進(jìn)業(yè)務(wù)數(shù)字化，并且加快業(yè)務(wù)的投產(chǎn)？ DevOps為上面所說(shuō)的開(kāi)發(fā)模式提供了軟件生產(chǎn)線。

所以總結(jié)的來(lái)講，企業(yè)業(yè)務(wù)敏捷是DevOps發(fā)展的直接推動(dòng)力，容器云，以及微服務(wù)為DevOps提供了技術(shù)可行性。而敏捷幫助提高DevOps工作效能。

對(duì)于團(tuán)隊(duì)的拆分，這個(gè)問(wèn)題真的要結(jié)合產(chǎn)品規(guī)模來(lái)看。團(tuán)隊(duì)的拆分有很多辦法，貝索斯說(shuō)的two pizza team，是建議一個(gè)團(tuán)隊(duì)中的人盡可能少，不要超過(guò)兩個(gè)Pizza能吃飽的規(guī)模。用敏捷實(shí)踐來(lái)講，可以分為多個(gè)特性團(tuán)隊(duì)，以及維護(hù)團(tuán)隊(duì)，不同的團(tuán)隊(duì)各司其職，合理分工。在我以前的實(shí)踐中，三個(gè)人可以做一個(gè)Feature，來(lái)交付一個(gè)月迭代的工作量。

當(dāng)然將原有的巨石應(yīng)用分割成更小的微服務(wù)是挑戰(zhàn)很大的事情。因?yàn)槔碚撋系奈⒎?wù)的設(shè)計(jì)對(duì)現(xiàn)有的團(tuán)隊(duì)組織結(jié)構(gòu)，以及工程師設(shè)計(jì)能力都帶來(lái)了一定的挑戰(zhàn)。有些組織按照DDD（領(lǐng)域驅(qū)動(dòng)的設(shè)計(jì)）的方式去實(shí)踐微服務(wù)，會(huì)發(fā)現(xiàn)以前一個(gè)應(yīng)用的復(fù)雜度變得很高，對(duì)項(xiàng)目管理來(lái)講也是一件頭疼的事情。現(xiàn)在有個(gè)比較新的看法就是，大家宣稱做微服務(wù)（MicroService）的時(shí)候，實(shí)際上做的是迷你服務(wù)（MiniService）。迷你服務(wù)的粒度較之微服務(wù)的粒度更粗一些，關(guān)注度由一個(gè)域Domain，變成了能力。一個(gè)迷你服務(wù)提供一種能力，這種能力的提供也許是跨越多個(gè)域的。

最好的方法是以一個(gè)團(tuán)隊(duì)能承擔(dān)的任務(wù)劃定微服務(wù)的界限比較好，這樣以來(lái)，不論是任務(wù)管理，代碼構(gòu)建，產(chǎn)品部署都會(huì)比較好做。

更關(guān)注服務(wù)的能力，這樣也會(huì)減少因?yàn)榭缬蚨鴰?lái)的復(fù)雜事物處理

4. 為什么落地DevOps還是那么難？

我認(rèn)為DevOps概念對(duì)市場(chǎng)的教育工作已經(jīng)完成了，并且它宣傳在國(guó)內(nèi)有點(diǎn)泛濫的趨勢(shì)，甚至一些以前做項(xiàng)目管理工具的廠商也宣傳他們?cè)谧鯠evOps。究其原因在于DevOps的概念太大，幾乎可以成為軟件工程的代名詞。

至于落地的痛點(diǎn)，我覺(jué)得有以下幾個(gè)：

1. DevOps對(duì)于組織來(lái)講是一個(gè)系統(tǒng)工程化的投入，在貫徹的過(guò)程中，需要一個(gè)組織建立標(biāo)準(zhǔn)，統(tǒng)一紀(jì)律，而這個(gè)過(guò)程往往需要組織中的強(qiáng)力部門自始至終的貫徹執(zhí)行。

2. DevOps對(duì)組織現(xiàn)存的管理方式，或者人員知識(shí)結(jié)構(gòu)多少帶來(lái)了一些挑戰(zhàn)。

3. 認(rèn)為購(gòu)置了工具就是DevOps，卻忽略了工具產(chǎn)物之間的聯(lián)系。

4. 認(rèn)為有了全生命周期的工具就是DevOps，忽略了軟件過(guò)程方法的運(yùn)用，所以很多組織停留在用舊的方法使用新的工具上。

開(kāi)啟DevOps工具和文化缺一不可。DevOps的最高目標(biāo)是讓組織內(nèi)的人都具有相同的工作理念，最終形成一種工作文化。而有些倡導(dǎo)者談到如何去培養(yǎng)這種文化就顯得有點(diǎn)空談了。我認(rèn)為在形成DevOps文化的過(guò)程中，敏捷實(shí)踐必不可少。過(guò)去的敏捷實(shí)踐更多的是在開(kāi)發(fā)階段，而現(xiàn)在DevOps的理念下，其實(shí)可以很順暢的將部署階段的事情也納入敏捷實(shí)踐中。讓合適的人去做合適的事。當(dāng)然團(tuán)隊(duì)文化的改變需要一個(gè)過(guò)程。

我認(rèn)為以敏捷方法為核心配合以下三個(gè)方面來(lái)開(kāi)啟DevOps。

• 看板：以任務(wù)的狀態(tài)為核心，管理在制品的生產(chǎn)情況。任務(wù)是自組織團(tuán)隊(duì)的工作契約。

• 基線：以工件的版本為核心，選取合格的交付物。比如說(shuō)開(kāi)發(fā)團(tuán)隊(duì)決定哪個(gè)代碼提交版本，或者編譯的構(gòu)建版本為最終交付的版本。度量指導(dǎo)基線的產(chǎn)生。

• 流水線：以生命周期的階段為核心，控制基線交付物的投產(chǎn)。比如說(shuō)一個(gè)合格的代碼基線目前處于編譯態(tài)，還是部署態(tài)。自動(dòng)化工具圍繞管道互相集成。

其實(shí)工具和文化最終的落實(shí)還是要靠人的提高，特別是通過(guò)上一段舉出的例子。

DevOps會(huì)重新塑造IT組織的研發(fā)系統(tǒng)，從工具到文化，再到方法。因此參與這個(gè)生態(tài)系統(tǒng)的所有人都應(yīng)該關(guān)注。

• 從開(kāi)發(fā)的角度看：開(kāi)發(fā)人員會(huì)變得更加業(yè)務(wù)化，有更多的機(jī)會(huì)和客戶交流。開(kāi)發(fā)人員將從以前對(duì)代碼負(fù)責(zé)，轉(zhuǎn)向編譯構(gòu)建負(fù)責(zé)，對(duì)測(cè)試負(fù)責(zé)，甚至對(duì)部署物負(fù)責(zé)。敏捷可以讓需求足夠的小，這樣就可以讓一個(gè)開(kāi)發(fā)人員變得全生命周期化了。

• 從運(yùn)維的角度看：其實(shí)運(yùn)維的前景是有些悲觀了，至少運(yùn)維的規(guī)模要縮減很多。

  原因有三。首先，自動(dòng)化部署工具的發(fā)展，使得部署工作提前了，以前碎片化的腳本，被更加規(guī)范化的部署設(shè)計(jì)代替，用設(shè)計(jì)驅(qū)動(dòng)腳本生成，這都是自動(dòng)化的。其次，基礎(chǔ)環(huán)境的改善使得開(kāi)發(fā)環(huán)境和生產(chǎn)環(huán)境的差異性極大縮小了，企業(yè)完全可以制造一個(gè)和生產(chǎn)環(huán)境一樣的預(yù)發(fā)環(huán)境，來(lái)保證交付的成功率。容器技術(shù)的不可變配置也保證了同樣的鏡像在不同的環(huán)境中不會(huì)出現(xiàn)太大的差異。最后，運(yùn)維工作相對(duì)開(kāi)發(fā)工作來(lái)講，可以自動(dòng)化，甚至運(yùn)用人工智能的空間都比較大。我們已經(jīng)看到百度已經(jīng)開(kāi)始AIOps。