分享人：鄭云龍

時(shí)間：2017-1-17

 

睿云智合持續(xù)交付產(chǎn)品負(fù)責(zé)人，在敏捷和DevOps領(lǐng)域有豐富經(jīng)驗(yàn)的實(shí)踐，過去作為敏捷和DevOps技術(shù)教練向多家大型企業(yè)提供咨詢和培訓(xùn)服務(wù)。

 

虛擬化，容器化，云計(jì)算，自動(dòng)化為DevOps運(yùn)動(dòng)提供了底層技術(shù)支持，新的工具鏈和技術(shù)棧的采用進(jìn)一步降低了DevOps的技術(shù)門檻，越來越多的企業(yè)紛紛開始自己的DevOps轉(zhuǎn)型之路，然而……

? DevOps以及企業(yè)DevOps轉(zhuǎn)型的現(xiàn)狀

? 為什么我們需要在DevOps轉(zhuǎn)型中強(qiáng)調(diào)度量

? 如何實(shí)現(xiàn)度量驅(qū)動(dòng)的DevOps轉(zhuǎn)型

? DevOps轉(zhuǎn)型中的其它實(shí)踐

 

 

Wiki上講：DevOps（Development和Operations的組合詞）是一種重視“軟件開發(fā)人員（Dev）”和“IT運(yùn)維技術(shù)人員（Ops）”之間溝通合作的文化、運(yùn)動(dòng)或慣例?（這個(gè)是目標(biāo)）透過自動(dòng)化“軟件交付”和“架構(gòu)變更”的流程（這個(gè)是方法）來使得構(gòu)建、測試、發(fā)布軟件能夠更加地快捷、頻繁和可靠（這是結(jié)果）。

所以對(duì)于企業(yè)來說的真正價(jià)值則在于通過團(tuán)隊(duì)間協(xié)作關(guān)系的改善，?整個(gè)組織效率的提升的同時(shí)，可以有效降低伴隨頻繁變化而帶來的生產(chǎn)環(huán)境風(fēng)險(xiǎn)，從而提升企業(yè)應(yīng)對(duì)市場變化響應(yīng)力。

 

根據(jù)2016 DevOps調(diào)查報(bào)告顯示。成功實(shí)施DevOps組織可以更快的去適應(yīng)整個(gè)市場環(huán)境的變化，同時(shí)能夠更快的做出調(diào)整。

擁有相比競爭對(duì)手擁有更加高的部署頻率，更快的故障恢復(fù)時(shí)間，更低的變更失敗率以及以及更短的需求交付周期。

 

 

然后當(dāng)企業(yè)大量的采納并使用這些新的工具鏈之后，我們并沒有看到我們所交付的軟件真的如同DevOps的目標(biāo)一樣，能夠真正的實(shí)現(xiàn)軟件快捷，頻繁并且可靠的交付。

 

 

DevOps不是盲目的使用新的工具鏈和技術(shù)棧，通過自動(dòng)化部署流水線的方式，將低質(zhì)量的代碼頻繁的部署到運(yùn)行環(huán)境。

目前實(shí)施DevOps轉(zhuǎn)型的傳統(tǒng)企業(yè)，通過引入自動(dòng)化確實(shí)能提升在軟件交付的某些環(huán)節(jié)中的效率，但是卻很難去提升軟件的交付質(zhì)量，依然引入獨(dú)立的測試部門進(jìn)行大量的系統(tǒng)測試來確保軟件的質(zhì)量，同時(shí)企業(yè)也很難度量持續(xù)交付和DevOps實(shí)施的效果。

所以目前大部分企業(yè)基本上是把自動(dòng)化當(dāng)做DevOps在做，把自動(dòng)化部署當(dāng)做持續(xù)交付在做，而很少去考慮軟件交付流程的整體性優(yōu)化。

自動(dòng)化是實(shí)施DevOps的先決條件但是并不能真正的幫助企業(yè)跨越DevOps轉(zhuǎn)型的鴻溝的銀彈。

 

 

而對(duì)于DevOps的成功轉(zhuǎn)型而言，我們需要做的是持續(xù)的對(duì)我們的軟件交付過程進(jìn)行優(yōu)化，發(fā)現(xiàn)軟件交付過程各個(gè)環(huán)節(jié)中存在的瓶頸并持續(xù)改進(jìn)。

 

 

 

You Can’t Fixed What You Can’t.

而數(shù)據(jù)和度量則是幫助企業(yè)去發(fā)現(xiàn)DevOps轉(zhuǎn)型過程中的瓶頸并且做出改進(jìn)的關(guān)鍵基礎(chǔ)。

 

 

在開始時(shí)我們說從Wiki上看，DevOps會(huì)主要設(shè)計(jì)到3個(gè)部分：目標(biāo)，方法和結(jié)果。

所以從度量的交付上看我們需要從兩個(gè)方面去度量我們的DevOps轉(zhuǎn)型。哪些度量指標(biāo)是能夠支撐企業(yè)判定DevOps轉(zhuǎn)型結(jié)果。而哪些是能夠去評(píng)判軟件的交付過程，并且用于發(fā)現(xiàn)交付瓶頸的。

 

 

根據(jù)2016DevOps報(bào)告顯示，目前度量企業(yè)DevOps轉(zhuǎn)型是否成功的最終結(jié)果性關(guān)鍵指標(biāo)包括：

吞吐量指標(biāo)：部署頻率，變更交付周期。

穩(wěn)定性指標(biāo)：變更失敗率，問題平均恢復(fù)時(shí)長（mean time to recover）。

吞吐量即敏捷性，確保企業(yè)能夠適應(yīng)市場的變化，并且快速做出反饋。穩(wěn)定性，即高質(zhì)量。

 

 

相比于傳統(tǒng)的IT服務(wù)流程績效指標(biāo)ITIL而言，DevOps更加關(guān)注結(jié)果性指標(biāo)，?即客戶價(jià)值。

就好比我們做軟件交付和外賣小哥其實(shí)很像，可以評(píng)價(jià)一個(gè)產(chǎn)品是否優(yōu)秀更多的是看交付效率如何，質(zhì)量如何，并且是不是能夠滿足我的預(yù)期的？

這兩種截然不同的度量方式本質(zhì)就是OKR和KPI的區(qū)別：

OKR基于目標(biāo)和關(guān)鍵成果，促使我們思考，溝通，每個(gè)人都知道什么是最重要的；并且能讓團(tuán)隊(duì)所有人共同的為某件事而努力。

所以對(duì)于基于OKR驅(qū)動(dòng)的DevOps可以確保參與軟件交付過程中的所以角色圍繞具有通過的目標(biāo)，并且為了這些共同目標(biāo)去嘗試新的技術(shù)和方法。

而KPI理論則避免按照SMART標(biāo)準(zhǔn)制訂，有些事情值得去做，但在做出來一部分之前無法測量因此無法制訂目標(biāo)。KPI 還有一個(gè)更嚴(yán)重的問題，那就是為了完成可測量的目標(biāo)，有可能實(shí)際執(zhí)行手段與該目標(biāo)要達(dá)到的愿景正好相反。

KPI使得團(tuán)隊(duì)使勁往前走，而OKR則確保團(tuán)隊(duì)能夠往正確的方向走。而在軟件交付過程中，開發(fā)，測試，運(yùn)維都有著不同的考核標(biāo)準(zhǔn)。所以KPI能夠團(tuán)隊(duì)各個(gè)成員使勁的按照各自的目標(biāo)走，而OKR則確保團(tuán)隊(duì)能夠一起往正確的方向走。

DevOps需要的是整體性的優(yōu)化，當(dāng)你選擇自己企業(yè)內(nèi)部的度量標(biāo)準(zhǔn)時(shí)，請(qǐng)問自己兩個(gè)問題：

為什么需要度量這個(gè)指標(biāo)？從這個(gè)指標(biāo)中我們能學(xué)到什么？

 

 

 

 

根據(jù)DevOps 2016報(bào)告高效的IT組織與中等和低效的IT組織之間在DevOps最終結(jié)果性關(guān)鍵指標(biāo)存在則顯著的差異。

DevOps的最終結(jié)果性指標(biāo)能夠幫助企業(yè)去衡量和評(píng)判DevOps轉(zhuǎn)型的結(jié)果。

 

 

當(dāng)然除了結(jié)果性的指標(biāo)去驗(yàn)證DevOps轉(zhuǎn)型所起到的作用以外，我們還需要持續(xù)的度量其他的數(shù)據(jù)去幫助我們發(fā)現(xiàn)在軟件交付各個(gè)階段的問題。

包括從需求管理，源碼管理，構(gòu)建過程，測試過程，部署過程，發(fā)布，配置管理，監(jiān)控等各個(gè)方面，這里我們列舉了在各個(gè)過程當(dāng)中可能需要的一些度量數(shù)據(jù)。

其中比較典型的包括通過對(duì)需求管理進(jìn)行度量，我們可以知道從需求到需求部署上線的變更交付時(shí)間。

在CI過程中我們持續(xù)的去獲取相關(guān)的過程數(shù)據(jù)，如構(gòu)建次數(shù)，構(gòu)建頻率，構(gòu)建時(shí)長，成功率，平均恢復(fù)時(shí)間等可以幫助團(tuán)隊(duì)去判定研發(fā)團(tuán)隊(duì)是否能夠做到小步提交，頻繁提交，并且當(dāng)發(fā)現(xiàn)問題之后能夠快速的恢復(fù)。

除此之外，低質(zhì)量的，高復(fù)雜度的代碼也會(huì)使得軟件交付效率無法得到有效提升，所以我們需要持續(xù)的獲取代碼質(zhì)量相關(guān)的數(shù)據(jù)，持續(xù)改進(jìn)代碼質(zhì)量等等。

 

 

所以對(duì)于度量驅(qū)動(dòng)的DevOps轉(zhuǎn)型而言，我們需要持續(xù)的去獲取在軟件交付各個(gè)階段所產(chǎn)生的數(shù)據(jù)，以及軟件部署上線之后的監(jiān)控?cái)?shù)據(jù)，用戶行為數(shù)據(jù)等，并且形成對(duì)團(tuán)隊(duì)所有人可見的DevOps可視化看板。

而產(chǎn)品/需求管理人員，則可以根據(jù)DevOps結(jié)果性數(shù)據(jù)去評(píng)價(jià)在過去一段時(shí)間內(nèi)DevOps實(shí)施所產(chǎn)生的效果，從過程性數(shù)據(jù)中去發(fā)現(xiàn)交付過程中的瓶頸，根據(jù)用數(shù)據(jù)以及線上監(jiān)控?cái)?shù)據(jù)去評(píng)價(jià)軟件產(chǎn)品是否如預(yù)期的一樣產(chǎn)生相應(yīng)的價(jià)值，如果沒有，是否應(yīng)該做出及時(shí)的調(diào)整。

除了通過自動(dòng)化的方式去構(gòu)建軟件交付的端到端流程提升軟件交付，并且持續(xù)的獲取軟件交付的各個(gè)階段所產(chǎn)生的數(shù)據(jù)以外。

我們還應(yīng)該在軟件交付流程中去設(shè)置相應(yīng)的門禁機(jī)制，去讓不滿足質(zhì)量要求的構(gòu)建快速失敗。

 

 

在實(shí)踐當(dāng)中，根據(jù)軟件產(chǎn)品的體量的不同完整運(yùn)行端到端自動(dòng)化的過程可能會(huì)非常長。

所以對(duì)于研發(fā)團(tuán)隊(duì)而言，持續(xù)部署流程所產(chǎn)生的反饋周期過長，不利于研發(fā)團(tuán)隊(duì)快速發(fā)現(xiàn)和解決問題。

1 基本CI流水線頻繁執(zhí)行，由代碼提交觸發(fā)，包含構(gòu)建，單元測試，集成測試，代碼靜態(tài)掃描，部分自動(dòng)化驗(yàn)收測試等（端到端運(yùn)行周期短）。

2 FOR TEAM：全量流水線每日定時(shí)多次觸發(fā)，包含構(gòu)建，單元測試，集成測試，代碼掃描，全量的自動(dòng)化驗(yàn)收測試，部署，部署冒煙測試等等（端到端運(yùn)行周期長）。

3 FOR QA：手動(dòng)指定版本部署，手動(dòng)觸發(fā)。

通過分層流水線，在滿足快速反饋的原則的同時(shí)，又能持續(xù)的對(duì)軟件進(jìn)行集成和測試。

 

 

同時(shí)在流水線當(dāng)中通過引入質(zhì)量門去控制代碼質(zhì)量，避免技術(shù)債務(wù)的積累。

當(dāng)然對(duì)于歷史遺留系統(tǒng)而言，通常會(huì)存在大量的歷史債務(wù)，這時(shí)候我們可以將當(dāng)前系統(tǒng)的代碼質(zhì)量作為基線標(biāo)準(zhǔn)，同時(shí)針對(duì)新增代碼設(shè)置質(zhì)量門控制，包括新增代碼的代碼風(fēng)格，復(fù)雜度，測試覆蓋率等。

 

 

通過可視化流水線將將持續(xù)部署流水線的構(gòu)建過程向整個(gè)團(tuán)隊(duì)進(jìn)行展示，讓所有人都知道當(dāng)前的項(xiàng)目構(gòu)建狀態(tài)以及進(jìn)度，如果又構(gòu)建失敗了，成員之間也可以相互提醒盡快修復(fù)流水線的失敗。

 

 

持續(xù)的獲取過程有效性數(shù)據(jù)和質(zhì)量有效性數(shù)據(jù)為團(tuán)隊(duì)提供可視化看板。

 

 

除了門禁機(jī)制以外，質(zhì)量內(nèi)建也是團(tuán)隊(duì)成功實(shí)施DevOps的關(guān)鍵因素，通過在軟件交付的各個(gè)階段建立自動(dòng)化的保障體系可以使團(tuán)隊(duì)能夠盡早的發(fā)現(xiàn)和解決發(fā)現(xiàn)的缺陷。

 

 

對(duì)于度量驅(qū)動(dòng)的DevOps轉(zhuǎn)型，通過自動(dòng)化部署流水線有效提高軟件交付的效率，通過質(zhì)量內(nèi)建確保軟件交付的質(zhì)量，通過對(duì)過程性數(shù)據(jù)的持續(xù)收集和分析發(fā)現(xiàn)交付過程中存在的瓶頸，通過對(duì)軟件產(chǎn)品和用戶的線上數(shù)據(jù)獲取反饋并且及時(shí)作出調(diào)整，通過結(jié)果性數(shù)據(jù)去評(píng)價(jià)團(tuán)隊(duì)的成效。

 

 

最后對(duì)于企業(yè)DevOps轉(zhuǎn)型而言：

Automation 自動(dòng)化是實(shí)施DevOps轉(zhuǎn)型的先決條件，自動(dòng)化一切可以自動(dòng)化的，降低部署和發(fā)布的難度。

Measure 通過建立有效的監(jiān)控與度量手段來獲得反饋，推動(dòng)產(chǎn)品和團(tuán)隊(duì)的持續(xù)改進(jìn)，支持業(yè)務(wù)決策。

Lean 協(xié)作文化，自動(dòng)化，和有效的反饋，這些實(shí)施是個(gè)長期的過程，需要以精益的方式小步快跑，對(duì)過程與技術(shù)進(jìn)行持續(xù)改善。

Culture OKR目標(biāo)和關(guān)鍵成果驅(qū)動(dòng)?建立具有跨職能協(xié)作文化和共同目標(biāo)的一體化團(tuán)隊(duì)；這是DevOps運(yùn)動(dòng)的根本！

Sharing 不同職能、不同產(chǎn)品之間分享開發(fā)和運(yùn)維過程中的想法，知識(shí)，問題，以及失敗經(jīng)驗(yàn)，共同提升能力。

 

 

Q&A

 

Q：基于Jenkins的CI/CD不同用戶是怎么管理的?？權(quán)限怎么控制的？

A：在DevOps實(shí)施里面提倡充分授權(quán)團(tuán)隊(duì)，所以在基礎(chǔ)設(shè)施自服務(wù)的基礎(chǔ)上讓團(tuán)隊(duì)有自己獨(dú)占的Jenkins Master能夠有效的減少權(quán)限控制此類問題，同時(shí)可以避免不同團(tuán)隊(duì)之間構(gòu)建任務(wù)的相互影響；如果是共用JenkinsMaster，Jenkins有權(quán)限控制的插件可以控制用戶的權(quán)限。

Q：剛才你介紹的CI整個(gè)交付流程，每個(gè)細(xì)節(jié)都需要花大量的時(shí)間和精力去開發(fā)和實(shí)施，如果公司團(tuán)隊(duì)很多，如果分配自己團(tuán)隊(duì)的時(shí)間，時(shí)間少了自然達(dá)不到效果。

A：在實(shí)施DevOps轉(zhuǎn)型過程里面，可以先嘗試試點(diǎn)團(tuán)隊(duì)，通過試點(diǎn)團(tuán)隊(duì)去完成DevOps工具鏈相關(guān)的技術(shù)選型，在工具鏈成熟的情況下向其它團(tuán)隊(duì)推廣。

Q ：請(qǐng)問你們有DevOps的自動(dòng)化運(yùn)維平臺(tái)嗎？可能是一個(gè)Web頁面，把DevOps相關(guān)的流程和工具集成在上面，方便管理的同時(shí)也方便運(yùn)維開發(fā)一體化操作。這個(gè)平臺(tái)可能還包括全鏈路檢測系統(tǒng)？

A：目前我們公司做的基于容器持續(xù)交付平臺(tái)主要就是解決此類問題，通過流水線來組織工具鏈，同時(shí)對(duì)相關(guān)的環(huán)節(jié)進(jìn)行度量，為避免廣告嫌疑就不便多說。

Q：?你們?cè)谶@個(gè)過程中怎么做溝通管理，以防止因?yàn)檫@造成的對(duì)需求理解的偏差等問題？

A：這塊更多是團(tuán)隊(duì)的組織結(jié)構(gòu)的問題，有興趣可以嘗試通過看板方法，團(tuán)隊(duì)的各個(gè)角色都會(huì)基于看板完成迭代的開發(fā)，通過看板可以幫助團(tuán)隊(duì)成員之間的溝通和需求確認(rèn)。

Q：因?yàn)楹芎唵?，持續(xù)集成持續(xù)交付，快速迭代，小步快跑，穩(wěn)扎穩(wěn)打，這些都有所有的理論最后都回歸到代碼，所有的變更都回歸到本源代碼的變更，如何保障所有的變更無遺漏，如何保證每一次任務(wù)都在正確的代碼基準(zhǔn)線上進(jìn)行，如何出了問題快速反饋到研發(fā)第一線，及時(shí)終止問題的蔓延？

A：這塊其實(shí)主要的方式就是基于持續(xù)部署流水線的方式，上面分享的時(shí)候有提到。通過將流水線通過自動(dòng)化流水線的方式進(jìn)行控制，在任何階段出現(xiàn)問題都應(yīng)該讓流水線失?。ㄩT禁），另外出問題不怕，快速解決問題是關(guān)鍵，對(duì)于流水線最好可以設(shè)置Webhook實(shí)時(shí)觸發(fā)，可以確保當(dāng)問題出現(xiàn)后，問題代碼的域可以關(guān)聯(lián)到最近的一次提交。

Q：請(qǐng)問你們?nèi)萜靼l(fā)布是如何自動(dòng)區(qū)分開發(fā)、測試、正式等不同環(huán)境的，是否需要人工介入修改應(yīng)用訪問關(guān)系和啟動(dòng)環(huán)境變量？

A：目前我們自己持續(xù)交付平臺(tái)對(duì)接不同的容器運(yùn)行環(huán)境（目前主要是Rancher），團(tuán)隊(duì)會(huì)對(duì)環(huán)境進(jìn)行分類管理，流水線中進(jìn)行容器部署的時(shí)候選擇相應(yīng)的環(huán)境即可；另外由于主要是基于容器在做，所以也對(duì)容器鏡像的不同狀態(tài)也進(jìn)行了劃分，并且在多個(gè)Registry實(shí)例之間進(jìn)行了流轉(zhuǎn)，物理隔離了開發(fā)，測試以及發(fā)布狀態(tài)的容器鏡像。人工介入的部分主要是控制鏡像狀態(tài)的變化這塊。

Q：Jenkins的Pipeline和普通的Project都可以支持流水線?，2者有區(qū)別嗎？

A：主要解決的問題就是當(dāng)構(gòu)建出問題的時(shí)候如何快速定位問題，假如在流水線線中涉及8個(gè)階段，如果只是在一個(gè)Project中實(shí)現(xiàn)，需要開發(fā)者花很多時(shí)間定位；如果是Build Pipeline的話，則可以很直觀的知道問題是發(fā)生在什么階段。